http://gaperton.livejournal.com/58526.html
"Приступая к задаче, вы осознаете, что есть некая общая проблема, для разработки которой совершенно необходимо разработать фреймворк. Например? Например, вы понимаете, что вам надо писать юнит-тесты, и на секунду предположим, что в вашем языке нет готового фреймворка для этого. Либо - они есть, но по какой-то объективной причине вам не подходят.
И вы решаете написать свой. Решение во всех смыслах разумное, и вы приступаете, начиная думать, думать над проблемой... И вы начинаете программирование с фреймворка. Концепции мелькают в голове, преобразуясь в код, вы начинаете смотреть на код фреймворка, оценивая его стройность, вам что-то нравится, что-то нет, и вы его правите, и тут вам в голову приходит еще одна замечательная идея...
Программисты любят это. Занимаясь фреймворком, они, подобно фундаментальным математикам, уходят в небеса абстракций, теряя контакт с внешней решаемой проблемой. Это психологически очень комфортно. Не приходится иметь дело с практикой, которая способна внести в теорию свои неожиданные и неприятные коррективы. Вернее, этот момент оттягивается. И это приятно.
Подход push - когда разработка архитектуры опережает непосредственный контакт с проблемой, оттягивая его.
Это явление существует объективно. Просто потому, что нам приятно этим заниматься. В особенности, когда проблема, которую мы решаем, непонятна. Некомфортно работать с такими проблемами. Проблема написания фреймворка - кажется понятной. И потому, ей комфортно заниматься.
Что интересно, программист, который довел данный подход до маразма, избегая контакта с непонятной проблемой, никогда не признается, что его заклинило в ватерфоле. И формально - он будет прав. Он же код пишет :). Однако, кто сказал, что при проектировании люди не пишут код? :) Почти все пишут, и некоторые по какой-то причине стесняются этого."
"А уж если вся группа придерживается стратегии pull, то сушите весла. Они дружно и слаженно колбасят тонны говнокода, впечатляя одних, и вселяя ужас в сердца других. Они могут удивительно долго это делать, прежде чем цена правок возрастет настолько, что любая правка будет обходится неимоверно дорого, и менеджмент решит нанять дохера людей и внедрить "процессы"."
"Думаю, теперь вы легко узнаете в описанных утрированно-полярных типажах "программирование сверху вниз" и "программирование снизу вверх". Или же - "вотрефол" и "agile", тут уж все зависит от вида разводимых тараканов.
Бывают ли такими реальные люди? Я вам отвечу - да, и я встречал людей обоих видов. Это не редкость, их на самом деле очень много. Более того, многие из нас временами переживали оба описанных позыва. И это не есть сознательный метод - это нечто сидящее в пучинах психики.
Опознать их очень просто. Человек, придерживающийся любой из описанных крайностей, неспособен видеть градаций межу ними. Он двоичен, как единичка или нолик. Все просто - если вы не разделяете его радикальных взглядов - то, сталбыть, автоматически придерживаетесь противоположных. Это может быть смешно, может быть грустно, но такова жизнь.
Если же человек полагается не на крепкую веру, а на логику, и если он психически здоров - то он может находится в точке равновесия, будучи равно заинтересованным в обоих исходах дела, и - поэтому может позволить себе думать, а это уже не мало. И начинает понимать много чего интересного. Я объясню, и станет понятно, почему я назвал это pull и push.
С одной стороны понятно, что удачный фреймворк позволит сильно снизить последующие затраты на разработку, и что наличие такого фреймворка критично при масштабировании команды.
С другой стороны, ясно, что избегая контакта с изначальной проблемой (для решения которой и примененяется фреймворк) - невозможно понять, хорош он, или плох.
Как же правильно делать этот фреймворк? И, главное, как писать приложение - ведь разработка фреймворка не может являться целью, так как у него отсутствует ценность для пользователя. Я скажу как. В разработке разумно применять вытягивающий принцип (pull), в сочетании с предварительным проектированием (push). И объясню, что означает эта фраза. После чего, рассмотрим это на интереснейшем примере, которого все избегают - как работает архитектор в случае живого продукта с длинной историей и тоннами легаси кода."
"Приступая к задаче, вы осознаете, что есть некая общая проблема, для разработки которой совершенно необходимо разработать фреймворк. Например? Например, вы понимаете, что вам надо писать юнит-тесты, и на секунду предположим, что в вашем языке нет готового фреймворка для этого. Либо - они есть, но по какой-то объективной причине вам не подходят.
И вы решаете написать свой. Решение во всех смыслах разумное, и вы приступаете, начиная думать, думать над проблемой... И вы начинаете программирование с фреймворка. Концепции мелькают в голове, преобразуясь в код, вы начинаете смотреть на код фреймворка, оценивая его стройность, вам что-то нравится, что-то нет, и вы его правите, и тут вам в голову приходит еще одна замечательная идея...
Программисты любят это. Занимаясь фреймворком, они, подобно фундаментальным математикам, уходят в небеса абстракций, теряя контакт с внешней решаемой проблемой. Это психологически очень комфортно. Не приходится иметь дело с практикой, которая способна внести в теорию свои неожиданные и неприятные коррективы. Вернее, этот момент оттягивается. И это приятно.
Подход push - когда разработка архитектуры опережает непосредственный контакт с проблемой, оттягивая его.
Это явление существует объективно. Просто потому, что нам приятно этим заниматься. В особенности, когда проблема, которую мы решаем, непонятна. Некомфортно работать с такими проблемами. Проблема написания фреймворка - кажется понятной. И потому, ей комфортно заниматься.
Что интересно, программист, который довел данный подход до маразма, избегая контакта с непонятной проблемой, никогда не признается, что его заклинило в ватерфоле. И формально - он будет прав. Он же код пишет :). Однако, кто сказал, что при проектировании люди не пишут код? :) Почти все пишут, и некоторые по какой-то причине стесняются этого."
"А уж если вся группа придерживается стратегии pull, то сушите весла. Они дружно и слаженно колбасят тонны говнокода, впечатляя одних, и вселяя ужас в сердца других. Они могут удивительно долго это делать, прежде чем цена правок возрастет настолько, что любая правка будет обходится неимоверно дорого, и менеджмент решит нанять дохера людей и внедрить "процессы"."
"Думаю, теперь вы легко узнаете в описанных утрированно-полярных типажах "программирование сверху вниз" и "программирование снизу вверх". Или же - "вотрефол" и "agile", тут уж все зависит от вида разводимых тараканов.
Бывают ли такими реальные люди? Я вам отвечу - да, и я встречал людей обоих видов. Это не редкость, их на самом деле очень много. Более того, многие из нас временами переживали оба описанных позыва. И это не есть сознательный метод - это нечто сидящее в пучинах психики.
Опознать их очень просто. Человек, придерживающийся любой из описанных крайностей, неспособен видеть градаций межу ними. Он двоичен, как единичка или нолик. Все просто - если вы не разделяете его радикальных взглядов - то, сталбыть, автоматически придерживаетесь противоположных. Это может быть смешно, может быть грустно, но такова жизнь.
Если же человек полагается не на крепкую веру, а на логику, и если он психически здоров - то он может находится в точке равновесия, будучи равно заинтересованным в обоих исходах дела, и - поэтому может позволить себе думать, а это уже не мало. И начинает понимать много чего интересного. Я объясню, и станет понятно, почему я назвал это pull и push.
С одной стороны понятно, что удачный фреймворк позволит сильно снизить последующие затраты на разработку, и что наличие такого фреймворка критично при масштабировании команды.
С другой стороны, ясно, что избегая контакта с изначальной проблемой (для решения которой и примененяется фреймворк) - невозможно понять, хорош он, или плох.
Как же правильно делать этот фреймворк? И, главное, как писать приложение - ведь разработка фреймворка не может являться целью, так как у него отсутствует ценность для пользователя. Я скажу как. В разработке разумно применять вытягивающий принцип (pull), в сочетании с предварительным проектированием (push). И объясню, что означает эта фраза. После чего, рассмотрим это на интереснейшем примере, которого все избегают - как работает архитектор в случае живого продукта с длинной историей и тоннами легаси кода."
Комментариев нет:
Отправить комментарий