Главный навык разработчика, который сделает ваш код лучше

Автор оригинала: Hüseyin Polat Yürük
  • Перевод


Предисловие переводчика: Прочитав эту статью, вы, возможно, удивитесь или даже разозлитесь. Да, мы тоже удивились: автор будто бы никогда не слышал про иерархию в команде, про постановку задач со статусом «сделать быстро и без рассуждений». Да, всё так, это немного странный текст. Действительно, автор предлагает программисту взять на себя роль системного архитектора — а зачем тогда нужен архитектор? Но все эти возражения не должны закрывать от вас главного — того, почему мы всё же взяли и перевели этот текст. Он ведь не про роли. Этот текст — про профессиональный подход и осознанность. Правда в том, что, пока вы просто «делаете что скажут», не задумываясь о смысле своих действий, вы никогда не станете большим программистом.

Сказать «нет» лишнему коду. Все, что вы должны сделать, — собрать вместе три буквы и произнести это слово. Давайте попробуем сделать это вместе: «Неееееет!»

Но погодите. Зачем мы это делаем? Ведь основная задача программиста — писать код. Но нужно ли писать любой код, который от вас требуют? Нет! «Понимание того, когда не стоит писать код, вероятно, важнейший скилл для программиста». The Art Of Readable Code.

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Skillbox рекомендует: Практический курс «Мобильный разработчик PRO».

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

На что закрывают глаза программисты?

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

Но есть проблема: что бы вы ни написали, это усложнит ваше ПО и, вероятно, добавит багов в будущем.

По словам Рича Скрента, код — наш враг. Вот что он пишет:
«Код плохой, потому что он начинает гнить и требует постоянного обслуживания. Добавление новых функций зачастую требует модификации старого кода. Чем он объемнее, тем выше вероятность появления ошибки и больше времени нужно на компиляцию. Больше времени требуется другому разработчику, чтобы разобраться. А если нужен рефакторинг, то обязательно найдутся фрагменты, которые стоит изменить. Объемный код зачастую означает снижение гибкости и функциональности проекта. Простое и элегантное решение работает быстрее, чем сложный код».

Как узнать, когда не стоит писать код?


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

Вы должны четко осознавать, что нужно вашему проекту, а что — нет.

В качестве примера можно привести приложение, которое решает всего одну задачу — управляет электронной почтой. Для этого введены две функции — отправка и получение писем. Не стоит ожидать, что почтовый менеджер станет одновременно и таск-менеджером.

Нужно твердо сказать «нет» предложениям добавить функции, которые не относятся к главной задаче приложения. Это именно тот момент, когда становится понятно, что дополнительный код не нужен.

Никогда не сбивайте фокус вашего приложения.

Всегда спрашивайте себя:

— Какая функция сейчас должна быть реализована?
— Какой код стоит написать?

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

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



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

По мере расширения приложения появляется все больше файлов с кодом. Они заполняют каталог, в каждом — сотни строк. Для того чтобы всё это организовать правильно, придется создавать дополнительные каталоги. При этом запоминать, какие функции за что отвечают и какие действия вызывают, становится все сложнее; ловля багов также требует больше времени. Усложняется и управление проектом, требуется уже не один, а несколько разработчиков, чтобы уследить за всем. Соответственно, растут затраты, как денежные, так и временные, тормозится процесс разработки.

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

Теперь приходится бороться за жизнь проекта. Почему?

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

Звучит как сценарий фильма ужасов, верно?

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

«Один из самых продуктивных моих дней — тот, когда я удалил 1000 строк кода».
— Кен Томпсон.

Научиться понимать, когда не нужно писать код, сложно. Но это необходимо.

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

Продолжайте творить, но знайте, когда нужно сказать «нет».

Skillbox рекомендует:

Skillbox
171,94
Онлайн-университет профессий будущего
Поделиться публикацией

