Современные принципы и методы разработки программных приложений кратко

Обновлено: 02.07.2024

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

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

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

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

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

Принципы

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

Приложение Б. Общие параметры программ для системы X Window

Приложение Б. Общие параметры программ для системы X Window Каждая программа, предназначенная для работы в системе X Window, имеет параметры, представленные в табл. Б.1.Параметры программ X Window Таблица Б.1 Параметр Описание -background <red|green|blue> Устанавливает цвет фона -background

22.4.2 Общие принципы выделения адресов

22.4.2 Общие принципы выделения адресов Работу по делегированию прав присвоения блоков адресного пространства IPv6 региональным организациям регистрации ведет Internet Assigned Numbers Authority (IANA). Региональные организации регистрации могут передавать блоки адресов в меньшие

Общие принципы

Общие принципы работы со спецификациями

Общие принципы работы со спецификациями При работе с документом-спецификацией в КОМПАС-3D обычно пользуются таким понятием, как объект спецификации.Объект спецификации – это строка или несколько текстовых строк в документеспецификации, характеризующих (описывающих)

8.1. Общие принципы хорошего программирования

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

6.5. Общие команды меню Windows-программ. Буфер обмена Windows

6.5. Общие команды меню Windows-программ. Буфер обмена Windows Практически все Windows-программы имеют главное меню, которое расположено сразу под заголовком окна. В большинстве случаев некоторые команды главного меню совпадают. Например, многие Windows-программы имеют меню Файл,

1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ

1.4. ОБЩЕСИСТЕМНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ПРОГРАММ При создании и развитии программного обеспечения (ПО) рекомендуется применять следующие общесистемные принципы:1) принцип включения, предусматривающий, что требования к созданию, функционированию и развитию ПО определяются

1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ

1.8. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ ГОСТ 19.102—77 регламентирует стадии и этапы программных разработок в течение всего жизненного цикла. Данный стандарт сформировался на основе анализа удачных и неудачных программных разработок и содержит основные рекомендации по

6.6. СОМ — ТЕХНОЛОГИЯ РАЗРАБОТКИ РАЗВИВАЮЩИХСЯ И РАССРЕДОТОЧЕННЫХ КОМПЛЕКСОВ ПРОГРАММ

6.6. СОМ — ТЕХНОЛОГИЯ РАЗРАБОТКИ РАЗВИВАЮЩИХСЯ И РАССРЕДОТОЧЕННЫХ КОМПЛЕКСОВ ПРОГРАММ СОМ — Component Object Model (модель компонентных объектов) — это спецификация метода создания компонент и построения из них программ.В литературных источниках можно найти множество теорий и

Приложение 1 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ ПО ГОСТ 19.102-77

Приложение 1 СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ ПО ГОСТ 19.102-77 Данный текст не заменяет сам стандарт, который может измениться, и приводится здесь лишь для пояснения порядка работы с этим и другими стандартами.Таблица 1Стадии разработки, этапы и содержание работ Стадии

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

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

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

1. Будь проще, Саймон (Keep It Simple Simon, KISS)

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

Ваши методы должны быть небольшими, не превышающими 40-50 строк.

Каждый метод должен решать только одну проблему.

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

Always Keep It Simple, Stupid (KISS) позволяет вам и другим программистам быстро выявлять ошибки. Он также помогает вносить дальнейшие изменения в код. Это один из наиболее распространенных принципов бережливого производства в гибкой разработке программного обеспечения.

2. Вам это не понадобится (You Aren't Gonna Need It, YAGNI)

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

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

Этот принцип экономит время, усилия и расходы, которые тратятся впустую на попытки понять или отладить код.

3. Дважды отмерь и один раз отрежь (Measure Twice and Cut Once)

Некачественно выполненный этап написания требований обычно приводит к более чем 50% проблем в разработке. Поэтому подготовьтесь, разработав системный подход к процессу программирования.

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

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

4. Не повторяйся (Don’t Repeat Yourself, DRY)

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

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

Чтобы избежать этой ловушки, вы можете извлечь общую логику.

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

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

5. Бритва Оккама

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

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

6. Сначала большое проектирование (Big Design Up Front, BDUF)

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

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

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

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

7. Избегайте преждевременной оптимизации

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

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

Причина в том, что приоритизация кода занимает много времени и значительно усложняется, если делать её не вовремя. Кроме того, в процессе реализации наиболее оптимального решения требования могут измениться. Если это произойдет, ваша программа окажется в мусорной корзине или ее будет сложно изменить.

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

8. Наименьшее удивление

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

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

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

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

9. Закон Деметры

Закон Деметры пытается разделить обязанности между классами и уменьшить связанность между ними.

Настоятельно рекомендуется:

Обеспечить независимость программных объектов друг от друга.

Уменьшить общение или связь между разными классами.

Поместить связанные классы в один и тот же пакет, модуль или каталог для достижения согласованности.

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

10. S.O.L.I.D

Эта аббревиатура обозначает пять принципов объектно-ориентированного программирования и дизайна.

S - Single Responsibility Principle (SRP) - Принцип единой ответственности.

O - Open/Closed Principle (OCP) - Принцип открытия / закрытия.

L - Liskov Substitution Principle - Принцип замещения Лисков.

I - Interface Segregation Principle - Принцип разделения интерфейса.

D - Dependency Inversion Principle - Принцип инверсии зависимостей.

Давайте кратко рассмотрим каждый из этих принципов

Принцип единой ответственности (SRP)

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

Здесь мы говорим о связанности. Все элементы в структурах или модулях данного класса должны иметь функциональное родство друг с другом. Чётко определив ответственность своего класса, вы повысите его связанность.

Принцип открытости / закрытости (OCP)

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

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

Принцип замещения Лисков (LSP)

В своей исследовательской работе 1988 года Барбара Лисков заявила, что производные классы должны быть спроектированы так, чтобы их при необходимости можно было заменить своими базовыми классами без потери обратной совместимости. Таким образом, вам нужно проявлять осторожность при использовании наследования в проекте.

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

Перед выполнением наследования необходимо учитывать предварительные условия класса.

Принцип разделения интерфейса (ISP)

ISP предпочитает много конкретных интерфейсов одному общему. Цель состоит в том, чтобы иметь гранулярные и специфичные для клиента интерфейсы.

Вам необходимо повысить связанность в интерфейсах и разработать бережливые модули - с минимально возможным поведением.

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

Принцип инверсии зависимостей (DIP)

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

Модули высокого уровня должны быть независимыми от модулей низкого уровня. И те, и другие должны зависеть от абстракций

Абстракции не должны зависеть от деталей реализации. Детали должны зависеть от абстракций.

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

Заключение

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

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

Программирование и разработка

Есть несколько современных принципов разработки программного обеспечения. Следуя этим современным принципам, мы можем разработать эффективное программное обеспечение, отвечающее всем потребностям клиентов. Для разработки правильного программного обеспечения необходимо следовать следующим 10 принципам разработки программного обеспечения:

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

1. Этапы жизненного цикла ПО

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

Жизненный цикл разработки программного обеспечения от английского Software Development Life Cycle, SDLC — это условная схема, которая содержит в себе все этапы, через которые ПО проходит от формирования в виде идеи до последних дней своей работы, что еще раз подтверждает вышесказанное: разработка приложения не прекращается даже после его релиза.

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

Основные модели разработки ПО

Идея, сбор и анализ требований для ее осуществления.
Дизайн и проектирование.
Реализация и программирование.
Тестирование и отладка.
Внедрение и эксплуатация.
Сопровождение и поддержка.

Остановимся на каждом из них подробнее.

Идея, сбор и анализ требований для ее осуществления

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

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

Дизайн и проектирование

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

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

Реализация и программирование

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

Тестирование и отладка

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

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

Внедрение и эксплуатация

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

Сопровождение и поддержка

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

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

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

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

2. Основные модели разработки ПО

Методология разработки ПО — это система, которая определяет порядок и сроки выполнения задач внутри этапов жизненного цикла, методы оценки и контроля. Бюджет и сроки выполнения проекта и метод разработки связаны и зависят друг от друга.

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

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

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

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

Преимущества каскадной модели

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

Недостатки каскадной модели

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

V-образная модель (разработка через тестирование)

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

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

Преимущества V-образной модели

Тестирование проходит на всех этапах разработки.
Вероятность ошибок сводится к минимуму.

Недостатки V-образной модели

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

Incremental Model (инкрементная модель)

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

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

Преимущества инкрементной модели

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

Недостатки инкрементной модели

RAD (быстрая разработка)

RAD Model (Rapid Application Development model) — это модель быстрой разработки приложений. Это своего рода ответвление инкрементной модели, так как процесс создания ПО происходит таким же образом с единственным исключением — над проектом работает сразу несколько команд. То есть в один момент времени параллельно существует несколько мини-проектов в одном большом проекте, которые интегрируются в рабочий прототип по мере готовности.

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

Iterative Model (итеративная модель)

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

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

Преимущества итеративной модели

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

Недостатки итеративной модели

Spiral Model (спиральная модель)

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

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

3. Что такое Agile и Lean: принципы разработки ПО

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

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

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

Преимущества гибкой модели

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

Недостатки гибкой модели

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

Scrum — где люди постоянно общаются и взаимодействуют между собой на собраниях и обсуждениях.
Kanban — где есть виртуальная доска с задачами, которые можно выполнять в любом порядке.
RUP — где есть четкие фазы планирования, уточнения и построения новых итерация ПО.
Extreme Programming — где применяется высокая частота обновления версии продукта ориентация на постоянные изменения требований и поиск самых быстрых решений.

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

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

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

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

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

Сначала я хотел вам рассказать доклад по плану указанному ниже:

Проектирование систем — архитектура
Дизайн сервиса — организация кода внутри приложения
Хранение и обработка данных сервиса — организация данных
Quality Assurance — shift left и пирамида тестов
Инфраструктура — IaaC, *aaS
Доставка на продакшен — CI/CD pipelines
Безопасность
Данные для отчетов — подходы Data Lake и Data Mesh

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

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

Код может превратиться в спагетти от

неопытности разработчиков
продавливания бизнесом разработчиков по срокам

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

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

Например, в Тинькофф мне досталось несколько таких систем по наследству 4 года назад и мы с моими командами их успешно переписали. Самым ярким примером были 2 системы:

Система персонализаций и тестов версии 1.0, которая выросла из прототипа, где ее разработчик не любил лишних вызовов функций (и функции у него были по 500 строк) и не признавал понятие цикломатической сложности и важности ее ограничения
Система управления контентом версии 1.0, где несколько фронтендеров писали бекенд систему с API

Теперь подведем итоги разработки в лоб:

Всегда ли такой подход плох? — Нет. В прототипах и RnD он может быть хорош.
Что делать, если мы пишем не прототип? Или пишем много прототипов? — Нам нужна более умная разработка

Надо добавить как минимум стадию проектирования.

А что же такое проектирование?

По-факту, оно разделяется на две части: что делаем и как делаем. “Что делаем” относится к требованиям — надо очень внимательно посмотреть на требования, а конкретно на функциональные и нефункциональные требования.

Функциональные требования определяют, что будет делать система или приложение, особенно в контексте внешнего взаимодействия (с пользователем или с другой системой). …
Нефункциональные требования — это любые требования, которые не описывают поведение системы ввода / вывода.

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

“Как делаем” относится больше к паттернам и фреймворкам, которые можно использовать для ускорения и улучшения структуры приложений. Шаблон проектирования или паттерн — это повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста. Фре́ймворк — каркас, определяющий структуру программной системы и облегчающий разработку и объединение разных компонентов большого программного проекта.

Если мы воспользуемся этим подходом, то мы вместо спагетти-кода придем к архитектуре. Обычно это слоеная архитектура, например

UI-слой
слой бизнес-логики
слой хранения данных

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

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

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

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

Эволюция подходов изображена на рисунке ниже.

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

совместный доступ к данным
сложные выборки данных, когда паттерн выборки меняется

Эти моменты решаются при использовании реляционных баз данных, которые предложил доктор Эдгар Кодд в 1970, когда он работал в IBM. Для работы с реляционными БД применяют реляционные системы управления базами данных (для краткости просто базами данных). Кодд предложил 12 правил, которым должна удовлетворять база данных, чтобы считаться реляционной. Интересно, что большинство реляционных баз данных не соблюдают часть этих правил:)

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

Также обычно реляционные базы данных дают гарантии ACID

Atomicity — Атомарность
Consistency — Согласованность
Isolation — Изолированность
Durability — Стойкость

Реляционные базы данных подходили не ко всем нагрузкам. Их хорошо было использовать для OLTP нагрузок (Online Transaction Processing). А вот для OLAP нагрузок (Online Analytical Processing) нужны отдельные решения. Саму концепцию предложил тоже Кодд в 1993 году. Основная причина использования OLAP для обработки запросов — скорость. В OLAP решении важна подготовка суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. OLAP-структура, созданная из рабочих данных, называется OLAP-куб.

Дальнейшим развитием файловых систем стало появление объектных хранилищ, первым популярным среди которых стало Amazon S3 (Simple Storage Service), предоставляющая возможность для хранения и получения любого объёма данных, в любое время из любой точки сети, так называемый файловый хостинг. Впервые появилась в марте 2006 года в США и в ноябре 2007 года в Европе.

В начале 2000-х годов объем информации, которую нужно было обрабатывать перестал помещаться в одно хранилище и потребовалась возможность параллельной обработки на группе машин. Google представил модель распределенных вычислений MapReduce, который использовался для параллельных вычислений над очень большими, вплоть до нескольких петабайт, наборами данных в компьютерных кластерах. Apache Hadoop — это open source проект, который был разработан на основе идеи MapReduce для распределенных вычислений. Он нашел своих последователей и стал крайне популярным в своем классе решений для обработки BigData. Кстати, проект был назван в честь игрушечного слонёнка ребёнка основателя проекта.

