Автор | Чжу Тяньфу (Хай Пей)

Редактор | Orange Jun

Произведено | Alibaba New Retail Tao Technology

Когда речь заходит о качестве кода, на ум приходит много слов: соглашения об именах, соглашения о форматировании, соглашения о ведении журналов, покрытие модульными тестами...

Но я думаю, что качество кода можно описать двумя словами: красивый и простой в использовании.

Красивый означает, что код удобочитаем, легок для понимания и прост в сопровождении, и другие не будут ругать вас, когда возьмутся за дело; простота в использовании означает, что код надежен, не подвержен ошибкам, и машина не будет ругать вас, когда он работает. Даже если есть ошибка, ее легко найти, остановить убыток и восстановить.

Зачем нужно улучшать качество кода?

Вот несколько моментов, на мой взгляд:

Улучшите ремонтопригодность кода и сократите расходы на привлечение новых людей
Способствуйте общению, содействуйте обмену знаниями и хорошо выполняйте резервное копирование
Обеспечьте единообразие стилей и упростите обмен приложениями между командами.
Создайте командную атмосферу, в которой код написан хорошо, а дизайн выполнен хорошо.

Но нужно пояснить одну вещь. Я считаю, что написание кода само по себе является творческим процессом, которым люди могут наслаждаться. Если будет слишком много правил и ограничений, написание кода потеряет радость творчества. Поэтому вот принцип для конструкция качества кода:

Только предложения, не обязательные для выполнения
Поощряйте творческое кодирование
Поощряйте художественное кодирование

Как получить качественный код

Есть два способа:

Первый способ: сначала создать хороший дизайн ---> затем реализовать его с отличным кодированием ---> продолжить отличный стиль кодирования
Второй способ: начать с плохого кода ---> продолжить рефакторинг и продолжить подход к отличному дизайну и стилю кода ---> продолжить

С чего начать построение качества кода?

**В первую очередь нужно знать, что такое хороший код, **Для этого нужны стандарты, то есть различные спецификации, которые мы часто видим, но я думаю, что есть несколько простых принципов, слишком много, не могу вспомнить Live, Есть несколько простых принципов, вы можете использовать их время от времени, чтобы судить, делаете ли вы это прямо сейчас.

Тогда это практика норм.Здесь нам нужны некоторые навыки и некоторые инструменты, которые помогут нам лучше следовать нормам.

**Далее идет измерение. **Глядя на влияние нашей практики на нормы, это то, что мы часто говорим и делаем Code Review, но Code Review также должен следовать определенным нормам и применять определенные навыки.

**За измерением следует улучшение, **Результаты CR нужно отслеживать вовремя, это самая важная часть, иначе CR будет бессмысленным.

Суммируйте необходимые, Replay - очень полезный инструмент, CR также нужно повторно установить, суммирует аспекты процессов, процедур CR и другие хорошие и плохие места, обновленные нормы и контрольный список.

Далее мы обсудим каждый шаг отдельно.

Спецификация: сначала узнайте, что такое хороший код

Из приведенного выше пути рождения высококачественного кода мы видим, что дизайн также является очень важной частью, поэтому наши спецификации включают спецификации дизайна и спецификации кодирования.В сочетании с нашим фактическим производством, вот спецификации для безопасного производства, поэтому есть Спецификация 3. Раздел: Дизайн, кодирование, безопасность производства.

Дизайн: сначала составьте отличный план

Для выражения дизайна рекомендуется использовать диаграммы.Диаграммы имеют более интуитивную коммуникативную способность, чем слова:

**Первый — это бизнес-схема, ** с ее помощью можно быстро построить наше понимание бизнеса, а затем взглянуть на код с пониманием бизнеса и получить вдвое больший результат, затрачивая половину усилий.

**Затем следует диаграмма вариантов использования, которая четко выражает обязанности, границы и объекты обслуживания нашей системы.В сочетании с блок-схемами бизнес-процессов мы можем быстро построить наше понимание обязанностей системы.

** Далее следует схема архитектуры. ** Исходя из наших ежедневных требований к дизайну, необходима схема архитектуры. Хорошая архитектурная диаграмма может быстро построить структуру для понимания людьми, а затем рассмотреть детали системы, и ее легко понять. Диаграмма архитектуры рекомендует спецификацию C4, которая является наиболее четко выраженной спецификацией диаграммы архитектуры, с которой я когда-либо сталкивался.

