Известно, что иногда приятно нарушать правила. Будь то превышение скорости на одну милю или игнорирование истекшего времени на паркомате. У программистов отношения с правилами особенно странные. С одной стороны, код — это набор правил, которые должны исполняться идеально. Но есть и другой уровень правил, которые не столь священны и часто нарушаются самими программистами. Дебаты о том, стоит ли людям нарушать собственные правила, ведутся давно. Некоторые из этих правил устарели, другие были плохо продуманы с самого начала, а некоторые стали скорее привычками. Несколько лет назад был составлен список плохих программных привычек, которые программисты тайно обожают. Теперь предлагается ещё 10 таких привычек. 10 плохих программных привычек, которые любят разработчики -
Код без комментариев - Нередко некомментированный код сложно понимать и отлаживать. Хорошие комментарии считаются важной частью программирования, но иногда комментарии могут ухудшить ситуацию. Документация может быть несоответствующей или устаревшей, а иногда комментарии пишутся на языке, который не все знают. Поэтому некоторые разработчики предпочитают писать простые функции и использовать описательные имена переменных вместо комментариев.
- Проблемы с комментариями: Иногда комментарии не соответствуют коду. Команда документации может находиться в другом месте или просто не успевать обновлять комментарии. Иногда программисты не обновляют комментарии после внесения изменений в код.
- Альтернативный подход: Вместо комментариев можно писать простые и короткие функции с длинными описательными именами переменных. Это помогает понять код без дополнительных пояснений.
-
Медленный код - Чтобы код был быстрым, его нужно делать простым. Но иногда проще и медленнее — лучше, чем сложнее и быстрее. Бывает, что медленный код легче понять и поддерживать.
- Баланс между скоростью и сложностью: Быстрый код часто бывает сложным, что затрудняет его понимание и поддержку. Иногда лучше выбрать более медленный, но понятный код, особенно если скорость не является критичным фактором.
-
Развернутый код - Использование новых операторов и конструкций может сделать код короче, но не всегда проще для понимания. Некоторые программисты предпочитают писать более длинный, но более читаемый код.
- Пример: Некоторые разработчики любят использовать новые операторы в JavaScript, делая код более компактным. Однако это может усложнить его чтение и понимание для других.
- Исторический контекст: Языки программирования, такие как APL, которые стремились к максимальной компактности, практически исчезли. Другие языки, как Python, наоборот, избегают сложных конструкций и остаются популярными благодаря своей простоте и читаемости.
-
Старый код - Некоторые считают, что использование всех возможностей языка программирования — хорошая практика. Однако слишком много функций может запутать. Ограничение количества используемых функций может снизить уровень путаницы и упростить чтение кода.
- Избыток возможностей: Слишком много абстракций и синтаксических конструкций может сделать код трудным для понимания.
- Пример: Разработчики языка Go решили ограничить набор функций, чтобы язык был легче для изучения и использования.
-
Самописный код - Вместо использования готовых библиотек, иногда имеет смысл написать специализированный код для конкретной задачи. Это может быть быстрее и эффективнее, но в некоторых случаях, таких как криптография, лучше использовать проверенные решения.
- Преимущества: Самописный код может быть более оптимальным и быстрым для конкретной задачи.
- Недостатки: Это может быть опасно в сложных областях, таких как криптография, где ошибки могут привести к серьёзным проблемам.
-
Преждевременная оптимизация - Часто говорят, что преждевременная оптимизация — зло. Но иногда небольшое планирование и оптимизация в начале могут существенно упростить дальнейшую работу над проектом.
- Мудрое планирование: Важно найти баланс между оптимизацией и эффективностью разработки. Иногда небольшая оптимизация в начале может предотвратить большие проблемы в будущем.
-
Небрежность - Чрезмерная проверка данных может замедлить работу кода. Иногда стоит игнорировать инстинкты и писать код, который выполняет только необходимый минимум проверок.
- Экономия ресурсов: Иногда можно позволить себе меньше проверок, чтобы повысить производительность кода. Но это должно быть оправдано и сделано с осторожностью.
-
Несогласованность - Однообразие в коде делает его легче для понимания, но требует времени и усилий. Иногда лучше принять некоторое разнообразие в коде, особенно если проект зависит от разных библиотек и API.
- Практическая реальность: Полное однообразие часто недостижимо из-за различных источников кода, таких как старые библиотеки и внешние API.
-
Погоня за новыми функциями - Введение новых функций и библиотек может нарушить старые шаблоны, но это цена прогресса. Иногда стоит рискнуть и внедрить новые возможности.
- Инновации: Добавление новых функций и технологий может потребовать нарушить старые стандарты, но это необходимо для развития и улучшения проекта.
-
Нарушение правил - Программисты часто нарушают собственные правила. В эпоху больших языковых моделей и машинного обучения старые правила меняются. Не всегда нужно понимать алгоритмы в деталях, иногда достаточно доверить эту работу машинам.
- Эволюция правил: С развитием технологий старые правила могут устареть. Программисты должны адаптироваться и быть готовыми нарушать устаревшие нормы.
Плохие программные привычки не всегда однозначны. Некоторые из них могут показаться негативными на первый взгляд, но при определённых условиях они могут принести пользу и повысить эффективность работы. Например, отсутствие комментариев может стимулировать разработчиков писать более понятный и самообъясняющийся код. Медленный код, несмотря на его очевидные недостатки, часто оказывается более устойчивым и легче поддерживаемым. Использование старого кода или написание собственного вместо использования библиотек может повысить производительность в специфических случаях. Эти привычки отражают творческий процесс программистов, стремящихся найти баланс между эффективностью, производительностью и поддерживаемостью кода. Нарушение правил иногда является необходимым шагом для инноваций и прогресса. Важно понимать контекст и последствия таких решений, чтобы они приносили пользу, а не вред. Современные технологии и подходы к программированию продолжают развиваться, и вместе с ними эволюционируют и правила. Программисты должны быть готовы адаптироваться и пересматривать свои методы работы. В конечном итоге, главное — это создание качественного и надежного программного обеспечения, которое решает поставленные задачи и легко поддерживается в долгосрочной перспективе. Понимание и анализ своих привычек позволяет программистам совершенствовать свои навыки и подходы, делая их более гибкими и эффективными в меняющемся мире технологий.
|
