Ваша команда когда-нибудь сталкивалась с таким опытом: низкая эффективность разработки, найм большого количества людей, работа сверхурочно каждый день, но не так много работы, частые онлайн-баги, сумасшедшие лидеры, беспомощность среднего звена, постоянные жалобы инженеров и трудности с поиском ошибок. На самом деле это недостатки плохого качества кода. Качество кода является основой управления качеством НИОКР, оно определяет эффективность разработки всей команды разработчиков, качество проекта, другие средства мониторинга, тревоги, журналы и другие средства могут быть компенсированы только впоследствии. В этой статье для справки приведены некоторые примеры и методы обеспечения качества кода.
Качество кода само по себе не имеет определенного количественного показателя, и в зависимости от разных этапов развития компании, размера команды, характера проекта и т. д. требования к качеству кода также различны. Однако если в проекте происходят следующие ситуации, значит, качество кода заслуживает внимания.
Вышеупомянутые проблемы в основном вызваны плохим качеством кода, в том числе отсутствием комментариев, отсутствием документации, плохим именованием, плохой иерархией проекта, запутанными связями вызовов, жестким кодом везде, временными решениями и так далее. Как всегда обеспечить высокое качество кода и избежать вышеуказанных проблем? Конечно, техническое качество команды очень важно, кроме того, есть некоторые методы, которым нужно следовать.
1. Знакомство с соглашениями о кодировании
Строгое выполнение спецификаций написания кода может сделать код проекта и даже компании полностью единым по стилю, как будто его писал один и тот же человек, а удачно названные переменные, функции, классы и комментарии несомненно улучшают читабельность кода . Специально реализовано на уровне реализации, вы можете ссылаться на стандарты кодирования Google или официальные стандарты кодирования Java, которые можно найти в Интернете.Главное — строго соблюдать их, и во время проверки кода необходимо указывать и требовать строгие требования. быть изменены.
Реальная ситуация часто такова, что, хотя все знают, как выглядит хорошая спецификация кода, в процессе написания кода его исполнение неудовлетворительно, во многих случаях не уделяется должного внимания пониманию, и не имеет значения, как выглядит код. имя переменной или функции такое. , поэтому не хватает внимательности, и многие комментарии не пишутся.При просмотре кода каждый не имеет ничего общего со своим собственным менталитетом, или они чувствуют, что нет необходимости сосредотачиваться на деталях, что приводит к постепенному износу всей кодовой базы. Поэтому здесь следует подчеркнуть, что успех или неудачу определяют детали, и ключевым моментом является улучшение понимания командой спецификаций кода и их строгое выполнение.
2. Пишите качественные модульные тесты
Модульное тестирование — один из самых простых в выполнении и один из самых быстрых способов улучшить качество кода. Но все еще есть много компаний, которые не уделяют должного внимания модульному тестированию, в том числе некоторые крупные интернет-компании, которые не пишут или пишут вскользь.
Некоторые инженеры считают, что достаточно иметь команду тестировщиков, а написание модульных тестов — пустая трата времени. На самом деле тестирование группы тестирования и модульное тестирование находятся на разных уровнях. Тестирование группы тестирования обычно представляет собой тестирование черного ящика и интеграционное тестирование на уровне системы. Для сложных систем комбинация взрывается, и группа тестирования не может исчерпывающе перечислить все тестовые случаи. . Модульное тестирование — это тест на уровне кода, обычно тест для конкретного класса. Поскольку невозможно гарантировать, что система в целом соответствует нашим ожиданиям на 100%, модульное тестирование может, по крайней мере, гарантировать, что наш код работает должным образом на детальном уровне.
Некоторые инженеры считают, что нет времени писать задачи разработки. Это все же недостаточно внимания к модульному тестированию, я думаю, что это необязательная часть, поэтому есть такая идея. Хорошо пишите модульные тесты, экономьте много времени на исправлении онлайн-ошибок и уделяйте больше времени разработке.
Есть также много инженеров, которые пишут модульные тесты, но тестируют только обычные процессы. Большинство ошибок в коде вызваны нештатной ситуацией, когда код пишется без всестороннего рассмотрения, а нормальный процесс вообще не вызывает проблем. Функция модульного тестирования состоит в том, чтобы проверить, работает ли код должным образом в различных аномальных условиях, поэтому только обычное тестирование процесса не может играть реальную роль модульного тестирования.
В нормальных условиях объем кода юнит-тестов больше, чем код для тестирования, а это обычно в 1-2 раза.Технических сложностей при написании юнит-тестов не так много.Писать скучно, поэтому написание качественного юнит-теста испытаний зависит от терпения инженеров с одной стороны и строгих требований команды с другой стороны. Конечно, все они основаны на признании важности модульного тестирования.
3. Обзор кода, который не является простой формальностью
Если многие инженеры не уделяют много внимания модульному тестированию, то проверка кода не очень приемлема. Я разговаривал со многими людьми из крупных интернет-компаний, но они не согласны с код-ревью.Большинство отзывов сводится к тому, что эту штуку нельзя реализовать хорошо, и это пустая трата времени.Да, как бы гладко ни было обзор кода, это займет время Да, ключ в том, готовы ли мы потратить 2 дня на написание кода и 5 дней на исправление ошибок, или мы готовы потратить 3 дня на написание кода и полдня на исправление ошибок.
На самом деле преимущества проверки кода заключаются не только в том, что она может значительно улучшить качество кода и уменьшить количество ошибок в коде.Если подумать, если у нас нет проверки кода, код, который мы обычно пишем, будет «секретно». Неизбежно, что некоторые люди не будут дисциплинированы.С проверкой кода, прямой трансляцией кода, разоблачением грязного кода все будут более серьезными. Во-вторых, проверка кода также является эффективным способом технического руководства.Каждая проверка кода представляет собой анализ случая, который может помочь младшим инженерам развивать стандарты кодирования, улучшать качество кодирования, способности проектирования и даже способности архитектуры, и наоборот. хороший код, написанный другими, — это тоже своего рода обучение и совершенствование для себя.
Кроме того, строгий код-ревью может не только обеспечить качество кода, но и сформировать хорошую техническую атмосферу.
4. Сначала разработайте нетронутые документы
Написание технической документации — мерзость для большинства инженеров. Вообще говоря, перед разработкой системы или важного модуля или функции необходимо написать технический документ, а затем отправить его той же группе или соответствующим коллегам на рассмотрение, а затем разработать его, когда в обзоре нет проблем, так что консенсус может быть достигнут заранее, и разработанные вещи не будут псевдонимами, и когда этап проверки кода выполняется после завершения разработки, рецензент кода может быстро понять код, прочитав документ разработки.
Кроме того, документация является важным активом для команды и компании. Для новичков очень полезно присоединиться к компании, чтобы ознакомиться с кодом, продуктами и передачей задач. эффективный способ отказаться от мастерской разработки и индивидуального героизма, и это способ обеспечить эффективное командное сотрудничество.
Однако есть много инженеров, которые говорят, что не умеют писать технические документы, не знают, что писать, и хотят дать шаблон или справочник. Я думал о том, мог бы я дать фиксированный шаблон раньше, но я в конце концов сдался. Это сложно. Сложность в том, что направленность каждого проекта разная, и ее нелегко обобщить. Нет смысла быть поучительным . Вообще говоря, содержание документа в основном состоит в том, чтобы прояснить, что нужно сделать, включая предысторию проблемы, какая проблема решается, как использовать или вызывать извне, как это реализовать внутри, большая архитектура, ключевые функции и алгоритмы. и т. д., а также некоторые нефункциональные сексуальные соображения.
5. Продолжайте рефакторить, рефакторить, рефакторить
Лично я против того, чтобы не обращать внимания на качество кода и нагромождать гнилой код, если его нельзя поддерживать, то его рефакторят или даже переписывают. Иногда в проекте слишком много кода, и полностью выполнить рефакторинг сложно, а в итоге получается странный монстр, от которого еще больше хлопот!
Отличный код или архитектура не проектируются полностью с самого начала, точно так же, как отличные компании или продукты также повторяются, мы не можем удовлетворить будущие потребности на 100%, и у нас нет достаточно энергии, времени и ресурсов для того, чтобы далекое будущее оплатило счет, поэтому с развитием системы неизбежен рефакторинг кода.Хотя вышеизложенное не поддерживает большой рефакторинг, который подталкивают к повторному запуску, непрерывный небольшой рефакторинг по-прежнему более уважаем, и это также время. эффективные средства для обеспечения качества кода и предотвращения повреждения кода. Простое предложение: не ждите, пока накопится слишком много проблем, прежде чем приступать к рефакторингу. Кто-то всегда должен нести ответственность за код в целом и менять код, если делать нечего. Не думайте, что рефакторинг кода — это пустая трата времени и не правильные вещи!
Особенно для некоторых команд разработки бизнеса, иногда для того, чтобы быстро завершить продукт или бизнес-функцию, они гонятся только за скоростью, жёстким кодом везде и нагромождают какой-то гнилой код, вообще не учитывая нефункциональные требования.Такая ситуация относительно распространена. Но это не имеет значения, вы должны помнить о рефакторинге, когда у вас есть время, иначе плохой код будет накапливаться, и никто однажды не сможет его поддерживать.
6. Проект и команда "микросервис"
Поддерживать можно только небольшие проекты, большие проекты поддерживать нельзя. Когда команда относительно небольшая, выглядит как десяток человек, объем кода не большой, не более 100 000 строк, не важно как разрабатывать и управлять, все понимают работу друг друга, качество кода очень плохое , это большое дело Перепишите еще раз. Но если это очень большой проект, с сотнями тысяч строк кода и десятками разработок и сопровождения, в основном никто не может нести ответственность за код.
Поэтому, когда проект слишком большой, необходимо разделить код и команду, модульность, разделить большую команду на несколько маленьких команд, а большой проект разбить на несколько маленьких проектов, чтобы код каждой команды и каждого Проект отличается. Как и для многих, нет ситуации, когда качество кода слишком низкое, чтобы его поддерживать. На самом деле, многие технологии также отражают эту идею, например, soa, микросервисы, такие маленькие, как jar, .so и другие разработки модулей lib , и инкапсуляция классов Class. , это раздвоение мысли.
7. Обращайте внимание на код и внимание к деталям
Все остальные методы, описанные выше, предназначены для лечения симптомов, а не первопричин.Нахождение нужных людей и правильное их использование, а также создание превосходной технологической культуры являются основой совершенства. Есть много инженеров, которые больше заинтересованы в изучении архитектуры, инструментов и вещей на уровне фреймворка.Я видел много инженеров, которые не писали код в течение трех или пяти лет, а затем стали архитекторами.Они перестают писать код и валяют дурака. .Это нехорошо.Информация в Интернете настолько прозрачна. ,Разные люди работают над одним и тем же проектом.На самом деле окончательный проект архитектуры и функций примерно одинаков.В конце концов,каждый может внедрить эту систему.Однако некоторые люди делают система с множеством ошибок, низкой производительностью и плохой масштабируемостью.Ну, можно вызвать не более одного POC.
Конкуренция между экспертами по-прежнему заключается в деталях, достаточно ли оптимизирован алгоритм, невысока ли эффективность доступа к данным, достаточно ли памяти и т. д., которые в совокупности определяют, достаточно ли хороша система.
Конечно, это не значит, что изучение фреймворков, инструментов и архитектурного проектирования не имеет значения. Главное, чтобы была глубина. Я надеюсь, что этому можно научиться на практике, а не читая паблики и блоги WeChat повсюду.
Отечественным инженерам вообще не хватает глубины.Через несколько лет технологии они перейдут на управление или чистое архитектурное проектирование без написания кода.Однако в зарубежных странах по-другому.Кодеров постарше много,поэтому там больше отличных открытых исходные проекты за рубежом, но мало в Китае.
8. Если рабочий хочет делать добрые дела, он должен сначала наточить свои инструменты
Многие низкоуровневые проблемы с качеством в коде не нуждаются в ручном просмотре, и есть множество готовых инструментов для java-разработки, таких как: checkstyle, findbugs, pmd, jacaco, sonar и т.д.
Checkstyle, findbugs и pmd — это инструменты статического анализа кода, которые анализируют исходный код или байт-код для поиска дефектов кода, таких как несоответствие параметров, неоднозначные вложенные операторы, неправильная рекурсия, недопустимые вычисления и возможные нулевые указатели. Цитаты и многое другое. Все три могут быть интегрированы в инструменты сборки, такие как gradle.
Jacoco — это инструмент статистики покрытия модульными тестами. Его также можно интегрировать в инструменты сборки, такие как gradle, для создания красивых отчетов статистики покрытия тестами. В то же время Eclipse предоставляет подключаемый модуль, который позволяет EclEmma интуитивно просматривать покрытие модульных тестов в ИДЕ. .
Sonar Sonar — это платформа для управления качеством кода. Отчеты о качестве, такие как статический анализ, покрытие модульными тестами и т. д., могут отображаться и управляться на единой платформе.
Наконец, резюмируя
Все вышеперечисленные методологии не должны быть чем-то новым, и нет такого понятия, как книга сокровищ подсолнечника.Это очень просто сказать.Сейчас, когда Интернет так развит, информация очень прозрачна, поэтому все знают общее направление, конкретная стратегия и структура. Все похожи. В конце концов, кто делает работу лучше всего, зависит от исполнения и деталей. Я часто слышу, как люди говорят, что мы провели модульное тестирование, мы провели тестирование производительности, но в конце все еще есть куча проблем с производительностью и багов, так что надо подумать, достаточно ли хорошо вы это сделали, сделали ли вы детальный анализ конкретных проблем, и не используете ли вы строгость для формирования замкнутого цикла от принятия решения до выполнения к оценке.Много раз это просто пустые лозунги,а лозунг 100 баллов.Набрал 50 баллов,а в итоге оценки не было вообще,и никто не знал хорошо это или плохо.
Автор Ван Чжэн, бывший инженер Google, автор книг «Красота структур данных и алгоритмов» и «Красота шаблонов проектирования», на которые подписано 150 000 человек. Общедоступная учетная запись WeChat: Сяо Чжэнгэ, подпишитесь на общедоступную учетную запись WeChat, чтобы ответить на PDF-файл, и получите более 100 страниц изучения алгоритмов и обмена опытом интервью с инженерами Google.