Безжалостные истины, которые должен знать каждый разработчик JavaScript
Ни один разработчик не любит делать ошибки.
Каждый разработчик хочет, чтобы его код был идеальным. Мы, разработчики, хотим, чтобы наш код не только не содержал ошибок, но и был удобочитаемым для человека.
Но есть определенная ошибка, которую мы совершаем, которая заставляет нас страдать в будущем. Когда мы совершаем эти ошибки, мы не знаем, какие трудности это вызовет. Тем не менее, мы делаем эти ошибки снова и снова.
Вот четыре из этих ошибок.
1. Использование запутанных длинных имен
Короткие имена не предоставляют достаточно информации при использовании. Вот почему мы избегаем написания коротких функций и имен переменных.
Когда короткие имена не обеспечивают достаточного контекста, большинство программистов начинают использовать длинные описательные имена.
Описательные имена — это хорошо, но длинные и запутанные описательные имена — это плохо. Грань между описательными именами и запутанными длинными описательными именами очень тонкая.
Когда вы пишете имя, которое передает слишком много смысла о чем-либо. Это смутит читателей кода.
Если вы напишете имя функции следующим образом:
vectorControl.addAndDisplayModifiedAndCopiedScalers();
Становится трудно понять.
Прочитав приведенное выше название функции, любой программист запутается между двумя вещами:
- Если вышеуказанная функция добавляет и отображает масштаберы, которые одновременно изменяются и копируются.
- Если указанная выше функция добавляет и отображает измененные масштабаторы вместе с копируемыми масштабаторами.
Новичок, который только начал учиться программировать, не только путается, но и начинает бояться длинных описательных имен функций.
Как разбить длинное имя на несколько частей
Мы будем использовать различные вещи, которые происходят с вышеупомянутой функцией, чтобы разбить имя на несколько частей.
Если вы хотите внести изменения в вышеуказанную функцию. Просто убедитесь, что новая функция выполняет только одну операцию за раз.
Вы можете разделить вышеуказанную функцию на четыре отдельные функции:
vectorControl.addCopiedScalers(); vectorControl.displayModifiedScalers(); vectorControl.addModifiedScalers(); vectorControl.displayCopiedScalers();
Не используйте длинные имена только для того, чтобы скрыть свою плохую абстракцию.
Длинные имена не проблема, обычно это запутанная абстракция, которая создает весь беспорядок.
2. Комментарии к коду нарушают принцип DRY
«Не повторяйся».
Если вы разработчик, вы будете слышать этот термин не реже одного раза в день.
Старшие разработчики продолжают повторять этот принцип младшим разработчикам.
Большинство программистов считают, что сухое нарушение происходит только тогда, когда вы пишете один и тот же код в двух или более местах своей кодовой базы.
Сухие нарушения могут возникать в нескольких точках кодовой базы.
Если какой-либо разработчик написал самодокументирующийся код, а также написал комментарии, поясняющие этот код прямо здесь.
Сухой принцип в этом случае нарушается.
Чтобы внести небольшое изменение в код, мы должны внести изменения в код и в комментарии.
Это означает, что знания дублируются.
Вот несколько примеров:
return 1; //returns 1 getUserInfo(); //This function helps to get user information. i--; //decrease the value of i by 1
Если ваши комментарии не добавляют смысла коду, не пишите комментарии.
3. Не писать маленькие функции
Любой разработчик, который зарабатывает на жизнь написанием кода, читает много кода.
95% нашей повседневной жизни как разработчиков связано с чтением чужого кода.
Мы читаем код, когда:
- мы ищем способы исправить ошибки в нашем коде.
- мы читаем документацию.
- мы изучаем новый язык или структуру.
Мы всегда читаем чей-то код.
Как разработчик, мы прочитали функции, которые имеют:
- более 500 строк кода.
- более 200 строк кода.
- менее 100 строк кода.
- менее 50 строк кода.
В идеале все разработчики хотят, чтобы длина функций находилась в пределах 50–100 строк читаемого кода.
Если функция содержит более 200 строк кода. Мы не хотим это читать, потому что это будет трудно понять.
Для старых языков было почти невозможно сохранить маленькую длину функции.
В современных языках вы можете сохранить небольшую длину функций. Разработчик, который читает функцию с меньшим количеством строк кода, должен делать меньше переключений контекста.
Вот небольшой пример:
function payEmployees(employees){
employees.forEach(employee => {
const employeeRecord = database.lookup(employee);
if(employeeRecord.isActive()) {
pay(employee);
}
});
}
Вышеуказанная функция может быть разбита на две отдельные функции.
function payActiveEmployees(employees){
employees.filter(isActiveEmployee).forEach(pay);
}
function isActiveEmployee(employee){
const employeeRecord = database.lookup(employee);
return employeeRecord.isActive();
}
Вышеупомянутые две небольшие функции становятся легко читаемыми.
Когда есть возможность разделить функцию на отдельные функции, просто сделайте это.
Держите функцию небольшой, потому что небольшие функции очень помогают программистам.
4. Не оставаться эмоционально отстраненным от своего кода
Оставаться эмоционально отстраненным от своего кода и дизайна — это суперсила.
Если в прошлом вы написали код, который больше не служит своей цели, вы должны удалить этот код.
Когда вы относитесь к своему коду так, как если бы он был вашим детищем, это вынуждает вас принимать критику кода на свой счет.
Когда вы остаетесь отстраненным от своего кода, вы будете положительно воспринимать отзывы о нем, а не чувствовать себя атакованными.
Если рецензент попросит вас удалить часть кода и переписать его, оставайтесь в стороне, чтобы не спорить с рецензентом.
Если вы останетесь отстраненным, вы будете мирно смотреть на свой код.
Если после тщательного изучения вы обнаружите, что допустили ошибки, вы, скорее всего, измените его, даже если этот код писался месяц.
Краткое содержание
- Следует избегать длинных имен.
- Комментарии к коду могут нарушать принцип DRY.
- Не пишите маленькие функции.
- Вы не являетесь своим кодом.
Вы хотите ускорить свою карьеру программиста
Присоединяйтесь к группе людей, которые любят программирование и технологии.
Вы можете присоединиться к этому здесь.
С помощью нашего сообщества мы решим основные проблемы в жизни программистов и обсудим фронтенд и бэкенд.
Мы поможем вам перепрограммировать ваше понимание различных вещей в технологии.
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord.
