Что-то там driven Development

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

Разработка по RUP

Возьмём ключевые процессы разработки по RUP.

Ключевые процессы

Или возьмём ключевые процессы из википедии.
1) Моделирование
2) Требования
3) Проектирование
4) Кодирование
5) Тестирование
6) Отладка
7) Документирование
8) Развёртывание
9) Сопровождение

Смена порядка процессов разработки

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

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

Процесс (роль).

1) Разработка через моделирование (бизнес аналитик)
2) Разработка через требования (системный аналитик)
3) Разработка через проектирование (архитектор)
4) Разработка через кодирование (кодировщик)
5) Разработка через тестирование (тестировщик)
6) Разработка через отладку (отладчик)
7) Разработка через документирование (документовед)
8) Разработка через развёртывание (мейнтейнер)
9) Разработка через сопровождение (поддержка)

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

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

Теги в коде

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

В AsciiDoctor это может выглядеть как-то так.

abs.lua

print(
-- tag::example[]
math.abs(-25)
-- end::example[]
)

documentation.adoc

.показать весь документ
include::abs.lua[]

.показать только тег example
include::abs.lua[tag=example]

Получим документацию.

показать весь документ
print(
-- tag::example[]
math.abs(-25)
-- end::example[]
)

показать только тег example
math.abs(-25)

О том для чего это нужно говорилось в других статьях.

Модифицируемость кода (Changeability QA)

Автор: velkin
Дата: 08.01.15

Отсечение целей (сложность разработки)

Автор: velkin
Дата: 11.01.15

Ascii-графика

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

8-ми битный байт

[ditaa, target=byte8]
....
+--+--+--+--+--+--+--+--+
:0 :1 :2 :3 :4 :5 :6 :7 : 
+--+--+--+--+--+--+--+--+
|1 |2 |3 |4 |5 |6 |7 |8 |
+--+--+--+--+--+--+--+--+
....

Граф

[ditaa, target=graph]
....
        /--\
     /->+b +-\
/--\ |  \--/ |  /--\
|a +-+       +->|d |
\--/ |  /--\ |  \--/
     \->+c +-/
        \--/
....

Диаграмма активности

[ditaa, target=activitydiagram]
....
            ● начало

            |
            v
          /-+-\
     +----+{c}+----+
     |    \---/    |
     v             v
/----+-----\ /-----+----\
|активность| |активность|
\----+-----/ \-----+----/
     |    /---\    |
     +----+{c}+----+
          \-+-/
            |
            v

            ◉ конец
....

Диаграмма состояний

[ditaa, target=statediagram]
....
     /------\
     |начало|
     \--+---/
        |
   /----/
   |
   v
/--+--\  /-------\
|ждите+->+закрыть|
\--+--/  \---+---/
   |         |
   \----+----/
        |
        v
     /--+--\
     |конец|
     \-----/
....

Интерфейс

[ditaa, target=interface]
....
/------------------------------\
| Привет чумба             _[]x|
+--+--+--+---------------------+
|N |O |S |                     |
+--+--+--+--+------------------+
|           |                  |
|           |                  |
|           |                  |
|           |                  |
|           |                  |
|           |                  |
|           |                  |
+-----------+------------------+
|я слежу за тобой чумба...     |
+------------------------------+
....

Классификация понятий

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

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

.классификация по [признаку1]
Категория 1::
 * Элемент 1
 * Элемент 2
Категория 2::
 * Элемент 3
 * Элемент 4

.классификация по [признаку2]
Категория 3::
 * Элемент 1
 * Элемент 3
Категория 4::
 * Элемент 2
 * Элемент 4

Как видим элементы всё те же, то есть Элемент 1, Элемент 2, Элемент 3, Элемент 4, но когда они классифицируются по другим признакам, то входят в другие категории понятий.

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

Содержа́ние поня́тия — это знание о совокупности существенных признаков класса предметов.

Объём понятия — это знание о круге предметов, суще­ственные признаки которых отображены в понятии.

Обобщить понятие — это значит перейти от менее общего к более общему понятию.

Ограничить понятие — это значит перейти от более общего понятия к менее общему понятию.

Заключение

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