Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

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

по поводу

Похоже на правду? А то башка уже не очень варит, а завтра опять весь день митинговать.

Comments

[m e (from livejournal.com)]

хороший вопрос

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

п.1 это ортогональность, п.2 это непрерывность в математической терминологии

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

discuss

[vit-r.livejournal.com]

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

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

[m e (from livejournal.com)]

почему я вообще не употребил слово "релевантность"? потому что

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

2. релевантна ли модель реальности может быть само по себе сложным вопросом

3. модель может быть релевантна сейчас, но не релевантна потом

4. и наоборот, первоначальная модель может оказаться нерелевантной, но затем приведена в порядок

в сухом остатке — система должна легко модифицироваться; "легко модифицироваться" как раз означает "ортогонально модифицироваться и непрерывно модифицироваться"

[m e (from livejournal.com)]

хех

в первой редакции слова "кода" не было, было просто "построения системы по ее аспектам", но потом я решил уточниться немного

в том случае, когда люди — винтики, слово "код" вполне подходит (хотя и с маленькой натяжкой); а вот в случае наличия в системе уникальных людей уже, кхм, все несколько по-другому

[m e (from livejournal.com)]

> минимизирующее внешние связи подсистем

тут требуется уточнение терминов, т.к. скажем трудно найти более "внешне связанную" подсистему, чем фильтр (типа producer | filter | consumer > result.txt)

да, почему это хороший вопрос — потому что ответ на него задает критерии качества языков программирования

btw, мое гугление по "критерии качества языков программирования" закончилось полным провалом

интересно, кто-то вообще этим интересуется?

[m e (from livejournal.com)]

наконец, аспект — это не подсистема

тут конечно можно придраться к моей терминологии, но по-моему она близка к общепринятой

[m e (from livejournal.com)]

и еще можно чуть-чуть познакомиться

1. в будущем я вообще не буду писать слово discuss, оно неявно подразумевается *везде*

2. уверенные формулировочки с моей стороны не должны останавливать от возражений — как раз возражения это самое *интересное*, что я могу услышать

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

[m e (from livejournal.com)]

например, аспект "сохранение тепла в доме" может учитываться в подсистеме утепления стен, в подсистеме окон (тройные стекла вместо двойных), и в подсистеме вентиляции (теплообменник)

конечно, в софте аспект ближе к подсистеме, но все равно это разные вещи

[m e (from livejournal.com)]

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

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

1. подачу напряжения от батарейки на плату

2. механическое удержание задней крышки часов

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

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

[vit-r.livejournal.com]

Релевантность, то есть соответствие поведения модели поведению системы на заданной области соответствия, - это основной параметр модели.

[vit-r.livejournal.com]

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

Инженерное решение - это такое решение, которое даёт оптимальный результат при учёте плюсов, минусов и рисков.

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

[vit-r.livejournal.com]

"сохранение тепла в доме" - это не "аспект", а нефункциональное требование к системе. Хотя всё равно понятно. А подсистемы - это про основную тему поста.

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

[vit-r.livejournal.com]

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

[m e (from livejournal.com)]

тут, понятно, спорить невозможно

но я считаю, что методология должна делаю упор не на "модель должна быть релевантна прямо сейчас", а на "модель может быть сделана релевантной путем небольших изменений, и при этом мы (гарантированно?) не уткнемся в непреодолимые границы"

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

скажем, для начала можно считать, что итог игры всегда дает в сумме 1 (0+1=1/2+1/2=1+0), но бывает, что обоим командам присуждают техническое поражение

или скажем в шахматах не всегда pgn прокатывает, т.к. иногда судья может решить, что король, уроненный и (случайно?) поставленный не на ту клетку, стоит именно на неправильной клетке, и т.п.

это я к тому, что то, что казалось очень даже релевантным, может неожиданно оказаться не таковым

[m e (from livejournal.com)]

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

понятно, что это камешек в огород учОных

[vit-r.livejournal.com]

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

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

[vit-r.livejournal.com]

Выведение подобного определения оставит без работы многие слои высокооплачиваемых специалистов. А они этого не хотят.

А так, ИТ давно надо было бы приписать к гуманитарным дисциплинам. Но профессорам это не выгодно.