Я бы даже уточнил, что это не просто риск, это факт, если проект не совсем уж тривиальный. После «водопада» результат получается почти всегда как в карикатуре про качели на дереве.
Это просто смена рода деятельности. Нельзя одновременно быть программистом и руководить серьезным бизнесом. Хотя может у некоторых людей с раздвоением личности и получится :-)
Другими словами, программист может стать руководителем, но в этом момент он либо перестанет быть программистом, либо станет фиговым руководителем.
Мне показалось, что статья скорее про Waterfall vs Agile, чем про американских и русских дизайнеров.
И в этом плане ничего нового: в случае водопада вы получаете фиксированный бюджет на 100 страничное ТЗ, который будет с достоверной вероятностью нарушен. С достоверной, потому что он будет превышен если вам хоть капельку не понравится то, что вам покажут в качестве первого результата работы. А во втором случае вы можете узнать только бюджет на итерацию, т.к. о бюджете и о ТЗ на весь проект agile-компания даже разговаривать не будет, потому что аппетит у заказчика меняется с каждой итерацией и хз сколько итераций займёт проект.
Для проекта, конечно, итеративная модель разработки лучше, если он не совсем уж тривиальный и при условии, что заказчик лучше понимает свою ЦА, чем исполнитель. Но почему-то многие заказчики с неохотой на неё соглашаются, им приятнее тешить себя иллюзией, что кто-то может точно оценить бюджет и сроки проекта в самом начале.
Блин, ну если кто-то считает, что в windows есть нормальная история команд, то пусть почитает хотя бы обзорную статью о возможностях нормальной истории команд, при том, что это только «верхушка айсберга».
Думаю, если Вы напишете подобную статью, как всё это сделать не в bash, а в cmd, получите кучу плюсов в карму :-)
Есть ещё четвёртый вариант — движок на базе популярного фреймворка. Такие легко кастомизировать и расширять, а плюсом ко второму варианту идёт то, что при тех же возможностях кастомизации уже готово не только ядро, но и наиболее популярные фичи в конкретной области, будь то e-commerce, новостной портал или соц.сеть. Для каждой области будет отдельный движок на одном фреймворке.
Ruby 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+
Круг — это не отдельная независимая сущность, а лишь частный случай возможного состояния эллипса.
Да, в условиях отсутствия контекста применения этих классов вполне можно сказать, что класс Circle излишен и убрать его совсем тоже решение. Причём при некоторых контекстах даже идеальное решение. С другой стороны может быть контекст, в котором окружность будет именно отдельной независимой сущностью без возможности стать эллипсом. Но мне что-то лень фантазировать на эту тему :-)
возврат объекта другого класса — тоже нетривиальная задача, если нужно соблюсти принцип гласящий, что код не должен знать о всех возможных реализациях интерфейса, но только сам интерфейс.
Обычно её решают как раз тривиально, в данном случае метод просто будет всегда возвращать Ellipse, а в более общем случае IFigure.
А абстрактный пример с окружностью и эллипсом сильно надуман и конкретная реализация зависит от контекста применения данных классов. В целом можно сказать, что вариантов реализации, не нарушающих SOLID, в данном примере вполне хватает.
Да, но при растягивании по одной оси круг перестаёт быть кругом, а значит методы stretch… должны либо нарушить правила наследования (установив более сильные предусловия и нарушая LSP), либо должны кидать исключения (что по сути и есть уменьшение интерфейса), либо должны возвращать объект другого типа.
Важное уточнение, только начиная с 4.0. А подобная задача мелькает на собеседованиях гораздо дольше, чем существует .NET 4.0
С Java и Perl соглашусь. Действительно языков оказалось больше, чем я полагал.
Ну а функциональные — это отдельная тема, тут изначально речь шла о PHP, в котором в stdlib этого нет, да и не в stdlib есть возможность работать со строками, содержащими большие числа, но не с целочисленным типом данных.
«Individuals and interactions over processes and tools» © agilemanifesto.org
А в начале статьи говорили, что это фуфло… :-)
Другими словами, программист может стать руководителем, но в этом момент он либо перестанет быть программистом, либо станет фиговым руководителем.
И в этом плане ничего нового: в случае водопада вы получаете фиксированный бюджет на 100 страничное ТЗ, который будет с достоверной вероятностью нарушен. С достоверной, потому что он будет превышен если вам хоть капельку не понравится то, что вам покажут в качестве первого результата работы. А во втором случае вы можете узнать только бюджет на итерацию, т.к. о бюджете и о ТЗ на весь проект agile-компания даже разговаривать не будет, потому что аппетит у заказчика меняется с каждой итерацией и хз сколько итераций займёт проект.
Для проекта, конечно, итеративная модель разработки лучше, если он не совсем уж тривиальный и при условии, что заказчик лучше понимает свою ЦА, чем исполнитель. Но почему-то многие заказчики с неохотой на неё соглашаются, им приятнее тешить себя иллюзией, что кто-то может точно оценить бюджет и сроки проекта в самом начале.
Думаю, если Вы напишете подобную статью, как всё это сделать не в bash, а в cmd, получите кучу плюсов в карму :-)
Ruby 1.8.6 уже сильно не актуален. Уже состоялся последний релиз Ruby 1.8.7, осталось 11 месяцев, в которые при необходимости будут выпускать security-патчи и на этом всё.
Так что если будете делать хостинг для Ruby, делайте поддержку только 1.9.3+
Да, в условиях отсутствия контекста применения этих классов вполне можно сказать, что класс Circle излишен и убрать его совсем тоже решение. Причём при некоторых контекстах даже идеальное решение. С другой стороны может быть контекст, в котором окружность будет именно отдельной независимой сущностью без возможности стать эллипсом. Но мне что-то лень фантазировать на эту тему :-)
Обычно её решают как раз тривиально, в данном случае метод просто будет всегда возвращать Ellipse, а в более общем случае IFigure.
А абстрактный пример с окружностью и эллипсом сильно надуман и конкретная реализация зависит от контекста применения данных классов. В целом можно сказать, что вариантов реализации, не нарушающих SOLID, в данном примере вполне хватает.
Важное уточнение, только начиная с 4.0. А подобная задача мелькает на собеседованиях гораздо дольше, чем существует .NET 4.0
С Java и Perl соглашусь. Действительно языков оказалось больше, чем я полагал.
Ну а функциональные — это отдельная тема, тут изначально речь шла о PHP, в котором в stdlib этого нет, да и не в stdlib есть возможность работать со строками, содержащими большие числа, но не с целочисленным типом данных.