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

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

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

1. Предыстория

По моему впечатлению, Этот проект стартует 12 августа 2022 года. Ко мне впервые пришел руководитель проекта, который на тот момент отвечал за проект. Позвольте мне нести ответственность за подготовку технического обоснования этого проекта. С того времени, Этот проект стартовал, и ему уже больше года. В этот период, дорогие лидеры, эксперт, Менеджер продукта/проекта, разработка, Полное сотрудничество тестировщиков и другого персонала, Пусть этот проект продвигается гладко. Проект также был официально запущен ранее в этом году. На момент написания этой статьи версия была обновлена ​​до v1.4.8. Вот специальный обзор процесса разработки всего проекта, Поделиться со всеми стандартизации с точки зрения развития.

2. Процесс

График ключевых узлов всего проекта резюмируется следующим образом:

2.1 Технико-экономическое обоснование

Узнайте заранее:

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

Технико-экономическое обоснование проекта программного обеспечения в основном включает в себя следующие пять аспектов:：

• Экономическая целесообразность: в основном учитывайте соотношение затрат и выпуска.,То есть, имеет ли инновационное программное обеспечение экономическую выгоду?
• Техническая осуществимость: в основном относится к тому, могут ли существующие технологии (или другие технологии) реализовать функции программного обеспечения.
• Эксплуатационная осуществимость: главным образом, может ли метод работы системы быть распознан пользователями.
• Юридическая осуществимость: основной вопрос заключается в том, имеются ли какие-либо незаконные или нарушающие права аспекты.
• Временная осуществимость: в основном учитывается, может ли программное обеспечение быть завершено в течение указанного времени.

обзор процесса

Согласно требованиям технической осуществимости, Разработчикнужно пройтиdemo Проверить содержание требований технической осуществимости. Затем оцените и проверьте, соответствует ли текущая технология потребностям проекта. И благодаря реализации демо-версии, Заранее выявляйте и прогнозируйте риски проекта. Затем предоставьте технически осуществимые решения, включая выбор технологии, методы реализации технологии и т. д. наконец, На основе предыдущего анализа определите, осуществима ли технология проекта.

Резюме после:

1. Понять содержание технического технико-экономического обоснования Вы не можете просто начать делать это сразу, когда увидите спрос. Если вы не понимаете, вы можете сказать больше и руководитель общение в проекте, Избегайте доработок, вызванных отклонением демо-версии производства от первоначальных требований технической проверки.
2. Оцените технические риски в технологиитехнико-экономическое В обоснование Разработчик также должен оценить возможные технические риски, такие как проблемы, которые могут возникнуть в ходе технической реализации процесса, соответствуют ли результаты технической реализации ожиданиям и т. д. Оценив эти риски, можно заранее принять соответствующие контрмеры.
3. Заранее продумайте последующую разработку демо-версии Потому что выполняем технологию технико-экономического обоснование людей, как правило, будет основой последующих проектов. Поэтому необходимо учитывать частоту вызовов интерфейса. Использовать ли кэширование, Будет ли использоваться очередь и т. д., это окажет влияние. Анализировать риски проекта, и думать о решениях, Заранее спланируйте структуру проекта.

2.2 Стартовая встреча проекта

Узнайте заранее:

Стартовое совещание проекта должно позволить всем заинтересованным сторонам понять цели, планы, роли и ожидания проекта, а также прояснить меры предосторожности при запуске проекта. В состав участников стартовых совещаний проекта обычно входят: Соответствующие руководители компании, Связанные областиэксперт, Менеджер продукта/проекта, разработчик, Тестировщики и представители заказчика (если есть)

Встречи по началу проекта обычно включают в себя следующие задачи:

• Определить цели и объем проекта：Уточнить цели и объем проекта, которые необходимо достичь.,определить направление и направленность проекта
• Определите заинтересованных сторон проекта: Определите соответствующих заинтересованных сторон проекта и поймите их потребности и ожидания.
• Определите потребности проекта в ресурсах: определите человеческие, технические и финансовые ресурсы, необходимые для проекта, и спланируйте, как получить эти ресурсы.
• Определить риски и проблемы проекта：Первичное выявление возможных рисков и проблем,и сформулировать контрмеры
• Определите, как проект будет передаваться и сотрудничать.：Планируйте, как общаться и сотрудничать с заинтересованными сторонами,Для обеспечения плавного хода проекта
• Создайте команду управления проектом и ее роли: Определите команду управления проектом и обязанности каждой роли, чтобы обеспечить эффективное управление и контроль над проектом.
• Рассмотрение и утверждение плана проекта: после рассмотрения и обсуждения доведите план проекта до сведения всех заинтересованных сторон и получите их одобрение.

