11 правил эффективного программирования
Перевод статьи Jakub Kapuscik “11 rules of effective programming”
1. Правило бойскаутов.
“Всегда оставляйте лагерь чище, чем он был до вас” — это отличнейшее правило, по которому стоит жить. Если вы нашли мусор на земле, вы убираете его, вне зависимости от того, кто его оставил. Это одно из правил скаутов. Тоже самое должно применяться и в программировании. Как перефразировал это правило Роберт С. Мартин: “Оставь свой код лучше, чем он был до тебя”. Если мы встретим какой-то трудный для чтения участок кода, написанный кем-то другим, и потратили время на его понимание, давайте сделаем его хотя бы немного лучше. Если это выходит за рамки задачи, над которой мы работаем, всегда можно создать новое техническое задание, хорошо его описать и перейти к следующему спринту.
Мы должны помнить, что кто-то когда-то возьмет на себя ту часть кода, который мы когда-то разработали, и попытается его изменить. Давайте хотя бы не будем усложнять их жизнь.
2. Думай о проблеме, не только о решении.
Разработчики программного обеспечения действительно хороши в том, как решить задачу. Мы знаем языки, шаблоны, библиотеки, фреймворки и понимаем, как их применять. Проблема в том, что часто вещи, которые мы делаем, не имеют смысла с точки зрения бизнеса. Некоторые фичи, которые вы разрабатываете, могут быть дублированием уже существующих, о чем заказчик мог и не знать. Некоторые фичи могут быть не продуманы, и они никогда не попадут в следующий релиз, или просто ни один пользователь никогда не воспользуется этой фичей. На это тратится много времени, денег и в итоге приводит к разочарованию. Многие не удосуживаются спросить разработчиков об их мнении. Они исходят из того, что работа разработчиков заключается в том, чтобы реализовывать функционал. Без обсуждений. Только техническая работа.
Программисты работают с приложением каждый день. Они знают каждую фичу, даже если ею никто и не пользовался. Иногда задача, которая с точки зрения бизнеса кажется легкой, при разработке занимает месяца работы. А те, которые кажутся практически нереализуемыми, на работу отнимают всего пару дней. Причина кроется в отсутствии связи между разработчиками и заказчиком. Существует огромная разница между этими двумя:
- Создать постоянное хранилище для покупательских корзин пользователей.
- Пользователи должны иметь возможность сохранять свои покупательские корзины и использовать их как в мобильных, так и веб-приложениях.
Первое — просто. Без вопросов. Второе — немного сложнее, так как заставляет вас задуматься. И именно вы можете предложить решение данной проблемы. Будет много вопросов о деталях, функциональных требованиях, оценках качества и т.д. Такое решение будет гораздо лучшим, т.к. здесь вы не просто исполнитель.
3. Думай об общей стоимости владения.
Иногда очень хочется срезать углы, оставить тесты на потом, сделать временное решение и пообещать исправить это позже. В большинстве случаев это никогда не произойдет, пока что-то не сломается. Появятся новые задачи, приоритеты, новый функционал для реализации, баги, которые нужно исправить. Проблема, с которой вы столкнетесь в будущем, заключается в том, что такая часть приложения вероятнее всего когда-то сломается. И тогда исправить будет намного труднее.
Общая стоимость владения фичей — это сумма денег и усилий, потраченных от начала разработки до ее внедрения и обслуживания, весь путь до окончания ее существования. Если вы урежете время на разработку, это станет самое дешевой частью. Вы сможете быстрее выпустить фичу, но вот обслуживание окажется большой головной болью, пользователи будут недовольны, и в целом все это встанет намного дороже, чем могло бы быть.
Всегда лучше сделать правильно с самого начала.
4. Применяй SOLID.
В программировании существует множество замечательных правил: DRY, KISS, YAGNI, SOLID и т.д. SOLID — это набор правил, которые должны помочь сделать код чище и избежать распространенных ошибок.
SOLID может стать отличным чек-листом перед отправкой вашего кода в репозиторий. Поддерживает ли этот класс принцип единственной ответственности? Может ли этот класс быть заменен любым родительским классом из той же иерархии (выполняется ли принцип подстановки Барбары Лисков)? Это поможет отсеять множество источников будущих проблем. Понимание причин, лежащих в основе каждого из правил, и осознанное их применение сделает вас как программиста лучше и повысит качество ревью вашего кода.
5. Применяй шаблоны проектирования.
В большинстве случаев вы не первый, кто пытается решить проблему, с которой вы столкнулись, или внедряете фичу со сходными требованиями. Существует тысячи CRM, CMS, банковских систем, чатов, интернет-магазинов, торговых площадок и т.д. Система, которую вы разрабатываете, может быть лучшей на рынке и обладать некоторыми чрезвычайно продвинутыми и уникальными функциями, которых нет у других. И тем не менее, большая часть работы будет в какой-то степени отсылкой к уже существующим решениям. Кто-то другой может попытаться сделать это разными способами и даже описать весь процесс. Это может избавить вас от многих хлопот и поможет найти более лучшее решение.
Есть отличная книга Банды Четверых, в которой представлены некоторые из повторяющихся шаблонов проектирования, которые можно применять для решения общих проблем. Она была написана в 1994 году, но эти шаблоны актуальны и полезны до сих пор. Для программирования это давний срок, но почему-то проблемы, с которыми мы сталкиваемся при написании кода, не сильно-то изменились. С тех пор было придумано много более новых шаблонов проектирования. Знание этих шаблонов может значительно облегчить вашу работу.
Весь дизайн — это редизайн. Учись на опыте других.
6. Своди сложность к минимуму.
Разработка программного обеспечения по своей природе задача сложная. И поэтому без должной необходимости не делайте ее еще сложнее. Иногда очень хочется реализовать некоторые бизнес-правила, введя несколько дополнительных “если” или циклов. Так быстрее, но код тогда станет темнее, а добавление нового функционала сделает его еще сложнее. И если что-то пойдет не так, выяснить причину будет трудно.
Есть одна очень простая метрика с загадочным названием “Cyclomatic Complexity”. Она была представлена еще в 70-х годах, но до сих пор не утратила свою полезность. Этот показатель измеряет количество ветвлений выполнения вашего кода. Каждый условный оператор или цикл добавляет +1 к общему баллу. Чем ниже оценка, тем лучше. Когда мы анализируем какой-то метод и оценка находится в диапазоне:
- 0–10: код хорошо структурирован и не должен вызывать неожиданных проблем;
- 10–20: код довольно сложный и имеет много потенциальных ветвлений выполнения, которые нужно протестировать. Это кандидат на рефакторинг;
- 20–50: код очень сложный и должен подвергнуться рефакторингу;
- 50+: рефакторинг обязателен.
Читаемость кода важнее производительности. С некоторой оговоркой по поводу этого утверждения, но в основном, читаемость кода окупается в долгосрочной перспективе. Тогда вы способны менять код с гораздо меньшим количеством внесенных ошибок. Микрооптимизация может легко превратить ваш код с хаос, и это не принесет особой пользы конечным пользователям.
7. Не решай задачи в одиночку.
Может показаться противоречивым, но программирование — это социальная деятельность. Эпоха программистов, запрятавшихся в темноте подвала, канула в лету. Обмен опытом и знаниями становится все более и более важным. В худшем случае ваш собеседник будет молчаливой резиновой уткой, но скорее всего вы получите ценную обратную связь. Кто-то может обнаружить проблему в вашем решении, о которой вы даже и не подозревали. Взгляд с другой точки зрения — отличный инструмент, и его очень легко получить.
Один человек не в ответе за участок кода в опубликованном релизе. Создавать новый функционал — это работа для команды, а не отдельного человека. Проверка кода, парное программирование, пул-реквесты — все это инструменты, которые забирают ответственность от отдельного человека и делегируют ее на команду людей с пересекающимися навыками. Ответственность за важную функцию, которая может повлиять на производительность всей компании в лучшую или худшую сторону, слишком велика для одного разработчика. Такое положение очень вредно для здоровья и никогда не должно происходить.
8. Тесты — обязательны.
Раннее обнаружение ошибок чрезвычайно важно. Оно экономит много усилий, а также ограждает от гневных звонков клиентов. Раннее обнаружение проблем облегчает их исправление. Во время разработки, когда мы находимся в контексте, нам легче помнить о деталях и логике конкретного участка кода. Мы помним все причины принятия того или иного решения по коду, и знаем как этот код отлаживать. С течением времени стоимость исправления ошибок растет экспоненциально.
9. Учи английский.
Обмен знаниями всегда был одной из основ сообщества программистов. Большая часть информации написана на английском языке, и поэтому на английском языке она более доступна. Это самый популярный язык в мире программного обеспечения. Если вы не умеет читать и писать по-английски, вам будет гораздо труднее, вы многое упустите. Более того, синтаксис почти каждого языка основан на английском.
Также хорошей практикой считается писать комментарии к коду на английском языке. Это делает код более согласованным с синтаксисом. Когда мы делимся кодом с коллегами, особенно из других стран, нет лучшего способа делать это на общепринятом английском языке.
10. Многозадачность снижает твою работоспособность.
Люди просто не способны выполнять несколько задач одновременно. Разработка программного обеспечения требует использования абстракций и зачастую построения довольно сложных моделей в уме. Если вы начинаете работать над чем-то другим, то ваше внимание отвлекается и чтобы вернуться к прежней задаче, вам придется снова вникать в задачу и начинать с самого начала. Более того, есть много исследований, которые доказывают, что многозадачность оказывает негативное влияние на эффективность, производительность и IQ.
11. Лучше меньше, но лучше.
Чем меньше кода и инфраструктуры нужно обслуживать, тем лучше. Есть много людей, кто любит похвастаться огромным количеством кода в своих проектах, количеством модулей, серверов, узлов, нод, микросервисов и т.д. И есть какая-то вероятность, что каждая строка кода находится в правильном месте и имеет наивысшее качество. Но такая вероятность крайне мала. Поэтому если вы можете сделать ту же самую работу меньшим количеством ресурсов, вы должны пойти на это. Помните, что главная цель — не количество, а качество.
Источники:
- “97 Things Every Programmer Should Know”, Kevlin Henney
- “Scrum : The Art of Doing Twice the Work in Half the Time”, Jeff Sutherland
- “Clean code”, Robert C. Martin
- “Design Patterns”, GoF
- https://stackoverflow.com/questions/9097987/calculation-of-cyclomatic-complexity
- https://martinfowler.com/bliki/OpportunisticRefactoring.html
- https://appliedpsychologydegree.usc.edu/blog/to-multitask-or-not-to-multitask/