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

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

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

10 плохих программных привычек, которые любят разработчики

1. Код без комментариев

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

2. Медленный код

   • Чтобы код был быстрым, его нужно делать простым. Но иногда проще и медленнее — лучше, чем сложнее и быстрее. Бывает, что медленный код легче понять и поддерживать.
   • Баланс между скоростью и сложностью: Быстрый код часто бывает сложным, что затрудняет его понимание и поддержку. Иногда лучше выбрать более медленный, но понятный код, особенно если скорость не является критичным фактором.

3. Развернутый код

   • Использование новых операторов и конструкций может сделать код короче, но не всегда проще для понимания. Некоторые программисты предпочитают писать более длинный, но более читаемый код.
   • Пример: Некоторые разработчики любят использовать новые операторы в JavaScript, делая код более компактным. Однако это может усложнить его чтение и понимание для других.
   • Исторический контекст: Языки программирования, такие как APL, которые стремились к максимальной компактности, практически исчезли. Другие языки, как Python, наоборот, избегают сложных конструкций и остаются популярными благодаря своей простоте и читаемости.

4. Старый код

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

5. Самописный код

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

6. Преждевременная оптимизация

   • Часто говорят, что преждевременная оптимизация — зло. Но иногда небольшое планирование и оптимизация в начале могут существенно упростить дальнейшую работу над проектом.
   • Мудрое планирование: Важно найти баланс между оптимизацией и эффективностью разработки. Иногда небольшая оптимизация в начале может предотвратить большие проблемы в будущем.

7. Небрежность

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

8. Несогласованность

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

9. Погоня за новыми функциями

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

10. Нарушение правил

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

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

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

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

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