обзор процесса:

Во время стартовой встречи В основном состоит изМенеджер проекта предлагает описание проекта, цели и описание плана, а все заинтересованные стороны работают вместе над выявлением рисков в проекте.. когда时我们邀请了相关领域的эксперт, Отвечает за предоставление мнений о бизнесе, процессе разработки и управлении командой. После начала стартового совещания по проекту Менеджер проекта формирует группу разработки проекта,

Позже пообщавшись с менеджером проекта, я узнал, что Весь основной процесс на ранней стадии заключается в следующем: Проект требует исследования——Уточнить общее направление и ключевые потребности——Технико-экономическое обоснование проекта——Создание проекта（Создание проекта завершено）——Стартовая встреча проекта (проект официально стартует)——Анализ потребностей проекта идизайн——Обзор требований——……

Резюме после:

1. Обратите внимание на стартовую встречу Для разработчиков, Самая большая роль стартового совещания проекта состоит в том, чтобы позволить нам прояснить обязанности по проекту и общие механизмы реализации проекта. Поймите свои обязанности по проекту, Только тогда вы знаете, что вам следует делать; Знание общей схемы проекта, Только тогда вы знаете, что и когда делать.
2. Обратите внимание на Стартовая встреча Проект является официальным разработано за этот период времени (если есть) В течение этого периода вы можете работать над планом проекта. Эскизное проектирование включает в себя: Архитектура, развертывание, выбор технологий, информационная безопасность, эксплуатация и обслуживание и т. д.

2.3 Обзор требований

Узнайте заранее:

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

обзор процесса:

Прежде чем проводить совещание по рассмотрению требований, Менеджер проекта заранее подготовит список описания требований. ЗатемРазработчикНеобходимо проанализировать требования, Выявление недостатков и проблем в конструкции, И запланируйте заранее (как показано ниже)

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

Резюме после:

1. Разработчикможет быть сруководитель проектобсудить,существовать Обзор требованийпосле, Повторное подтверждение документов планирования спроса Поскольку формулирование графика проекта необходимо осуществлять при полном понимании проекта, В противном случае можно легко проигнорировать период строительства проекта и сделать неверные суждения.
2. Пересмотрите требования, изменив точки зрения Необходимо понимать требования с точки зрения продукта или системы в целом, а не просто фокусироваться. —Часть того, за что я несу ответственность. В противном случае, когда людей много, легко создать избыточный код и запутать стыковку. Одна система, несколько стилей.
3. Обратите внимание на Обзор Время после требования к следующему этапу Здесь вы можете осуществить детализацию проектадизайн, Содержание дизайна деталей проекта в основном включает в себя: дизайн базы данных, Дизайн интерфейса, дизайн структуры кода и т.д.
4. Внимательно проверьте требования и часы вашего проекта. Заранее выявить проблемные требования, Старайтесь избегать доработок, вызванных последующим усовершенствованием. При проверке проектных часов, как правило, можно оценить напрямую, Если процесс относительно сложен, для его проверки можно использовать однокодовую сетевую диаграмму.

2.4 Официально разработано & Обзор базы данных

Узнайте заранее:

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

Анализ проекта базы данных — это процесс рассмотрения, оценки и предоставления отзывов по документам проекта базы данных. Цель проверки — убедиться, что структура базы данных соответствует потребностям бизнеса, соответствует спецификациям, безопасна и надежна, а также проста в обслуживании и расширении.

Ниже приведены основные этапы анализа проекта базы данных:

