Код-ревью, чуть не провалил пробный период!

спецификация кода
Код-ревью, чуть не провалил пробный период!

Автор: Брат Сяофу
Блог:bugstack.cn - 原创系列专题文章

Осаждайте, делитесь, растите и позвольте себе и другим получить что-то! 😄

Введение

好的代码往往也很好看

Код запускается для машин, но он также предназначен для просмотра людьми, и люди должны управлять им и поддерживать его, когда он выходит в сеть. затем написать可扩展,易维护,好读懂Код очень важен.

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

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

2. Конференц-зал

谢飞机, Вскоре после того, как я присоединился к компании, я был взволнован, чтобы написать требование, данное лидером, и код был быстрым. Бывало, что подходил тимлид: «Самолет, принеси свой компьютер, пойдем со мной в конференц-зал облака кода и проверим код».

leader: Самолет, почему твой код такой грубый!

самолет:Какие? 😱

leader: Если я вас не остановлю, я чувствую, что ваш код может взлететь.

leader: Посмотрите на это, просто скажите эту строку, этот лог набрался, была проблема после выхода в интернет, можете узнать причину?

самолет:как...

leader: А вот это, вот эта мысль тебя натолкнула, и это все жёлтым сообщается, почему бы тебе не посмотреть на это. Также этот код не отформатирован, он узнаёт вас через месяц, вы всё ещё его знаете?

leader: Вы прочитали спецификацию кодировки входа, которую я вам отправил?

самолет: Ой, читал, забыл, когда писал.

leader: Не спешите сначала писать, а потом код прочитав.Есть тоже хороший проект:«Бой Netty + JavaFx: имитация настольной версии чата WeChat», вы можете обратиться.

写代码不是以完成功能就算完事，还需要写的漂亮。评审后，飞机，坐回工位，收起了躁动的心，安心熟读手册并练习。

3. Обзор кода

1. Технические характеристики журнала

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

Как журнал в этом коде ниже;

public Result execRule(RuleReq req) {
    try {
        logger.info("执行服务规则 req：{}", JSON.toJSONString(req));
        // 业务流程
        return Result.buildSuccess();
    } catch (Exception e) {
        logger.error("执行服务规则失败", e);
        return Result.buildError(e);
    }
}
  • Вроде бы нет проблем, но в этом коде исключения нет информации о входных параметрах для метода. Если исключение метода выдает только некоторую информацию о стеке исключений, трудно найти конкретный триггер при втором вызове.
  • Кроме того, если в вашей службе системного мониторинга нет аналогичного метода отслеживания функции ID, то лучше в качестве условия запроса занести в журнал идентифицирующий ID этого звонка.

Измененный журнал:

public Result execRule(RuleReq req) {
    try {
        logger.info("执行服务规则{}开始 req：{}", req.getrId(), JSON.toJSONString(req));
        // 业务流程
        logger.info("执行服务规则{}完成 res：{}", req.getrId(), "业务流程，必要的结果信息");
        return Result.buildSuccess();
    } catch (Exception e) {
        logger.error("执行服务规则{}失败 req：{}", req.getrId(), JSON.toJSONString(req), e);
        return Result.buildError(e);
    }
}
  • Итак, теперь это изменено на такой журнал, очень удобно запрашивать проблемы, такие как поиск;执行服务规则100098921, то можно найти всю строку информации об этом звонке, что удобно для устранения неполадок.
  • Печать входных параметров в исключении предназначена для более удобного поиска проблемы и не требует сравнения контекста.
  • Существует множество методов ведения журнала, но цель любого ведения журнала — быстро найти проблему, когда она возникает, но также будьте осторожны, чтобы не записывать слишком много, это может быть упрощено и легко в использовании.

2. ИДЕЯ Советы

Много раз из-за вас рассеянность, небрежность, скользкие руки и написанные неверные коды,IntelliJ IDEA, выдаст вам предупреждение⚠подсказку, а вы, не видели, не видели, не видели!

Предупреждение от идеи;

小傅哥 & idea警告

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

3. Формат кода

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

Неформатированному коду не хватает души;

小傅哥 & 代码格式化

  • Для программистов, которые являются строго своими, по-прежнему неудобно иметь неформатированный код.
  • Глядя на фрагмент кода, если вы обнаружите пропущенный пробел, вы узнаете, отформатирован он или нет.

4. Модульное тестирование

Одиночный тест? охват? Разве недостаточно написать код?

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

Какова длина одного измерения;

  • Полнота одиночного теста в основном означает, что надежность кода лучше.Если одиночный тест можно написать хорошо, с вами не будет так много девушек-испытателей, болтающих с вами по базовому представленному коду.
  • Во многих компаниях вообще требуется превышение охвата одним тестом.В противном случае компиляция и отправка не разрешены.Есть плагины,которые можно комбинировать сJenkinsС использованием.

5. Спецификация отделения

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

Но в Интернете это не так: часто для обслуживания и развития системы требуется несколько человек одновременно. Как правило, это будет включать в себя: основную ветку, тестовую ветку, ветку этого требования, как использовать так много веток, как показано ниже;

  1. Мастер-ветка — это основная ветка и онлайн-ветка, в ней нельзя изменять код напрямую.
  2. Тестовая ветка — это ветка тестовой среды.Каждый должен объединить ветку, которую они разработали, в тестовую ветку после тестирования и отправить ее на тест для проверки.
  3. Ветка требований также является веткой личной разработки.Под одно и то же требование все пишут код в этой ветке.Конечно, также возможно, что ветка этого системного модуля разрабатывается одним человеком.

