Эффективное программирование

Что-то там driven Development

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

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

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

https://upload.wikimedia.org/wikipedia/ru/d/da/RUP_process.png

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

Или возьмём ключевые процессы из википедии.
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)
Отсечение целей (сложность разработки)

Ascii-графика

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

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

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

http://files.rsdn.org/99832/documents-byte8.svg

Граф

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

http://files.rsdn.org/99832/documents-graph.svg

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

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

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

            ◉ конец
....

http://files.rsdn.org/99832/documents-activitydiagram.svg

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

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

http://files.rsdn.org/99832/documents-statediagram.svg

Интерфейс

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

http://files.rsdn.org/99832/documents-interface.svg

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

29.05.2022 7 комментариев

комментировать обсудить в форуме

scf

29.05.2022 07:24

Здравствуйте, velkin, Вы писали:

V>

Что-то там driven Development

Эти идеи уже в прошлом. На практике программные системы настолько сложны, что их детальное проектирование и верификация неподъемны.

ответить

velkin

29.05.2022 08:07

Здравствуйте, scf, Вы писали:

scf>Эти идеи уже в прошлом. На практике программные системы настолько сложны, что их детальное проектирование и верификация неподъемны.

Недокументируемые особенности

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

Приёмы мышления

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

Системы документирования

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

Модель разработки

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

Исчерпывающая документация

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

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

итеративная модель разработки

ответить

kov_serg

29.05.2022 08:14

Здравствуйте, velkin, Вы писали:

V>

итеративная модель разработки

V>Image: 320px-Iterative_development_model.svg.png

https://i.pinimg.com/originals/ee/bf/1e/eebf1e3f011e967a471ce1cdb5758e3c.jpg

ответить

velkin

29.05.2022 08:31

Включение кода

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

Исходные файлы

.main.cpp
include::main.cpp[]

.test.hpp
include::test.hpp[]

.test.cpp
include::test.cpp[]

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

Функционал 01

.functional 01, main.cpp
include::main.cpp[tag=functional01]

.functional 01, test.hpp
include::test.hpp[tag=functional01]

.functional 01, test.cpp
include::test.cpp[tag=functional01]

Функционал 02

.functional 02, test.hpp
include::test.hpp[tag=functional02]

.functional 02, test.cpp
include::test.cpp[tag=functional02]

Функционал 03

.functional 03, main.cpp
include::main.cpp[tag=functional03]

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

ответить

Ночной Смотрящий

31.05.2022 08:13

Здравствуйте, velkin, Вы писали:

V>

Ascii-графика

Открой уже для себя PlantUML

... << RSDN@Home 1.3.17 alpha 5 rev. 62>>

ответить

velkin

31.05.2022 11:57

Ошибочное предположение

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Ascii-графика
НС>Открой уже для себя PlantUML

Это давно уже известно. В статье я ограничился комментарием.

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

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

Полный список расширений можно посмотреть здесь.
https://docs.asciidoctor.org/diagram-extension/latest/

a2s
actdiag
<barcode,barcode>>
blockdiag
bpmn
bytefield
diagrams
ditaa
dpic
erd
gnuplot
graphviz
meme
mermaid
msc
nomnoml
nwdiag
packetdiag
pikchr
plantuml
rackdiag
seqdiag
shaape
smcat
svgbob
symbolator
syntrax (Syntrax)
syntrax (JSyntrax)
tikz
umlet
vega
vegalite
wavedrom

Виды PlantUML

Обрати внимание как выглядит PlantUML:
https://plantuml.com/ru/

Uml диаграмма:
1) Диаграммы последовательности
2) Диаграммы использования (прецедентов)
3) Диаграммы классов
4) Диаграммы объектов
5) Диаграммы активности (вот устаревший синтаксис)
6) Диаграммы компонентов
7) Диаграммы развёртывания
8) Диаграммы состояний
9) Диаграммы синхронизации

