tag:blogger.com,1999:blog-8278700074442979782.post2326709504955083600..comments2023-07-12T12:53:44.630+02:00Comments on "Поток сознания" о тестировании и программировании: Ссылка. Кому нужен архитектор?Alex W. Lulinhttp://www.blogger.com/profile/08400475846894229767noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8278700074442979782.post-46492833136250659202014-01-09T23:03:38.848+03:002014-01-09T23:03:38.848+03:00Смешно кстати. Я раз 10-15 перечитывал FAQ Тепляко...Смешно кстати. Я раз 10-15 перечитывал FAQ Теплякова про C++11. И Всё время им ВОСХИЩАЛСЯ!!!<br />Но при этом его блог я "только что заметил".. :-(Alex W. Lulinhttps://www.blogger.com/profile/08400475846894229767noreply@blogger.comtag:blogger.com,1999:blog-8278700074442979782.post-19731681800865086572014-01-07T23:07:49.675+03:002014-01-07T23:07:49.675+03:00Статья годная, о чём я отписался здесь https://plu...Статья годная, о чём я отписался здесь https://plus.google.com/100903871335644471614/posts/BCz2Q92ZkRx<br />Спасибо за ссылку.<br /><br />Но для меня, наиболее близким в ней было следующее:<br />«ПРИМЕЧАНИЕ <br />Дизайн – это постоянный поиск компромиссов. Если мы добавляем гибкость, то мы жертвуем чем-то другим – обычно стоимостью разработки и сопровождения. Аналогично тому, как нет особого смысла заниматься тюнингом производительности приложения на ранних стадиях, нет особого смысла закладывать чрезмерную гибкость каждого разрабатываемого компонента. Именно из-за своих накладных расходов на разработку и сопровождение, оптимизация производительности или гибкости должны производиться лишь тогда, когда мы четко знаем, что это действительно окупится! <br />Обычно именно простота (помните о разнице между simple и easy ) является наиболее оптимальным фундаментом для будущего улучшения эффективности или изменения функционала. <br /><br />Мое сдержанное отношение к аспект-ориентированному программированию заключается в том, что у нас уже есть приличное количество хороших техник для выделения аспектов в приложении, которые мы не используем. Я не думаю, что мы решим реальную проблему путем использования более продвинутых техник разделения ответственностей. Мы просто не знаем, какие аспекты нужно выделять и не знаем, когда вообще стоит их выделять, а когда нет. <br /><br />ПРИМЕЧАНИЕ <br />Аналогично тому, как Мартин Фаулер сдержано относится к AOP, я сдержано отношусь к IoC-контейнерам. Ведь в нашем арсенале есть огромное количество принципов борьбы со сложностью и обеспечения гибкости: неизменяемость и композиция помогает бороться со сложностью, а многие паттерны проектирования упрощают изменения определенных аспектов системы. Чрезмерное выделение интерфейсов (вначале выделим, а потом посмотрим, нужно ли это) делают систему гибкой и слабосвязной ценой увеличения сложности. <br />Не делайте систему гибкой на всякий случай, делайте ее гибкой там, где это вам действительно необходимо.»<br />-- у меня сдержанное отношение и к АОП и к IoC, хотя в той или иной степени/форме находят применение оба подхода. Хотя здесь уместнее говорить даже не о подходах, а о концепциях.NameRechttps://www.blogger.com/profile/00070033877714975718noreply@blogger.com