Написать этот пост меня побудила статья "В чем конечная цель программирования?" и её обсуждение в комментах. Я поставил свой плюс за статью сразу же, как прочитал первое предложение:
В том, чтобы иметь код, который легко изменять.
Ведь это же очевидно любому, кто попрограммировал достаточно долго, чтобы столкнуться с необходимостью изменять свой собственный код через какое-то достаточно продолжительное время (более полугода от момента завершения проекта). Про чужой код я не говорю, потому что его, в массе своей, изначально пишут "криворукие ваш-любимый-эпитет" и нужно потратить кучу времени хотя бы для того, чтобы понять, что он делает, а чтобы что-то в нём изменить и не порушить всё остальное, времени нужно потратить в разы больше.
Но статья с таким очевидным (ну, лично для меня) выводом имеет, по состоянию на сегодня, оценку "-5" ("8" - в плюс, "13" - в минус). Под катом мои размышления о возможных причинах этого.
По итогу дискуссий в комментах с коллегами @hlogeon и @saboteur_kiev (спасибо им за подачи с их стороны) у меня перед глазами в конце-концов появилась известная всем "пирамида Маслоу":
В основании пирамиды лежат базовые потребности, а всякие "излишества" располагаются на верхних уровнях. Потребность в них начинает проявляться только после удовлетворения базовых.
Если представить цели программирования в виде подобной пирамиды то я бы расположил их в таком порядке (от базовых и к "излишествам"):
Write
Конечная цель программирования - сам текст программы. Это настолько очевидно, что перестаёт восприниматься как конечная цель уже после второй-третьей самостоятельно написанной программы.
Compile
Конечная цель программирования - создание компилируемой программы. Для программистов на интерпретируемых языках можно считать целью создание такой программы, каждая строка которой не вызывала бы ошибок, связанных с интерпретацией кода. Кстати, современные IDE очень сильно помогают в создании "компилируемых" программ.
Run
Конечная цель программирования - создание работающей программы. Бывают случаи, когда код успешно компилируется, но программа вылетает сразу же после запуска. Или не сразу же - вылетает при определённых условиях. Деление на ноль, переполнение стека, undefined и прочее - все эти вещи делают невозможным использование программы, даже если она написана и компилируется (или IDE не обнаруживает в ней ошибок).
Business
Конечная цель программирования - создание программы, решающей некоторую бизнес-задачу. Действительно, с точки зрения капиталистического общества нет смысла платить деньги за бесполезные программы, пусть даже они успешно компилируются и работают без ошибок.
Update: если вам не нравится программирование за деньги, считайте, что программа должна решать некоторую общественно (на край - персонально) значимую проблему.
Read
Конечная цель программирования - создание программы, которую удобно читать. "Код пишется один раз, а читается много раз" - я как-то сразу забыл упомянуть этот пункт, добавляю сейчас. Такое требование к коду появляется в тот момент, когда программа перестаёт быть детищем одного автора.
Test
Конечная цель программирования - создание тестируемой программы. Не каждому проекту может понадобиться этот уровень. Но когда проект нуждается в тестировании, то это накладывает свой отпечаток на стиль написания кода (TDD, инъекция зависимостей и т.п.). Как правило, это проекты с большой кодовой базой и большой текучкой в команде.
Modify
Конечная цель программирования - создание легко изменяемой программы. Эти проекты, как правило, с продолжительным сроком жизни (свыше месяцев) и итерационным подходом к разработке (можно сразу же выкинуть из этого списка лендинги для сельских магазинов, но оставить в нём движок для создания этих самых лендингов).
Итого
Таким образом пирамида "главных целей" программирования может выглядеть так:
Я уверен, что можно ещё надстроить уровней "главных целей", но я со своим опытом могу видеть только эти. Кто-то другой может найти ещё цели, которые начинают проявляться после достижения здесь описанных.
Уровень цели не означает её "весомости" - понятно, что если программа не решает какую-либо бизнес-задачу, то всем, кроме её создателя, глубоко фиолетово насколько хорошо она компилируется или тестируется. Уровень говорит лишь о том, что нет смысла достигать текущей цели, если не достигнуты низлежащие. Т.е. нет смысла реализовывать бизнес-логику в неработающей программе - сначала нужно добиться того, чтобы она работала. Нет смысла делать тестируемой программу, которая не решает бизнес-задачи, как и нет смысла беспокоиться о модифицируемости кода, непокрытого тестами.
На мой взгляд, конечных целей в программировании много. Они, как матрёшки, вложены друг в друга. Что конкретный программист в конкретном проекте принимает за конечную цель зависит как от опыта самого программиста, так и от проекта. В некоторых проектах действительно нет смысла подниматься выше бизнес-целей.
Ну, а коллегу @undeadlol1 зря заминусили, как по мне.
P.S.
Добавил пункт Read.
Комментарии (33)
Batalmv
08.10.2023 16:51+10Если бы авторы статей с минусами попробовали подумать, а почему так, то наверное они смогди бы написать статью, которую бы плюсовали
Но, совершенно случайно и необьяснимо один и те де "идеи" заслуженно минусятся
Про "легкость изменения кода" - это просто одно из многих нефункциональных требований, которые могут ввдвигаться, а могу и нет
И да, хорошо спроектированный код обычно легче править, это "бонус"
danilovmy
08.10.2023 16:51+2Я вижу эту статью, как не совсем корректное применение идеи Абрахама Маслоу к коммерческому программированию. Почему не совсем корректное - потому, что в изначальной идее фундаментом являются безусловные предпосылки личности каждого. В идее статьи смешались бизнес задачи владельца бизнеса и его безусловные стремления и задачи программиста, и не важно, если это одна и та же персона.
Но не суть. Если допустить таки идею, что идея пирамиды потребностей применима, то становится понятно, что закладывал автор:
В Пирамиде Маслоу есть несколько уровней и, казалось бы, обеспечил себя жратвой и потомством, и остановись, но нет - сытому и размножившемуся индивиду надо уже развитие и признание.
Так и в идее статьи автор, предположительно, хочет добавить другие потребности, какие должны быть удовлетворены, после удовлетворения потребностей бизнеса.
И именно тут и кроется нестыковка. Задачи бизнеса достигнуты - остановись. Это бизнес проект а не личность. Но нет, давайте добавим тестирование и простой саппорт, как надстройку к потребностям. Хотя на самом деле - эти задачи тоже должны быть задачами бизнеса, поскольку, как и было разумно отмечено в комментариях, не каждому бизнесу это надо. Например, я пишу MVP для проверки бизнес идеи. Прошло плохо - убил проект. Не рефакторнул, а просто отказался! О тестах и улучшении речи даже не идёт. Только так и работает в бизнесе, а в применении к личностям подобный подход, минимум, аморален. Хотя бы поэтому идея с потребностями не сработает в коммерческом программировании.Batalmv
08.10.2023 16:51Ну наверно, просто есть ощущение, что автор еще толком не оказывался в мире, где есть ТЗ, definition of done, таски :)
Если же говорить о программировании не за деньги ... вообще логично применять те же принципы, что и в коммерческом, если интересует результат
flancer Автор
08.10.2023 16:51IMHO, это всё относится к пункту Business. Всё, что вы перечислили (ТЗ, definition of done, таски) нацелено на создание кода, решающего определённую задачу.
Batalmv
08.10.2023 16:51В реальной жизни все остальное находится за пределами круга интересов программиста. Исключение - фрилансеры, которые все делают в одном лице.
Но тогда все еще проще. Есть проект создания программного продукта и некий цикл с артефактами. Условно:
идея
PoC
бюджетирование/планирование
получение финансов и ресурсов
написание требований
написание ТЗ
разработка
тестирование
пилот
допиливание
выход на рынок
Понятно этапы могут быть различными а может набежать 100500 знатоков методологий и прочего, но суть не в этом. Зачем натягивать заведемо иную концепцию, которая именно пирамида или матрешка, на известную всем процедуру разработки продукта?
Никакой матрешки в процессе создания продукта нет, это последовательно-итеративный процесс, о чем вам расскажет любой менеджер/продуктовик.
Основная же "идея" пирадимы Маслоу - мотивация человека в конкретный момент времени и пояснение, почему и как это происходит для разных людей.
Просто ... я могу еще объяснить все эти изыскания просто, но в чем-то обидно для программистов. Процесс создания продукта долог и участие программиста в нем не так велико, как ему кажется. Да, он делает абсолютно НЕОБХОДИМУЮ вещь, но с точки зрения timeline его участие довольно таки невелико. Вместо того, чтобы "философствовать" на тему, достаточно просто понять, что ты просто ВАЖНЫЙ участник сравнительно небольшого участка большого дела. И если хочешь понять, как и что - меняй роль и иди, в менеджеры/продуктовики, которые проходят весь путь от начала и до конца.
Но можно пытаться строить из себя мудреца, который пытается по капле узнать о существовании океана, если океан недалеко и до него можно дотопать ножками и посмотреть
flancer Автор
08.10.2023 16:51Абсолютно с вами согласен, что точка зрения любого менеджера/продуктовика не должна совпадать с точкой зрения программиста. Но и наоборот тоже верно. Эта статья про написание кода, а не про разработку продукта. Для программистов, а не для менеджеров/продуктовиков. Но спасибо, что поделились своим мнением.
Wrench_IT
08.10.2023 16:51+11Как по мне, статью заминусили по двум причинам. Первая — грубейшая логическая ошибка в первой же строчке, что, очевидно, не понравится аудитории IT-ресурса. Что есть программирование? Процесс создания компьютерной программы. Что есть компьютерная программа? Совокупность инструкций и данных, на основе которых аппаратное обеспечение выполняет требуемые действия. Таким образом конечная (то есть, основная, конкретизированная и измеримая) цель программирования — создание компьютерной программы, а не что-то другое.
Код может быть отвратительно спроектирован и плохо поддаваться дальнейшему обслуживанию, но при этом работать и выполнять действия, которые и должен был в соответствии с ожидаемым результатом, а значит, конечная цель была достигнута. Или же наоборот, все может быть написано "по феншую", но при этом программа будет выполнять совсем не те действия, которые от нее ожидались, или же не все из них, то есть, будет незавершенной, а значит, конечная цель в данном случае достигнута не была. Вот если бы автор начал с чего-то вроде: "Чем принципиально отличается хорошая архитектура от плохой?", а далее развил мысль про изменяемость кода, минусов было бы гораздо меньше.
Но они бы все равно были, поскольку автор что-то пытался сказать, но в итоге растекся мыслями по тексту. Много лирики и мало практики. Основная мысль в общем верна, но для опытного разработчика материал не имеет смысла, поскольку такой человек и так прекрасно знает, насколько важна простота сопровождения программы и к чему может привести фанатичное следование даже самым хорошим и правильным принципам проектирования, а для новичков там слишком мало фактического материала. Лонгрид для начинающих с большим количеством реальных кейсов обязательно бы собрал гору плюсов, как и статья про не самые очевидные ошибки проектирования с далеко идущими последствиями, ориентированная на матерых программистов. Полезные статьи сообщество любит и ценит.
xxxphilinxxx
08.10.2023 16:51+5Самое главное: прежде, чем спорить, неплохо бы договориться о терминах: что понимать под "конечной целью" и целью кого: заказчика, потребителя, программиста, мирового сообщества или кого-то еще. Цель - осознать, где и когда остановиться? Дойти до этой точки? А кто принимает решение? Или каким должен быть идеальный продукт в каждом конкретном случае? Разработка плана, как создавать идеальный продукт? Как перейти от зафиксированного продукта к процессу? Каким должен быть идеальный процесс разработки?
Конечная цель программирования - сам текст программы. Это настолько очевидно, что перестаёт восприниматься как конечная цель
Нередко оказывается, что пресловутая очевидность как раз мешает ясно взглянуть на что-то: мнение уже сформировано и не пересматривается.
Сначала по пирамидке: как у вас Business не оказался основанием? Уровень должен быть самодостаточным, т.е. иметь ценность без верхних, иначе это просто цепочка промежуточных этапов. Нельзя ведь начинать писать код, если не сформулированы хоть какие-то требования? Значит, ниже надо положить постановку задачи. Постановка задачи тоже в свою очередь чем-то будет заблокирована: например, бюджетом и подбором персонала, и так далее. А просто написанный, но неиспользуемый код сам по себе не имеет ценности, только потенциал.
Теперь по сути: имхо в вашей пирамидке не хватает настоящего основания: цели создания конкретной программы. Не универсальной цели, а конкретной для отдельно взятого случая. Посмотрим на примерах.
Для первого варианта положим в основу банальную практику. Хочу, скажем, IDE-шку получше изучить, библиотеку или язык. Для такого проекта у меня будет только Write в ваших терминах: мне даже критические ошибки в этом коде необязательно исправлять, это просто черновик. Никаких compile, run, bisuness, test, modify тут не будет. Да, write тут станет ценным уровнем, хотя выше я утверждал обратное, но только из-за специальной цели всего действа.
Возьмем прикладную утилитку личного пользования, а то и одноразовую. Ее уже надо собрать, запустить, но test, modify, business не будет. Возьмем инди-игрушку: тесты могут быть, могут нет, зато появляются производительность и бизнес. Построитель отчетов для внутренннего пользователя компании: тесты обязательны, это важная информация, зато производительность может быть выкинута, как и легкая модификация. Фреймворк: тесты, производительность, читаемость, документация, но может не быть business и легкой модификации. Ключевой сервис компании: тесты, легкая модификация, производительность. Открытое ПО - необходим выстроенный и поддерживаемый процесс коллективного принятия решений и внесения изменений; кстати, тут появляется "процесс" помимо продукта и исходника.
Возьмем любой программный компонент: при наличии доступного уже готового софта выкидываем (!) write, compile, даже run в случае стороннего сервиса. Можно утратить исходники и остаться с бережно отныне хранимым бинарником, который будет годами успешно работать, процеденты такие есть. А то и вовсе все сделают другим способом - механикой, электрикой вместо электроники или еще как-то. Задача решается без написания единой строчки кода, почти что идеал; круче только удалением.
Для специальных случаев добавим всякие интересные условия типа работы в масштабе миллиардов пользователей, в realtime, в жестких ограничениях по CPU/RAM/IO или обязательного использования особенностей конкретного железа, без которых все опять-таки не будет иметь никакого смысла.
Легко заметить, что ни один из ваших пунктов не оказался сразу во всех перечисленных сценариях - правда, занятно? Кстати, производительность и читаемость/поддерживаемость обычно являются взаимоисключающими, их вместе не запихнешь. Получается, что универсальной схемы развития идеального программного продукта попросту не существует, есть лишь цели на конкретные случаи со своими функциональными и нефункциональными требованиями к готовому продукту, исходникам и рабочим процессам. Как только все требования легли в основание, можно поверх что-то строить, но не линейное, а очевидно (хехе) многовекторное, больше похожее на розу ветров. А раз уникальное и многовекторное - значит, единой цели не может быть.
P.S. есть интересные эксперименты (например, Вселенная-25), косвенно связанные с пирамидой Маслоу, показывающие-таки наличие ее верхней границы.
Tiriet
08.10.2023 16:51+2эээх. Сам Маслоу никакой пирамиды не рисовал. Он написал, что есть потребности физиологии, которые будучи неудовлетворенными- перебивают вообще все остальные вопросы мотивации. А после удовлетворения этих физиологических потребностей есть целый ряд других потребностей, которые вроде как упорядочены по иерархии, но эта иерархия вообще никак не жесткая, из нее есть исключения и этих исключений- много (http://psychclassics.yorku.ca/Maslow/motivation.htm, Part 3)! А потом уже какие-то ушлые дизайнеры понарисовали красивых пирамид, приплели к этому Маслоу, который сам в шоке от того, чего из него сделали и носятся с этой пирамидой, как с догмой, пихая ее куда надо, и куда не надо.
Вселенная-25 с пирамидой Маслоу связана оооочень косвенно- через потребность в признании у авторов Вселенной-25 :-). Потому как крысы- это животные, как это ни странно- чистоплотные! А вольерчик во Вселенной-25 чистили раз в две недели! то есть, крысам там жестко прищемили базовую потребность в комфорте. И температурка там прямо скажем, была некомфортная- лето было, жара, а ни кондеев, ни обдува не предусмотрено было в экспериментальном ангаре. Кроме того, организация жилых отсеков- звезда звезд, предполагала возможность контроля одной особью целого общежития, то есть, молодые самки физически были лишены возможности доступа к изолированным норкам- на входе на этаж сидела жирная старуха, в результате получилась смешная ситуация- крысам закрыли потребность в еде и напрягли по всем остальным возможным пунктам их не самой простой организации жизни. А вот в популярной литературе расписали это как будто организовали им там рай райский, а они в нем жить не захотели. Им организовали гетто-коммуналку в сортире, совмещенном со столовой на 500 рыл, с жарой и общими корридорами в качестве бонуса (линк на техническое описание эксперимента я щас не найду, но для любознательного читателя комментов, думаю, не потребуется много времени чтобы перепроверить мои слова), там не потолок пирамиды Маслоу достигался, а дно днищенское этой пирамиды.
funca
08.10.2023 16:51+2Думаю, что у каждого своё понимание зачем он программирует. Соседство Run и Business в статье скорее всего говорит об изначально рациональных мотивах автора. Это достойно уважения на самом деле.
Для меня программирование это игра. Как играть на гитаре, например, или в шахматы. На кухне, в парке, в пабе - какая разница? Это не спорт и не бизнес. Критерии оценки результата в первую очередь основаны на внутреннем ощущении удовольствия, красоты и достаточности (здесь я говорю о личных мотивах, а не формальных quality attributes, которые зависят от целей конкретного проекта). На работе я это делаю за деньги, решая бизнес задачи, чтобы кормить свою семью и давать возможность колллегам делать то же самое. Но по большому счету эта суета тут за скобками.
SquareRootOfZero
08.10.2023 16:51+3Я, возможно, не понял, что хотел сказать автор, но, на мой взгляд, автор зря делает две вещи:
- Смешивает между собой понятия "цели" в смысле "цели решения задачи, бизнеса, удовлетворения потребности, каковую должен удовлетворить создаваемый программный продукт" и в смысле "цели программиста по приближению технического уровня исполнения программного продукта к уровню гипотетически идеальному". Эти две цели не просто зачастую плохо сочетаются, а то и противоречат друг другу — каждая из них сама многокомпонентна, и компоненты эти, зачастую, сами плохо между собой сочетаются, а то и противоречат друг другу. Цель бизнеса может вполне удовлетворительно для бизнеса решать едва скрипящий MVP, на код которого без слёз не взглянешь. И, напротив, технически отлично исполненный продукт может решать её хуже или вовсе не решать.
- Пытается всю эту сложную мешанину свести в единую пирамиду строгой иерархии — там не будет пирамидальной иерархии, а будет — если будет — что-то вроде диады "инь-ян", только не с двумя элементами, а с парой десятков входящих в противоречия друг с другом элементов, для которых, под каждый случай, надо находить свой уникальный баланс (как в известном примере: "эту задачу можно решить быстро, дёшево и качественно — выберите любые два пункта", только сложнее гораздо).
- Вкорячивает туда пункт "чтоб обязательно за деньги". Совершенно параллельный момент, программирование, за которое не платят, от этого не перестаёт ни существовать, ни быть программированием.
Вотъ. Вот эти вот три пункта испанской инквизиции, на мой взгляд, автор делает совершенно зря.
MaxKitsch
08.10.2023 16:51+2Цель программирования — создавать ПО, удовлетворяющее потребностям пользователя. Всё остальное — средства достижения этой цели.
gmtd
08.10.2023 16:51+2Я бы выделил два основных фактора/цели/причины:
1. Бизнес потребности
2. Творчество
Иногда они пересекаются
Всё остальное - средства достижения целей
profFortran
08.10.2023 16:51+2Хватит искать смысл и цель там, где их нет. Просто пишем код, получаем зарплату.
Zara6502
08.10.2023 16:51В том, чтобы иметь код, который легко изменять
Идеализация - высшая форма глупости.
У программирования, как у любого другого процесса чисто утилитарные свойства, как у молотка - забивать гвозди. Несомненно есть люди, которые покупают себе очень дорогой молоток, забивают очень специальные гвозди и так, чтобы, тот кто их захочет вырывать - делал это с комфортом.
Но вы в своей практике в 90% случаев сталкиваетесь с тем, что до вас никто так не делал и то что именно вы так будете делать - ровным счётом ничего не изменит, вы просто будете всегда тратить много времени и сил на лишнюю работу.
Поэтому я бы сказал что программирование:
1) Для души
2) Для заработка
Кто-то умеет это совмещать (не я точно), но я только для души пишу и очень давно. Уверен что 90% программистов делают это ради заработка. И какая разница что там потом будет после вас?
ForSokolov
08.10.2023 16:51+4Задача программиста — намагнитить быстро вращающуюся металлическую пластину в нужных местах. (с) народное творчество
Araki_Satoshi
08.10.2023 16:51Не вижу смысла углубляться так далеко. Моё мнение - цель лишь в выполнении прикладной задачи, которую поставил программист. Разумеется, задача меняется от проекта к проекту.
А кода без задачи быть не может. Даже если человек просто тренируется, а не пишет что-то определенное, то тогда задачей этого кода будет практика программирования его автора.
qw1
08.10.2023 16:51+1Не увидел ту первую статью, когда она вышла, и прочитал только сейчас.
Больше всего места в ней занимает разбор примера реализации требований отображения 3 элементов списка вместо 1. И автор советует не вводить параметр, а просто захардкодить число 3 где-то в коде.
С этим я не согласен. А если завтра скажут — 4?
Где гарантии, что эта тройка в коде встречается ровно 1 раз? Придётся заново вычитывать код, проверять все подозрительные тройки, и соседние с ней числа, например, в конструкциях типаif (list.Count > 2)Это повторное выполнение работы, которая уже сделана. Лучше сразу сделать хорошо, выделив эту тройку в параметр. А что касается тестов? Кто заставляет писать их на все варианты параметра, в том числе отрицательные? Пишите на кейс, который сейчас нужен — для n=3. При необходимости, тесты можно потом дописать.
domix32
08.10.2023 16:51+1Получилась пирамида для китайской комнаты - нет постановки задачи, нет алгоритма, нет требований. И всё это должно было быть на этапе до написания каких-то символов в какой-то блокнотик.
gun_dose
08.10.2023 16:51+1У вас в рассуждениях фундаментальная ошибка в самом начале. Вы задаётесь вопросом "какая цель?", а в итоге большую часть статьи рассуждаете не о цели, а о средствах её достижения. Цель программирования - программа. А код - это средство достижения цели. К примеру, вот такая программа может полностью удовлетворять всем критериям из вашей пирамиды, но при этом является абсолютно бессмысленной:
if (FALSE) { // Миллион строк легкоподдерживаемого и удобно-расширяемого кода }flancer Автор
08.10.2023 16:51Какова бизнес-задача, решаемая этой программой?
gun_dose
08.10.2023 16:51Бизнес-задача может решаться вне блока if. Но при этом внутри недосягаемого блока может быть какая-то сложная логика, задействующая много разных классов, объединённых какими-то паттернами, да ещё и покрытых юнит-тестами. Факт запуска юнит-теста при этом закрывает ярус Run из вашей пирамиды. То есть программа по факту работает, и код в ней крутой, но ненужный.
И кстати есть ещё один очень важный критерий любого кода - ресурсоёмкость. Почему-то об этом очень часто забывают. До недавнего времени было принято считать, что в случае серверных приложений выгоднее нанять более дешёвых разработчиков, но арендовать более дорогой сервер, но в последнее время всё чаще бизнес стал понимать, что выгоднее один раз заплатить программисту условно на 5000$ больше, чтобы в будущем экономить 200$ в месяц на инфраструктуре
flancer Автор
08.10.2023 16:51Что-то я вас не понимаю. Цели закрываются по иерархии: Write -> Compile -> Run -> Business -> ... Приведённый вами фрагмент кода сваливается уже на уровне Business - он не решает никакой задачи. Все остальные, вышестоящие, цели в иерархии просто теряют смысл.
Вы можете спокойно выкинуть код под
if(FALSE) {...}. А можете не выкидывать и так пытаться понять, что я имел в виду под иерархией целей. Но это будет сложнее и тут я вам, пожалуй, не помощник. Я тоже тут теряюсь.gun_dose
08.10.2023 16:51Я привёл этот пример только за тем, чтобы показать, что решение бизнес-задачи - это и есть единственная конечная цель программирования, а все остальные ярусы пирамиды ну никак не могут являться конечными целями ни в каком понимании.
Тем не менее, в вашей пирамиде есть одна интересная закономерность. Под ярусом Business у вас перечислены необходимые технические критерии, а над ярусом - экономические. Ненаписанная, не скомпилированная или не запускаемая программа по определению не может выполнить задачу. А вот плохо читаемая, плохо тестируемая и трудно модифицируемая программа с задачей может справляться хорошо, но быстро станет для бизнеса невыгодной.
Glumist
08.10.2023 16:51Вполне возможно, что этот блок был полезен, но задачи бизнеса поменялись и, чтоб совсем его не удалять, оставили так. А завтра бизнес может попросить этот блок вернуть.
bloomdido
08.10.2023 16:51Вашу мысль правильней изображать не в виде пирамиды, а в виде вложенных одна в другую петель обратной связи, каждая из которых может "вернуть" код на доработку. Написали строчку - увидели что строчка слишком длинная - исправили, увидели что компилятор ругается - исправили, тест не прошел - исправили, зарелизили, всем понравилось - всем захотелось миллион новых фич - исправили и т.д.
Так вот, если вы надеетесь, что ваша программа станет успешной, то нужно быть готовым, что к вам придут просить миллион новых фич, и с большой вероятностью "проблема Возняка с лимитом 2к на размер" из комментов здесь будет наименьшей проблемой из тех, что у вас будут, вам ради новых фич с радостью докинут и 2к места, и 222к если надо будет.
thegriglat
08.10.2023 16:51Согласно дяде Мартину (книга Совершенный код), основная задача программирования это **управление сложностью**.
Как реального мира (упрощая взаимодействие с ним и изменение оного), так и собственно программных продуктов
vadimr
Области применения и типы программ бывают разные, поэтому общего подхода нет.
Если, например, вы, как Возняк, имеете целью уместить программу-монитор в 2 килобайта ПЗУ Apple II, то простота модификации вообще не принимается во внимание.