Другие диаграммы:
1) JSON данные
2) Данные в формате YAML
3) Диаграммы сети (nwdiag)
4) Каркасный графический интерфейс
5) Диаграммы ArchiMate
6) Язык описания и спецификации (SDL)
7) Диаграммы Ditaa
7) Диаграммы Gantt
8) Диаграммы MindMap
9) Диаграммы иерархической структуры работ (WBS)
10) Математика в нотации AsciiMath или JLaTeXMath
11) Диаграммы типа сущность — связь (ER)

Минусы PlantUML

Давай для примера возьмём диаграмму активности из примера на сайте.

[plantuml, target=plantumlactivity, format=svg]
....
@startuml
start
if (Graphviz установлен?) then (да)
  :доступны все\nдиаграммы;
else (нет)
  :доступны только диаграммы
  __последовательностей__ и __активностей__;
endif
stop
@enduml
....

http://files.rsdn.org/99832/plantumlactivity.svg

Здесь есть очевидные минусы:
1) Диаграмму активности нельзя править без специальных знаний синтаксиса PlantUML, который сложнее ascii-графики.
2) Этот синтаксис по сути просто дублирует код, пусть и на псевдоязыке, то есть лишняя работа.
3) Документацию при правке в которой и будет происходить вся работа придётся видеть не в виде схемы, а в виде кода.
4) Документация может быть сгенерирована без использования диаграмм,
то есть так (без генерации диаграмм)

asciidoctor asciidoctor.txt

а не так (с генерациями диаграмм)

asciidoctor -r asciidoctor-diagram asciidoctor.txt

5) Чтобы проверить диаграмму PlantUML на правильность придётся её сгенерировать и обновить страницу, это очень много лишней работы.
6) Синтаксис конкретных диаграмм как правило менее универсален, в отличии от ascii-графики, которая имеет менее жёсткие ограничения.

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

@startuml
abstract        abstract
abstract class  "abstract class"
annotation      annotation
circle          circle
()              circle_short_form
class           class
diamond         diamond
<>              diamond_short_form
entity          entity
enum            enum
interface       interface
@enduml

@startuml
Class01 "к одному" *-- "от многих" Class02 : композиция
Class03 o-- Class04 : агрегация
Class05 --> "1" Class06
@enduml

@startuml
class Object << general >>
Object <|--- ArrayList
note top of Object : In java, every class\nextends this one.
note "Это не привязанная\nни к чему заметка" as N1
note "Эта заметка привязана\nсразу к нескольким классам" as N2
Object .. N2
N2 .. ArrayList
class Foo
note left: Эта заметка будет\nпривязана к последнему\nопределенному классу
@enduml

По мне так наглядность подобных "схем" стремится к нулю. Я когда давным давно попробовал PlantUML был впечатлён, как впрочем и другими генераторами. Но вот когда начинаешь набирать что-то сам на практике, то некоторые вещи становятся слишком сложными.

Плюсы PlantUML

Но у генераторов не из ascii-графики, в частности у PlantUML есть плюсы. Например, если сгенерировать формулу с помощью stem
https://docs.asciidoctor.org/asciidoc/latest/stem/

Для примера вот так:

stem:[P\left(A=2\middle|\frac{A^2}{B}>4\right)]

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

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

а текст

\(P\left(A=2\middle|\frac{A^2}{B}>4\right)\)

А почему так происходит можно почитать:
https://docs.mathjax.org/en/latest/input/asciimath.html
https://docs.mathjax.org/en/latest/input/tex/index.html
https://en.wikipedia.org/wiki/MathJax

И вот здесь пусть даже сложный синтаксис может прийти к месту. Тем более он что так, что так сложный для вывода математики. Главное, что в результате получим изображение в формате svg, а не какой-то JavaScript.

[plantuml, target=plantumlformula1, format=svg]
....
@startmath
f(t)=(a_0)/2 + sum_(n=1)^ooa_ncos((npit)/L)+sum_(n=1)^oo b_n\ sin((npit)/L)
@endmath
....

