Разработка программного обеспечения: Код как ремесло
На протяжении многих лет я работал на многих технически ориентированных должностях. Это включает в себя проектирование, контроль качества, разработку автоматизированного тестирования, DevOps, сборку и выпуск и, наконец, архитектора платформы. Я видел МНОГО кода. Я видел некоторые чистые, а некоторые нет. Я работал в организациях больших и малых, государственных, частных, прибыльных и нет. Одна вещь, которая действительно бросается в глаза, это то, насколько очевидно, когда кто-то заботится о своем ремесле. Они показывают это, написав чистый код.
После достаточно долгой работы с программным обеспечением и просмотра достаточного количества кода, чтобы глаза закружились… Я думаю, что слышал практически все оправдания в книге относительно того, почему неудачная реализация кода, отсутствие документации, монолитная реализация или отсутствие комментариев по какой-то причине допустимы. Давайте рассмотрим некоторые из моих любимых фраз (ну, не моих любимых, но, по крайней мере, некоторые из наиболее популярных), которые я слышал за эти годы:
Разработчик в классе из 4500 строк: код не документирован, потому что код на самом деле ЯВЛЯЕТСЯ документацией.
Разработчик: комментарии быстро устаревают и на самом деле бесполезны.
Архитектор их Monolith: у нас есть архитектура, похожая на Micro Service, хотя наша база данных представляет собой одну массивную базу данных Cassandra DB.
Разработчик: это не спагетти-код, это объектно-ориентированный Perl.
Хорошо, я думаю, мы установили, что плохие методы написания кода есть везде. Я уверен, что у вас есть свои собственные страшилки о программировании, и я хотел бы их услышать. Хотя я считаю, что есть несколько статей о хороших методах кодирования, я думаю, что этот вопрос заслуживает серьезной статьи о надежных методах чистого кодирования.
Чистый код — это просто забота о ремесле. Это заблаговременное обдумывание следующего человека, который придет, чтобы исправить или изменить его. Итак, имея это в виду, давайте начнем с некоторых основ:
Метод 1: Архитектура микросервисов:
Эта концепция существует столько же, сколько существует программное обеспечение. В одну эпоху это называлось инкапсуляцией, в другую — SOA [сервисно-ориентированная архитектура]. Совсем недавно он назывался Micro Services. Давайте быстро взглянем на схему микросервиса.
Здесь важно отметить одну важную вещь — разделение баз данных между службами. Это ОЧЕНЬ важный компонент микросервиса. Это делается для того, чтобы гарантировать возможность выпуска и обновления службы в любое время без негативного влияния на другие службы.
Начать проще, чем вы думаете. Просто по одному начните организовывать вещи в эту архитектуру. Разделяйте проблемы и медленно разбивайте монолит на микроориентированное решение по мере продвижения. Прежде чем вы это узнаете, вы окажетесь в стране микросервисов.
Техника 2: Практика правильного именования переменных
Именование переменных часто остается на усмотрение разработчика и может иметь множество непредвиденных последствий в будущем. Одна практика, которую я ненавижу, - это чрезмерное использование X, Y, J, Z, B и т. Д. В качестве имен переменных. Давайте посмотрим на пример:
В этом примере мы видим чрезмерное использование переменных e, c, f, a и т. д. Ни одна из переменных не имеет никакого значения и не объясняет их назначение. И наоборот, мы могли бы использовать описательные имена переменных. Вот несколько советов:
- Выбирайте описательные имена [оценка вместо s, единица вместо u и т. д.]. Лично я использую венгерскую нотацию:
a) bBusy : boolean
b) chInitial : char
c) cApples : количество элементов
d) dwLightYears : двойное слово (системы)
e) fBusy : флаг (или float )
f) nSize : целое число (системы) или количество (приложения)
g) iSize : целое число (системы) или индекс (приложения)
h) fpPrice: число с плавающей запятой
i) dbPi : double (Systems)
j) pFoo : указатель
k) rgStudents : массив или диапазон
l) szLastName : строка с завершающим нулем
m) u16Identifier : без знака 16-битное целое (системы)
n) u32Identifier : 32-битное целое число без знака (системы)
o) stTime : структура часов
p) fnFunction : имя функции
2. Будьте последовательны в своих условностях. Если такового не существует, создайте его, если он существует, следуйте ему.
3. Соблюдайте разумную длину. Не пишите абзац для имени переменной и, наоборот, не используйте ни одной буквы.
Метод 3: префикс методов и функций с комментарием, описывающим ввод-вывод:
Это личное предпочтение. Один действительно удобный прием, которому я научился, состоит в том, чтобы ставить перед моими методами простой комментарий, описывающий, что метод принимает и что он выдает. Это позволяет легко понять общий ввод-вывод метода и быстро просматривается.
Эта практика пришла из старой школы Java, но я считаю, что она довольно актуальна независимо от языка.
Прием 4: оставьте спагетти для еды, а не для кода
Спагетти-код существует уже несколько поколений; Клянусь!. Это действительно легко предотвратить, но ТОННЫ магазинов программного обеспечения ОС делают это. Вот как это работает:
Разработчик пишет метод или функцию и ссылается на нее. Затем на это ссылается что-то еще, на что ссылается что-то еще. ЗОМГ! Конечный результат выглядит так:
a->b->c->d->e
Лучшей практикой здесь является сохранение ваших вызовов на уровне 1 в глубину. То есть создать экземпляр объекта, вызвать метод. Если метод должен быть общим для всех классов, используйте базовый класс и наследуйте его. Старое правило KISS имеет большой смысл.
Техника 5: Ограничение комментариев к коду и «TODO»
Комментарии к коду могут быть действительно полезны в определенных местах, однако они также могут быть формой неправильного направления и технического долга. При написании комментариев к коду следите за тем, чтобы они либо обновлялись, либо удаляли старые бесполезные комментарии к коду.
Если их не проверить, они могут предоставить ложную документацию, которая сбивает людей с толку и добавляет места для ошибок.
Техника 6: Практикуйте код как ремесло
Использование кода как ремесла действительно важно. Это просто означает, что вы заботитесь о своем конкретном ремесле и качестве своей работы. Очень похоже на то, как плиточник заботится о своем ремесле. Если мы тратим дополнительное время, необходимое для того, чтобы по-настоящему заботиться о своей работе, работа говорит сама за себя.
Многие из наших коллег часто с гордостью говорят, что они ленивы. Ленивое программирование в наши дни стало популярной практикой. Хотя какая на самом деле разница между ленивым программистом и совсем неквалифицированным ландшафтным художником? Давайте не будем впадать в этот шаблон.
Заключение
Написание чистого кода не должно быть трудным. Это просто вопрос того, чтобы помнить о людях, которые придут позже, когда вы будете это писать. В Интернете есть несколько отличных ресурсов для написания чистого кода, который можно обслуживать. Каковы некоторые из ваших практик? Какие у вас страшилки?
Я хотел бы услышать.