Затем используйте диаграммы последовательности, диаграммы состояний и диаграммы ER.И т. д., чтобы выразить дизайн критических и сложных деталей.

Однако наши повседневные потребности меняются, и планы не должны следовать единому шаблону, дизайн ради дизайна только увеличит нагрузку. Возьмите потребность в качестве первого принципа, и будьте в состоянии ясно выразить, что делать и как это делать. Вот рекомендуемые сценарии использования для каждого графа по сценарию:

Новое приложение/значительная модификация существующего приложения/сложного проекта

Схема бизнес-процессов (учет бизнес-фона)
Контекст системы C4, контейнер, это сборка фиг. 3
Диаграмма вариантов использования: существует несколько внешних субъектов
Диаграмма классов: более 5 ключевых моделей
Диаграмма состояний: более 3 состояний объекта
Диаграмма последовательности: более 3 участников ключевых процессов или сложных звеньев
Диаграмма ER: включает изменения базы данных (включая документы структуры таблицы данных)

Общие проекты/Основные процедуры

Блок-схема бизнеса
Диаграмма последовательности (сложные функции, ключевые процессы)

ежедневно

На лету

Кодирование: хорошие решения требуют хорошего кодирования

Самое главное в кодировании — быть читабельным, контролировать сложность, быть самоочевидным и позволять людям читать свой собственный код, как естественный язык.Это высшее состояние, и это также сказочное состояние. Кроме того, существует удобство сопровождения и изменяемость, и целью является возможность быстро и безопасно изменять код. Наконец, есть требование к элегантной реализации.Отличный код заставит людей хлопать по бедру.Это не редкость.В нашем грязном коде случаются вспышки.

Высший принцип кодирования:

удобочитаемость

Контроль сложности
self-document

ремонтопригодность

милость

✎ Иерархические спецификации

Разумное многоуровневое кодирование позволяет контролировать сложность каждого уровня, создавать многоуровневый дизайн, а также улучшать возможность повторного использования кода. Что касается расслоения, я думаю, то, с чем вы знакомы, это хорошо, и это хорошо, чтобы встретить большинство ситуаций в работе.Я не буду говорить о таких понятиях, как гексагональная архитектура, четкая архитектура и DODAF. Я рекомендую самую простую 4-уровневую многоуровневую архитектуру DDD, а именно:

用户界面/接口层
    ⇩
   应用层
    ⇩
   领域层
    ⇩
 基础设施层

Вот пример, используемый в моем реальном проекте:

-- bootstrap
    -- BeanConfig
-- application
    -- pv
        -- ChannelPvApplicationService
    -- sns
-- domain
    -- abtest
        -- AbtestService
    -- address
    -- coupon
        -- entity
            -- Coupon
            -- CouponStatus
            -- CategoryCouponTemplate
    -- category
    -- user
        -- UserRepository
        -- service
            -- OneIdService
            -- UserService
    -- item
        -- ItemRepostory
    -- live
        -- LiveStatus
-- infrastructure
    -- concurrent
        -- ThreadPoolExecutorFactory
        -- MonitorableCallerRunsPolicy
    -- dal
        -- IGraphDal
        -- TuringDal
        -- DefaultUserRepository
    -- dao
        -- MybatisItemDao
    -- util
        -- DateUtil
        -- MoneyUtil
        -- UriUtil
    -- monitor
        -- Event
        -- Timing
        -- TimingAspect
        -- TimingEvent
        -- Monitors
-- view
    -- atomicwidget
        -- BannerWidget
        -- CrazySubsidyWidget
        -- FeedItemsWidget
        -- NavigateBarWidget
        -- LiveWidget
    -- page
        -- HomeScreenPage
        -- CategoryFeedsPage
        -- SearchCardPage
    -- widget
        -- Widget
        -- DispatchableWidget
        -- Debuggable
        -- AbstractWidget
        -- AbstractDispatchableWidget
        -- WidgetDispatcher
        -- WidgetResult
        -- WidgetContextIncompatibleException

