Написание чистого кода - довольно сложная задача. У многих людей есть свои стандарты написания хороших кодов. Однако как правильно определять код как «чистый код»?
Есть несколько моментов, на которые мы можем указать, чтобы определить, написан ли код чисто или нет.
# 1 R доступные коды
Прежде всего, написание хорошего кода - это не всегда сложные функциональные возможности с множеством мощных функций. Важно создавать приложение с использованием правильных методов, отвечающих потребностям конечного пользователя.
Приложение получит обновления рано или поздно при масштабировании. Обновление означает написание еще одной кучи кода и рефакторинг этих строк кода в том же проекте.
Вопрос в том, «запомнят ли разработчики содержимое кодовой базы через 3 месяца?». Возможно, да, скорее всего, нет. Но одно можно сказать наверняка: команде разработчиков придется снова прочитать и просмотреть весь код. Если код не читается, команда разработчиков потратит много времени без необходимости даже на то, чтобы понять назначение переменной.
# 2 C постоянные коды
Большинство разработчиков работают в одиночку, самостоятельно пишут свой код, со своим собственным стилем написания, и только сами понимают значение своего кода. Эту парадигму можно применить в небольшом разовом проекте, где нет необходимости поддерживать и обновлять код.
Другой случай применяется, когда мы работаем в команде разработчиков, где разные разработчики используют одну и ту же кодовую базу. В рамках одного проекта каждый разработчик будет читать, писать и взаимодействовать друг с другом коды.
Представьте, если коды написаны так
публичная функция getStaffDataFromDB () {}
публичная функция insertStaffDataToDB () {}
публичная функция updateStaffDataById ($ staff_id) {}
публичная функция deleteStaffDataById ($ staff_id) {}
и другой разработчик в той же команде пишет это так
публичная функция get_project () {}
публичная функция add_project () {}
публичная функция modify_project ($ ID) {}
публичная функция delete_project ($ ID) {}
Когда код в какой-то момент вырастет в размерах, команда может запутаться, когда они будут читать и использовать методы из-за несогласованного именования. Особенно, если предыдущий разработчик ушел в отставку, новому члену, который присоединился к команде, придется прочитать и выяснить предыдущие коды.
Работая в команде разработчиков, лучше установить стандартные правила именования для классов, методов, переменных и формата, прежде чем углубляться в проект.
«Хороший код требует планирования»
# 3 Модульные коды
Модульный означает подход к проектированию, при котором система подразделяется на более мелкие части, которые могут быть независимо созданы и затем использованы в разных системах. Такой подход к дизайну фактически увеличивает время разработки для программистов. Написание модульного кода означает разбиение больших функций на несколько более мелких.
Этот принцип принято называть принципом единой ответственности. Каждая функция служит только одной цели. Функция не должна выполнять набор инструкций. Когда одна функция выполняет слишком много вещей, разработчикам будет сложно рефакторинг и обновление кода.
Это пример каталога модульных классов, где каждый класс служит одной цели.
/ app
- контроллеры
- - StudentController
- - TeacherController
- - LoginController
- модели < br /> - - Студент
- - Учитель
- - Пользователь
- помощники
- - DatabaseHelper
- - SecurityHelper
- - ValidationHelper
- - ErrorHelper
Большинство разработчиков склонны забывать о разделении многоцелевого класса на несколько классов, когда кодовая база увеличивается. Лучше спланировать и разбить проект на модули, прежде чем зацикливаться на спагетти-кодах.
Почему так важно писать модульные коды?
Повторное использование. Меньшая функция должна быть многоцелевой. Не наоборот.
Без избыточности. Лучше использовать уже существующую функцию, чем переписывать ее заново.
Масштабируемость. Когда приложение становится больше, коды не переплетаются друг с другом.
Предотвратить путаницу. Когда бывший программист уходит в отставку, новый член команды будет легко изучать коды.
Легко отлаживать. Обнаружить ошибку в небольшой функции намного проще, чем найти ошибку в большой функции.
Перед тем, как написать это краткое руководство по чистому коду, меня вдохновила книга Чистый код, написанная Робертом Мартином. Это действительно меняет мой личный образ мыслей о написании кодов (потому что раньше я большую часть времени писал беспорядочные и нечитаемые коды).
Наконец, как разработчик и энтузиаст, которому еще предстоит многому научиться, я хотел бы призвать каждого разработчика, который читает это, тратить больше времени на создание чистых и аккуратных кодов. Преимущества не только для нынешней команды разработчиков, но и для будущего разработчика, который присоединится к команде.
Будем очень признательны за любые отзывы, комментарии или вопросы, если они у вас есть. Добрый день!
