Давайте примем тот факт, что большинство из нас были разочарованы количеством дикой природы, обнаруженной в коде, который мы пишем, или при просмотре чужого кода.
Все программисты проходят аналогичные этапы:
- Вау! Программирование становится волшебством, как только они видят, что их первая программа успешно запускается.
- Это интересно. Этот язык потрясающий. Я думаю, что я влюблен. Все логично, но немного тупее и на более высоком уровне
- Тогда ладно. Я буду читать об этих структурах данных и различных алгоритмах и других темах, которые я понятия не имею, как они будут использоваться в ближайшем будущем.
- Реализация этого алгоритма с нуля будет потрясающей, но тогда я забуду обо всем этом в ближайшем будущем.
- ВТФ! Я не могу этого сделать. Математика меня убивает.
- Хорошо. Я не буду пытаться заново изобретать колеса. Я просто буду использовать эти библиотеки и фреймворки, чтобы все заработало.
- ** Прошло несколько тысячелетий ** Что это за код? Я правда это написал? Я был таким нубом.
- ** Спустя несколько тысячелетий снова ** Я ничего не знаю, но могу говорить о чем угодно. :П
Вот что я делаю, чтобы писать чистые коды (по крайней мере, попробуйте писать коды чище)
И. Правильное соглашение о написании кода для языка программирования
Это помогает другим разработчикам легко сотрудничать.
II. Правильное соглашение об именах переменных и методов
Правильное присвоение имен переменным наверняка избежит стрессовых размышлений, если вы будете читать свои коды некоторое время спустя. Это делает коды более подробными.
III. Предотвращение дублирования кода
Если есть повторяющиеся части кода, я стараюсь разделить их и поместить в отдельное место, чтобы предотвратить дублирование.
IV. Модульность
Мои коды большую часть времени следуют парадигме объектно-ориентированного программирования, чтобы компоненты были как можно более модульными. На самом деле не обязательно следовать ООП при выполнении простых задач.
Модульность в некотором смысле делает его более функциональным, как компонент. Это не обязательно должен быть сам объект, но могут быть и функции.
Однако, если задачи, которые необходимо выполнить, несложны, ООП усложняет коды. Итак, будьте проще.
В. Напишите соответствующую документацию
Надлежащая документация ведет любого разработчика через необъятность кодов.
На самом деле, в прошлом я ломал голову над старыми кодами из-за отсутствия документации, и мне приходилось буквально тратить часы, чтобы понять, что эти коды делают.
VI. Правильное структурирование пакетов
Это тоже имеет для меня решающее значение. В более крупном проекте структура имеет большее значение. Потому что структурирование фактически основано на общей архитектуре самого проекта.
Правильно структурированный проект, как правило, представляет собой хорошую архитектуру.
VII. Будь проще, глупо (KISS)
Как я сказал в (IV), во имя ООП люди склонны пренебрегать основами кодирования, то есть просто заставить все работать просто.
Итак, в простом проекте, который имеет тенденцию делать только одну вещь (например, автоматизацию и т. д.). Я придерживаюсь простоты и стараюсь избегать самого ООП.
Но
Нет кода лучше, чем глючный. Ваше здоровье. Минимализм должен быть сутью кодирования.
P.S. Хочу добавить цитату:
Всегда кодируйте так, как будто парень, который в конечном итоге будет поддерживать ваш код, будет жестоким психопатом, который знает, где вы живете.