Комментарии 11

    +1
    Как узнать, когда не стоит писать код?

    Проблема в том, что программисты зачастую преувеличивают количество функций, нужных их приложению. В результате многие участки кода остаются незавершенными или их никто не использует, а вот приложение они усложняют.
    Пришёл однажды программист на работу, думает давай-ка я новую фичу запилю, пусть пользователи порадуются.
    Правда в том, что, пока вы просто «делаете что скажут», не задумываясь о смысле своих действий, вы никогда не станете большим программистом.
    Это точно, не станете большим программистом — вы станите product-owner, даже архитектор не принимает решение нужна функция или нет, не его это дело.
      +6
      Статья сообщает о проблеме, но не предлагает решений. Никому не нравится нагромождение непонятного кода, а тема о чистоте и лаконичности, в общем понимании уже раскрыта. Как не писать код, если заказчик или рынок требует новый функционал? Отправить к конкурентам и оставить репозиторий в чистоте и красоте?
        +2
        Как не писать код, если заказчик или рынок требует новый функционал? Отправить к конкурентам и оставить репозиторий в чистоте и красоте?

        Да, примерно так и надо сделать :)
        https://habr.com/ru/company/liteorder/blog/289498/
        https://habr.com/ru/company/liteorder/blog/289976/

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

          Я помню давнюю историю ещё из моей жизни Windows-программистом. Когда нас попросили добавить «кнопочку с чекбоксиком» в трей. Проблема в том, что иконка в трее рисовалась драйвером (чтобы без прав администратора её нельзя было убрать), драйвер ничего не знал о приложении и добавление вылилось в несколько тысяч строк кода и две недели того, что сегодня называется рефакторингами.

          Когда, мы, гордые такие, это показали… заказчик на некоторое время потерял дар речи. Но не потому, что он «оценил» нашу «крутизну» — а от того, что он не оценил уровень идиотизма.

          Если отфильтровать мат, то речь звучала примерно как: «а сказать, что кнопку в этот #%$$&**% трей сложно добавить? и вместо двух недель работы двух человек выставить счёт за пять минут работы по добавлению ещё одного пункта в главное меню приложения?».

          Очень часто вы можете изменив мелкие детали задания упростить его в разы — но сигнал об этом должен идти снизу. Ни архитектор, ни, тем более, заказчик или рынок, не знают точно — что для вас сделать сложно, что просто.
          +2

          Похоже, что автор открыл для себя unix-way.

            +1
            Программирование — это искусство решения проблем.

            разве что для совсем новичков — для которых проблема даже загуглить функцию по изучаемому языку.
            Проблема нащупывается, формулируется и решается не программированием, а совсем другой мыслительной деятельностью. И только после того, как решение нащупано, выбрано, и сформулировано как задачи, начинается их программирование
              +3
              Странный подход, автор статьи когда нибудь работал в больших проектах? Ощущение что он пишет утилиты, а не продукт в условиях спроса, конкуренции и непрерывного развития
                0
                Вот как раз в условиях «спроса, конкуренции и непрерывного развития» — его советы куда важнее.

                Потому что если вы будете им следовать — у вас будут тысячи недовольных посетителей crbug.com, которая там будут оставлять гревные тирады.

                А вот если не будет — то ваш продукт вначале будут проклинать миллиарды, а потом он рухнет под собственной тяжестью. Вместе с crbug.com
                  0

                  При наличии на рынке конкурента с большим количеством функционала написать версию с сильно меньшим функционалом может быть более чем разумно. Особенно, если тот функционал, который вы всё-таки сделаете, будет сделан лучше.
                  Примеров не так мало. Jira и Trello. Photoshop и Sketch.

                  +1
                  1. Контекст оригинальной статьи соответствует самому низкому уровню зрелости, в её конце приходит понимание, что Автор оригинала обращается к совсем неопытному разработчику.
                  В этом случае, обращаясь к его целевой аудитории, добавлю: не самообучаетесь, не изучаете common-библиотек проекта, API языка разработки или сторонних эффективных для применения фреймворков, тогда, вряд ли Вам позволят долго учиться на своих ошибках, внедрять странную логику (быстро скажут: НЕТ, прощай! и, возможно, Вам удастся более осознанно определиться с выбором своей профессии).

                  2. К Переводчику (относительно предисловия к статье).
                  2.1
                  Действительно, автор предлагает программисту взять на себя роль системного архитектора
                  Где в тексте Автор оригинала незрелому разработчику вменяет роль Архитектора, тем более, системного?
                  2.2 В отличие от Вашего, моё мнение: Разработчику необходимо «делать что скажут» — типа правильные требования, и делать это правильно. В этом заключается профессиональный подход, а включать «осознанность» (по отношению к уместности реализации требования, не нарушающего законодательство, не несущего угрозы безопасности эксплуатации) Разработчику, не ведающему коммерческой стратегии Руководства или особенно планов и обстоятельств Заказчика, не имеет смысла.

                  Приведу пример исключительной ситуации (в эту «топку меня бросил» начальник, занимаясь более важной задачей): в моей практике был один случай визуального программирования вместе с Заказчиком — задача была срочная и сделана за 3 дня, решение работало и результат достиг цели, но его реализация выглядела ужасно (ничего не ломала). Затем его профессионально переделали 3 разработчика, включая меня, за неделю, но обновленное решение, как оказалось, было уже не нужно.

                  Резюмируя: все опасения Автора оригинальной статьи по поводу качества кода лечатся code-review, unit- и function- авто тестами, своевременным рефакторингом и документированием кода и сопровождением требований/спеки, а предупреждение подобных проблем возможно, если свои решения начинающий разработчик будет обязан предварительно согласовывать с ведущим разработчиком и придерживаться регламентированных правил кодирования и ведения проектов.
                    0
                    Обычно по первым абзацам понимаешь, насколько тебе ценен материал. Второй полностью обесценил всё то, что мог далее написать автор (или переводчик, тут не суть). Выделено мною:
                    собрать вместе три буквы и произнести это слово. Давайте попробуем сделать это вместе: «Неееееет!»

                    Ради красного словца скармливать читателю такую лажу — не понимаю.

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

                    Самое читаемое