Отсутствие кода — лучший код

Лучший код тот, который никогда не был написан. В нем нет ошибок, он не нуждается в обслуживании, проверке кода, тестировании, просто ничего. Он не может сломать существующий код и не сломается при обновлении программного обеспечения. Идеально. Всякий раз, когда вы можете убедить своего менеджера, что код не нужен — делайте это. Фича не нужна с большой вероятностью. Более того — удаляйте ненужный код: мёртвый код, закомментированный код, неиспользуемые фичи, глючные или вечно игнорируемые юнит-тесты. Чем меньше кода — тем лучше. Нет кода лучше.

Если вам нужен код, постарайтесь его не писать

Узнайте, был ли код уже написан для вас. Он может быть в вашей кодовой базе, но может быть и в другой библиотеке.
Не попадайтесь в ловушку синдрома Изобретено не здесь. Если вам нужно создать библиотеку обработки http или даты, подумайте дважды — возможно, кто-то уже написал ее. Потратьте некоторое время на изучение библиотеки, а затем просто используйте ее. Есть плохие библиотеки, но большинство из них достаточно хороши. Если это библиотека с открытым исходным кодом и в ней нет функции, которую вы хотели бы иметь — внесите свой вклад, это все равно будет быстрее, чем писать все с нуля. Все равно лучше не напишешь с большой долей вероятности.

Не пишите код, который никто не просил

Если вы говорите А что, если мне это понадобится позже, то позже вы это напишете. Но, скорее всего, вам это не понадобится.

Нет необходимости в Позолоте. Время дорого, не тратьте его на ненужные функции.

Не оптимизируйте несуществующие проблемы с производительностью. Преждевременная оптимизация — корень всех зол. Если вы не знаете, в чем проблема, вы можете сделать еще хуже.

Пишите столько, сколько вам нужно, но не более того

Если вам все еще нужно писать код, Не усложняйте, глупец. Если ваша работа должна выполняться каждую ночь — сделайте задание cron. Не делайте его настраиваемым с помощью файла свойств или переменной среды. Не развертывайте отдельный сервер, не создавайте БД для хранения в ней конфигурации, не создавайте конечные точки REST и SOAP для изменения конфигурации, не создавайте GUI с авторизацией и аутентификацией с разными разрешениями для разных пользователей , что подразумевает еще одно хранилище для идентификации пользователя и еще один графический интерфейс для управления ими. Не попадайтесь в ловушку создания внутренней платформы и не пишите фреймворк для обработки разных видов заданий в разные промежутки времени, если вам нужно запустить только это одно задание. Cron работы достаточно.

Сущности не должны умножаться сверх необходимости.

Не переписывайте рабочий код

Если работает, не трогай. И помните — один из самых больших грехов — это полный рерайт.

Не все задачи должны быть сложными

Если задача кажется слишком утомительной, возможно, есть более простой способ. Узнайте — это может сэкономить вам массу времени. Если вам нужно написать одно и то же заявление тысячу раз, возможно, вам не нужно копировать-вставлять. Вы можете спросить кого-нибудь, и они расскажут вам о петлях. Просить людей о помощи — это не признак слабости, это признак мудрости.

Но если задача настолько сложна, что вы не можете ее выполнить, возможно, она невозможна в текущих условиях. Узнайте ограничения — и тогда, возможно, вам не придется писать код.

Если это не невозможно, но все же слишком сложно — поговорите с бизнесом. У них свои представления о соотношении финансов и возможностей, может эта функция им не подходит. Они могут сказать, что эта функция была просто приятной и ее можно пропустить. И вам не придется писать никакого кода.

Не стремитесь к совершенству

Идеальный код может устареть к тому времени, когда вы его закончите. Лучше сделано, чем идеально. Чем хуже, тем лучше.

Не тратьте слишком много времени на размышления. Если дело не в архитектуре и есть вроде бы похожие подходы, библиотеки, технологии, форматы, инструменты, каждый со своими плюсами и минусами, просто берите любой. Вы можете провести рефакторинг позже.

Поисковик — ваш друг

Если не можете найти решение самостоятельно, ищите его. В школе это назвали бы списыванием. На работе это нормально. Вам не нужно изобретать решения, если они уже имеются в наличии.

Автоматизируйте все

Многие ваши действия можно автоматизировать с помощью скриптов. Пусть скрипты сделают всю работу за вас. Написание части кода также может быть автоматизировано. Так что пусть инструменты сделают всю работу за вас. Знайте, что они могут сделать. Используйте редактор по вашему выбору — он может содержать функции для создания и управления кодом, чтобы вам не приходилось делать это самостоятельно. Инструменты генерации кода существуют.

Не спешите

Поспешишь - людей насмешишь. Это относится и к коду. Если вы пишете код на скорую руку, вы вводите больше ошибок, вы затрудняете его чтение, и позже вы потратите больше времени на исправление ошибок и попытки понять, что вы там написали, чем если бы вы писали это спокойно с самого начала.

Манифест ленивого разработчика на github: https://github.com/navpil/lazy-developer-manifesto