http://files.rsdn.org/99832/plantumlformula1.svg

Иные генераторы Ascii-графики

Помимо Ditaa есть так же A2S (ASCIIToSVG), Shaape, Svgbob. Хотя за некоторые генераторы можно сказать, что они более продвинутые, тогда как Ditaa самая скромная по функционалу, так же стоит отметить их сложную установку в некоторых случаях.

Иные возможности генерации

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

Например, ссылка:

qrcode:https://rsdn.org/forum/management/8287889.all[target=qrcode, format=svg]

Превращается в:

И считывается смартфоном. Да, сейчас такое модно не только в печатных книгах, но и на сайтах.

Теория против практики

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

Я ведь в статье не шучу, что разработку через тестирование придумали из-за лени. А всё почему, да потому что всё, что замедляет процесс работы программисты очень быстро отбрасывают. И они понимают это, но ничего не могут с собой поделать. Тогда появляются что-то driven Development. Попробуй заставить даже не других людей, а себя писать на PlantUML.

Какие-либо рациональные предложения должны решать проблемы, а не создавать их.

Обрати внимание на старую тему (25.06.20):

https://www.rsdn.org/forum/shareware/7763329.all

От: velkin
Дата: 26.06.20 09:49

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

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

У меня было требование чтобы она не зависела ни от подключения к интернету, ни от выбранной темы, например, тёмной и так далее. Вот эти строчки просты, но я провёл не один опыт, прежде чем к ним прийти:
# source
parameter_source_highlighter="-a source-highlighter=pygments"
parameter_pygments_linenums_mode="-a pygments-linenums-mode=inline"
parameter_pygments_style="-a pygments-style=native"
Или генерация диаграмм, если делать не в svg, а например в png, то качество страницы получается ниже. При этом нужно генерировать диаграммы из текста, для этого должны быть установлены сторонние генераторы диаграмм.

Такой текст написанный как внутри файла txt, так и отдельно, который можно вставить в документацию:
[plantuml, diagram-classes-en, svg]
....
class CatProcessor
class DiagramBlock
class DitaaBlock
class PlantUmlBlock

CatProcessor <|-- DiagramBlock
DiagramBlock <|-- DitaaBlock
DiagramBlock <|-- PlantUmlBlock
....
Превращается в такую диаграмму:

А вот его перевод:
[plantuml, diagram-classes-ru, svg]
....
class КошачийПроцессор
class БлокДиаграмм
class БлокДитаа
class БлокПлантУМЛ

КошачийПроцессор <|-- БлокДиаграмм
БлокДиаграмм <|-- БлокДитаа
БлокДиаграмм <|-- БлокПлантУМЛ
....
И получившаяся svg графика это лёгкий способ поддерживать многоязычность.

Или такое:
[plantuml, graphic-mind, svg]
....
@startmindmap
* Debian
** Ubuntu
*** Linux Mint
*** Kubuntu
*** Lubuntu
*** KDE Neon
** LMDE
** SolydXK
** SteamOS
** Raspbian with a very long name
*** <s>Raspmbc</s> => OSMC
*** <s>Raspyfi</s> => Volumio
@endmindmap
....
PlantUml это различные виды UML диаграмм. Другое дело Syntrax:
[syntrax, syntrax-test, svg, style='syntrax.ini', transparent=true]
....
choice('кошка', 'собака', 'ворона') 
....
И получается:

Я думал над созданием одинаковых стилей для разных генераторов. И ещё чтобы хорошо было видно диаграмму как в тёмных темах, так и в светлых.

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

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

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

Для меня не проблема поставить практически любой динамический сайт на известных CMS, да и ставил я уже их много раз. Но там смысл тот же самый, даже после настройки, что публиковать? С тем же успехом мог бы писать текстовые файлы, а для диаграмм использовать псевдографику.
╭──────────────────────────────╮
│━┃вариант с разделами         │
├───────────────┬──────────────┤
│ главный поток │ доп. поток   │
├───────────────┼──────────────┤
│      ● начало │              │
│      │        │              │
│      ▼        │              │
│  ━━━━━━━━━━━━━┿━━━━━━━━━━━━  │
│      │        │      │       │
│      ▼        │      ▼       │
│ ╭────┴─────╮  │ ╭────┴─────╮ │
│ │активность│  │ │активность│ │
│ ╰────┬─────╯  │ ╰────┬─────╯ │
│      │        │      │       │
│      ▼        │      ▼       │
│  ━━━━━━━━━━━━━┿━━━━━━━━━━━━  │
│      │        │              │
│      ▼        │              │
│      ◉ конец  │              │
╰───────────────┴──────────────╯

       product            factory method
╭╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╮ ╭╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╮
┊ ┌───────────┐     ┊ ┊ ┌────────────────┐  ┊
┊ │<interface>│     ┊ ┊ │<interface>     │  ┊
┊ │Product    │     ┊ ┊ │Creator         │  ┊
┊ ├───────────┤     ┊ ┊ ├────────────────┤  ┊ ┌─────────────────────────┐
┊ └───────────┘     ┊ ┊ │+factoryMethod()│  ┊ │...                      │
┊       ▲           ┊ ┊ │+AnOperation() ○┼╌╌┼╌┤product = FactoryMethod()│
┊       ┊           ┊ ┊ └────────────────┘  ┊ │...                      │
┊       ┊           ┊ ┊         ▲           ┊ └─────────────────────────┘
┊       ┊           ┊ ┊         ┊           ┊
┊ ┌───────────────┐ ┊ ┊ ┌─────────────────┐ ┊
┊ │<realization>  │ ┊ ┊ │<realization>    │ ┊
┊ │ConcreteProduct│◃┼╌┼╌┤ConcreteCreator  │ ┊
┊ ├───────────────┤ ┊ ┊ ├─────────────────┤ ┊
┊ ├───────────────┤ ┊ ┊ ├─────────────────┤ ┊ ┌──────────────────────────┐
┊ └───────────────┘ ┊ ┊ │+factoryMethod()○┼╌┼╌┤return new ConcreteProduct│
┊                   ┊ ┊ └─────────────────┘ ┊ └──────────────────────────┘
╰╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╯ ╰╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╯
Я вижу на rsdn небольшие искажения, но у меня в текстовом редакторе их нет.

А между тем существует RFC, в котором люди создали огромное количество стандартов. Тот же RFC 2223 это инструкция для авторов RFC. А можно сделать ещё проще, отбросив условности и просто набирать текст, максимум оставить ограничения во сколько-то символов, если используется терминал. Да и то не обязательно, перенос строк уже много где есть.

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

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

В итоге интернет переусложнён. Неудивительно, что я до сих пор не вижу мощного воплощения идей о корпоративных приложениях Мартина Фаулера, когда данными можно легко и просто манипулировать.

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

ответить

B0FEE664

10.06.2022 11:50

Здравствуйте, velkin, Вы писали:

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

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

ответить

комментировать обсудить в форуме

Эффективное программирование

Разработка через документирование (documentation-driven development)

Что-то там driven Development

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

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

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

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

Теги в коде

Ascii-графика

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

Граф

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

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

Интерфейс

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

Заключение

Что-то там driven Development

Недокументируемые особенности

Приёмы мышления

Системы документирования

Модель разработки

Исчерпывающая документация

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

итеративная модель разработки

итеративная модель разработки

Включение кода

Исходные файлы

Функционал 01

Функционал 02

Функционал 03

Ascii-графика

Ошибочное предположение

Виды PlantUML

Минусы PlantUML

Плюсы PlantUML

Иные генераторы Ascii-графики

Иные возможности генерации

Теория против практики

Обрати внимание на старую тему (25.06.20):