Оригинал: Miss Sister Taste (идентификатор публичной учетной записи WeChat: xjjdog), добро пожаловать, пожалуйста, сохраните источник для перепечатки.
Теперь дайте вам возможность пожаловаться на решения или коды других людей, с чего вам начать?
Вы чувствуете, что есть тысячи слов, которые вы хотите взорвать, и в конце вы думаете только о проблеме кодового наименования? Если вы java, вы подумаете о «Спецификации разработки Baba», но это все еще на уровне кода. в том числеsonarЯ дал это, и нашел некоторые очевидные проблемы.
Сегодняшние разработчики смешанные, и чтобы минимизировать риски в зародыше, нужны какие-то средства. Одним из средств является технический обзор, использующий зоркие глаза масс, чтобы обуздать пропасть.
1. Классификация технического обзора
Технический обзор сократит время разработки продукта, но улучшит производительность качества продуктов, программного обеспечения и обладает хорошей масштабируемостью, легко реконструируется, в долгосрочной перспективе это то, что принесет пользу будущим поколениям.
Если вы не можете полностью понять возможности НИОКР отдельного устройства, вы должны настаивать на технической проверке, которая может уберечь вас от многих скучных и низкоуровневых ошибок и дефектов.
Но, учитывая текущую ситуацию, когда большинство совещаний не улавливают главного, часты отклонения. Правильно смотреть техосмотр, не выдавать запаха пороха и не идти напролом, это две крайности.
Что касается технологических исследований и разработок, я обычно делю обзоры технологий исследований и разработок на три категории. Ввиду проблем с пространством, укажите на конец.
Согласно общему процессу разработки программного обеспечения. Его можно условно разделить на: обзор программы, обзор дизайна, обзор кода. Слишком часто мы сосредотачиваемся только на проверке кода и обнаруживаем некоторые структурные проблемы с опозданием, что приводит к высокому качеству кода, но низкому общему качеству.
2. Обзор программы
2.1. Программный фон
1. Объясните проблемы и опасности, которые должен решить план.
Это простая причина создания проекта. Если проблема не держится, дизайн бессмысленен.
2. Попробуйте решить большую проблему с помощью одного решения.
Наконец, соедините задачи одного и того же цикла последовательно, чтобы увидеть, является ли общее решение оптимальным. Так называемый первый дивизион, а затем тотал, может не только позаботиться о своей части.
2.2, можно приземлиться
1. План должен иметь возможность реализоваться и перейти, не отклоняясь от реальности, чтобы построить утопию.
Быть разработанным в соответствии с ресурсами компании могут быть скоординированы. Например, компания не хочет платить большие доллары, чтобы купить сервер, журнал не подходит для печати слишком много подробностей, сохранить слишком долго.
2, цена должна быть максимально маленькой, сможет выполнить шаг за шагом, поэтапное принятие.
Для функций с немного большим периодом里程碑, чтобы существовали правила, которым необходимо следовать при внешней синхронизации и отслеживании хода выполнения.
2.3. Вводить ли новые компоненты
1. Можно ли удовлетворить спрос, используя имеющиеся ресурсы.
В идеале полная, в реальности очень худенькая. Хорошее решение не обязательно является лучшим решением в отрасли. Стоимость внедрения нового компонента очень велика, даже если он стабилен.
2. Исследование и обслуживание новых компонентов.
Если вам нужно представить некоторые компоненты, должны быть базовые исследования, а также компоненты для будущих соображений обслуживания.
2.4, хорошая масштабируемость
1, программа должна быть впереди, избегая краткосрочной реконструкции.
Это вообще нормально через 2-3 года, но во избежание недальновидности, типа того, что переворачивают и перезапускают меньше чем за полгода.
2, чтобы иметь хорошую масштабируемость.
Масштабируемость неизбежно приведет к увеличению количества модулей и количества внешних интерфейсов, которые должны соответствовать «приземляемым» выше, и пренебрегать ими нельзя. Вообще говоря, предоставление возможностей интерфейса, которые могут быть расширены, означает, что он обладает хорошей расширяемостью.
2.5. Вовлеченные группы и люди
1. Инвестиции в ресурсы НИОКР.
Существует хороший контроль над способностями участников, а цели, которые не слишком далеки друг от друга, требуют детализации разборки задач и освоения решения сложных проблем.
2. Межведомственная связь и координация.
Если функция включает в себя несколько отделов компании, следует также учитывать мощность и продолжительность работы других отделов, а также необходимо участие ключевого персонала на протяжении всего процесса.
3. Точки обзора дизайна
3.1. Предоставить проектные чертежи
1. Вам нужно оставить чертеж оформления документа, который можно понять.
Как правило, по мере углубления проблемы в конструкцию вносятся незначительные изменения, но общая идея не меняется. Чертежи дизайна могут снизить стоимость повторного общения и избежать повторяющихся обсуждений.
2. Он может отражать простое намерение дизайнера.
Дизайн должен быть лаконичным и выделять основные функции. Второстепенные функции могут быть дополнены дополнительными схемами для пояснения, и не должны перегружать, игнорируя обзор основного дела.
3. Следуйте существующим нормам и структурам.
У любой компании будут свои спецификации и структура, а не акклиматизированному дизайну в будущем суждено быть ухабистым. При условии полного понимания текущей ситуации в компании следует провести пересмотр проекта.
4. Следует ли рассмотреть вопрос об избавлении от устаревших интерфейсов.
Многие разработчики предпочитают разрабатывать новые функции, рассматривая устаревший код как вонючие собачьи фекалии. Необходимо учитывать эти факторы на этапе проектирования, для адаптации устаревших интерфейсов, расширений, вне конвейера, представителя числа будущих ошибок.
5. Следует ли рассматривать удаление исторических данных.
Если план проектирования требует исправления исторических данных, этот процесс гораздо более опасен. Удаление и изменение любого из ваших полей может привести к очень серьезным последствиям. Общий принцип проектирования заключается в том, чтобы при переходе только добавлять, а не вычитать.
6. Рассматривать ли параллель и откат старой и новой схем.
Много раз ваш новый дизайн должен работать параллельно со старой функцией. В это время вы должны учитывать автономное влияние и цикл старого решения; если ваш дизайн должен заменить старую функцию, вы должны рассмотреть резерв в случае серьезных проблем. , что обычно спасает жизни.
3.2. Снижение сложности
1. Оцените сложность.
В целом, сложность отражена в следующих аспектах: 1) Цепочка вызовов слишком длинная 2) Стратегия программы является сложной и не может быть реализована 3) кросс-библиотека, кросс-хранилище 4) кэш используется 6) Asynchronous используется Отказ
Каждая из вышеперечисленных точек в большинстве случаев может быть оптимизирована, и это также место, где возникают сложные ошибки. Пригласите к участию нескольких людей, знакомых с бизнесом, и разработчиков, чувствительных к проблемам распределенных приложений, чтобы избежать проблем как можно раньше. Например, когда дело доходит до кэширования, вы можете думать о синхронизации данных, проникновении, лавине, емкости и других проблемах, которые называются技术敏感.
Для каждого компонента, используемого в проекте, может быть выполнена «технически чувствительная» проверка.
2. Отрежьте ненужные компоненты.
Если нет особой потребности в компонентах, не вводите их, а сначала используйте существующие мощности компании для их комплектации. Ты не можешь позаботиться о своей жизни.
3.3 Метод проверки
1. Дизайн модульного теста.
Можно ли легко протестировать ваш дизайн. Если модульное тестирование невозможно, как проверить правильность некоторой логики.
2. Тестовый дизайн интерфейса.
Независимо от того, объединяет ли ваш дизайн все функции вместе, один удар затрагивает все тело, и тест интерфейса не может быть выполнен. Существует много дизайнов с этой проблемой, например, использование неизвестного json (строки) для передачи данных, одновременная передача нескольких избыточных и мешающих данных и т. д.
3.4, высокая доступность (сервис)
1. Классификация услуг.
Ваш дизайн, а также функциональность — это то, на чем вы стоите. Требуется ли больше ресурсов, чтобы гарантировать более высокий уровень SLA. Вам нужно выполнить эластичное развертывание или зарезервировать ресурсы? Есть ли непредвиденные всплески запросов?
2. Напоминания о воздействии выше и ниже по течению.
Функция, которую вы проектируете, оказывает влияние на вверх по течению и ниже по течению. Для вверх по течению, может ли быть добитый уровень обслуживания (вообще, SLA будет немного выше, чем у upstream Service). Для нижнего потока необходимо учитывать источник лопного трафика: в целом от временных задач или многопоточных.
3.5, высокая надежность (данные)
1. Согласованность данных.
Будут ли данные несогласованными после экстремальных случаев (таких как смерть некоторых важных компонентов). Общая деградация службы вызовет проблемы с согласованностью данных. В этой части может не быть автоматизированного плана ремонта, но должен быть проведен предварительный анализ сложности ремонта, если сложность слишком высока, ее следует решить путем записи избыточной информации.
2. Имитационные упражнения.
Перед запуском проведите имитационное упражнение на возможных узлах. Это могут быть физические упражнения, но и на бумаге.
3.6 Ресурсы
1. Определите ресурсы каждого отдела.
На этапе проектирования определяются подробные ресурсы координации отдела, а также определяются отделы короткой доски во всем процессе, а ресурсы распределяются.
2. Расписание.
Разбирать и планировать функции в соответствии с вехами, и этот отдел должен быть в состоянии оценить общую нагрузку.
3.7 Риск
1. Есть ли технические трудности?
Также существует 28 принципов развития технологий. Некоторые технические трудности могут занимать 80% вашего времени. Эти проблемы, как правило, блокируются до конца, чтобы решить их, вам нужно найти способ издеваться, и эти каналы были открыты по умолчанию.
2. Существуют ли бизнес-риски?
Нарушает ли соответствующая функция соответствующие законы и правила? Собираются ли вещи, которые не должны собираться? Не десенсибилизирована ли некоторая конфиденциальная информация? Если это не ваше подтверждение, то молча молчите.
3. Безопасность.
Некоторые проблемы безопасности следует предусмотреть заранее, например, злонамеренная регистрация, текущий лимит, бан и т. д. Обычно они имеют низкий приоритет, если ресурсы ограничены. Пока ты не вырастешь слоном, все, на что ты сможешь смотреть, это муравьи.
4. Точки обзора кода
4.1. Результаты автоматической проверки кода
1. Какой уровень должен быть рассмотрен.
Предварительное сканирование с помощью сонара может найти много проблем. Это позволяет избежать ситуации цитирования священных писаний (в частности, развивающих норм). То, что автоматизировано, всегда вызывает больше доверия, чем то, что запомнено в вашей голове.
4.2. Двойной обзор
1. Основная логика обработки судебного процесса.
2. Обработка исключений в пробной версии.
3. Оцените производительность.
4. Просмотрите оперативную информацию.
5. Просмотрите записи.
Выше приведен контент, которым должен овладеть хороший разработчик. Корректность логики обработки является основой для того, чтобы функция прошла приемку, но проблема обычно в каких-то скрытых местах.
Некоторые исключения раскрывают конфиденциальную информацию или вызывают непредвиденные ответвления. Появятся некоторые сообщения об ошибках友好, доставляя массу неприятностей пользователям. Некоторая информация в аннотациях будет смещена от реальности, особенно если разработчик работает нестабильно.
Обзор этого шага, 360 градусов без тупиков.
End
Многие компании не имеют избыточных мощностей для проведения технических обзоров, а разработчики ездят туда-сюда, как автобус, поэтому со временем яд накапливается.
Не рецензируйте ради рецензии, рецензия предназначена для решения проблем, а не для формы. Если вы чувствуете, что каждый раз открывается текущий счет, все кивают (сонно), это не проблема процесса, но вы глубоко отравлены на дороге бюрократии.
Об авторе:Мисс сестра вкус(xjjdog), публичная учетная запись, которая не позволяет программистам идти в обход. Сосредоточьтесь на инфраструктуре и Linux. Десять лет архитектуры, десятки миллиардов ежедневного трафика, обсуждение с вами мира высокой параллелизма, дающие вам другой вкус. Мой личный WeChat xjjdog0, добро пожаловать в друзья для дальнейшего общения.