• Подтвердить потребности бизнеса：Рецензенты должны понимать потребности бизнеса и ключевые бизнес-процессы.,Чтобы подтвердить, соответствует ли дизайн базы данных этим требованиям.
• Характеристики проверки：Рецензенты должны проверить База данныхдизайн Соответствует ли она выбранным спецификациям и стандартам базы данных.,Включить соглашения об именах、тип данных、ограничение、Индекс и т. д.
• Подтвердить модель данных: рецензент должен проверить правильность модели данных конструкции базы данных.,включать сущности、свойство、связь、Парадигма и т. д.
• Оценка безопасности: рецензент должен оценить меры безопасности и контроля доступа в базе данных, чтобы гарантировать защиту конфиденциальных данных.
• Оценка эффективности：Рецензенты должны оценить База данныхдизайнпроизводительность,Включая производительность запросов, производительность обработки транзакций、Производительность хранения и индексирования и т. д.
• Обслуживание и расширение：Рецензенты должны оценить База Ремонтопригодность и масштабируемость данныхдизайн,Чтобы гарантировать, что база данных сможет продолжать играть роль в будущих изменениях требований.
• Предоставление обратной связи: Рецензенты должны предоставить конкретные отзывы и предложения персоналу, занимающемуся проектированием.,Помочь улучшить базу данныхдизайн,гарантировать его качество инадежность

обзор процесса:

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

Резюме после:

1. Уведомление Характеристики проверки нуждатьсясосредоточиться наименование таблиц и спецификации полей базы данных, Постарайтесь быть как можно более едиными, Например, при именовании полей базы данных Срок создания спецификации, создатель, время обновления, Типы команд и полей программы обновления
2. Обратите внимание на проектирование на основе чертежей прототипов. Обратите внимание на потенциальные данные, то есть данные, которые не показаны в прототипе проекта, но могут использоваться в реальных потоках данных или функциях. А также длину поля и тип данных в соответствии с прототипом и бизнесом.
3. Обратите внимание на добавление в таблицу 1-2 зарезервированных полей. Функция зарезервированных полей — оставить место для возможных будущих изменений или новых требований, чтобы облегчить расширение и обслуживание системы. Как правило, нет ограничений на зарезервированные поля, и их можно свободно задавать в соответствии с конкретными потребностями. При разработке таблицы обычно рекомендуется размещать зарезервированные поля в конце таблицы, чтобы избежать изменения или удаления существующих полей.
4. Запишите содержание обзора и сформируйте документ. База данныхдизайн Содержимое, полученное в результате обзора, состоит изВывод, который признается всеми членами команды и делается на практике. Результаты проверки должны быть записаны для дальнейшего использования в базе данных. и Для справки в расширении

2.5 Обзор тестового примера

Узнайте заранее:

Проверка тестовых примеров — это процесс рассмотрения и проверки тестовых примеров в процессе тестирования программного обеспечения для обеспечения качества и эффективности тестовых примеров.

Проверка тест-кейса включает в себя следующие аспекты:

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

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

обзор процесса:

После завершения проектирования базы данных Затем мы провели обзор вариантов использования, Ключевые участники — менеджеры по продуктам, тест, Разработчики и т. д. Цель состоит в том, чтобы определить, соответствует ли тестовый пример реальной ситуации. И соответствуют ли тестовые примеры требованиям к продукту. Просьба предоставить комментарии по вариантам использования, которые не соответствуют требованиям, Тестировщик модифицирует тестовые примеры, основываясь на мнении каждого. После этого тест отправит измененный вариант использования теста в разработку. Его можно использовать в качестве справочного материала после модульного тестирования при последующей разработке.

Резюме после:

1. Обратите внимание на согласованность тестовых примеров. долженОбратите внимание на то, соответствуют ли тестовые примеры логике вашего бизнес-процесса. , Постарайтесь избежать сценария «настоящего и фальшивого Короля обезьян». В противном случае в течение последующего периода тестирования могут возникнуть конфликты с тестом по поводу некоторых расплывчатых вариантов использования теста ( Они все думают, что то, что они делают, хорошо, и ищут руководителя. проекта"Комментарий" )
2. Логику проверки тест-кейсов можно использовать как дополнение к последующей логике разработки. В общем, вот и вседасуществоватьКак тестировать и как писать тесты, обеспечивая при этом последовательность. Кстати, это также может помочь определить объем и границы вариантов использования тестов. Конечно, реальная ситуация такова, что большинство вариантов использования появятся, когда проект почти завершен. На данный момент мы можем использовать его как инструмент для обнаружения бизнес-логики вместе с описанием требований.

2.6 Тестирование проекта

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

