Методология - это способ построения сложных систем сверху вниз, причём такой, что на каждом уровне абстракции остаются релевантные модели будущей системы.
идеальная методология — это такой способ разбиения системы на аспекты и построения кода системы по ее аспектам, что 1. изменения внутри каждого аспекта могут вноситься независимо от других аспектов, и 2. для небольших изменений функциональности требуются небольшие изменения внутри аспектов
п.1 это ортогональность, п.2 это непрерывность в математической терминологии
роли аспектов могут выполнять уровни, но аспекты вовсе не всегда образуют иерархию
в первой редакции слова "кода" не было, было просто "построения системы по ее аспектам", но потом я решил уточниться немного
в том случае, когда люди — винтики, слово "код" вполне подходит (хотя и с маленькой натяжкой); а вот в случае наличия в системе уникальных людей уже, кхм, все несколько по-другому
тут требуется уточнение терминов, т.к. скажем трудно найти более "внешне связанную" подсистему, чем фильтр (типа producer | filter | consumer > result.txt)
да, почему это хороший вопрос — потому что ответ на него задает критерии качества языков программирования
btw, мое гугление по "критерии качества языков программирования" закончилось полным провалом
например, аспект "сохранение тепла в доме" может учитываться в подсистеме утепления стен, в подсистеме окон (тройные стекла вместо двойных), и в подсистеме вентиляции (теплообменник)
конечно, в софте аспект ближе к подсистеме, но все равно это разные вещи
"сохранение тепла в доме" - это не "аспект", а нефункциональное требование к системе. Хотя всё равно понятно. А подсистемы - это про основную тему поста.
На самом деле оно должно быть выражено в терминах "Охлаждение помещения при внешней температуре -10 градусов не должно превышать Х килоджоулей в сутки" или в чём там выражается теплоотдача. Я уже не помню, тем более на русском.
ортогональность аспектов в данном случае означает, что утепление стен, скажем, должно быть отделено от несущей конструкции, которая реализует аспект прочности (т.е. если допустим потребуется усилить утепление, то это было возможно сделать без полного разбора дома (т.е. независимо от несущей подсистемы); кстати, тут еще видно, что в некоторых случаях, когда есть хорошая теория + стабильность внешних условий, не обязательно делать такой сильный упор на модифицируемость внутри аспекта или внутри подсистемы)
или вот скажем говнопроектировщики реальных настольных часов, бывших у меня в советские времена, смешали два аспекта:
1. подачу напряжения от батарейки на плату
2. механическое удержание задней крышки часов
оба этих аспекта были реализованы парой контактных пружин (одна на плюс, другая на землю)
в результате частого съема крышки (емнип для замены батарейки) эти пружины стерли контактные площадки, которых касались пружины, и незначительное касание крышки нарушало контакт (особенно потому, что одна пружина не может *качественно* *одновременно* давить и вбок на крышку, и вглубь на контактные площадки)
Опять же, переводя на русский язык, есть требования, выполнение которых взаимосвязано. Есть те, которые противоречат друг другу и надо искать или их важность для клиента, или оптимальный баланс.
1. в будущем я вообще не буду писать слово discuss, оно неявно подразумевается *везде*
2. уверенные формулировочки с моей стороны не должны останавливать от возражений — как раз возражения это самое *интересное*, что я могу услышать
3. наконец, если я где-то типа "победил в споре", это не значит, что я забыл противоположное мнение — я его помню и обдумываю, и могу даже скажем через полгода-год неожиданно понять рациональное зерно в противоположной точке зрения
почему я вообще не употребил слово "релевантность"? потому что
1. и так понятно, что хочется иметь модель, релевантную реальности
2. релевантна ли модель реальности может быть само по себе сложным вопросом
3. модель может быть релевантна сейчас, но не релевантна потом
4. и наоборот, первоначальная модель может оказаться нерелевантной, но затем приведена в порядок
в сухом остатке — система должна легко модифицироваться; "легко модифицироваться" как раз означает "ортогонально модифицироваться и непрерывно модифицироваться"
но я считаю, что методология должна делаю упор не на "модель должна быть релевантна прямо сейчас", а на "модель может быть сделана релевантной путем небольших изменений, и при этом мы (гарантированно?) не уткнемся в непреодолимые границы"
кроме того, "соответствие поведения модели поведению системы на заданной области" может быть практически достаточно, но затем подвергнуто дальнейшему улучшению
скажем, для начала можно считать, что итог игры всегда дает в сумме 1 (0+1=1/2+1/2=1+0), но бывает, что обоим командам присуждают техническое поражение
или скажем в шахматах не всегда pgn прокатывает, т.к. иногда судья может решить, что король, уроненный и (случайно?) поставленный не на ту клетку, стоит именно на неправильной клетке, и т.п.
это я к тому, что то, что казалось очень даже релевантным, может неожиданно оказаться не таковым
Задача методологии (по крайней мере первого типа) - это не заменить голову инженеру, а предоставить ему наиболее удобные инструменты для решения проблемы.
В любой методологии инженер может сделать модель системы не релевантной или не подстраиваемой под изменения. Но в некоторых методологиях глупости делать сложнее и они видны сразу. В других никто даже и не знает, насколько релевантной получилась или не получилась модель.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
branchandroot
no subject
Date: 2013-08-31 03:52 pm (UTC)идеальная методология — это такой способ разбиения системы на аспекты и построения кода системы по ее аспектам, что 1. изменения внутри каждого аспекта могут вноситься независимо от других аспектов, и 2. для небольших изменений функциональности требуются небольшие изменения внутри аспектов
п.1 это ортогональность, п.2 это непрерывность в математической терминологии
роли аспектов могут выполнять уровни, но аспекты вовсе не всегда образуют иерархию
discuss
no subject
Date: 2013-08-31 03:57 pm (UTC)И, естественно, разбиение - это тоже инженерное решение, минимизирующее внешние связи подсистем или локализирующие риск изменений.
no subject
Date: 2013-08-31 04:10 pm (UTC)в первой редакции слова "кода" не было, было просто "построения системы по ее аспектам", но потом я решил уточниться немного
в том случае, когда люди — винтики, слово "код" вполне подходит (хотя и с маленькой натяжкой); а вот в случае наличия в системе уникальных людей уже, кхм, все несколько по-другому
no subject
Date: 2013-08-31 04:19 pm (UTC)тут требуется уточнение терминов, т.к. скажем трудно найти более "внешне связанную" подсистему, чем фильтр (типа producer | filter | consumer > result.txt)
да, почему это хороший вопрос — потому что ответ на него задает критерии качества языков программирования
btw, мое гугление по "критерии качества языков программирования" закончилось полным провалом
интересно, кто-то вообще этим интересуется?
no subject
Date: 2013-08-31 07:26 pm (UTC)Инженерное решение - это такое решение, которое даёт оптимальный результат при учёте плюсов, минусов и рисков.
Задача в том, чтобы подсистемы можно было рассматривать независимо, и при этом интерфейсы между ними были бы стабильными и понятными.
no subject
Date: 2013-08-31 08:00 pm (UTC)понятно, что это камешек в огород учОных
no subject
Date: 2013-08-31 08:17 pm (UTC)А так, ИТ давно надо было бы приписать к гуманитарным дисциплинам. Но профессорам это не выгодно.
no subject
Date: 2013-08-31 04:25 pm (UTC)тут конечно можно придраться к моей терминологии, но по-моему она близка к общепринятой
no subject
Date: 2013-08-31 05:01 pm (UTC)конечно, в софте аспект ближе к подсистеме, но все равно это разные вещи
no subject
Date: 2013-08-31 07:30 pm (UTC)На самом деле оно должно быть выражено в терминах "Охлаждение помещения при внешней температуре -10 градусов не должно превышать Х килоджоулей в сутки" или в чём там выражается теплоотдача. Я уже не помню, тем более на русском.
no subject
Date: 2013-08-31 05:13 pm (UTC)или вот скажем говнопроектировщики реальных настольных часов, бывших у меня в советские времена, смешали два аспекта:
1. подачу напряжения от батарейки на плату
2. механическое удержание задней крышки часов
оба этих аспекта были реализованы парой контактных пружин (одна на плюс, другая на землю)
в результате частого съема крышки (емнип для замены батарейки) эти пружины стерли контактные площадки, которых касались пружины, и незначительное касание крышки нарушало контакт (особенно потому, что одна пружина не может *качественно* *одновременно* давить и вбок на крышку, и вглубь на контактные площадки)
no subject
Date: 2013-08-31 07:32 pm (UTC)no subject
Date: 2013-08-31 04:38 pm (UTC)1. в будущем я вообще не буду писать слово discuss, оно неявно подразумевается *везде*
2. уверенные формулировочки с моей стороны не должны останавливать от возражений — как раз возражения это самое *интересное*, что я могу услышать
3. наконец, если я где-то типа "победил в споре", это не значит, что я забыл противоположное мнение — я его помню и обдумываю, и могу даже скажем через полгода-год неожиданно понять рациональное зерно в противоположной точке зрения
no subject
Date: 2013-08-31 04:04 pm (UTC)1. и так понятно, что хочется иметь модель, релевантную реальности
2. релевантна ли модель реальности может быть само по себе сложным вопросом
3. модель может быть релевантна сейчас, но не релевантна потом
4. и наоборот, первоначальная модель может оказаться нерелевантной, но затем приведена в порядок
в сухом остатке — система должна легко модифицироваться; "легко модифицироваться" как раз означает "ортогонально модифицироваться и непрерывно модифицироваться"
no subject
Date: 2013-08-31 07:22 pm (UTC)no subject
Date: 2013-08-31 07:41 pm (UTC)но я считаю, что методология должна делаю упор не на "модель должна быть релевантна прямо сейчас", а на "модель может быть сделана релевантной путем небольших изменений, и при этом мы (гарантированно?) не уткнемся в непреодолимые границы"
кроме того, "соответствие поведения модели поведению системы на заданной области" может быть практически достаточно, но затем подвергнуто дальнейшему улучшению
скажем, для начала можно считать, что итог игры всегда дает в сумме 1 (0+1=1/2+1/2=1+0), но бывает, что обоим командам присуждают техническое поражение
или скажем в шахматах не всегда pgn прокатывает, т.к. иногда судья может решить, что король, уроненный и (случайно?) поставленный не на ту клетку, стоит именно на неправильной клетке, и т.п.
это я к тому, что то, что казалось очень даже релевантным, может неожиданно оказаться не таковым
no subject
Date: 2013-08-31 08:15 pm (UTC)В любой методологии инженер может сделать модель системы не релевантной или не подстраиваемой под изменения. Но в некоторых методологиях глупости делать сложнее и они видны сразу. В других никто даже и не знает, насколько релевантной получилась или не получилась модель.