В приведенной выше структуре проекта, поскольку это проект руководства по покупкам, представление эквивалентно уровню пользовательского интерфейса, приложение — это уровень приложения, домен — это уровень домена, а инфраструктура — это уровень инфраструктуры.

Затем объясните разделение пакета:

Объект домена, объект значения, DTO, Сервис и другие определения помещаются в пакет субдомена, не имеют больших и всеобъемлющих пакетов, таких как сущность, сервис, внедрение (поддомен здесь представляет собой связное логическое понятие, соответствующее домену. Поддомен в дизайн, такой как элемент в приведенном выше примере, является поддоменом продукта в нашем руководстве по покупкам)
Определения констант должны максимально следовать за связанными классами.Как и статические поля классов, не должно быть больших и всеобъемлющих классов констант (за исключением тех, которые относятся к коммутаторам, но классы коммутаторов также должны быть разделены в соответствии с их обязанностями)

✎ Характеристики кода

Спецификация кода рекомендует протокол развития экономики Али, который является очень всеобъемлющим и также является основным требованием студентов Али. Спецификация кода рекомендует «Протокол развития экономики Али», который является очень всеобъемлющим и также является основным требованием студентов Али. Версия с открытым исходным кодом:Руководство по разработке Java для Alibaba.

Исходя из собственного опыта, вот несколько основных моментов:

имя

Не используйте общие имена (встречный пример: processData)
Старайтесь использовать полные слова, чтобы четко описать функцию и намерение, не бойтесь слишком большого количества слов.
Суффикс объекта Объекты домена без суффикса DTO: объекты, предоставляемые интерфейсом RPC как VO: объекты, взаимодействующие с внешним интерфейсом PO: объекты, взаимодействующие напрямую с базой данных

журнал

Все фоны должны иметь журналы операций и журналы изменения данных
Журнал должен быть настроен с асинхронной записью на диск.
В сети хранятся только журналы уровня ПРЕДУПРЕЖДЕНИЕ и ОШИБКА.
Все журналы должны иметь traceId
Журнал исключений должен иметь стек, входные параметры и информацию, которая может объяснить, что не так (унифицированный компонент можно экспортировать)
При печати логов запрещено напрямую использовать инструменты JSON для преобразования объектов в String

аномальный

Как бросать: попробуйте использовать непроверенные исключения, чтобы улучшить читаемость кода
Что делать: унифицированная обработка исключений с аспектом или унифицированная обработка с помощью SpringMvc ControllerAdvice
Объем аномального улова должен быть как можно меньше, а стабильный код следует отличать от нестабильного кода.
Не поглощайте исключения напрямую
Всегда будьте бдительны в отношении NPE и используйте опционально, чтобы обрабатывать больше

Примечания

Комментарии используются только для объяснения того, почему, а не того, что делается.

объектно-ориентированный

Принципы, которым необходимо следовать: SRP/OCP/LSP/ISP/DIP
Старайтесь раскрывать только поведение, а не данные
Используйте наследование с осторожностью, предпочитая композицию

Другие характеристики

Количество строк метода сохраняется в пределах одного экрана (в пределах 30 строк).
Сообщение фиксации отправки кода должно четко объяснять, что было сделано для контроля количества кода, отправляемого каждый раз (одна функция отправляется один раз).
Попробуйте использовать неизменяемые объекты для параметров (не изменяйте входные параметры, сохраните четкие входные параметры и выходные параметры) старайтесь не использовать неявные входные параметры (ThreadLocal)
Когда в структуре данных нет случайного чтения, используйте LinkedList вместо ArrayList
Стиль многоуровневый, и один и тот же слой использует единый стиль (дизайн/кодирование).

Безопасное производство

Безопасность производства еще не была систематически обобщена, и я упомяну несколько моментов, основанных на собственном опыте работы в области стабильности.Позже я узнаю больше от студентов, которые отвечают за безопасность производства, а затем обновлю:

Предотвращение потери капитала

Оценка/мониторинг ущерба активам

Легко восстановить

Любая новая онлайн-функция должна поддерживать оттенки серого.

Мониторинг/Тревога

Дизайн/контроль заднего кармана
мониторинг производительности
мониторинг исключений
Низкая допустимая ошибка для сигнала тревоги
Ключевые показатели для мониторинга (бизнес/технические)
Уменьшите количество ненужных сигналов тревоги

