Найти тему
Дед Мазай на Котлине

Как сделать некрасивый код красивым

Хочешь сделать хорошо - сделай сам
Хочешь сделать хорошо - сделай сам

Как понять, что такое качественный, практичный и логичный код, если у вас недостаточно опыта?
Можете взять за основу чьи-то существующие правила или на практике вывести свои. Мне для этого понадобилось 2 проекта, которые я начинал делать с нуля и долгое время делал один.
В свободное время читайте статьи и книги о лучших практиках разработки и применяйте их в своём коде. Если проект будет полностью в вашем распоряжении, вы сможете легко и непринуждённо в любое время отрефакторить его в любую сторону, без риска "спутать карты" другим разработчиками.
В ходе тестирования чужих подходов к разработке вы постепенно отбросите всю шелуху и оставите себе только самое лучшее и самое нужное.
При работе с красивым кодом у вас не будет возникать чувства дискомфорта или ощущения, что вы делаете мартышкину работу.
Не останавливайтесь в своих экспериментах, ведь предела совершенству не существует.
Читайте чужой код и берите из него то, до чего ещё не дошли сами.
Не ленитесь рефакторить НЕКРАСИВЫЙ код - натренируете руки на создание красоты и воспитаете в себе чувство прекрасного.

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

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

Как понять, что перед вами плохой, некачественный код?
Это не сложно:
1) после клонирования репозитория код не запускается в ИДЕ кнопкой "Run project", в Readme.md не написаны инструкции как это исправить и нет ссылки на такие инструкции;
2) для локального заапуска, приложение требует наличия больше двух сторонних приложений, поднятых в докере;
3) вам нужно помнить, с каким профилем вы должны запустить приложение в текущей фазе Луны;
4) вам нужно руками создавать таблички в базе данных, чтобы приложение могло запуститься;
5) логи приложения - это каша из неотформатированного текста;
6) вы никогда сами не найдёте, какая версия приложения является текущей;
7) в какой ветке проекта находится production ready код, знает только 1 человек, который в данный момент в отпуске / на больничном / работает на конкурентов;
8) при работе с кодом, вам нужно делать много ручной работы (искать обновления, отслеживать уязвимости, следить за настройками для разных профилей и т.п.)
9) код сложно читать из-за нагромождения комментариев, не несущих никакого самостоятельного смысла;
10) вы не можете просто так, в браузере, посмотреть логи на стенде для разработки,
11) вы не можете просто так, через свой любимый клиент базы данных, посмотреть в базу данных на стенде для разработки,
12) код ставит на вашем пути сотни других препятствий, мешающих вам с ним работать.