фокус, если кто-то не следует спецификации ветки или вообще не имеет понятия, напишите свой собственный код требований в тестовой ветке и напишите несколько ревизий и коммитов в тестовой ветке. Тогда это опасно, и серьезно затянет пуск, зачем?

  1. Тестовая ветка используется всеми для слияния и обмена собственным кодом, тогда эта ветка будет содержать 2 или более параллельных требований.Когда вам нужно выйти в интернет, вам нужно слить свой собственный код в мастер, но код тестовой ветки Это не может быть объединен с мастером, поэтому много неизвестного содержимого вообще не находится в онлайн-диапазоне.
  2. Затем, если вы хотите выйти в сеть, но не можете избежать тестовой ветки, вам нужно повторно вставить написанный вами код, что требует много времени.
  3. Тестовая ветка может быть удалена и повторно извлечена в любое время. Если кто-то сообщит вам об удалении и повторном извлечении, ваш код будет потерян.

6. Требования к уносу

提交测试，但还藏一个需求

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

  1. Хочу исправить баги оставленные в прошлом, но забыл сказать тест
  2. При разработке этого требования пришли другие продукты и добавили функции, заявив, что функций очень мало, и они не отправляли электронные письма, чтобы уведомить соответствующих тестировщиков.
  3. Когда я вижу, что определенный кусок кода, написанный ранее, слишком грязный, я думаю о его оптимизации, у меня высокая уверенность в себе и мне не нужно рассказывать тесту.

В настоящее время, если код, который вы отправляете, выходит за рамки тестирования и возникает проблема, вы можете только разработать собственное сопротивление. И во всех R&D командах почти невозможно пустить спрос на увлечение в онлайн.Если вы это сделаете, вас не будут считать кредитом.Если вы сделаете проблему, вас отругают.

Так что не берите на себя! Даже если ты добрый!

7. Аномальный процесс

擦屁屁的纸，80%的面积都是保护手的！

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

Итак, каковы исключения?

  1. Платеж прошел успешно, не удалось отправить сообщение MQ, требуется компенсация работникам
  2. Ошибка вызова интерфейса PRC, время ожидания сети истекло, фактический успех
  3. Интерфейс является идемпотентным, а результаты нескольких вызовов непротиворечивы.

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

8. Код загроможден

小傅哥 & 代码成坨

CRUD往往可能是因为你的设计，换个人写也许不同

Много раз я разрабатывал и пишу код, не задумываясь о том, стоит ли его расширять.Короче говоря, один класс + десятки строк ifelse могут справиться со всеми потребностями. Когда вы будете разрабатывать что-то подобное в следующий раз, просто вставьте это и поработайте с этим, это сработает.

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

Здесь я рекомендую написанную мной книгу «Повторное изучение шаблонов проектирования Java». В книге 22 реальных бизнес-сценария, соответствующих 59 наборам кейс-проектов, и написан PDF-файл из 180 000 слов и 271 страницы, включая транзакции, маркетинг, всплески, промежуточное ПО, исходный код и т. д. 22 реальная сцена. можно добавитьПриобретение Сяо Фу Гэ WeChat: fustack

9. Производительность SQL

select * from table where status = 1 limit 200;

Это SQL для запланированной задачи сканирования таблицы базы данных., этот sql будет регулярно сканировать базу данных, сканировать статус 1 в таблице базы данных для обработки и каждый раз сканировать 200 строк. Вы нашли что-то не так?

  1. Просто сканируйте нужные поля, а не все поля
  2. Этот sql будет становиться все медленнее и медленнее, даже если поле состояния проиндексировано. так какstatusНевозможно исключить большое количество других полей состояния, и по мере увеличения данных это все еще полное сканирование таблицы.

Итак, как оптимизировать, на самом деле оптимизация относительно проста, вам нужно запросить наименьший id, который соответствует условиям по статусу, а затем добавить его в условия запроса sql.id > xx, ты сможешь. Кроме того, если ваша задача требует сканирования несколькими работниками для повышения эффективности, вы можете увеличить дизайн номера дома для повышения эффективности сканирования следующим образом;

小傅哥 & 门牌号扫描

10. Сопутствующее программирование

Последний момент, о котором я хочу рассказать при обзоре кода,陪伴式开发, может это и не партнерское программирование, не совместное сотрудничество, но одному НИОКР нужна постоянная помощь другого НИОКР. Иногда это может быть очень простой вопрос, и я не хочу его проверять, или я не знаю, как его проверить, а просто спрашиваю.

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

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

4. Резюме

  • Вышеизложенное представляет наиболее распространенные моменты, связанные с проверкой кода, которые в основном являются местами, которые многие разработчики НИОКР склонны игнорировать и делать ошибки. Эти проблемы, но какую вы вынесете, не большие. Но работая в коде, возможны фатальные или неприятные вещи.
  • Если вы хотите уметь писать код хорошо, не только ответ постройки самолета на собеседовании, какая временная сложность, какая реентерабельная блокировка, какое красно-черное дерево, какой ДДД, пока правильно посадить не сможете а использовать эти технологии, мол Всё что больше - пустой трёп.
  • Нет ничего плохого в том, чтобы больше учиться, больше смотреть и больше спрашивать, но только если вы сможете расти сами, применять полученный опыт для развития бизнеса и писать масштабируемый и удобный в сопровождении код, вы действительно сможете улучшить себя. Это также позволяет как возможность остаться, так и возможность выйти.

Пять, рекомендация серии

Категории