Это ни в коем случае не исчерпывающий список, это скорее моя субъективная вершина после нескольких лет работы в ИТ. Надеюсь, вы найдете некоторые из них полезными

Русская версия статьи доступна по следующей ссылке

Спасибо, Гена!

1. Правило бойскаутов

«Всегда оставляйте палаточный лагерь чище, чем вы его нашли» - отличное правило. Когда вы находитесь рядом с палаточным лагерем, вы должны сделать его чище, даже если это не вы сделали беспорядок. Это одно из правил разведчиков. То же самое относится и к программированию. Как перефразировал Роберт С. Мартин: «Оставьте свой код лучше, чем вы его нашли». Если нам трудно прочитать часть приложения, написанного кем-то другим, и мы потратили некоторое время на ее понимание, давайте сделаем ее хотя бы немного лучше. Если это выходит за рамки задачи, над которой мы работаем, всегда можно создать новую небольшую техническую задачу, хорошо ее описать и перенести на следующий спринт.

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

2. Думайте о проблеме, а не только о ее решении.

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

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

  1. Создайте постоянное хранилище для тележек покупок пользователей.
  2. Пользователи должны иметь возможность сохранять свои тележки для покупок и использовать их в мобильных и веб-приложениях.

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

3. Подумайте о совокупной стоимости владения

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

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

Всегда лучше сделать это правильно с первого раза

4. Используйте SOLID

В программировании существует множество замечательных правил в виде аббревиатур: DRY, KISS, YAGNI, SOLID и многие другие. SOLID - это набор правил, которые должны помочь сделать код более чистым и избежать распространенных ловушек.

Это может быть отличным контрольным списком для вашего кода, прежде чем помещать его в репозиторий. Поддерживает ли этот класс принцип единой ответственности? Можно ли заменить этот класс другим из той же иерархии (выполняется ли LSP)? Это поможет отфильтровать множество источников будущих проблем. Понимание и сознательное применение причин, лежащих в основе каждого правила, сделает вас лучшим программистом и повысит качество проверки кода.

5. Используйте шаблоны проектирования

В большинстве случаев вы не первый, кто пытается решить возникшую проблему или реализовать функцию с аналогичными требованиями. Существовали тысячи CRM, CMS, банковских систем, чатов, интернет-магазинов, торговых площадок и практически любых возможных типов приложений, которые только можно придумать. Система, которую вы разрабатываете, может быть лучшей на рынке или обладать некоторыми чрезвычайно продвинутыми и уникальными функциями, которых нет ни у кого другого. Тем не менее, большинство вакансий в той или иной степени будут ссылочными. Кто-то другой может попытаться сделать это разными способами и даже описать весь процесс. Это избавит вас от лишних хлопот и поможет найти лучшее решение.

Есть отличная книга «Банды четырех», в которой представлены некоторые повторяющиеся паттерны, которые можно использовать для решения общих проблем. Он был написан в 1994 году, но они все еще актуальны и полезны. В программном обеспечении это давние времена, но почему-то проблемы, с которыми мы сталкиваемся при написании кода, теперь не сильно отличаются. С тех пор было разработано много новых шаблонов проектирования. Их знание может значительно облегчить вашу работу.

Весь дизайн переработан. Учитесь на опыте других

6. Минимизируйте сложность

Разработка программного обеспечения по своей природе является сложной задачей. Не усложняйте это более чем необходимо. Иногда очень соблазнительно реализовать некоторые бизнес-правила, добавив в функцию несколько дополнительных «если» или циклов. Разработка будет быстрее, но код станет темнее, а добавление новых функций только усложнит его. Если что-то пойдет не так, просто будет сложнее выяснить причину.

Есть отличная и очень простая метрика с загадочным названием «Цикломатическая сложность». Он был представлен в 70-х годах, но до сих пор может быть очень полезным. Этот показатель измеряет несколько способов выполнения вашего кода. Каждый условный оператор и цикл добавляет +1 к счету. Чем меньше балл, тем лучше. Когда мы анализируем метод, и оценка находится в диапазоне:

  • 0–10: код хорошо структурирован и не должен вызывать неожиданных проблем.
  • 10–20: код довольно сложен и имеет множество потенциальных путей выполнения для тестирования. Кандидат на рефакторинг
  • 20–50: код крайне сложен и требует рефакторинга.
  • 50+: рефакторинг - необходимость

Читаемость важнее производительности. У этого утверждения есть некоторые ограничения, но в основном удобочитаемость окупается в долгосрочной перспективе. Вы можете изменить свой код с меньшим количеством ошибок. Микрооптимизация может легко испортить ваш код и не принести пользы пользователям.

7. Не делайте этого в одиночку

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

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

8. Обязательны тесты.

Выявление ошибок на раннем этапе чрезвычайно важно и позволяет сэкономить силы и избежать гневных звонков со стороны клиентов. Раннее обнаружение проблем облегчает их решение. Мы можем лучше всего запомнить все детали и логику конкретного приложения, когда мы его разрабатываем. Мы помним все причины для принятия конкретного решения и способы отладки каждой части приложения. Стоимость исправления ошибок со временем растет в геометрической прогрессии.

9. Учите английский

Обмен знаниями всегда был одной из основ сообщества разработчиков программного обеспечения. Большая часть информации написана на английском языке и легко доступна. Сейчас это самый популярный язык в мире программного обеспечения. Если вы не умеете читать и писать по-английски, вам будет намного труднее и вы потеряете много возможностей. Более того, синтаксис почти каждого языка по умолчанию написан на английском языке.

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

10. Многозадачность делает вас глупым.

Люди просто не могут хорошо делать сразу несколько вещей. Разработка программного обеспечения требует использования абстрактных концепций и часто построения довольно сложных ментальных моделей. Если вы отвлекаетесь или начинаете работать над чем-то другим, вы теряете все это, и вам придется начинать с самого начала. Более того, существует множество исследований, которые доказали, что многозадачность отрицательно влияет на производительность, продуктивность и IQ.

Однажды я посетил тренинг в компании по разработке программного обеспечения, который познакомил меня с очень полезной практикой. Если у вас нет запланированных встреч или звонков, вы можете играть в «Помидор». Правила очень просты - вам не нужно ни с кем разговаривать. Если кто-то задаст вам какой-либо вопрос, вы отвечаете одним словом: «помидор». Таким образом, вы показываете, что находитесь в процессе работы и не хотите, чтобы вас беспокоили. Когда люди находятся в «режиме помидора», они также указывают это в своих календарях на выбранные часы. Не всегда хорошо ехать полностью «помидором», но это интересный способ улучшить результативность.

11. Лучше меньше, но лучше

Чем меньше кода и инфраструктуры нужно поддерживать, тем лучше. Есть много людей, которым нравится хвастаться огромным количеством строк кода в своем приложении, количеством модулей, серверов, узлов, подов, микросервисов или любых других вещей. Есть шанс, что каждая строчка кода в их приложении имеет высочайшее качество и находится в нужном месте. Но это очень редкий случай. Если вы можете выполнить ту же работу с использованием меньшего количества ресурсов, вам следует пойти на это. Качество - это цель, а не количество.

Ресурс: