Отсечение целей (сложность разработки)
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 11.01.15 08:01
Оценка:
Для начала небольшое наблюдение. При прочих равных условиях маленькую программу создать обычно легче, чем большую. Однако так же верно, что суммарная сложность частей порой оказывается гораздо выше в собранной единой системе, чем в отдельных её составляющих. Иными словами по мере увеличения размера кода программы сложность создания растёт непропорционально применяемым усилиям.

http://files.rsdn.org/99832/сложность_создания.png

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

Но архитектура это отдельный разговор, срабатывает лишь в определённых случаях. Пока же заострим внимание на схождении красной и синей линии, причём именно первая должна стремиться ко второй, а не наоборот. Речь об уменьшении возрастания сложности путём чёткого деления созданного функционала. Данная возможность базируется на модифицируемости кода (Changeability QA) рассмотренного в предыдущей статье, то есть его способности к изменениям. Напомню, что речь о маркерах изменений позволяющих технично проводить операции над функционалом программы (выделить, вставить, удалить и обновить).

Хотя речь идёт о списке функционала, под этим часто подразумевают функциональные требования. Более того, нефункциональные требования не являются абстракциями, иначе программа без них была бы в точности идентична программе с ними. Так или иначе, но существуют куски кода явно или не столь явно их поддерживающие. Требования так же имеют критерии качества (correct, unambiguous, complete, consistent, prioritized, testable, traceable, understandable, modifiable).

http://files.rsdn.org/99832/requirements.png

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

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

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

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

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