Понижение/лимит

Определите слабые зависимости и убедитесь, что слабые зависимости могут быть ухудшены
Определите проверяющие стороны, которые могут ограничивать ток, и проделайте хорошую работу по мониторингу и настройке ограничения тока.

Практика: как практиковать нормы

Дайте некоторые принципы и технические предложения, которые помогут реализовать нормы.

дизайн

Картинки не нужны, если вы можете объяснить, как это сделать и почему вы это делаете.

кодирование

Используя Aone-Idea, он интегрировал функции PMD/FindBugs/CheckStyle, что очень удобно для развивающихся студентов. Версия с открытым исходным кодом: Руководство по кодированию Java на Alibaba Alibabaplugins.jet brains.com/plugin/1004…
Сохраняйте лаконичность кода с помощью ломбока
Продолжайте рефакторинг и следуйте следующим принципам: DRY/YAGNI/Rule Of Three/KISS/POLA Каждое требование — это возможность провести рефакторинг и спросить себя, можете ли вы улучшить [читабельность/простота обслуживания]
Сделайте так, чтобы код читался как естественный язык
Разделение функционального и нефункционального кода

Безопасное производство

Это должно следовать спецификациям компании и отдела, учиться, а затем дополняться.

Метрики: как проверить результаты практики - CodeReview

Сроки проверки

Первый раз после тестирования проекта: Не рецензируйте проект накануне его запуска, если уже поздно вносить изменения, то результаты рецензирования легко отложить, потратив молодость участников.

Метод проверки

Небольшой модуль: Anytime/Aone code review/@backup одноклассники
Код проекта: очная проекция/проверка кода Aone + демонстрация IDE/команда проекта + фокус на одноклассниках

Проверить содержимое

Обратите внимание на то, насколько дизайн кода соответствует требованиям
Общий процесс
ключевой дизайн
Ключевая особенность

Предпосылка обзора

Код скомпилирован
Включить обнаружение Aone-Idea в режиме реального времени

Checklist

нормативный

удобочитаемость

Ремонтопригодность (высокая связность, низкая связанность, объектно-ориентированные принципы, сложность реализации и т. д.)

Изменяемость (расширяемость и т.д.)
Безопасность/надежность Проверка входных данных Обработка исключений Проверка границ
Эффективность зависит от разумности

Улучшение: отслеживание выполнения результатов CodeReview.

Проблемы с рисками во время выполнения должны быть изменены до запуска
Для других проблем, пожалуйста, завершите модификацию, прежде чем выходить в Интернет, насколько это возможно.Если она не изменена, вы должны добавить задачу и указать человека и время для ее изменения.
Используйте инструменты для подсчета и подсказки об улучшении результатов CR

Суммарная оптимизация

Регулярный обзор и подведение итогов (еженедельная встреча)
Обновление контрольного списка и спецификации кода
Откройте для себя хороший код и дизайн, регулярно демонстрируйте их и вознаграждайте.

позже

Вышеприведенные отрывки из слов каждой семьи плюс некоторые мои собственные мысли. Обучение — это постепенный процесс, и я все еще в процессе изучения качества кода, если будет прирост, я его обновлю. Если меня отвергнут, я все еще думаю, что это разумно, и я обновлю его.

Это также мои собственные направления обучения и практики, поэтому, если вы обнаружите, что мой код не делает этого, пожалуйтесь мне, а затем дайте мне предложения, чтобы я мог работать лучше.

Технологический отдел Департамента Дао - Глобальная маркетинговая команда

Набор серверных технологий, технологий данных, P6-P8. Мы являемся одним из самых важных маркетинговых направлений Ali, мы углубляемся в основной бизнес электронной коммерции, принимаем самые большие вызовы и добиваемся ожидаемого роста. Чтобы узнать подробности, нажмите «Читать исходный текст» ниже.

Возобновление доставки, электронная почта 📮:haipei.ztf@taobao.com

Список используемой литературы:

Есть много книг, которые рассказывают нам, как писать хороший код, вот некоторые из них, которые я прочитал и выучил:

«Искусство написания читаемого кода»
"Реконструкция"
«Рефакторинг и шаблоны»
«Путь к улучшению кода»

Google Engineering Practices Documentation

Модель C4 для архитектуры программного обеспечения