Кодекс и искусство обслуживания мотоцикла: типичные ошибки новичков

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

Удобочитаемость важнее производительности, но не всегда

С чего начинают типичные начинающие мотоциклисты? Цифры и гаджеты. Мощность, крутящий момент, детали производительности, чтобы откусить теоретические миллисекунды на четверти мили... Так же, как если бы они собирались выйти на стартовую решетку MotoGP. Между тем, их главная задача — просто научиться ездить безопасно. Аналогичным образом начинающие разработчики часто зацикливаются на производительности кода там, где это не нужно. Статьи, в которых обсуждаются вопросы о том, что эффективнее в Python: `dict()` или `{}`, или о плюсах и минусах использования фреймворков, несмотря на их потенциал снижения производительности, подпитывают эту одержимость. Хотя понимание тонкостей вашего языка программирования полезно, а иногда и критически важно — например, в программном обеспечении для самолетов, биржевых роботов или медицинских приборов — это не всегда критично для большинства программ, которые мы создаем ежедневно. Даже если вы работаете над критически важным для производительности программным обеспечением, важно знать, какие части кода требуют высокой производительности, а какие нет.

Однако всегда важна читаемость кода. Многочисленные исследования и опросы подтверждают, что разработчики тратят больше времени на чтение и понимание кода, чем на его написание. Например, исследование «Я знаю, что вы сделали прошлым летом. Расследование того, как разработчики проводят свое время» обнаружили, что только 4% времени, проведенного в IDE, используется для редактирования кода. Глобальный отчет о времени кода , основанный на опросе более 250 000 разработчиков, показал, что респонденты тратят всего около 52 минут в день на активное написание кода. Остальное время уходит на обсуждение и планирование проекта, около 41 минуты отводится на чтение кода в IDE и проектной документации.

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

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

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

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

• Нагрузочное тестирование : моделирование высоких нагрузок может помочь выявить узкие места производительности до того, как они превратятся в реальные проблемы.

• Анализ отзывов пользователей : сбор отзывов пользователей может выявить области с низкой производительностью.

• Ведение журнала и мониторинг : анализ журналов выполнения и метрик может выявить проблемные области во время реальной работы приложения. Этот этап может выявить неожиданные проблемы, такие как неправильное использование API, вызывающее проблемы с производительностью.

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

  
  

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

Документирование помогает понять проделанную работу

На дороге одним из важнейших навыков безопасности является предсказуемость и, соответственно, чтение намерений других. В кодировании, как и в езде, вы не можете напрямую читать мысли других людей. На двух колесах вы должны замечать едва заметные движения и предсказывать, что другие сделают в следующую секунду. Программисты обладают (но не всегда используют) мощным инструментом, заменяющим телепатию: бумажной работой. Большинство разработчиков согласны, что документация имеет решающее значение для проекта, о чем свидетельствуют такие опросы, как Опрос разработчиков Stack Overflow 2023 , где 90,36% респондентов регулярно используют техническую документацию. Однако они часто не могут найти там все ответы, обращаясь вместо этого к Stack Overflow (82,56%) и различным блогам (76,69%). Другое исследование, Microsoft Research: Повседневная жизнь разработчиков программного обеспечения , показывает, что разработчики тратят 1–2% своего дня на документацию, при этом 10,3% респондентов теряют много времени из-за некачественной или устаревшей документации.

Документация может принимать различные формы: от подробных описаний проектов в таких системах, как Confluence, до комментариев к коду и автоматически или полуавтоматически сгенерированных веб-сайтов с описанием проектов. Это может быть даже такой простой файл README в корневом каталоге проекта. Независимо от формата, процесс создания документации выходит далеко за рамки простого предоставления информации о том, как работает продукт. Этот процесс заставляет нас переосмысливать то, что мы сделали , что часто может привести к улучшению API и общей архитектуры. Я часто осознавал, документируя созданную мной функциональность, что с ней может быть сложно работать, и я нашел способы исправить это.

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

Рассказывать другим о своих планах не стыдно

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

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

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

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

Тестирование: инструмент для понимания и проверки кода

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

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

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

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

Любите свой код, как вы любите своего друга, и заботьтесь о нем.

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

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

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

Короче говоря, любите свой код и уделяйте ему время, но не чрезмерно, иначе вы закончите как главный герой «Теоремы Зеро». Удачи!