Перевод статьи Мэтью Макдональда (Matthew MacDonald) Преподаватель, кодер, Microsoft MVP
4 мин чтения
Всегда хорошо проводить рефакторинг старого кода, подвергать измененные программы строгим тестам и обновляться на последнюю версию JavaScript. Но теперь пришло время взглянуть на другую сторону — на ковбойских кодеров и корпоративных сотрудников, которые поддерживают некоторые из худших практик программирования, которые вы когда-либо видели. Это список семи худших правил для программистов. К сожалению, вы регулярно найдете их на работе в реальном мире.
0. Храните секреты
Если вы не можете быть программистом 10 уровня, будьте программистом из 9 жизней. Это тот, кого слишком сложно уволить, потому что они знают секреты приложения компании — и они не делятся.
Чтобы осуществить это, будьте готовы. Младшие разработчики будут задавать вам вопросы. Вы будете вести их в запутанных играх с угадайкой, иногда с пренебрежительным фырканьем и загадочными комментариями вроде «мы это запутали (obfuscated)».
Да, вы могли бы поделиться своими знаниями, учиться друг у друга и расти вместе. Но если целью является максимальная безопасность работы с минимальными усилиями, ваша оптимизация ведет сюда.
1. Если сомневаетесь, добавьте другой шаблон проектирования (design pattern)
Как говорят мудрецы: «Все проблемы в информатике могут быть скрыты с дополнительным уровнем косвенности». Использование новых мостов, адаптеров, прокси-серверов, пользовательских интерфейсов может не устранить ошибок в вашем коде. Но они хорошо поглотят их, превратив ваш недостаток в чужую проблему.
Кроме того, запутанная ошибка означает, что у вас есть правдоподобное оправдание. Кто знает, кто в этом виноват?
2. Боготворите новое
Всему есть сезон. Если вы говорите о библиотеках JavaScript, этот сезон может длиться всего несколько недель. Но независимо от технологии, в конце концов, пришло время перейти к чему-то новому.
Новые технологии волнуют всех. Старые вещи могут все еще работать, но в одночасье это вызывает смущение. Помните, «это все еще работает» является вторичным по отношению к «это впечатляет кого-либо на конференциях?»
Если вы сообразительны, вам могут заплатить за написание одного и того же программного обеспечения несколько раз, каждый раз используя разные библиотеки и фреймворки. И если вы по-настоящему проворны, вы можете перейти на новую платформу непосредственно перед тем, как рассчитывать стоимость собственного спагетти-кода. Постоянные изменения = разумный шанс опередить ваши ошибки.
3. Не позволяйте тестированию мешать большему количеству кода
Если вы хотите быть продуктивным, вы должны прокачивать эти цифры. Тестирование определенно не продуктивно. Вы знаете, что продуктивно? Инструментальная генерация кода. Рассказываю. Вам нужно множество материалов, целые наборы классов данных, автоматически сгенерированные на основе вашей схемы базы данных. На следующей неделе вы можете изменить схему и снова запустить все инструменты. Теперь это сделает большой коммит вашего кода.
В любом случае, тестирование – это снижение эффективности. Помните, что гибкое (Agile) программирование означает, что вам не нужно извиняться.
4. Напишите один раз, потом не трогайте
Код непредсказуем. Но когда это работает, это похоже на нежную снежинку, аккуратно взгроможденную на башне Jenga в середине игры. На данный момент, полюбоваться вашим творением. Но не рискуйте ничего менять.
Стоит помнить правило кодирования Pottery Barn. «Если он сломается, когда его держит кто-то другой, тогда это его проблема».
5. Если сначала у вас ничего не получится, скопируйте, скопируйте и вставьте
Если бы Бог (вставьте здесь ваше любимое божество) хотел, чтобы мы страдали, он не использовал бы Ctrl + C на наших клавиатурах. Нет проблем для правильного копирования и вставки. Ваша задача состоит в том, чтобы собрать воедино комбинацию ключевых слов, которые приведут вас к фрагменту кода, связанному с условным StackOverflow. Добавьте это к своей базе кода и получите себе бесплатный код!
6. Комментарии для лохов
Вы написали это в коде. Зачем повторять это в комментариях? (Единственное исключение: если есть функция, которая немного сложна в реализации и используется редко, добавьте комментарий TODO и отметьте его в своем списке.)
Эта тактика также помогает привычке #0.
7. Это ошибка конечного пользователя
Вот чего они хотели. Нет, они специально не говорили «создайте мне сетку кнопок 10 на 6 для запуска различных команд» (фактический пример из реальной компании). Но они сказали, что все эти команды должны быть доступны одним щелчком мыши. Вы программист, так что вы знаете все о логических выводах.
Если кто-то спрашивает вас, запомните это: не только этот пользовательский интерфейс лучший, но и единственный возможный на основе предоставленных мне спецификаций. Даже не пытайтесь рекомендовать изменения – клиент никогда не согласится. Подождите, вот новый запрос на функцию. Нам понадобится еще одна кнопка.
(Если это кажется восьмым пунктом, то позвольте мне напомнить вам, что здесь мы проводим подсчет Base-0. В конце концов, как еще люди узнают, что мы Настоящие Программисты ™?)