TDD: Trauma Driven Design
Oct. 22nd, 2019 02:46 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ex0_planet... Или Tool Driven Design, кому как больше нравится...
Как-то вдруг внезапно осознал, что всё что стоит за концепцией, например, "инкапсуляции" (как это понимается обычно в современном ООП) — всего лишь чья-то боль по поводу невозможности быстро найти и заменить все вхождения паттерна А на паттерн Б.
Ну, то есть, натурально, какой-нибудь восемьдесят восьмой год, сидит бородач в свитере перед монитором и кодовой базой в 100K-200K SLOC и понимает, что вместо "foo->bar = 640" надо бы писать какое-нибудь "updateGeometry(&foo, 640, 480)". И с инструментарием уровня турбо си восемьдесят восьмого года это — ЖОПА. Ну, каждый кто с подобным встречался поймёт. Все мы знаем, что прижилось решение просто запретить программерам писать "foo->bar = 640".
И вот сейчас в исторической перспективе становится понятно, что возникшую проблему можно было решить миллионом разных способов. Во всяком там энтерпрайзе куда более злобные изменения прокатывают под названием "рефакторинга", а возникающая при этом боль сглаживается контролем версий, разными там автотестами, итд итп. Чего в восемьдесят восьмом году просто не было, или было в рудиментарном виде. И если бы что-то из этого успело чуть пораньше, то никакой "парадигмы" ООП могло бы и не быть, а просто была бы рекомендация уровня best practices делать всё на ADT. А если не догадались сразу — ну чтож, бывает, линтер со статическим анализатором в помощь.
Интересно, сколько там, внизу, еще живет поспешных, неуклюжих, ad hoc решений заматеревших со временем в "концепции"?
Как-то вдруг внезапно осознал, что всё что стоит за концепцией, например, "инкапсуляции" (как это понимается обычно в современном ООП) — всего лишь чья-то боль по поводу невозможности быстро найти и заменить все вхождения паттерна А на паттерн Б.
Ну, то есть, натурально, какой-нибудь восемьдесят восьмой год, сидит бородач в свитере перед монитором и кодовой базой в 100K-200K SLOC и понимает, что вместо "foo->bar = 640" надо бы писать какое-нибудь "updateGeometry(&foo, 640, 480)". И с инструментарием уровня турбо си восемьдесят восьмого года это — ЖОПА. Ну, каждый кто с подобным встречался поймёт. Все мы знаем, что прижилось решение просто запретить программерам писать "foo->bar = 640".
И вот сейчас в исторической перспективе становится понятно, что возникшую проблему можно было решить миллионом разных способов. Во всяком там энтерпрайзе куда более злобные изменения прокатывают под названием "рефакторинга", а возникающая при этом боль сглаживается контролем версий, разными там автотестами, итд итп. Чего в восемьдесят восьмом году просто не было, или было в рудиментарном виде. И если бы что-то из этого успело чуть пораньше, то никакой "парадигмы" ООП могло бы и не быть, а просто была бы рекомендация уровня best practices делать всё на ADT. А если не догадались сразу — ну чтож, бывает, линтер со статическим анализатором в помощь.
Интересно, сколько там, внизу, еще живет поспешных, неуклюжих, ad hoc решений заматеревших со временем в "концепции"?
no subject
Date: 2019-10-22 01:33 am (UTC)Но сломать си или джаву несложно; вот советую Раст, там ошибки, попадающиеся в таких ситуациях, компилятор находит. А дереференсинг полуавтоматический, тем не менее.
no subject
Date: 2019-10-22 09:22 pm (UTC)no subject
Date: 2019-10-22 02:35 pm (UTC)no subject
Date: 2019-10-22 09:20 pm (UTC)Или ООП тут стоит особняком?
no subject
Date: 2019-10-22 09:24 pm (UTC)no subject
Date: 2019-10-22 09:25 pm (UTC)