Узнайте заранее:

Тестирование проекта можно разделить на следующие категории:

• Модульное тестирование(Unit Test) Модульное Тестирование — это тест, выполняемый с использованием наименьшей единицы кода, обычно функции или метода. Модульное тестирование в основном проверяет логические ошибки и проблемы с производительностью в коде.
• Интеграционное тестирование(Integration Test) Интеграционное тестированиедатест Взаимодействие между различными модулями или компонентамида Это нормально?,В основном проверяйте правильность интерфейса между модулями.,И корректна ли передача и обработка данных между модулями
• Тестирование системы(System Test) Тестирование системыдасуществовать После завершения всей системы программного обеспечениятест,В основном проверяйте, соответствует ли система потребностям пользователя.,И это работает правильно. Объем теста включает в себя тест функций, тест производительности, тест безопасности и т. д.
• Приемочное испытание (Приемочное испытание) Приемочное испытание проводится заказчиком или конечным пользователем, главным образом, на предмет соответствия программного обеспечения потребностям и ожиданиям пользователя. Приемочные испытания обычно проводятся после завершения всех остальных типов испытаний.
• Регрессионный тест (Регрессионный тест) Регрессионный тест — это тест, выполняемый на исходном варианте использования теста после модификации, в основном с упором на исправленные дефекты, добавленные новые функции и влияние на существующие функции и т. д.
• производительностьтест(Performance Test) Тест производительности — это то, может ли система тестирования удовлетворить потребности и требования к производительности в различных условиях нагрузки, главным образом с точки зрения времени отклика теста, пропускной способности, использования ресурсов и т. д.

обзор процесса:

1. 16 ноября – 1 декабря В середине ноября, Дайте нам контрольный список тестов, Давайте сначала проверим себя. Поскольку задача внедрения относительно тяжелая, Они не уделяют должного внимания самооценке, И каждый борется сам по себе, В результате первый тур тестов 1 декабря не был пройден. Это болезненный урок для нас!

1. 15 декабря – 28 декабря Поскольку второй раунд тестирования включает в себя обе ошибки, оставшиеся от первого раунда, Он также содержит ошибки, вызванные новыми функциями, Поэтому исправлять ошибки в тот период было крайне сложно. Кажется, над командой проекта нависла темная туча... Но я все же завершил этот раунд теста, несмотря на спотыкание.
2. 5 января - 13 января(2023) Чтобы гарантировать бесперебойную работу проекта после его выхода в Интернет, и изменения в некоторых требованиях, У нас есть еще один возвратный тест, то есть третий тур теста Поскольку в этом раунде теста еще много проблем, Мы решили поработать сверхурочно в ночь перед отправкой контракта на завершение проекта. К счастью, в конце концов все работали вместе, Наконец, проект был запущен, как и было запланировано...

Резюме после:

1. Необходимо обратить внимание на самооценку Если взять в качестве примера серверную часть, После каждого разработки интерфейса в бэкэнде Каждый должен проводить самотестирование, проверить, удовлетворяет ли бизнес-логика бизнес-процессу, Требования и варианты использования. После того как интерфейс закрепит страницу, Также постарайтесь максимально улучшить интерфейсную страницу, Главное – проверить, нет ли на странице всплывающих окон с ошибками и проблем с отображением данных. По этой причине мы были в первом туре, Это приводит к сбою всего процесса. Поэтому работа по тестированию — это не просто тестирование. По крайней мере, до того, как проект будет запущен нормально, мы должны убедиться, что не будет явных ошибок в работе веб-страницы и серверной части.
2. После самотестирования обязательно протестируйте друг друга Продолжая рассматривать серверную часть в качестве примера, После завершения проекта, Часто проводятся самотестирования. Но почему после самотестирования все равно появляется много проблем? После моих размышлений, возможнодапотому что всеКаждый пишет свою историю, не понимая общих потребностей и не имея общего дизайна. Просто следуйте логике интерфейса, который вы написали, чтобы сделать простой тест. Однако вся логика интерфейса не раскрыта полностью. Все участники должны проверять друг друга, Найдите проблемы в коде с точки зрения пользователя.
3. Ошибки, возникающие во время самотестирования/взаимного тестирования, должны быть зафиксированы.. Также рекомендуется найти онлайн-документ для записи ошибок, обнаруженных во время самотестирования/взаимного тестирования. Используется для отслеживания последующих проблем. В противном случае ошибка может не быть исправлена ​​в будущем. Полученная ошибка появляется снова, Или возникшие новые ошибки будет трудно отследить, В тяжелых случаях это может привести к необходимости регресса.

