Написание чистого кода — непростая задача. Это требует различных техник и много практики. Написание чистого кода также является целью разработчиков.
Преимущества написания чистого кода
- Проекты легче начинать и продолжать
- Подходит для новых членов команды, чтобы присоединиться к команде проекта
- легче понять
Основы написания чистого кода
- Код легче читать
- Используйте более осмысленные имена для переменных, функций и методов.
- Заставьте каждую функцию или метод выполнять только одну задачу
- Используйте примечания для объяснения (важно)
- быть последовательным
- Регулярно проверяйте свой код
Преимущества написания чистого кода
Давайте сначала рассмотрим некоторые преимущества написания чистого кода. Одним из основных преимуществ является то, что чистый код помогает нам свести к минимуму время, необходимое для чтения и понимания кода. Грязный код может замедлить работу любого разработчика и усложнить его работу. Чем более запутан код, тем больше времени требуется разработчикам для его понимания. Также, если код слишком беспорядочный, разработчики могут подумать о рефакторинге.
1. Проекты легче начинать и продолжать
Позвольте мне продемонстрировать это на простом примере. Допустим, мы возвращаемся к проекту, который мы делали раньше, спустя долгое время. А теперь представим, что тогда мы писали не самый чистый код, а наоборот. После первого взгляда мы видим, насколько плохой и грязный код. И мы также видели, как трудно продолжить с того места, где мы остановились.
Так что теперь нам нужно потратить больше времени на проект, потому что нам нужно понять код, который мы написали ранее. Это совершенно не обязательно. Мы можем полностью избежать этого, написав чистый код с самого начала. Теперь мы должны заплатить. Кроме того, наш старый код настолько беспорядочный или плохой, что мы можем решить начать с нуля. Услышав эту новость, наши клиенты могут быть недовольны.
С другой стороны, чистый код обычно не имеет этой проблемы. Представьте предыдущий пример с противоположными условиями. Теперь наш предыдущий код чистый и элегантный. Сколько времени нужно, чтобы это понять? Может быть, нам нужно прочитать код в течение нескольких минут, чтобы понять, как все работает. Наконец, прошло много времени с тех пор, как мы его написали. Однако эти инвестиции будут значительно меньше, чем в первом случае. Наши клиенты этого даже не заметят.
Это первое преимущество кодирования, и оно согласуется с методами, которые мы обсудим. Причем, это касается не только наших собственных проектов, но и работ других разработчиков. Чистый код позволяет нам быстрее начать работу. Нам или кому-либо другому не нужно часами изучать его. Вместо этого мы можем сразу перейти к работе.
2. Больше подходит для адаптации новых членов команды
Еще одно преимущество написания чистого кода тесно связано с первым. Это позволяет упростить и ускорить внедрение. Я имею в виду это. Давайте представим, что нам нужно нанять еще одного разработчика. Сколько времени ей нужно, чтобы понять код и научиться им пользоваться? это зависит от. Если наш код беспорядочный и плохо написанный, ей потребуется больше времени, чтобы завершить его. С другой стороны, если наш код будет чистым, читабельным, понятным и простым, она сможет запуститься быстрее.
Кто-то может возразить, что это не проблема, потому что мы рядом и можем ей помочь. И это факт. Однако наша помощь должна занять короткое время, день, два или три. Однако это не должно быть неделя, две или три. В конце концов, мы решили нанять другого разработчика, чтобы ускорить нашу работу, а не замедлять ее. Наша цель — проводить больше времени, помогая ей научиться использовать наш код.
Когда мы усердно работаем и пишем чистый код, другим легче следовать ему и использовать его. Конечно, нам все еще нужно выделить некоторое время, чтобы помочь каждому новому разработчику узнать и понять наш код. Однако речь идет о днях, а не о неделях. Кроме того, чистый код поможет нам привлечь больше разработчиков в команду и помочь им сразу понять наш код. Короче говоря, чем понятнее код, тем проще его объяснить и тем меньше недоразумений.
3. Легче понять
Нам нужно помнить одну вещь. Знать и учиться использовать код — это одно. Однако это только начало. Мы также должны убедиться, что разработчики могут и хотят следовать нашим методам кодирования. Опять же, проще реализовать чистый код, а не беспорядочный. Это важно, потому что мы не только хотим писать чистый код, но и хотим, чтобы он оставался таким, независимо от того, сколько людей его использует. Нам нужно думать о долгосрочной перспективе.
Последнее, что нужно сделать с этим. Что, если один из наших разработчиков решит не следовать текущим методам написания кода? Обычно эту проблему можно решить. Предположим, у нас есть группа людей, работающих над одной кодовой базой, и один человек начинает отклоняться от стандартного стиля. Тогда произойдет одно из этих трех событий. Во-первых, остальная часть группы будет подталкивать разработчика к следованию стандарту. Она возьмет его, потому что не хочет уходить.
Второй вариант заключается в том, что разработчик фактически убедит остальную часть команды принять и следовать ее методам кодирования. Это может быть хорошо, если методы кодирования, предлагаемые разработчиками, будут чище и приведут к лучшим результатам. Написание и поддержание чистоты нашего кода не означает, что мы должны игнорировать любую возможность его улучшения. Наоборот. Я думаю, что мы всегда должны подвергать сомнению нашу текущую практику и искать возможности для улучшения.
Поэтому, если разработчик отличается от нашего, а его лучше, возможно, будет лучше, если мы внесем изменения вместо него. Я думаю, что мы никогда не должны игнорировать чью-то практику, пока мы не проверим и не попробуем. Всегда есть место для совершенствования, и мы должны продолжать искать его. Наконец, есть третий вариант. Разработчик решит не принимать нас и не убеждать нас принять ее. Вместо этого она может принять решение покинуть команду.
Советы по написанию чистого кода
1. Сделайте код понятным для человека
Действительно, код, который мы пишем, будет интерпретироваться машиной. Однако это не означает, что мы должны игнорировать его читабельность и понятность. Всегда есть шанс, что другой человек коснется нашего кода или ему придется его использовать. Даже если мы сделаем наш код недоступным для других, мы можем захотеть вернуться к нему в будущем. По этой причине в наших интересах писать код таким образом, чтобы его было легко понять. как насчет этого?
Самый простой способ — использовать пробелы. Мы можем уменьшить наш код перед отправкой. Однако нет необходимости писать код, который выглядит как минимизированный. Вместо этого мы можем использовать отступы, новые строки и пустые строки, чтобы сделать структуру кода более читаемой. Когда мы решим воспользоваться этой практикой, читабельность и понятность нашего кода могут быть значительно улучшены. Тогда достаточно взглянуть на наш код, чтобы понять его. Давайте рассмотрим два простых примера.
// 不好的习惯
const userData=[{userId: 1, userName: 'Anthony Johnson', memberSince: '08-01-2017', fluentIn: [ 'English', 'Greek', 'Russian']},{userId: 2, userName: 'Alice Stevens', memberSince: '02-11-2016', fluentIn: [ 'English', 'French', 'German']},{userId: 3, userName: 'Bradley Stark', memberSince: '29-08-2013', fluentIn: [ 'Czech', 'English', 'Polish']},{userId: 4, userName: 'Hirohiro Matumoto', memberSince: '08-05-2015', fluentIn: [ 'Chinese', 'English', 'German', 'Japanese']}];
// 好的做法
const userData = [
{
userId: 1,
userName: 'Anthony Johnson',
memberSince: '08-01-2017',
fluentIn: [
'English',
'Greek',
'Russian'
]
}, {
userId: 2,
userName: 'Alice Stevens',
memberSince: '02-11-2016',
fluentIn: [
'English',
'French',
'German'
]
}, {
userId: 3,
userName: 'Bradley Stark',
memberSince: '29-08-2013',
fluentIn: [
'Czech',
'English',
'Polish'
]
}, {
userId: 4,
userName: 'Hirohiro Matumoto',
memberSince: '08-05-2015',
fluentIn: [
'Chinese',
'English',
'German',
'Japanese'
]
}
];
2. Используйте осмысленные имена для переменных, функций и методов
Что значит значимо? Значимое имя — это имя, достаточное для описания другими людьми, а не только нами, сможет понять назначение переменной, функции или метода. Другими словами, само имя должно быть рекомендуемой переменной, функцией или тем, какой метод используется, или что в нем содержится.
// Bad
const fnm = ‘Tom’;
const lnm = ‘Hanks’
const x = 31;
const l = lstnm.length;
const boo = false;
const curr = true;
const sfn = ‘Remember the name’;
const dbl = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((i) => {
return i * 2;
});
// Better
const firstName = ‘Tom’;
const lastName = ‘Hanks’
const age = 31;
const lastNameLength = lastName.length;
const isComplete = false;
const isCurrentlyActive = true;
const songFileName = ‘Remember the name’;
const yearsDoubled = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((year) => {
return year * 2;
});
Тем не менее, мы должны помнить о некоторых вещах. Использование описательных имен не означает, что мы можем использовать столько символов, сколько захотим. Хорошее эмпирическое правило состоит в том, чтобы ограничить имена тремя или четырьмя словами. Если нам нужно использовать более четырех слов, возможно, мы пытаемся сделать слишком много одновременно, и нам следует упростить наш код. Итак, давайте просто используем нужные символы.
3. Заставьте функцию или метод выполнять только одну задачу
Когда я начинал программировать, я писал функции и методы, которые выглядели почти как швейцарский армейский нож. Они могут справиться и сделать почти все. Одним из следствий этого является то, что часто трудно найти хорошее имя. Во-вторых, почти никто, кроме меня, не знает, что делает та или иная функция и как ею пользоваться. Ну иногда даже у меня бывают проблемы. Так что пришлось писать инструкцию. В-третьих, эти функции иногда непредсказуемы. Я устроил беспорядок.
Затем кто-то придумал это замечательное предложение. Пусть каждая функция или метод выполняет только одну задачу. Это простое предложение изменило все и помогло мне писать чистый код, по крайней мере, чище, чем раньше. С этого момента другие наконец смогли понять мой код. Или им не нужно столько времени, сколько раньше. Мои функции и методы также стали предсказуемыми. Имея один и тот же вход, они всегда производят один и тот же результат. Кроме того, именование стало проще.
Подумайте о реализации этой практики, если вам трудно найти описательные имена для функций и методов или если вам нужно написать длинные инструкции, чтобы другие могли их использовать. Пусть каждая функция или метод выполняет только одну задачу. Это также можно реализовать, если ваши функции и методы выглядят и работают как швейцарский армейский нож. Поверьте мне, эта универсальность не является преимуществом. Это достаточно негативный фактор, который в любой момент может дать о себе знать.
4. Используйте примечания для объяснения
Есть шутка о том, что больше всего разработчики ненавидят писать собственные комментарии, а другие их не пишут.
Неважно, как сильно мы пытаемся придумать осмысленные имена для наших переменных, функций и методов. Сам наш код все еще не настолько чист и понятен, насколько это возможно. Есть еще некоторые строки, которые нуждаются в дополнительных пояснениях. Проблема может заключаться не в том, что их сложно понять или использовать. И наоборот, почему мы реализуем ту или иную функцию или метод или почему мы создаем ее определенным образом, может не иметь смысла. То есть история неясна.
Иногда нам, возможно, придется использовать довольно нетрадиционные методы для решения проблемы, потому что ничего не работает или у нас недостаточно времени, чтобы придумать лучшее решение. Это может быть трудно объяснить в коде. В этом нам может помочь использование комментариев в нашем коде. Комментарии помогают нам объяснить другим, почему мы написали то, что написали, и почему мы написали это определенным образом. В результате другим не приходится догадываться.
Более того, когда мы объясним почему, другие могут найти лучшие способы решения проблемы и улучшения кода. Это возможно, потому что они знают, в чем проблема и каков желаемый результат. Не зная этой информации, другим будет сложнее найти лучшие решения. Или они могут даже не попробовать это, потому что не думают, что это нужно. Они могут предположить, что это наше намерение.
Поэтому всякий раз, когда мы оказываемся в ситуации, когда мы решаем использовать какой-то хак, быстрое исправление или нетрадиционный подход, давайте использовать аннотации, чтобы объяснить, почему мы сделали то, что сделали. Лучше использовать пару строк в качестве пояснительного комментария, чем заставлять людей гадать.
Сказав это, мы должны использовать комментарии только тогда, когда это необходимо, а не объяснять плохой код. Написание бесконечных строк комментариев не поможет нам превратить плохо написанный код в чистый код. Если код плохой, мы должны решить проблему, улучшив код, а не добавив инструкции по его использованию. Код очистки имеет приоритет над использованием ярлыков.
5. Будьте последовательны
Когда мы находим конкретную практику кодирования или стиль, который нам нравится, мы должны придерживаться его и использовать везде. Не рекомендуется использовать разные методы или стили кодирования в разных проектах. Это почти так же полезно и полезно, как и отсутствие какой-либо практики или стиля кодирования. Возврат к нашему старому коду не будет таким гладким и естественным, как мог бы быть. Нам все еще нужно некоторое время, чтобы понять методы кодирования, которые мы использовали в этом проекте, прежде чем мы сможем его использовать.
Лучше всего выбрать набор методов кодирования и придерживаться их во всех проектах. Тогда было бы проще вернуться к нашему старому коду и продолжить с того места, где мы остановились, или улучшить его. Как прошел эксперимент? Это хорошая вещь, чтобы попробовать новые методы кодирования. Это помогает нам находить лучшие способы выполнения нашей работы. Однако лучше экспериментировать с разными практиками в разных экспериментальных проектах или упражнениях, чем в нашем основном проекте.
Кроме того, когда мы решаем провести некоторые эксперименты, мы должны попробовать эту практику несколько раз и попробовать несколько примеров. Мы должны найти время, чтобы тщательно провести этот эксперимент. Мы должны применять его только тогда, когда мы уверены, что нам нравится практика, и нам это удобно. И когда мы решим это сделать, лучше всего внедрить нашу новую практику во всех наших проектах. Да, это займет время, но заставит нас как следует обдумать изменения.
6. Регулярно проверяйте свой код
Это мой последний совет по написанию чистого кода. Простое написание чистого кода — это еще не все. Наша работа не заканчивается последней точкой с запятой. Следующим шагом будет поддержание чистоты нашего кода. Чистый код требует обслуживания. Когда мы что-то пишем, мы должны это регулярно проверять, очищать и пытаться улучшить. В противном случае, если мы не пересмотрим и не обновим наш старый код, он быстро устареет. Как и наше оборудование. Если мы хотим поддерживать их в отличной форме, нам необходимо регулярно их обновлять.
Это особенно верно для кода, который мы используем каждый день. Код со временем становится более сложным и запутанным, а не более простым и чистым. Мы несем ответственность за то, чтобы этого не происходило, и за чистоту нашего кода. Единственный способ добиться этого — регулярно просматривать наш код. Другими словами, мы должны поддерживать его. Это может не понадобиться для проектов, которые нам больше не интересны или у которых нет будущего. Для других техническое обслуживание является частью нашей работы.
Мысли о написании чистого кода
Мы в конце этой статьи. Шесть практик, которые мы сегодня обсуждаем, возможно, не имеют наибольшего влияния или влияния. Однако они наиболее часто упоминаются опытными разработчиками. Вот почему я выбираю их. Я надеюсь, что этих практик или советов достаточно, чтобы помочь вам начать писать чистый код. Теперь, как и во всем, самое главное — начать. Итак, выберите хотя бы одну практику и попробуйте ее.
Большое спасибо за уделенное время. Хорошего дня!