Начиная новый проект, хорошо вспомнить полезные принципы программирования, которые помогут правильно расставить приоритеты и избежать многих ошибок. Рекомендациями от автора с опытом программирования в 20 лет делимся к старту курса по Fullstack-разработке на Python.
Официально я программирую с 1999 года. Начинал с Basic, вскоре перешёл на Pascal и C, а затем изучил объектно-ориентированное программирование на Delphi и C++. В 2006 году стал работать с Java, а в 2011-м — с JavaScript. Сотрудничал с компаниями из самых разных сфер — от робототехники, финансов и медицины до медиа и телекома.
Иногда я становился исследователем, техническим директором или менеджером продукта, преподавателем, разработчиком системной архитектуры или техническим руководителем проекта, но всегда писал код.
Я работал и над продуктами, которыми пользовались миллионы людей, и над теми, что терпели неудачу ещё до выпуска. Я работал консультантом и даже основал свой стартап. Я потратил много времени на проекты с открытым, закрытым кодом, а также внутренние Open Source проекты, то есть проекты с проприетарным кодом, который разрабатывается сообществом внутри компании.
Я работал над крошечными микроконтроллерами, мобильными и настольными приложениями, облачными серверами, а в последнее время — бессерверными технологиями. К двадцатилетию карьеры я составил список главных принципов, которыми руководствовался все эти годы:
Не боритесь с инструментами: библиотеками, языком, платформой и т. д. Используйте как можно более нативные конструкции. Не перегибайте с технологией и с задачей. Выберите подходящий инструмент для задачи, или придётся найти подходящую задачу для того инструмента, что есть.
Вы пишете код не для компьютера, а для своих коллег и для себя в будущем, если только это не пробный проект или ассемблер. Пишите его как руководство для младших коллег.
Любой значимый, ценный программный компонент — это результат совместной работы. Взаимодействуйте эффективно, сотрудничайте открыто. Доверяйте другим и добивайтесь доверия от них. Уважайте людей больше, чем код. Вдохновляйте своим примером последователей, превращая их в лидеров.
Следуйте принципу «разделяй и властвуй». Пишите изолированные модули с отдельными, слабо связанными задачами. Тестируйте каждую часть отдельно и все вместе. Проводите тесты в условиях, приближенных к реальности, но тестируйте и пограничные случаи.
Не задирайте нос и не считайте себя главным специалистом по коду. Оптимизируйте его так, чтобы другие могли найти свой способ исправить баги и добавить функционал. Освободитесь от кода, чтобы перейти к следующему проекту или компании. Не присваивайте код себе, иначе вы никогда из него не выберетесь.
Есть несколько уровней безопасности: каждый нужно оценивать индивидуально, а также по отношению к безопасности в целом. Риск — это бизнес-решение, напрямую связанное с уязвимостью и вероятностью событий. У каждого продукта/организации свой уровень риска, на который в организации готовы пойти ради ещё большей выгоды. Пользовательский интерфейс, безопасность, производительность — эти три задачи часто противопоставляются.
У всего кода есть жизненный цикл. Иногда код умирает в зачаточном состоянии, ещё до производственной среды. Умейте отпустить. Различаются четыре категории функционала, в которые нужно вкладывать время и силы.
Основа. Это как движок автомобиля. Без неё продукт не имеет смысла.
Необходимая часть. Похожа на запаску: редко используется, но определяет успех системы, когда требуется.
Дополнительные возможности. Это как подстаканник: ну есть и есть, хотя продукт вполне можно использовать и без него.
Уникальные свойства: почему стоит купить продукт у вас, а не у ваших конкурентов. Например, ваш автомобиль — лучший внедорожник.Не отождествляйте себя со своим кодом. И вообще не отождествляйте код с его автором. Поймите, что люди отделены от производимых ими артефактов. Не принимайте критику кода на свой счёт и будьте очень осторожны, критикуя чужой код.
Технические недоработки — это как фастфуд. Иногда допустимо, но, если к ним привыкнуть, они убьют продукт очень быстро и болезненно.
Определяясь с решением, при прочих равных условиях выбирайте такую приоритетность: безопасность > надёжность > практичность (доступность и пользовательское взаимодействие) > удобство сопровождения > простота (процесс разработки / впечатления от разработки) > лаконичность кода > финансы > производительность. Но не стоит слепо ей следовать: приоритетность зависит от характера продукта. Чем больше у вас опыта, тем скорее вы сможете найти правильный баланс для каждой конкретной ситуации. Например, при разработке игрового движка главный приоритет — производительность, но при создании банковского приложения — безопасность.
Баги размножаются копипастой. Всегда читайте то, что копируете, и всегда проверяйте, что импортируете. Баги любят сложность. Магия хороша в зависимостях, а не в коде.
Не пишите код только для хорошего сценария. Пишите сообщения об ошибках, где есть ответы на вопросы о том, почему они произошли, как были обнаружены и что можно сделать для их устранения. Проверяйте весь системный ввод (в том числе пользовательский): ранний сбой, но с восстановлением после ошибок, когда это возможно. Представьте себе опасного пользователя: вы приложите все силы, чтобы избежать проблем с ним!
Используйте зависимости, только когда они удовлетворяют требованиям и затраты на импорт, сопровождение, устранение пограничных случаев / багов и рефакторинг у них значительно меньше, чем у вашего кода.
Сторонитесь разработки, вокруг которой поднят ажиотаж. Но учитесь всему, чему можно научиться. У вас всегда должен быть ваш проект.
Выйдите из зоны комфорта. Учитесь каждый день. Учите других тому, чему научились. Изучайте другие языки, технологии, культуру и оставайтесь любознательными.
Хорошему коду документация не нужна, а отличный код хорошо документирован: любой, кто не участвовал в развитии и изменении кода методом проб и ошибок, а также требований, которые привели к его текущему состоянию, может продуктивно с ним работать. Недокументированный — значит несуществующий функционал. У такого функционала кода быть не должно.
Максимально избегайте переопределений, наследований и неявных трюков, демонстрирующих ваш ум. Пишите чистые функции, их проще объяснить. Любая функция, которая не является чистой, должна быть классом. Любая конструкция кода, имеющая другую задачу, должна отличаться именем.
Никогда не начинайте писать код (создавать решение), если не полностью понимаете задачу. Вполне нормально на её уяснение тратить больше времени, чем на ввод кода. Разберитесь в предметной области, затем приступайте к написанию кода. Задача подобна лабиринту: чтобы дойти до конца, нужно последовательно пройти цикл «код — тестирование — улучшение» и изучить пространство предметной области.
Не решайте проблему, которой не существует. Не занимайтесь спекулятивным программированием. Пишите код с возможностью расширения, только когда есть подтверждённое предположение, что он будет расширен. Ко времени расширения постановка задачи, скорее всего, будет другая.
Не усложняйте: занимайтесь текущей задачей и поиском эффективного решения с эффективной реализацией.
Разрабатывать ПО интереснее вместе. Создайте жизнеспособное сообщество. Слушайте. Вдохновляйте. Учитесь. Обменивайтесь опытом.
Я не претендую на то, чтобы считаться авторитетом в разработке ПО — всего лишь поделился своим опытом. Уверен, что через 20 лет этот список пополнится.
А пока автор дополняет список, мы поможем вам прокачать скиллы или с самого начала освоить профессию, актуальное в любое время:
Выбрать другую востребованную профессию:
Краткий каталог курсов и профессий
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также
Комментарии (67)
fforthuser
11.04.2022 00:33-2Хоошие принципы и достаточно универсально могут быть понимаемы в сравнении с личным опытом конкретного разработчика безотносительно стека используемых технологий.
brain_tyrin
11.04.2022 00:33+3Интересный 18 пункт. Понятно, что на уяснение задачи можно тратить больше времени, чем на ввод кода. Но для меня это скорее выливалось в идею, что можно начинать вводить код, пилить прототипы (в том числе когда задача - впилить кусок в монолит), таким образом пробуя идеи. Опять же личное впечатление: "проектирование на бумаге" не дает такого понимания нюансов и возможных проблем, как попытка написать код.
Если автор под задачей имеет ввиду написание целой системы, то конечно да, тут он прав
DrPass
11.04.2022 01:29+2Кстати, да. По моему опыту, писать код и продумывать задачу — это параллельные процессы. Мне в сто раз удобнее итеративно менять/расширять код по мере того, как идея становится чётче и детальнее, чем пытаться сначала всё в деталях представить в уме, а потом уже это запрограммировать.
lovermann
11.04.2022 01:48Ну, в больших проектах это может и не прокатить.
DrPass
11.04.2022 01:52+1Почему? Это ещё надо постараться придумать такой проект, в котором архитектура, я даже не знаю как это сказать, какая-то вот этакая, что сразу не очевидно, какой она в укрупнённом виде должна быть, без тщательного и усидчивого планирования.
beerchaser
11.04.2022 09:25+2имхо, 18 пункт должен быть первым. никогда не садись за кодирование, пока нет понимания, что будет считаться решением поставленной задачи. к этому пункту относится правило преждевременной оптимизации и правило моратория на дополнительный функционал до получения продакшен-версии. 16 пункт — смеялся… через полгода вне контекста задачи даже в собственном коде задается вопрос о кролике, который его писал.
DrPass
11.04.2022 09:33никогда не садись за кодирование, пока нет понимания, что будет считаться решением поставленной задачи
Как раз это обычно написано в ТЗ :)beerchaser
11.04.2022 10:31-1В тз обычно написано «за все хорошее и против всего плохого...». в ирл по результатам тз создается (или не создается, ибо нужно трясти, и тогда это остается в рабочем блокнотике) и, по возможности, согласуется рабочая документация, в которой, как правило, и описывается: что, зачем и почему. и пока фаза создания/согласования именно рабочего задания/документации не пройдена, за код лучше не садится. иными словами: пока вы не сможете объяснить другим, что именно вы хотите сделать, писать код вы не должны.
funca
11.04.2022 09:36+1никогда не садись за кодирование, пока нет понимания, что будет считаться решением поставленной задачи
Вот что получится, то и будет считаться за решение, а с остальным разберемся потом - по мере поступления багов).
KvanTTT
11.04.2022 12:29Если это какой-то исследовательский проект, что-то типа мозгового штурма или слишком творческая задача, то правило не работает. Даже если это обычный проект, нередко случаются ситуации, когда разработчики отклоняются от первоначальной идеи, уходят в побочные, реализация которых может стать удачней основной.
Правило лучше всего подходит к багам, а не к пространным идеям: есть ожидамое поведение, есть фактическое. Нужно сделать так, чтобы фактическое совпало с ожидаемым.
YDR
12.04.2022 11:16Никогда - слишком категорично. Иногда можно прикинуть, что вообще получается, и потом из этого сделать продукт.
beerchaser
12.04.2022 11:28если есть ресурсы (деньги, время, специалисты, etc.) чтобы прикинуть — это ниокр, а не производство :) и таки да, пробуются как правило пути решения, сама цель к этапу начала проб должна быть определена.
piratarusso
11.04.2022 15:02Представим себе ситуацию: вам выкатили требования, реализовать которые выбранным инструментом невозможно в рамках текущего прототипа. Представили? А теперь представьте, что почувствует кодер после нескольких подобных заходов. На начачльных этапах код лучше не писать вовсе.
DrPass
11.04.2022 15:09+1Представим себе ситуацию: вам выкатили требования, реализовать которые выбранным инструментом невозможно в рамках текущего прототипа. Представили?
Нет. 23 года стажа в отрасли, Delphi, веб, финтех, трейдинг, ERP. Реальную, а не совершенно надуманную ситуацию, где такое произойдёт, не представляю. Разве что вы сами себе её искусственно сотворите, выбрав для прототипирования какой-то экзотический фреймворк, который в принципе мало что позволяет реализовать.piratarusso
11.04.2022 15:44-1И у вас за все 23 года не было ошибок?
DrPass
11.04.2022 18:27+1Таких, что получил ТЗ, выбрал инструмент, начал работу, а потом заказчик внёс изменения, и оказалось, что инструмент теперь не подходит? Нет, и я даже не слышал про такие случаи ни у кого. Гипотетически такая ситуация, конечно, может иметь место, но это явно не тот риск, который нужно закладывать в свою стратегию.
Ну хотя насчёт «нет», я чуть покривил душой, один раз был, в 2000 году. Когда заказчик попросил сайт и CMS под него (хотя такого слова тогда не было, но это сейчас называется CMS). Поскольку в 2000 году я был махровым джуном, и не знал ничего, кроме Delphi (да и Delphi так себе), я уточнил у заказчика, какие у них операционные системы. Заказчик сказал, что всё Windows, я облегчённо вздохнул, и написал CMS на том, что умел — на Delphi, соответственно, под IIS. Всё работало (к моему личному удивлению), всем всё понравилось, я получил свои деньги, а на следующей неделе контора объединилась с другой, и её ИТ-отдел напрочь отказался поднимать сервер под IIS, потому что винда-маздай, а линукс рулез. И то, проблему они решили, по-царски: выгрузили все HTML-ресурсы сайта в статические файлы, и потом правили их руками без CMS :)
Но это, скажем так, тот самый исключительный случай.
funca
11.04.2022 02:30+2Пишите чистые функции, их проще объяснить. Любая функция, которая не является чистой, должна быть классом.
Добавили в функцию логирование и теперь пол проекта переписывать на классы?
Возможно имелся ввиду какой-то конкретный случай, когда рекомендуется использовать классы. Интересно какой?
adal
11.04.2022 04:01+1Так в том и прикол не нужно там логирования. Пишите его в миддлварях, обзерверах ну или во враппере на худой конец. Типа single responsibility principle все дела..)
BugM
11.04.2022 04:38+3В теории оно конечно хорошо и правильно. А на практике вставить навсегда log.warning(...) в самые недра своего приложения иногда хочется. И это правда полезно и помогает в дебаге потом.
У любых правил должны быть исключения. Логи это исключение и расходимся.
Логи естественно асинхронные и неблокирующие. Мы закладываемся на то что в случае факапа одним из сайд эффектов которого была генерация огромного количества логов мы часть логов потеряем. Такие баги надо чинить ASAP. Есть хорошая вероятность того что сохранение всех логов не стоит тех расходов которые они несут.
0xd34df00d
11.04.2022 05:54+2Асинхронные неблокирующие логи с гарантией сохранения при падении всего приложения — это очень дёшево и вопрос одного memcpy на каждое сообщение.
funca
11.04.2022 09:04это очень дёшево и вопрос одного memcpy
Это в смысле как: дёшево/быстро/качественно - выберите любые два?)
Если вдуматься, логи нужны не для того, чтобы их писать, а чтобы - потреблять. И тут многое зависит от характеристик потребителя. Если он не успевает принимать ваши сообщения с той скоростью, с которой их пишет приложение, то теперь это ваша с ним общая проблема. Добавляя в решение асинхронщину, очереди и пытаясь заикнуться о гарантиях доставки получаем в плечи классический набор научных проблем из теории массового обслуживания.
Неспроста же 12factors заявили, десять вместо того чтобы пытаться решить нерешаемое - не майтесь дурью и пишите свои логи в stdout/stderr (синхронно, как же ещё больше), а там пусть разбираются.
0xd34df00d
11.04.2022 09:23+3Не слышал про 12factors, но в кое-каком коде, над которым я работал (что-то там про трейдинг и высокие частоты), мы
mmapили файл с логами и дописывали туда тем самымmemcpy, что позволяло без особых проблем логгировать под терабайт данных вдень8 часов, включая что общение с биржей, что какую-то внутреннюю кухню. Там, конечно, есть некоторые тонкости, в основном связанные с многопоточностью, но они не особо существенны — нужную для высоких частот скорость и нужную для аудита и разбора полетов надёжность (этим 12factors придется отдуваться перед не очень дружелюбными людьми из SEC, если что?) оно давало.А вот подход «выплевывайте синхронно в stdout, наверху разберутся» точно бы не сработал.
funca
11.04.2022 10:10+1мы mmap или файл с логами и дописывали туда тем самым memcpy
синхронно
А вот подход «выплевывайте синхронно в stdout, наверху разберутся» точно бы не сработал.
Почему? stdout это обычный дескриптор. Просто он стандартный и доступен автоматически. mmap/memcpy с ним вполне работают (как минимум в линуксах), если при запуске приложения перенаправлен в файл ./a.out > log.txt. С терминалом конечно же нет.
Технически суть оптимизации была в замене fwrite на memcpy?
0xd34df00d
11.04.2022 17:13синхронно
Синхронно выполняется только memcpy (ну и инкремент указателя), за очень несущественное по сравнению со средней записью в файл время. ОС изменённую страницу на диск сбросит потом и асинхронно.
Почему? stdout это обычный дескриптор. Просто он стандартный и доступен автоматически. mmap/memcpy с ним вполне работают (как минимум в линуксах), если при запуске приложения перенаправлен в файл ./a.out > log.txt
Потому что обычно под писаниной в
stdoutпонимают неmmapего куда-то.
Плюс, потому, что у вас тогда не получится из разных потоков иметь разные файлы с логами, чтобы поменьше заморачиваться с синхронизацией.Технически суть оптимизации была в замене fwrite на memcpy?
В некотором смысле — да.
BugM
11.04.2022 11:31+1Мы живем в мире контейнеров. И для гарантированного сохранения лог должен быть слит в какую-то внешнюю трубу. А она по определению ограниченного размера.
У вас было бизнес требование гарантированного сохранения логов. Я бы на вашем месте эту трубу сделал ну очень большую по гарантии. Видимо вы так и сделали. В обычных приложеньках делать такую гарантию на все логи всех приложений дорого. И приходится мириться с тем что часть логов может не доехать в каких-то случаях.
funca
11.04.2022 09:29У любых правил должны быть исключения. Логи это исключение и расходимся.
Чем логи принципиально отличаются от любого другого внешнего ресурса: файлов, базы данных, веб сервисов и т.п.?
edo1h
11.04.2022 10:56+4тем, что логирование в норме не влияет на поведение других программ?
абсолютно чистых функций быть не может, всегда есть побочные эффекты: тепловыделение процессора, попадание данных в кэш/вымывание других данных оттуда и т.п.
NikolayPyanikov
12.04.2022 09:27Логи нужны чаще всего в единственном случае - когда что то идёт не по плану поэтому их сохранение должно быть исключительно надежно. Их не должно быть много - для этого есть уровни логирования. Писать логи асинхронно имеет смысл когда код в котором они есть сам асинхронный и когда используются асинхронный подход при их записи, например асинхронный вызов для записи в файл. В тоже время, ассинхроность тут не означает параллельности.
BugM
12.04.2022 19:48Исключительно надежное сохранение это минимум две географически разнесенные точки и коммит только после подтверждения записи в обе. Вы точно так сохраняете логи? Остальное это компромиссы.
Важные бизнес данные сохраняются именно так.
NikolayPyanikov
12.04.2022 21:23В придираетесь к словам. Держать в памяти процесса информацию о событии, которое возможно завершит ваш процесс быстро, но не совсем корректно - как минимум не логично. И эта потерянная информация - возможно единственная ниточка что бы понять, что произошло. Нет большого смысла держать эту информацию в памяти процесса и записывать логи параллельно, оптимизация и так работает на уровне кэшей OS (и с этим возможно придется что-то делать) и железа (наверно тут поможет только надежное энерго снабжение). Имеет смысл писать логи асинхронно - это да, а параллельность обеспечится контроллером диска.
BugM
12.04.2022 23:09Думайте об этом процессе как о eventually consistent которое нарушается в случае какого-то факапа с генерацией неразумного объема логов.
В нормальном или около нормальном состоянии по количеству логов все работает почти синхронно. Потери логов не превышают одного сообщения при любом убийстве приложения. Что вообще нормально для любых адекватно надежных логов. Последнее сообщение при критической и вызывающей немедленную смерть приложения ошибке имеет право не записаться для любого типичного приложения.
Зато в случае когда ошибка вызывает ненормальную генерацию логов, допустим х100 от нормы, приложение будет работать дальше или упадет не от того что все потоки зависнут на попытке записать в лог. Это максимально разумное поведение при таких ошибках. И это дает возможность не считать запись в лог побочным эффектом. Удобно и нормально по гарантиям выходит.
Если у вас случай банковского приложения под аудитом когда нужны гарантии записи всего в лог это решение не подойдет, но честно говоря сколько таких приложений? В этом случае все логгирование уже не считается чистыми функциями, а должно рассматриваться как IO с потенциальным отказом.
NikolayPyanikov
12.04.2022 23:44Я не понимаю как запись в "других" потоках сделает ваше решение эффективнее по производительности, не говоря уже о надёжности и памяти? Если в "нормальном" состоянии вы не будете успевать записывать логи в файл, то через какое-то время упретесь в ограничение по памяти. Соответственно, количество затраченного времени на запись логов в файл должно быть меньше времени выполнения кода, который генерит эти логи. В этом же случае, используя асинхронную запись логов в файл драйвер вашего диска будет трансформировать эту операцию в последовательность команд, которые будут выполняется максимально эффективно для вашего физического устройства, используя его контроллер, кэш и прямой доступ к памяти, где хранятся ваши логи, не задействуя CPU, потоки вашего процесса и без переключения контекста выполнения (при нехватке ядер) . При всем при этом не будет расходоваться место в хипе вашего процесса для временного хранения вашего лога для записи его в отдельных потоках. Понятно что в некоторых случаях это не так, например игры, торговля на бирже роботами, где важна каждая наносекунда, но наверно там и логов много не будет, только исключительные ситуации, в которых можно и при тормозить на сотню наносекунд
BugM
13.04.2022 00:16У вас абстракции текут.
Как оно там пишется вот вообще не важно. Сколько на это тратится времени тоже не важно, пока это какое-то разумное время. Оптимизировать мы его не будем, доверимся типовой библиотечке для вашего языка и платформы. Эта библиотека точно достаточно хороша для любого разумного применения.
Из бизнес логики надо знать только одно: log.info(...) может вызвать IO с неизвестным временем выполнения или не может?
Если не может, значит это просто добавление в какую-то очередь в памяти которую кто-то другой скинет куда-то. Гарантии что все будет скинуто во внешнюю систему и сохранено нет. Но постараемся настроить все так что при нормальной работе все скидывается с минимальными задержками. И предусмотрим разумный запас на случай ошибок. Это назовем асинхронными логами.
Если может, значит это IO которое лимитировано чем-то и потенциально может выполняться любое произвольное время. Зато после возврата мы имеем гарантию что лог где-то во внешней системе которая сама отвечает за его сохранность. Это назовем синхронными логами.
bullitufa
11.04.2022 07:17А что насчёт "преждевременная оптимизация"?
И насчёт рефакторинга ни слова!
igrishaev
11.04.2022 11:04+4Без примеров эти тезисы не стоят и гроша.
eaa
11.04.2022 13:27+1Тем, кто дорос - норм, а остальные... ну надо расти еще, чтоб статьи научиться понимать, чтоб они на пользу шли
igrishaev
11.04.2022 13:30+2О как! Сатья без примеров, которую еще надо уметь понять... Может, автор не умеет хорошо излагать мысли? Допускаю, что программист он хороший. Но уж если взялся писать, то на каждый тезис нужно по два-три примера, а он поленился.
eaa
11.04.2022 13:42Любую статью надо понять и это тоже труд. Судя по комментам, многие поняли и без примеров. Еще по себе скажу, что моих примеров из моей жизни хватило, чтоб то, что написано, поименить к ним. Так что все-таки дело не в авторе, а в читателях. И да, не всякий автор подходит всякому читателю.
igrishaev
11.04.2022 13:45Первые два экрана комментариев хорошо показывают, как читателю поняли статью ("Делайте хорошо чтобы было хорошо" и ниже).
WASD1
11.04.2022 15:48+3Высказаны 3 блока мыслей:
1. Делайте хорошо.
2. Плохо не делайте.
3. Мой уникальный опыт, примите на веру.
По большому количеству вроде-бы интересных пунктов хотелось бы расшифровки.
Возьмём для примера:7. У всего кода есть жизненный цикл. Иногда код умирает в зачаточном
состоянии, ещё до производственной среды. Умейте отпустить. Различаются
четыре категории функционала, в которые нужно вкладывать время и силы.
Основа. Это как движок автомобиля. Без неё продукт не имеет смысла.
Необходимая часть. Похожа на запаску: редко используется, но определяет успех системы, когда требуется.
Дополнительные возможности. Это как подстаканник: ну есть и есть, хотя продукт вполне можно использовать и без него.
Уникальные свойства: почему стоит купить продукт у вас, а не у ваших конкурентов. Например, ваш автомобиль — лучший внедорожник.Хотелось бы, чтобы автор как-то прокомментировал к чему эта классификация, чему она помогает / где вредна (про моторы и подстаканники на тех.ресурсе - вопрос отдельный).
С ходу кажется, что она нужна для построения диаграмм Ганта на момент начала проекта (когда неопределённости много уровень абстракции высок и планирование - искусство "правильно предсказать" а не технология "сменеджерить"), но никаких подсказок в этом пункте не вижу.
sshikov
11.04.2022 19:28>Хотелось бы, чтобы автор как-то прокомментировал
Вы сейчас пытаетесь разговаривать с (гугло)переводчиком, у которого на 154 публикации 4 комментария.
xaosxaos2
11.04.2022 19:43+2Хорошему коду документация не нужна
Недокументированный — значит несуществующий функционал.
По-моему тут противоречие разве нет?
lxsmkv
11.04.2022 19:47+2Если бы опыт можно было передать в виде текста, то люди давно перестали бы учиться на своих ошибках. Парадокс засовывания пальцев в розетку. Сколько не говори, пока не долбанет - не усваивается. Человек не "специально" это делает. Он так устроен. Это часть алгоритма познания.
Так что, те, кто понимают упомянутые в статье принципы, пришли к ним на собственном опыте. А те кто не понимают - и не поймут. Не потому что они "тупые". А просто "приложить" этот совет не к чему.Поэтому я давно пришел к выводу, что можно подсказать когда у человека вопрос, обьяснить как подойти к задаче, если он не знает с чего начать, но никак не давать ему догмы или "серебрянные пули". Не зря ведь книги по самосовершенствованию всегда подкрепляют яркими жизненными примерами. Это нужно чтобы человеку было легче спроецировать совет на матрицу своего ситуативного опыта.
Так что статью можно было бы сократить до одного совета: "Набери 20 лет опыта". А так, без ситуативных примеров от этого сомнительная польза.
over_seer
12.04.2022 09:32+1Помню у нас в колледже статистики, экономики и информационных технологий, в туалете, была надпись: "Писать на стенах туалета, увы друзья не мудрено, среди говна мы все поэты, среди поэтов мы говно". Я тоже пишу промышленный код с 1999, но меня удивляют такие статьи. Я не понимаю, а куда делся здравый смысл инженера-программиста, и что за сервис, научить программировать за неделю. Куда делась высшая математика, алгебра, логика, статистка из программирования. С 99 года применялись ли правила к программам автора, такие как, рекурсия, рефлексия, полиморфизм, абстракция, фактические и формальные параметры и пр.. Даже, если, в новом мире, айти, это всего лишь продажная девка бизнеса, то никто и никогда не исключает инженерную культуру и здравый смысл инженера-программиста, основанного, в первую очередь, на науке. И вам этого желаю. ;)
botyaslonim
12.04.2022 11:28В целом хорошо, согласен, но вот такой пункт всегда удивлял:
"Выйдите из зоны комфорта. Учитесь каждый день. Учите других тому, чему научились."
Почему человек не должен чувствовать себя комфортно? Почему он должен учиться каждый день? Это же кратчайший путь к выгоранию
Enfriz
13.04.2022 15:4699 лет программирования. Вот мои принципы:
Вставайте утром с левой ноги, тогда код будет лучше.
Автоматическая клавиатура лучше, чем механическая.
В Half-Life 2 в главе на автомобиле, когда доедете до разрушенного моста, нужно нажать Shift, чтобы машина ускорилась, иначе не допрыгните. Ох, сколько попыток это мне стоило...
CrocodileRed
"Делайте хорошо чтобы было хорошо" ))
BugM
Делайте хорошо. Не делайте плохо.
randomsimplenumber
Плохо оно само получится ;)
Eugeny1987
для составления ТЗ клиентом тоже подойдет
newyorkin
Прочитал как "деплойте хорошее а плохое не деплойте"
MockBeard
Deloitte хорошо, а плохое не Deloitte?
Eugeny1987
ой, не знаю
brom_portret
"Делай хорошо — плохо само получится"
Francyz
Делайте как надо, а как не надо - не делайте.
Druj
Нормально делай — нормально будет