Аааа. Це так. Всяке буває))

Все вірно. Я так в кінці огляду і писав що

, що все це думки автора, а не правила, яких треба сліпо дотримуватись

Зауважу мабуть тільки шо про концепт «дотримуватись концепції яку вибрали з початку» то не про вимоги а про неймінг скоріше та про те які підходи обирати. Приклад — асершени через патерн стратегія. Якщо обрали так так краще притримуватись всюди так. Зручніше для ревю.

Вашу позицію зрозумів. Скажіть, як давно ви були у психолога і спілкувались про ваші проблеми? Чи обговорювали ви це ще з кимось? Як давно ви помітили що всі навколо неправі і ви молодець єдиний?
у відпуску можно ще сходити, доречі, та здати аналізи на вітаміни. Кажуть токсичність ще буває через депресію часто. А депресію треба лікувати. Лікуйтесь. бажаю швидкого одужання.

А ви такий токсичний через психологічні проблеми чи розумові?

ви дивились посилання що я скинув? і чому саме в тому випадку краще поліфморфізм аніж світч ? хіба там сказано ВИКИНУТИ світч взагалі? чому люди коли читають шось сприймають все радикально? :D

світ по можливості краще заміняти поліморфізмом але без фанатизма :D ну і також може порушувати принцип open-closed . як приклад можете читнути ось тут sourcemaking.com/...​itional-with-polymorphism

по-перше а що заважає розробнику поправити тест і відправити на ревʼю, по-друге а чим це відрізняєється від апдейту тестів будь-яких інших у процесі розробки? від мануальних до е2е :D я би не був таким категоричним у плані того який рівень хто покриває ))) є багато проєктів, компаній та умов коли межі сильно розмазані по всій команді :) я навіть ба більше скажу -є компанії де розробники пишуть е2е тести :) і доволі великі, продуктові, всім відомі :)

Сергію, ціль була як раз і зробити коротку вижимку найголовнішого шоб людина розуміла чи є сенс їй читати повністью книгу чи ці поради від дядки Боба для неї даремні шоб не витрачати час. по-друге список запахів коду та деяких порад можно використовувати початківцям одразу не читаючи всю книгу в деталях. Думаю, люди знайдуть користь в такому огляді — недарма ж лайкають та додають в обране.
якшо розписувати кожну пораду та приклади використання то вийде той самий чистий код :D
ну і коли я шукав огляд книжки — не знайшов нічого українською тому вирішив написати сам. доволі просто все :)

компанії типу MANGA з вами би не погодились :) в більшості компаній і проєктів — так, юніт тести лежать на девах, але якшо мова розробки спільна з мовою яку знає автоматизатор то це дуже дає буст у покритті тестами вашого продукту

яким боком забезпечення якості до тестування? самим я би сказав прямим :D це як спитати яким боком девелопмент до написання коду :D

100%. я саме це і пишу у коменті вище :)

враховуючи всі фактори треба приймати рішення щодо доречності використання того чи іншого патерна.
якщо доречність використання = 0 то використовувати не треба :) ізі катка :)

приклади реальні :)
вашу точку зору зрозумів, питань більше не маю :)

цитата

враховуючи всі фактори треба приймати рішення щодо доречності використання того чи іншого патерна.

якщо доречність використання = 0 то використовувати не треба :) ізі катка :)

ви написали що

цей набір 25 патернів є, мʼяко кажучи, не ідеальним.

от мені цікаво які на вашу думку кращі за ці 25 якщо ви їх так не полюбляєте

стосовно патернів які ви перерахували. доволі легко. дивіться — брідж може бути використан для запуску тестів на різних браузерах, інтерпретатор може бути використан коли ви пишите тест в своїй розробленій DSL — шось по типу геркіна чи бдд. адаптер може бути використан коли ви одну тестову тулу інтеграуєте в іншу, не знаю, наприклад, плейрат та селеніум. команд може бути використан коли ти розділяєш взаємодію з елементами сторінки та саму сторінку.
все залежить від контексту вашого проєкта, змін у ньому та як він буде еволюціюнювати і саме враховуючи всі фактори треба приймати рішення щодо доречності використання того чи іншого патерна.