2.7 Совещание по обзору хода реализации проекта

обзор процесса: Поскольку первый этап разработки системы X провалился, Кроме того, время разработки и тестирования второго этапа ограничено. Требуется завершить разработку и выйти в сеть до конца месяца. Поэтому мы решили объединить первый и второй этапы работы. Но с точки зрения менеджера проекта, Участники проекта обязаны оперативно поднимать возникающие в настоящее время проблемы, И понять текущий статус выполнения проекта. Поэтому руководитель проекта планировал провести совещание по ходу проекта. Чтобы понять текущий статус реализации проекта, И позвольте фронтальным и серверным сторонам полностью проводить самотестирование модулей, за которые они отвечают.

X system по обзору хода реализации проекта
Внимание: межведомственная совместная разработка одной системы, используемой всей компанией, сосредоточено несколько руководителей. на Внимание, многие люди отвечают за свой первый проект с нуля.
1. Цель
(1) Конечная цель: 31 декабря. Официальный релиз доступен всей компании;
(2) Цель онлайн: судебное разбирательство будет проводиться департаментом начиная с 27 декабря;
(3) Цель тестирования: отправьте тест до окончания работы в эту среду. На отладку осталось всего 8 дней, так что времени очень мало;
2. Планируйте
(1) Каждый должен пройти весь процесс тестирования самостоятельно или найти кого-то, кто будет сотрудничать друг с другом и сравнивать прототип, а не только модули, за которые он отвечает, что занимает около 2-3 часов.
     Координировать и решать проблемы в модулях, за которые вы несете ответственность, и передавать проблемы в модулях, за которые вы не несете ответственности, соответствующему лицу;
(2) Решите проблемы в ZenTao и документах со списком ошибок продукта до среды. Если у вас возникли проблемы, попросите кого-нибудь о помощи или работайте сверхурочно, чтобы решить их. Если это приводит к задержкам проекта или другим проблемам,
     Отправьте соответствующую информацию самостоятельно;
(3) Если вам нужно работать сверхурочно, сотрудничая с клиентской и серверной частью, заранее сообщите об этом другой стороне.
3. Проблемы, которые все еще существуют на переднем и заднем концах, требуют координации.

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

2.8 Официальный релиз

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

обзор процесса:

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

Резюме после:

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

2.9 Более поздние итерации

обзор процесса:

С момента выхода проекта v1.0.0 в начале этого года было выпущено подряд около 20 версий. За этот период совместными усилиями всех проект был полностью расширен. Благодаря непрерывному обновлению версии мы добавили версию для Pad и мобильную версию из исходной версии для ПК. Мы интегрировали систему тестовых заказов на работу и так далее.

Резюме после:

1. При итерации версий проекта Необходимо обратить внимание на принцип открытия и закрытия. То есть «Программные объекты (классы, модули, функции и т. д.) должны быть открыты для расширения и закрыты для модификации». другими словами,когдаКогда требования меняются, существующую функциональность следует расширять путем добавления нового кода, а не путем прямого изменения существующего кода.. Целью является улучшение удобства сопровождения, масштабируемости и возможности повторного использования программного обеспечения при одновременном снижении сложности программного обеспечения и риска.
2. Каждый раз при выпуске пакета новой версии информация о документе проекта и информация о версии в коде новой версии своевременно обновляются. Это облегчит обслуживание содержимого каждой версии соответствующим персоналом в будущем.

3. Мышление

Вопрос первый

мое мнение

Вопрос 2

мое мнение

Вопрос третий

В процессе стандартизации На какие аспекты вам как разработчику следует обратить внимание?

мое мнение

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

Вопрос 4

В ходе разработки, У многих людей есть такая идея: Эта ошибка настолько проста, И я так занят, Просто позвольте кому-то другому это изменить! Или, может быть, в последнее время я был занят другими проектами, Позвольте другим исправить ошибки, за которые я отвечаю! Так почему же я все же рекомендую вам изменить собственный код?

мое мнение

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