Написание чистого кода предназначено не только для тех, кто страдает ОКР, но и для каждого программиста, который работает в профессиональной среде и заботится о своей работе. Неважно, пишете ли вы код для побочного проекта, стартапа или предприятия, написание чистого кода должно быть одним из важнейших приоритетов при разработке программного обеспечения.
Так что же именно означает чистый код? Истинное определение этого может быть расплывчатым и спорным и зависит от точки зрения человека. Но, как программисты, мы также являемся авторами, постоянно пишущими код для чтения - эти люди могут быть вашими товарищами по команде или вы просто просматриваете код через некоторое время. Очень важно, чтобы мы писали читаемый и понятный код. Следующая цитата Роберта Мартина, автора книги Чистый код: руководство по созданию гибкого программного обеспечения »в значительной степени подводит итог важности написания читаемого кода:
Соотношение времени, затрачиваемого на чтение и на запись, значительно превышает 10: 1. Мы постоянно читаем старый код в рамках усилий по написанию нового кода
- Роберт К. Мартин
Короче говоря, написание чистого кода улучшает его ясность. Если вы работаете в команде и имеете привычку проводить регулярные проверки кода, то наличие согласованной и удобочитаемой базы кода гарантирует, что ваш код будет легче понять, что сделает проверки кода более продуктивными и потребует меньше WTF в минуту (см. Ниже 😂)
Даже если вы работаете в команде из одного человека, код, который вы пишете сегодня, будет казаться вам чуждым через полгода - так что привычка писать чистый и читаемый код в долгосрочной перспективе окупится. .
Еще один побочный эффект написания чистого кода - сокращение технического долга.
Технический долг - это концепция разработки программного обеспечения, которая отражает подразумеваемую стоимость дополнительных доработок, вызванных выбором простого решения сейчас, а не использованием лучшего подхода, на который потребовалось бы больше времени.
Чтобы сократить технический долг в будущем, мы должны написать чистый код сегодня - это похоже на вложение, которое окупится в будущем большим вознаграждением (экономия вашего времени и усилий), когда ваше приложение требует исправления ошибки или есть какие-то новые функции, которые нужно добавить.
Теперь, когда мы коснулись некоторых преимуществ написания чистого кода, мы можем углубиться в некоторые особенности того, как мы могли бы включить чистый код с помощью Swift.
В этой статье я коснусь 7 техник, которые программисты Swift могут использовать для написания чистого кода с помощью Swift.
1. Дайте вашим переменным понятные имена.
Вы когда-нибудь чувствовали себя виноватыми в использовании ярлыка для именования ваших переменных 'x', 'y', 'z' и 'i' или присвоения имен вашим функциям func1 (), temp (), и т. д. Было ли вам трудно понять тот же кусок кода, когда вы вернулись к нему через несколько недель? Приходилось ли вам дополнять этот фрагмент кода встроенными комментариями кода? Пожалуйста, не делайте этого - есть лучший подход - самодокументирующийся код.
Предоставьте своим переменным и функциям (включая аргументы, параметры и метки аргументов) значимые и удобочитаемые имена (по возможности близкие к английским), чтобы не требовать дополнительной документации для добавления ясности и смысла. Наличие встроенных комментариев для объяснения кода иногда может быть неправильным подходом, поскольку документация по этому коду может быстро устареть по мере изменения основного кода, что требует постоянного обслуживания.
Тема осмысленного наименования переменных и функций может показаться педантичной, но с практической точки зрения иногда именно эти мелочи имеют большое значение, особенно с учетом того, что некоторые приложения сегодня состоят из миллионов строк кода.
Пример:
var t:Int //elapsed time in days
Вместо того, чтобы предоставлять встроенный комментарий, как указано выше, сделайте это вместо
var elapsedTimeInDays:Int
Более описательное имя переменной может обеспечить большую ясность при использовании в других частях кода.
Важно отметить, что Swift как язык поощряет код быть кратким и по существу, но краткость никогда не следует рассматривать в ущерб ясности.
2. Назовите свои функции осмысленно.
Что касается именования функций, какой из двух вариантов вы бы предпочли - A или B?
// A static func createAlertDialog(withTitle title:String, withMsg message:String) -> AlertDialog // B static func setup(_ text:String, _ subText:String) -> AlertDialog
Очевидным ответом будет A, поскольку функция дает больше ясности относительно того, для чего она используется и как ее вызывать. Вариант B четко не объясняет, что делает настройка и что означают ее параметры.
Итак, что мы можем сделать из варианта А? Функция должна уяснять три вещи и четко указывать на них:
- Что он делает - Создает диалоговое окно с предупреждением
- Что ему нужно для работы - заголовок и сообщение
- Каков результат - он создал AlertDialog
То, как реализована функция, не имеет значения, поскольку именно так работает инкапсуляция.
Единообразно называйте свои функции. Если вы используете имя функции как «get» в одном классе, не используйте «fetch» в другом классе.
Не указывайте значения внутри функции жестко - лучше определите константу или используйте переменную. Использование переменной или константы не только сделает ваш код более читабельным, но также упростит изменение в одном месте и значение, доступное для использования в нескольких местах.
3. Используйте более длинные имена для переменных с более широким охватом.
Возьмем пример ниже.
for i in 1...5 {
print(i)
}
Когда область видимости узкая, как в приведенном выше цикле for, мы можем сделать исключения, чтобы не указывать более длинное и описательное имя переменной, поскольку код является изолированным и коротким, и его можно быстро понять, просто взглянув на него. . Если код внутри цикла for большой и охватывает более широкую область видимости, тогда имеет смысл иметь более длинное и описательное имя переменной.
Кроме того, когда область объявления переменной шире, как в примере ниже:
struct ShapeStruct {
let i: Int
}Переменная i, объявленная внутри структуры, скорее всего, будет использоваться вне области действия самого объявления Struct и может иметь большее значение. В этом случае предоставление более описательного и длинного имени переменной, как показано ниже, обеспечит большую ясность ее предполагаемого использования вне ее объявления.
struct ShapeStruct {
let distanceFromOrigin:Int
}
Ясность в момент использования. Когда функции и переменные объявляются один раз и многократно используются в остальной части кода, важно, чтобы имя функции / переменной было описательным и значимым, чтобы обеспечить большую ясность в точке использования.
4. Используйте произносимые и отчетливые имена для переменных и функций.
struct Map{
let dimfsd;
let dikfsd;
}
Два объявленных выше свойства не очень отличаются друг от друга и различаются только одним символом, что может привести к использованию в коде неправильного свойства и усугубить проблемы с отладкой. Кроме того, использование неразборчивых имен может затруднить их запоминание и вызвать трудности при обсуждении кода с вашими коллегами (например, во время сеанса проверки кода). Лучшим способом назвать свойства было бы:
struct Map{
let distanceInMilesFromStartToDest;
let distanceInKmsFromStartToDest;
}
5. Разделите большие методы / функции на более мелкие.
Первое правило функций - они должны быть небольшими. Второе правило функций - они должны быть меньше этого размера.
Разделение большой функции на несколько более мелких функций может иметь множество преимуществ. Во-первых, более мелкие функции обычно легче читать и понимать. Во-вторых, вызов нескольких более мелких функций внутри другой может быть самодокументированным (если имена функций выбраны правильно) и поможет избежать встроенных комментариев. В-третьих, наличие небольших функций может способствовать повторному использованию кода.
Сохранение функции менее 15 строк кода - хорошее начало. Но если это выходит за рамки этого, убедитесь, что вы держите его концептуально чистым для понимания.
Используйте не более трех аргументов. (Если аргументов больше трех, вы можете подумать о его рефакторинге в класс)
Функция должна делать только одно и делать это хорошо.
Функция, выполняющая только одно действие, служит хорошим руководством для написания чистого кода. Этот принцип не только способствует повторному использованию кода, но и упрощает написание модульных тестов. Если вы думаете, что ваша функция выполняет несколько задач, то было бы неплохо разделить ее на несколько более мелких функций.
Избегайте использования «и» в имени функции / метода, например «registerAndLogin». Вместо этого создайте два метода: один для регистрации, а другой - для входа в систему.
6. Чаще реорганизуйте код, чтобы он оставался свежим.
Мы много раз пишем плохой / неэффективный код; Причин для этого много - может быть, из-за чистой лени, может быть, приближается крайний срок выпуска, или, может быть, из-за нехватки кофеина в вашей системе. Часто мы сознательно пишем плохой код, ожидая, что вернемся и исправим его позже. Но в действительности в 9 случаях из 10 это не фиксировано, мы просто заняты следующей важной задачей. Последствия плохого кода могут снова и снова преследовать нас, особенно в тех случаях, когда приложению требуются новые улучшения или ошибка, которую необходимо быстро исправить. Это, в свою очередь, может привести к добавлению кода поверх существующего плохого кода, что может сделать код более уязвимым для поддержки в будущем.
Решением этой проблемы является постоянный рефакторинг кода - не только тогда, когда у вас есть время, но и превращение этого в обычную привычку. Добавление рефакторинга в качестве задачи в план проекта и выделение для него времени и ресурсов - хороший подход.
Начиная с Xcode 9 Apple представила ряд отличных встроенных инструментов Ninja, которые помогут вам выполнить быстрый рефакторинг кода Swift. Если вы до сих пор откладывали задачу рефакторинга кода, то сейчас самое время использовать Xcode для рефакторинга кода.
7. Покрытие модульных тестов
Одного чистого кода недостаточно, вы также должны убедиться, что ваш код может справиться с неопределенностями, которые могут потребовать изменений кода в будущем.
Каждый проект проходит неизбежную фазу, когда требуется изменение кода. Изменения кода могут быть связаны с исправлением ошибки или могут быть связаны с некоторыми изменениями API в другой части вашего приложения или внешней системы. Если вы планируете поддерживать свой код в актуальном состоянии и обновлять, вы должны убедиться, что любые изменения, которые вы вносите в код (включая рефакторинг), не нарушают какие-либо функции, которые ранее работали. Наличие хорошего покрытия модульным тестированием важно для обеспечения более стабильной кодовой базы, которая может оставаться устойчивой, несмотря на изменения кода.
Заключение
Таким образом, обязательно запомните и применяйте эти семь принципов «чистого кода», чтобы значительно повысить продуктивность вашей команды. Если вы хотите узнать больше о чистом коде, я бы порекомендовал вам почитать книгу ниже: (Это не что иное, как библия по написанию чистого кода)
Чистый код Роберта К. Мартина (дядя Боб)
Рефакторинг Мартина Фаулера.
Вышеупомянутые две книги являются обязательными в коллекции книг каждого программиста, и они предлагают бесценную информацию, которая может помочь вам в написании более удобного и качественного кода.
Если вы интересуетесь разработкой iOS и программированием на Swift, посетите мой блог на www.iosdeveloperblog.com, где я публикую интересные и полезные статьи, посвященные новостям разработки iOS, инструментам, фрагментам кода, методам, советам по повышению производительности, учебным пособиям и многому другому.
Спасибо за прочтение. Если у вас есть мысли по поводу этой статьи, обязательно оставьте комментарий.
Если вы нашли эту статью полезной, дайте мне несколько аплодисментов 👏.
И вы можете подписаться на меня в Твиттере здесь.