90+% роботи в автотестуванні це вибір, що має бути в тесті, а що — не має

і так і ні. тест дизайн це лише частина роботи яку робить тестувальник. треба піклуватись про інфрастуктуру в якій ви запускаєте тести, піклуватись про фреймворк, про його архітектуру, про гнучкість та розширяємість, про моніторинг та мейнтенанс. якщо ви просто фігарите тести у форматі рекорд енд плейбек або лінійного скриптінгу — так, це має право на життя, але чи як довго? і що робити у світі коли вимоги будуть змінюватись часто з таким підходом? :)

п.с. стосовно

Замість цього могло б бути написання на шаблонній мові з автогенерацією з неї

чи писали ви тести в форматі BDD? чи помітили ви використання патернів GoF в BDD? чи помітили ви НЕДОЛІКИ використання такого підходу? чи знаєте ви межі коли його можна використовувати а коли це зайвий прошарок абстракції? :) питання риторичне

а які на вашу думку патерни не є ідеальними? або які не можна використовувати у програмуванні?

цілі QA не мають проєцуватись напряму на конкретні рішення дизайну коду.

не зовсім зрозумів цей поінт — qa пише код, шоб код був розширяємим треба використовувати принципи ооп, солід, грасп, патерни програмування та автотестування. чи ви про щось інше кажете?

ну насправді так і є — принципи солід можуть конфліктувати з патернами гоф. той же патрен сінглтон -він є порушенням майже всіх принципів солід. але тим не менш інколи без нього ніяк :) в житті завжди треба шукати баланс :D

в принципі, в інтернеті є будь-що, якщо погуглити :D коли я шукав огляд книжки щоб вирішити чи читати її чи ні я не знайшов адекватного та повного огляду. тому вирішив його сам написати :) всі огляди були дуже поверхневі або присипані якоюсь агрегсією авторів.

доволі цікава думка — а можете більш детально розвивинути чому ви думаєте що патрени GoF — це інфоциганство?

п.с. відповім на питання

який звʼязок QA з темою

дуже жаль, що вам не пощастило працювати з автотестувальниками, QA та SDETами але тим не менш. робота QA/TAE/SDET це написання фреймворків для тестування та тестів на різних рівнях -юніт, інтеграційному та e2e, написання сервісів-заглушок, написання бібліотек для тестування, написання генераторів тестових даних, тощо. Без знання як це зробити достатньо масштабовано, гнучко, читабельно, розширяємо — рішення будуть виходити доволі осередкові.

так той, принципи GRASP в книгах Роберта Мартіна так само розглядаються і рекомендуються — навіть уц цьому огляді про них згадується -low coupling and hight cohesion, також використання поліморфізма :D ви точно читали ці книжки що критикуєте Роберта так яро? :D бо виглядає шо просто накидуєте на вентілятор :D

да, доречі у нього є на ютубчику ціла серія безкоштовних відосів можна знайти тут в секції Talks cleancoder.com/products

хм. цкава думка. Роберт Вважає їх саме підвидом ДТО(та і я теж в принципі) ось вставлю цитату з книжки сторінка 101:

thixalongmy.haugiang.gov.vn/...​media/1175/clean_code.pdf

Active Record
Active Records are special forms of DTOs. They are data structures with public (or beanaccessed) variables; but they typically have navigational methods like save and find. Typically these Active Records are direct translations from database tables, or other data
sources

код це є інтерпретація слів та ідей.
дивись, я пояснив тобі ідею яку Роберт Мартін хоче донести. ти продовжуєш писати токсичні коментарі з присмаком пасивної агресії.
якщо тобі не подобаються ідеї Роберта Мартіна — ти завжди можеш написати йому у лінкедин або його сайт cleancoders.com свої думки і попрохати його потестити, пописати код і тд.
на цьому слові, не маю інтересу продовжувати та спорити чи щось намагатись пояснювати далі, тому вибач, але бесіду завершено, на все добре :)

ну слово «запахи» по відношенню до коду використовується доволі часто на конфах та статтях різних. тому думаю саме слово «запахи» доречно вживати :) доречі, знайшов також в самій книзі в україньскому варіанті також вживається це слово — запахи :)