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

Оптимизация против читабельности. К черту оптимизацию

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

Сначала архитектура

Я встречал много людей, говоривших: “Нужно сдать этот проект как можно быстрее, на архитектуру времени нет!”. И 99% из них сами выкопали себе яму.

Писать код, не думая об архитектуре заранее – все равно, что хотеть чего-то без плана дальнейших действий.

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

Тестирование

Тесты – отличная штука, но не в каждом проекте они имеют смысл.

Тесты нужны, если:

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

Тесты НЕ нужны, если:

  • у вас стартап;
  • вы работаете в маленькой команде и код меняется очень быстро;
  • вы пишете скрипты, которые можно легко протестить опытным путем перед выпуском в работу.

И помните, код с плохо написанным тестом может принести намного больше вреда, нежели код вообще без тестов.

Keep It Simple, Stupid (делайте вещи проще)

Не нужно писать сложный код. Чем проще решение, тем меньше ошибок в итоге и легче их выловить. Код должен делать только то, что необходимо, без тонн абстракций и прочего ООП-мусора (особенно это касается java-разработчиков) + 20% того, что может понадобиться в скором будущем при обновлении.

Комментарии

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

Сильное сцепление или слабая связанность?

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

Просмотр кода (code review)

Может служить как на стороне добра, так и зла.

Код ревью имеет смысл если у вас есть разработчик, который понимает 95% всего кода и который может быстро и легко отслеживать все изменения. Иначе это будет потеря времени, которую все ненавидят.

Эта часть всегда вызывает гору вопросов, поэтому опишу подробнее, что я имею в виду.

Многие считают, что код ревью – это отличный способ объяснить новым сотрудникам как работает та или иная часть проекта. Но не стоит забывать, что главная цель просмотра не обучение, а улучшение качества. Представьте себе, что ваша команда занимается разработкой кода управления системой охлаждения ядерного реактора или ракетным двигателем. И где-то закралась ужасная ошибка в логике, и вы даете этот участок новичку для изучения. Как вы думаете, какова вероятность аварии? Поверьте моему опыту – более 70%.

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

Рефакторинг не работает

Как много раз я слышал: “Не переживай, мы исправим это в будущем”. Все, что ждет вас в будущем – это неисполненное обещание или новый код, который напишут, удалив все старые решения.

Поэтому, если у вас нет денег, чтобы начинать разработку несколько раз с нуля, не надо ничего откладывать на завтра.

Не пишите код уставшим или в плохом настроении

Уставший разработчик делает в 5 раз больше ошибок, нежели отдохнувший и полный энергии. Так что больше работать – плохая практика. Вот почему все больше и больше стран задумываются о 6-часовом рабочем дне. Работать головой – это вам не мешки ворочать.

Не делайте все разом – используйте итерации

Прежде чем браться за работу, проанализируйте проект и попробуйте предсказать, что вашему клиенту необходимо больше всего, затем выделите ОВФ (Особо Важные Фичи), которые вы сможете реализовать с высоким качеством и за короткое время. Используйте итерации для обновления качества разработки, вместо того, чтобы тратить силы и время на бессмысленные “хотелки” во вред качеству и здравому смыслу.

Автоматизация или “ручная работа”

Процесс автоматизации

Автоматизация дает 100% выигрыш в долгосрочной перспективе. Так что, если у вас есть ресурсы для автоматизации чего бы то ни было, займитесь этим прямо сейчас. Вы можете подумать: “Ой, зачем, это же занимает всего 5 минут?”. Но давайте посчитаем. Предположим, что есть некая ежедневная задача, которую должен делать каждый из 5 разработчиков. 5 минут * 5 разработчиков * 21 день * 12 месяцев = 6300 минут = 105 часов = 13.125 дней ~ 5250$. А сколько это будет стоить, если в команде 40000 разработчиков?

Отвлекитесь, найдите себе хобби

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

Изучайте что-нибудь новенькое как только появляется свободная минута

Когда человек перестает учиться, он начинает деградировать.

А что делаете вы, чтобы улучшить качество своего кода?

Оригинал статьи

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Похожие записи

Для личинки веб-разработчика

Сборка Webpack 4 для чайников и сочувствующих

Продолжаю пытать себя и окружающих попытками разобраться в настройках Webpack 4. И в процессе нашла совершенно невероятный набор уроков, которые даже мне помогли. Серьезно, абсолютное волшебство. Велкам: https://tocode.ru/curses/nastroika-webpack4/

Troubles Hunting

Использование инлайн SVG-спрайтов в WordPress теме

Недавно столкнулась с необходимостью добавить инлайн SVG-спрайт в тему WordPress. И вот, пожалуйста, перевод чудесного пособия о том, как просто это сделать.

Для личинки веб-разработчика

Как научиться чему угодно: 10-шаговая система Джона Сонмеза

Умение учиться – так же известное как “мета-обучение” – один из наиболее полезных навыков из всех, что вы можете приобрести. И до сих пор практически никто не знает как это сделать. Почему это так важно? Подробнее…

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: