Гледайки как дебатът за дизайна се разиграва по време на работа, бях поразен от липсата на действителна конкретна обратна връзка относно предложените алтернативи. Данните няма да премахнат политиката и личността от разговора, но (и тук може би съм наивен) обратната връзка не може да навреди. Ако съм аз в стаята, бих искал да чуя нещо по-конкретно от „Не харесвам Adapter Factories“.

Когато променя поведението на дадена програма, мога (е, „би трябвало да мога“) да получа незабавна обратна връзка от тестове за това дали поведението се е променило по начина, по който очаквах и само по начина, по който очаквах. Какво би означавало да се създаде аналогична ежеминутна обратна връзка за структурни промени?

Добър дизайн

Добрият дизайн е този, който позволява необходимите бъдещи промени в поведението. Ако трябваше да избираме между два дизайна, предвид безкрайни ресурси, ние просто щяхме да ги внедрим и двата и да видим кой позволява необходимите бъдещи промени в поведението.

Нямаме безкрайни ресурси, но понякога можем да играем малко от тази игра. „Знаете ли тази болезнена промяна в поведението, която току-що направихме? Ако дизайнът беше такъв и такъв, тогава това щеше да е промяна в един файл.

Едно от предимствата на тези хипотетични промени е конкретността. По същите причини, поради които тестовете в разработката, управлявана от тестове, подпомагат мисленето, задвижването на дизайн от конкретна промяна в поведението помага да се фокусира вниманието върху това, което има значение.

Хипотетичните промени страдат от това, че не са реални. Може би има основателна причина хипотетичната промяна да не е толкова проста, но няма да е очевидна, докато не я изпробваме.

Някои незабавни отзиви?

Възможно ли е да предложим някаква незабавна обратна връзка за качеството на наскоро завършени структурни промени? Може би. Ето един пример.

Да приемем, че имаме дублиран кодов фрагмент. Ако променим един фрагмент, за да повлияем на промяна на поведението (BΔ), тогава трябва да променим и другия.

След промяната на структурата (SΔ) на извличане на общ помощен метод, еквивалентната промяна на поведението (BΔ’) може да бъде направена чрез промяна на помощника.

Ето въпроса – като се имат предвид BΔ и SΔ, при какви условия можем автоматично да извлечем BΔ’? Това ми се струва неразрешимо като цяло (радвам се, че се оказа грешно), но може ли да се направи за полезно подмножество от промени?

Промени в структурата на точкуването

Ако можем да извлечем каква би била промяната в поведението, ако промяната на структурата вече е била приложена, тогава можем да сравним промяната на поведението със и без промяната на структурата. Как изглежда тази функция за точкуване?

  • По-добре е по-малко места за смяна (намаленото свързване в горния пример).
  • По-малък „диапазон“ от промени е по-добър. За система, подредена йерархично, колкото по-близък е общият прародител на промените, толкова по-добре. (Един вкус на сплотеност)

  • Колкото повече се промени даден елемент, толкова по-добре (другият вкус на сплотеността). В примера по-долу извличането на помощен метод, който трябва да бъде напълно заменен, е по-добро от модифицирането на 2 от много редове в оригиналния метод.

Тестване на структурни промени

Като се имат предвид тези две способности - извличане на еквивалентни промени в поведението след прилагане на промяна на структурата и оценка на промените в поведението - можем грубо да тестваме ефективността на промените в структурата. Като се има предвид промяна на структурата, оценете всички промени в поведението от всякога и сравнете резултатите преди и след промяната на структурата.

Кажете, че извличам метод. Околната среда отговаря с „4 исторически промени в поведението биха подобрили резултатите въз основа на тази промяна“. Или „3 промени ще се подобрят и 6 промени ще имат по-нисък резултат.“ Това ми се струва полезна обратна връзка.

Някои от промените в поведението няма да успеят да бъдат приложени. За някои промени в поведението промяната на структурата ще бъде без значение. Това е добре. Искам обратна връзка сега, а не перфектен отговор.

Предупреждения

Подходът за тестване на структурни промени, очертан тук, има много ограничения. Замислено е като „по-добро от нищо/спорене“, а не като последна дума (въпреки че намеците за ML, предлагани от фитнес функция, са интригуващи). Ето някои от ограниченията.

  • Post hoc. Можем да оценим само промените в поведението, които вече сме направили, но не и промените, които ще да направим. Бъдещето има тенденция да бъде подобно на миналото, освен когато не е.
  • Катерене по хълм. Мога да си представя блокове от структурни промени, ранните части на които влошават резултатите, докато последните промени не подобряват драстично резултатите. Не съм сигурен дали това наистина ще се случи, но е нещо, за което трябва да следите.
  • Голф. Най-добрият дизайн за една система не е непременно този, който понижава общия резултат на всички промени в поведението, не и ако този дизайн ограничава тези, които правят промени в поведението, до тези, които са изградили системата. „Умен“ има цена, която може или не може да си струва.
  • Законът на Гудхарт. Резултатите трябва да информират за вземането на индивидуални решения. Веднага щом генерирате число, някой, който не е уверен в решенията си, ще оцени числото, вместо да гледа територията.