Плохой хороший код
Свой блог я хотел бы запустить с размышлений на данную тему. Также, как когда-то с нее стартовала одна из моих стажировок в IT-компании. Жаль, что еще раньше на моем пути не оказалось людей, способных подсказать и направить. Зато сейчас, спустя время и много тысяч строк разработки, когда появился некоторый опыт и насмотренность, мне есть с чем сравнивать. Хороший или плохой код — это важно в итоге. И именно с этого я хотел бы начать.
Пожалуй, не существует эталонного определения хорошего (качественного, чистого) кода. Можно много гуглить и каждый раз находить разные формулировки. Очевидно, сколько существует программистов, столько найдется и определений. Но общепринятые тезисы здесь все же есть. Попробую перечислить их.
Во-первых, хороший код отличается простотой и прямолинейностью, понятной логикой, минимальными зависимостями, отсутствием дубликатов. Во-вторых, он легко читается, поддерживается и масштабируется. В-третьих, такой код работает. Причем, работает надежно. В-четвертых, он обеспечивает хотя бы базовую безопасность. Наконец, большую его часть можно покрыть тестами.
Даже этого достаточно, чтобы сформировать общую картину. И на первый взгляд вполне все понятно: необходимо научиться и следовать определенным принципам. Но, к сожалению, на практике бывает иначе.
На практике бывает иначе
Образование. Мне приходилось сталкиваться с начинающими программистами, которым давали знания и некоторые навыки, как писать работающий код, но не объясняли, как делать его лучше. В отдельных случаях не давали даже навыков, в основном, теорию.
Помню, довелось встретить педагога, который в ответ на рекомендацию посвятить хотя бы одно занятие элементарному code style, снисходительно улыбнулся, мол, освоить бы основную программу, остальное — приложится. Как преподаватель с 15-ти летним стажем, возможно, я понимаю, что он имел ввиду. К сожалению, в некоторых учебных заведениях к производству программистов сегодня относятся примерно также, как раньше — к производству экономистов. Тут без комментариев.
Уверен, что хорошую привычку лучше закреплять на старте, и с этим надо что-то делать.
Бизнес. Бизнес также может быть источником плохого кода. Каждый, наверное, бывал в ситуации, когда приходилось писать свою часть приложения в условиях неоправданно ограниченных временных рамок. Причины здесь разные (руководитель торопит с новой фичей, аккаунт-менеджер, не согласовав задачу с отделом разработки, наобещал клиентам с три короба), но результат всегда похожий — жертвуя качеством кода в угоду скорости, команда закладывает мину замедленного действия под весь проект. И это работает как снежный ком.
Иногда обстоятельства действительно вынуждают нас работать быстро, особенно в условиях жесткой конкуренции, а уже потом делать рефакторинг или вовсе переписывать приложение. Да, в некоторых случаях это оправдано, в некоторых — чревато. Но главная проблема даже в другом: судя по кодовой базе определенных продуктов, до последующего рефакторинга там так и не доходит.
Разработка культуры кода, наставничество, упорядочивание процессов и слаженная работа подразделений могли бы улучшить ситуацию.
Юниты. Хуже, когда разработчики по собственной инициативе работают спустя рукава. Как в том мультфильме: «И так сойдет». Сегодня, может, и сойдет, а завтра жди дополнительных трудозатрат и финансовых издержек.
Пожалуй, у профессионала должно быть понимание, что взяв на себя обязательства, необходимо стремиться выполнять их качественно. Также профессионал не забывает, что с его кодом кроме него самого будут иметь дело и другие специалисты.
Проблема плохого кода не только в том, что он не работает
Он как раз может очень хорошо работать. Работающий код, несомненно, — это важно (кто бы мог подумать). Но если программист писал приложение на скорую руку, беспорядочно, то вернувшись к нему (допустим, через месяц), наверняка завязнет на какое-то время. Сколько потребуется времени на выполнение задачи тому, кто видит код впервые, вопрос и вовсе открытый.
Таким образом, команда, которая могла делать быстрые правки, пока приложение было небольшим, со временем замедляется настолько, что тратит на поддержку дополнительные дни, недели и даже месяцы.
Результат? Разработка усложняется, фичи внедряются с опозданием, баги слишком долго отравляют жизнь пользователей, затраты на поддержку растут, растает и риск упущенных возможностей.
Что делать
Работайте над собой. Развивайтесь. Ибо команды состоят из отдельных специалистов и вклад каждого определяет ее эффективность.
Для начала:
- соблюдайте руководства по стилю кода, которые разрабатываются создателями и сообществами языков программирования (PSR для PHP, PEP 8 для Phyton и так далее);
- соблюдайте стандарты программирования, которые разрабатываются в компании (шаблоны проектирования, архитектура приложения, особенности обработки ошибок и прочее);
- изучайте документацию (спецификации, описания API и другое);
- используйте различные инструменты для написания кода (XAMPP, IDE, Docker, Git и все остальное, что сделает разработку качественнее и комфортнее);
- пишите модульные тесты (покрывайте тестами как можно больше кода);
- делайте оптимизацию и рефакторинг (но избегайте преждевременной и чрезмерной оптимизации).
А также:
- давайте наглядные и содержательные имена переменным, классам, методам (используйте CamelCase, snake_case и другие соглашения);
- пишите уместные комментарии (уточняйте, поясняйте, информируйте, но не пересказывайте код, не создавайте шум, не комментируйте все подряд);
- разбивайте код на небольшие блоки (один блок — одно действие);
- делайте проще, если это возможно (соблюдайте принцип KISS);
- не повторяйтесь (соблюдайте принцип DRY);
- следите за реализацией бизнес-логики (соблюдайте принципы SOLID, применяйте паттерны);
И это тоже:
- избегайте большого количества аргументов в функциях;
- избегайте отрицательных условий;
- минимизируйте уровни вложенности;
- используйте встроенные языковые функции;
- применяйте полиморфизм вместо if/else, если это возможно;
- замените магические числа именованными константами;
- и другое.
Что еще
Профессионалами становятся рядом с экспертами. Взаимодействуйте с другими разработчиками. Практикуйте парное программирование. Если есть возможность, найдите наставника. Запрашивайте код-ревью — это действительно сделает ваш код лучше.
Прочтите такие книги, как «Чистый код» Роберта Мартина (наряду с другими его книгами — «Чистая архитектура», «Идеальная работа» и «Идеальный программист» — она до сих пор стоит в моей домашней библиотеке), «Совершенный код» Стива Макконнелла и «Паттерны объектно-ориентированного программирования» Эриха Гамма, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса (боевой четверки).
Читайте больше чужого кода. Запишитесь в поддержку Open Source проекта.
Пишите много своего кода. Практикуйтесь.
P.S.
Не пытайтесь написать хороший код сразу. Это еще никому не удавалось (я таких, во всяком случае, не встречал). И даже когда вы будете думать, что у вас получилось, спустя какое-то время вы увидите, что что-то все еще можно улучшить. И это нормально. Это даже хорошо, ибо говорит о том, что вы развиваетесь.