В 2009 году появился термин NoSQL, который был придуман Эриком Эвансом, когда Джоан Оскарсон из Last.fm хотел организовать мероприятие для обсуждения распределенных баз данных с открытым исходным кодом. Сейчас он применяется к системам, в которых делается попытка решить проблемы масштабируемости и доступности за счёт полного или частичного отказа от требований атомарности и согласованности данных. В итоге, NoSQL базы уже не дают гарантии ACID, вместо этого они говорят о гарантиях BASE

Эти гарантии связаны с CAP-теоремой, которая является эвристическим утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:

согласованность данных (англ. consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу
доступность (англ. availability) — любой запрос к распределённой системе завершается корректным откликом, однако без гарантии, что ответы всех узлов системы совпадают
устойчивость к разделению (англ. partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций

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

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

Следующим шагом развития была сервис ориентированная архитектура (SOA), определение которого звучало неплохо

модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам

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

Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).

Данная архитектура стала популярной в конце 1990-х годов и начале 2000-х. Но она была достаточно сложна и из-за этого обрела достаточную популярность только в “кровавом enterprise”. В остальных местах ее использование зачастую было over engineering.

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

Для правильного проектирования границ сервисов можно использовать Предметно-ориентированное проектирование (Domain Driven Design) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом. Подробнее про DDD можно почитать в моем обзоре книги “What Is Domain-Driven Design?”

Также есть хорошая методология 12 factor app от Heroku для создания приложений, которые

Используют декларативный формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключённых к проекту;
Имеют соглашение с операционной системой, предполагающее максимальную переносимость между средами выполнения;
Подходят для развёртывания на современных облачных платформах, устраняя необходимость в серверах и системном администрировании;
Сводят к минимуму расхождения между средой разработки и средой выполнения, что позволяет использовать непрерывное развёртывание (continuous deployment) для максимальной гибкости;
И могут масштабироваться без существенных изменений в инструментах, архитектуре и практике разработки.

Современные микросервисные приложения реализуются в рамках cloud native подхода, который определяется так

CNCF Cloud Native Definition v1.0
Approved by TOC: 2018–06–11
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

Для некоторых нагрузок можно использовать следующий шаг — serverless architecture или FaaS (Function as a Service), когда приложение хостится третьей стороной в виде сервиса, который обрабатывает запросы клиентов или определенные события. В итоге, разработчикам не требуется думать про сервера, на которых развернуто их решение.

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

Читайте также: