Зачем? Вы же знаете, где работате или где работали?
>Оки, конкретные ответы на конкретные вопросы. ПОтому что такие к моей безмерной радости появились.
А оно вам надо? ;)
>>Недавно был модным, насколько я помню, extreme programming. А сколько возились с RUP?
>И то и другое успешно используется в большом количестве проектов. XP не БЫЛ модным, он есть реально работающий процесс. Если вы его не пробовали или он вам не понравился - ваше дело. Мне лично он принес и приносит конкретные результаты. А конкретный результат - это довольные клиенты.
Клиенты разные бывают. Некоторые получив в предыдущих заказах неудовлетвоительный результат, бывают очень довольны, когда им хоть что-то сделают работающее.
Я, например, всегда пытаюсь поставить себя на место заказчика и понять, что бы меня удволетворило, а что нет. А вы?
>>>Да? Допустим, спроектировали базу. Некотрые умники ее нормализовали по самое немогу. Потом подумали и решили, что нет расширяемости неких объектов-элементов (ну, не предусмотрели). И пришли к выводу, что надо ломать. А уже какой-нибудь middle сделан. Ай-ай-ай. И времени нет. И заказчик недоволен. Я б на месте заказчика знаете что сделал? ;)
>Для начала. Танцевать надо не от базы,
а от домейна.
Ой, не ругайтесь так. Что у вас есть такое - "домейн"?
>Тогда не будет проблем с изменением базы, если изменяется домейн. Мидл тайер не должен быть завязан на схему базы, а только на домейн.
Что вы говоирте? Вы еще скажите, что у вас система портируется на любые DBMS. Ну, да, если табличек максимум пять. ;)
>Ну а как маппить домейн в базу данных надеюсь вы знаете.
Да-да. Похоже, вы говорите о EJB? Я вам по секрету скажу. Только тссссссссссс. Все красиво на простейших вариантах. Чуть сложнее - и, ой, какая головная боль людей настигает.
>Для этого существует как минимум несколько жизнеспособных техник - O/RM и Code Generation. Если вы их не используете, мне жаль ваших программистов, которые пишут DAO руками. Поверьте, искренне жаль.
Вы в своих системах миллионы объектов в стресс-тестах использовали? И как? ;)
>>Чистый HTML? Или, например, JSP? ;)
>JSP не лучший способ делать UI.
Зато "крутой". Или уже нет? Значит, я отстал от жизни. А как же Struts и иже сним?
>Ну если и JSP, то там не должно быть логики. Если ее нет, то изменяется все элементарно.
Элементрано? Переделка генерации HTML - это элементарно?
>Если она там есть, мне опять же жаль ваших программистов.
;) Не надо в крайности впадать и напихивать туда функциональность. И вы думаете, что я так делаю? ;)
>>>На каждом по 4 квартины. Ну, пару двухкомнатных, остальные трешки. Высоты и ширины попожжа нарисуем, коммуникации тоже. Ну, примерно 40 человек нам хватит. Для начала детально проработаем первую квартиру, остальное потом достроим. Все, можно начинать работать."
>>Не смешите мои тапочки. Если вы так проектируете и делаете систему, то ... No comments.
>Я кажется догадываюсь почему вы так упорно сопротивляетесь. Вы не верите что изменения требований в процессе создания софта - это норма.
Это обычное явление.
>Но это действительно норма. Изменения требований это объективный процесс, которые неизбежен во многих проектах (не во всех, подчеркиваю, но во многих).
Есть контаркт, в котором хотя бы оговорены базовые вещи. Если вы не способны грамотно составить контракт, то и получаете кучу головной боли, когда заказчик на ходу меняет основные требования, а не только бантики-рюшечки.
>И очень глупо верить, что ваш план, который вы составили полгода назад, будет так же верен сейчас. Это не так. Это не так даже если требования не меняются. Вам ли это не знать.
Для этого и существует подговтовка (можно это и так назвать) к заключению контаркта, проектированию системы и пр, и пр. Но когда у людей не пропадает юношеский задор (даже с возрастом) и им море по колено (мы, мол, все можем), то они сразу с головой в омут ныряют. А я ленив. Я не хочу получать лишнюю головную боль. Мне мой имидж серьезного человека дорого - я не хочу позориться в последствии. И я хочу не просто получить деньги, а еще и моральное удовлетворение, что сделано достаточно хорошо и мне не стыдно за проделанную работу.
>Что вы говоирте? Вы еще скажите, что у вас система портируется на любые DBMS. Ну, да, если табличек максимум пять. ;)
Не на любое кол-во, но на штук 5-6 точно. На те которые ORM Тул поддерживает, Hibernate, Слыхали о таком? Видимо нет, в контексте про EJB
>Да-да. Похоже, вы говорите о EJB? Я вам по секрету скажу. Только тссссссссссс. Все красиво на простейших вариантах. Чуть сложнее - и, ой, какая головная боль людей настигает.
EJB сами юзайте, если вам нужен геморрой. В энтерпайс приложениях его уже мало кто использует, разве что 3.0 более-менее красивым стало. Я имел ввиду тулы типа Hibernate.
>Элементрано? Переделка генерации HTML - это элементарно?
Да, это элементарно. Если у вас это не так - это ваши проблемы.
> Вы в своих системах миллионы объектов в стресс-тестах использовали? И как? ;)
Вы намекаете, что нельзя добиться нормального перформанса если не писать DAO руками? Можно добиться.
У меня создается впечатление, что вы не в курсе как сейчас решаются типичные проблемы создания масштабируемых приложений. Об ОР маппинге не знаете, предлагете EJB, HTML вам сложно генерить, котя это должны быть JSF или хотя бы темплейты (если мы о яве говорим) и тогда это просто. В качестве процесса кроме вотерфола вам ничего ен подходит и даже слушать об этом не хотите... Уверен что к юнит тестам у вас тоже сугубо отрицательное отношение. И представляю что вы скажете от TDD ("Как? Писать тесты до кода? Это невозможно!") Может вы перестали учится или еще что, я не знаю. Но если это так, ваша компания никогда не сделает ничего выдающегося. И ваш имидж серьезного человека не спасет отца русской демократии.
Да, паттерны из архитектуры пошли. Это правда. Но мы тут спорим о процессе. Я не говорю, что процесс постройки дома и создания софта вообще НИЧЕМ не похожи. Похожи. Но разница присутствует, и она предполагает другой подход, другой процесс.
Вот он, корень наших разногласий. Вы говорите, что процесс общепринятый, но НЕПРАВИЛЬНЫЙ. ЧТо требования НЕ ДОЛЖНЫ менятся (интересно, скажите это клиенту, что вот типа контракт, и если захотит чего поменять, фиг вам, а не поменять. А если не фиг, то вы с вас возьмем мноооого денег, потому как все переделывать придется). Я же говорю, что изменение требований это ЕСТЕСТВЕННЫЙ процесс при разработке софта, и разработчики должны АДАПТИРОВАТЬСЯ к нему при помощи различных практик, а не убеждать клиента, что это порочно и вообще ничего не сделать если не зафиксировать требования.
Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
>>Что вы говоирте? Вы еще скажите, что у вас система портируется на любые DBMS. Ну, да, если табличек максимум пять. ;)
>Не на любое кол-во, но на штук 5-6 точно. На те которые ORM Тул поддерживает, Hibernate, Слыхали о таком? Видимо нет, в контексте про EJB
А вы пробовали портировать? ;) И что-нибудь более-менее сложное делать?
>>Да-да. Похоже, вы говорите о EJB? Я вам по секрету скажу. Только тссссссссссс. Все красиво на простейших вариантах. Чуть сложнее - и, ой, какая головная боль людей настигает.
>EJB сами юзайте, если вам нужен геморрой.
Как это, как это? Все ж кричат, что это rulez forever.
>В энтерпайс приложениях его уже мало кто использует, разве что 3.0 более-менее красивым стало. Я имел ввиду тулы типа Hibernate.
Еще недавно все было наооборот. ;)
>>Элементрано? Переделка генерации HTML - это элементарно?
>Да, это элементарно. Если у вас это не так - это ваши проблемы.
Ну, да. Шрифт поменять - несложно. ;)
>> Вы в своих системах миллионы объектов в стресс-тестах использовали? И как? ;)
>Вы намекаете, что нельзя добиться нормального перформанса если не писать DAO руками? Можно добиться.
И заработать очень большую головную боль. Даже оптимизаторы SQL в DBMS накалываются. Хотя там люди уже десятилетиями все вылизывают.
>У меня создается впечатление, что вы не в курсе как сейчас решаются типичные проблемы создания масштабируемых приложений. Об ОР маппинге не знаете, предлагете EJB, HTML вам сложно генерить, котя это должны быть JSF или хотя бы темплейты (если мы о яве говорим) и тогда это просто. В качестве процесса кроме вотерфола вам ничего ен подходит и даже слушать об этом не хотите...
Ваша начитанность поражает. Серьезно. ;) Только все ли это вы используете? ;)
>Уверен что к юнит тестам у вас тоже сугубо отрицательное отношение.
Нормальное.
>И представляю что вы скажете от TDD ("Как? Писать тесты до кода? Это невозможно!")
Тесты или протипы? ;)
>Может вы перестали учится или еще что, я не знаю.
Я просто скептически отношусь к моде. И всегда пытаюсь понять истинный смысл и возможности.
>Но если это так, ваша компания никогда не сделает ничего выдающегося.
Что значит - выдающееся? Вот у нас в стране собрались OS делать (или уже делают) для конкуренции с MS Windows и совместимую (насколько я понял) с оной. Выдающееся? Безусловно. Только одно "но". Надеюсь, вы понимаете?
>И ваш имидж серьезного человека не спасет отца русской демократии.
На этот пост я и не претендую. А вот вы, похоже, собираетесь спасти всю мировую демократию? Ну, что ж. Удачи.
---------------------------
>FF
8 февраля 2006 года, 12:55
>>Это общепринятый процесс. В силу многих причин.
>Вот он, корень наших разногласий. Вы говорите, что процесс общепринятый, но НЕПРАВИЛЬНЫЙ. ЧТо требования НЕ ДОЛЖНЫ менятся (интересно, скажите это клиенту, что вот типа контракт, и если захотит чего поменять, фиг вам, а не поменять. А если не фиг, то вы с вас возьмем мноооого денег, потому как все переделывать придется).
Простите, но это именно так. Иначе вы - плохой бизнесмен, если заключив контракт на поставку и производство, допустим, тысячи холодильников, ваш заказчик через какое-то время потребует не холодильники, а телевизоры, а вы молча согласитесь и будете срочно из холодильника делать телевизор.
Я не говорю, например, об изменении цвета, установки других компрессоров, каког-нибудь no frost. Это возможно. Но не кардинально.
>Я же говорю, что изменение требований это ЕСТЕСТВЕННЫЙ процесс при разработке софта, и разработчики должны АДАПТИРОВАТЬСЯ к нему при помощи различных практик, а не убеждать клиента, что это порочно и вообще ничего не сделать если не зафиксировать требования.
Это называетя - бесхребетность. У заказчика может быть очень буйная фантазия. И что, каждый раз все переделывать? Конечно, можно попытаться предусмотреть, что взбредет в голову заказчику. Но не все.
>Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
Точно. И работа по ночам. И, как следствие, ухудшение того же кода и пр., и пр. Потому что люди - не железные. Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и говорить: "чего еще изволите? мы за теже деньги можешь еще много чего переделать и добавить."
Наверное, я чего-то не понимаю. Ну, FF, вам и карты в руки.
Объясните это компаниями типа майкрософт, которые (да, даже они!) вводят у себя итеративную разработку на основе SCRUM. Объясните это тысячам других компаний, которые внедрили agile development. Они это сделали не просто так, а потому что увидели реальную выгоду. Никто не внердяет что -либо только потому что это модно. Цель у всех одна - доля рынка, кеш флоу и т.п.
>>>Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
>Точно. И работа по ночам. И, как следствие, ухудшение того же кода и пр., и пр. Потому что люди - не железные. Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и говорить: "чего еще изволите? мы за теже деньги можешь еще много чего переделать и добавить."
>Наверное, я чего-то не понимаю. Ну, FF, вам и карты в руки.
Да, вы действительно чего-то не понимаете. Вы не пробовали эти практики, а я пробовал. Мы говорим на разных языках. Возможно вы не знаете, что одно из правил XP - 40 часовая рабочая неделя. Как это согласуется с вашим утверждением "И работа по ночам"? Рефакторинг направлен на улучшение существующего кода, и это опять же не согласуется с вашим утверждением "как следствие, ухудшение того же кода"
>Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и
говорить: "чего еще изволите?
И опять же это не так. Главная задача разработчика - СОВМЕСТНО С ЗАКАЗЧИКОМ РЕШИТЬ ЕГО ПРОБЛЕМЫ. Ключевое слово "СОВМЕСТНО". Если вы утвердили требования, и не показываете клиенту систему на протяжении полугода, а потом бац - во, мы все сделали. Платите. Заплатят. Вы будете довольны. А заказчик возможно не будет доволен, потому что в работе обнаружится множество мелких и средних недочетов, что-то забыли учесть, что-то сделали не так как ОЖИДАЛОСЬ. Именно ожидалось, потому что это, как ни печально, самое важное. Сделать так, чтобы ОЖИДАНИЯ заказчика совпали с тем что вы ему отдаете в конце проекта. Agilde DEvelopment на сегодняшний день помогает достичь именно этого.
>Объясните это компаниями типа майкрософт, которые (да, даже они!) вводят у себя итеративную разработку на основе SCRUM. Объясните это тысячам других компаний, которые внедрили agile development. Они это сделали не просто так, а потому что увидели реальную выгоду. Никто не внердяет что -либо только потому что это модно. Цель у всех одна - доля рынка, кеш флоу и т.п.
И всегда сказать кастомеру, что, мол, мы используем то, то и то. И кастомер проникается этой крутостью. Вот все в ISO бросились. Понятно, что кастомер, начитавшийся вской всячины, сделает выбор в пользу того, кто имеет ISO. ;) А вот как там на самом деле дела обстоят - это уже второй вопрос. Это как бренд.
>>>Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
>>Точно. И работа по ночам. И, как следствие, ухудшение того же кода и пр., и пр. Потому что люди - не железные. Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и говорить: "чего еще изволите? мы за теже деньги можешь еще много чего переделать и добавить."
>>Наверное, я чего-то не понимаю. Ну, FF, вам и карты в руки.
>Да, вы действительно чего-то не понимаете.
Но все делаю довольно успешно. ;)
>Вы не пробовали эти практики, а я пробовал.
Пробовал кое-что. Достаточно тот же RUP привести как пример. очень хитро все - как хочешь так и делай по большому счету. И смысл тогда?
>Мы говорим на разных языках. Возможно вы не знаете, что одно из правил XP - 40 часовая рабочая неделя. Как это согласуется с вашим утверждением "И работа по ночам"?
А это и есть обычное явление. Как ни прикрывайся словами.
>Рефакторинг направлен на улучшение существующего кода, и это опять же не согласуется с вашим утверждением "как следствие, ухудшение того же кода"
Есть еще другой принцип: лучшее - враг хорошего. Сколько потом после рефакторинга необходимо исправлять? Конечно, идеальный случай, когда все очень просто сделано, как прямая линия. Но в жизни все несколько иначе.
>>Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и
говорить: "чего еще изволите?
>И опять же это не так. Главная задача разработчика - СОВМЕСТНО С ЗАКАЗЧИКОМ РЕШИТЬ ЕГО ПРОБЛЕМЫ.
Это идеальная ситуация. Но о своих проблемах большинство заказчиков очень мало знает. А тем более о возможных проблемах.
>Ключевое слово "СОВМЕСТНО". Если вы утвердили требования, и не показываете клиенту систему на протяжении полугода, а потом бац - во, мы все сделали.
Если достаточно серьезный проект, то ранее, чем через месяца три даже показывать ничего нельзя. Потому что это этап ПОДГОТОВИТЕЛЬНЫЙ, это и исследование возможных используемых технологий, это и прототипирование. Потому что действительно заранее нельзя знать, с какими проблемами можно столкнуться. А если вы в угоду заказчика чего-то там наклепали, чтобы отчитаться, то это - ваши проблемы. В конечном итоге и получится продукт, сделанный "на коленке".
Видел я это много раз. И когда сам что-то делаю, то сразу заказчика предупреждаю: "Вот столько-то времени вы ничего не увидите". Если заказчик разумный - он поймет. Если нет, то проводится ликбез. Если и это не помогает, а деньги заработать хочется, то делается простейшая вещь. Работа идет как надо, а заказчику время от времени показывается что-то, делаемое параллельно и фейковое. С таким заказчиком проходит такой финт хорошо Увы, это приводит к лишним расходам.
>Платите. Заплатят. Вы будете довольны. А заказчик возможно не будет доволен, потому что в работе обнаружится множество мелких и средних недочетов, что-то забыли учесть, что-то сделали не так как ОЖИДАЛОСЬ. Именно ожидалось, потому что это, как ни печально, самое важное. Сделать так, чтобы ОЖИДАНИЯ заказчика совпали с тем что вы ему отдаете в конце проекта.
Ожидания? Так вы ж сами говорили, что эти ожидания в процессе сильно меняются. ;) "Пойди туда, не знаю куда, принеси то, не знаю что".
>Agilde DEvelopment на сегодняшний день помогает достичь именно этого.
Возможно. А психологию заказчика-исполнителя он учитывает? А несовершенство технологий и возможные проблемы он учитывает. ПО-НАСТОЯЩЕМУ. А не процент риска?
А ничего если я скажу, что в этой ветке спор идет между работодателями и работникам?
Со стороны Полковника объяснения как сделать так, чтоб получить малорискованный результат и доказательства того, что это возможно (работодатель). Со стороны оппонентов мысль, что мол собственное понимание проблемы превыше всего(работники).
Разница в том что работник может спорить и экспериментировать, признавать догмы или отвергать, тратить время на собственные ошибки ( не признавая их или оправдывая сложившимися обстоятельствами). Ни один работник не будет нести финансовой ответственности за совершенные действия. По крайней мере за программинг или взаимоотношения с клиентом. Каждый работодатель не может себе позволить проводить эксперименты. Он будет следовать только проверенными методами которые точно гарантируют достижение цели, пусть даже на это уйдет немного больше времени чем при атаке “в лоб”., но это должен быть предсказуемый результат.
Отсюда и разница во взглядах. , когда с одной стороны слышится “Все так работают и нам не стоит напрягаться против этого”, с другой стороны заявления “Так работают только те кто не умеет четко работать”. Лично я на стороне Полковника. Мне нужен сто процентный результат, а его гарантией является четкая методика, проверенная технология, и соответствующий спрос с персонала. С другой стороны я прекрасно понимаю что персонал измеряет долю своего участия не прибылью, а степенью усталости или говоря по другому, тем сколько он потратил собственного времени на проект. Соответственно во время на проект он может потратить время на переработку тех элементов которые были неправильно поняты/согласованы с заказчиком. Ему по барабану- за это заплатит работодатель. А вот работодатель, предпочтет чтоб его персонал затратил большее время на выяснение подробностей по каждой фичке проекта, но затем персонал сможет ее сделать так, что она будет сдана с первого подхода без внесения изменений/доработок. И для этого есть четко отработанная методика. Со стороны персонала, следование данным методикам – пустая трата времени. Причина банальная – вероятность того, что неправильное понимание потребностей клиента, ВЕСЬМА МАЛА. Так и есть. Но эта “ВЕСЬМА МАЛА” при определенных обстоятельствах может поставить предприятие на колени или вообще его прибить, а это выходит за рамки понимания любого работника который не несет коммерческих рисков. Ему по барабану “Я работал - заплати”.
Извратоучитель, прекрасно сказано. Поддерживаю. Только одно уточнение: работник так же должен быть заинтересован в конечном результате. Если нет, то это на мой взгляд уже ошибка работодателя. Хотя бывают исключения, когда попадаются работник, которым все равно. Это уже психологический фактор и его так же надо учитывать.
Вы не правы. Я фаундер. Так что говорить что я представлю сторону работника в корне неверно. Я несу полную финансовую ответственность за все свои действия. Мы успешно проводим эксперименты (ессно, взвешенные, а не "давайте заюзаем этих пять новых тулов и все будет в шоколаде"). Процессы и подходы должны развиваться и улучшаться.
Я вас не совсем понимаю. Никто не утверждает, что надо ничего у заказчика не спрашивать, что-то там на коленке сделать и потом переделыват. Весь смысл в восприятии процесса создания софта. Он отличается от обычных инженерных дисциплин, это не строительство дома или моста. Это объективно итеративный процесс с часто изменяющимися требованиями. И для управления таким процессом нужные другие методы, отличные от методов и практик обычных инженерных дисциплин.
Работодатель действительно хочет минимизировать расходы и сократить риски. И ИМЕННО ЭТО позволяют сделать новые подходы. А такие вещи как BDUF, Waterfall и первый релиз через полгода риски увеличивают, и увеличивают серьезно.
>Что вы, Полковник, я софт прилюдно не ваяю, разве что в командировке, бывает, то-другое правлю; ковыряю ли я при этом в носу - не помню.
Поздравляю. ;)
>>У заказчика может быть очень буйная фантазия
>О, всегда, как только заказчик заюзает пробную версию!
Вот поэтому надо четко договариваться. Чтобы умерить пыл и фантазию заказчика.
>>Сделать так, чтобы ОЖИДАНИЯ заказчика совпали с тем что вы ему отдаете...
>Ну это типа, как выпить всю водку (заработать все бабки, удовлетворить всех женщин и т.д.).
Снова надо договориться обо всей водке, всех бабках, всех женщинах. Хотя бы максимально попытаться. ;)
>>О своих проблемах большинство заказчиков очень мало знает...
>Только не говорите об этом заказчику!
Я и не говорю. ;)
---------------------------------------->FF
9 февраля 2006 года, 11:18
>2Извратоучитель
>Вы не правы. Я фаундер. Так что говорить что я представлю сторону работника в корне неверно. Я несу полную финансовую ответственность за все свои действия. Мы успешно проводим эксперименты (ессно, взвешенные, а не "давайте заюзаем этих пять новых тулов и все будет в шоколаде").
Увы, но так очень часто бывает. Не у вас, возможно.
>Процессы и подходы должны развиваться и улучшаться.
Кто бы спорил?
>Я вас не совсем понимаю. Никто не утверждает, что надо ничего у заказчика не спрашивать, что-то там на коленке сделать и потом переделыват.
Вы несколько ранее говорили о том, что все определяется в процессе разработки. А это уже подразумевает постоянные переделки.
>Весь смысл в восприятии процесса создания софта. Он отличается от обычных инженерных дисциплин, это не строительство дома или моста.
Конечно отличается. Там стройматериалы, а здесь нечто возвышенное и эфемерное? ;)
>Это объективно итеративный процесс с часто изменяющимися требованиями.
Плохо договариваетесь, если требования часто изменяются.
>И для управления таким процессом нужные другие методы, отличные от методов и практик обычных инженерных дисциплин.
Естественно. Там люди точно знают, что будут строить мост. А здесь - сегодня "мост", а завтра "туннель"?
FF > Он отличается от обычных инженерных дисциплин, это не строительство дома или моста. Это объективно итеративный процесс с часто изменяющимися требованиями. И для управления таким процессом нужные другие методы, отличные от методов и практик обычных инженерных дисциплин.
ЧЕМ ОТЛИЧАЕТСЯ?
Решили строить мост - понтонный -начали, потом уточнили - на сваях - вбили, проворовались, отложили, приступили - решили подвесной... закончили туннелем, которым никто не пользуются ибо паром оказался дешевле или река к тому времени изменила русло.
Однажды в небольшом городе Италии перед жителями стояла трудная задача - каждый раз, когда они хотели возвести мост через реку, он обрушивался. При этом он был еще не построен. Так после очередной неудачи все вспомнили историю с юной девушкой, которой ели-ели удалось спастись от рук сатаны. Жители города решили применить меры, и договориться с дьяволом, что он заберет первого человека, который перейдет через мост. Люди снова стали строить мост, и это им удалось сделать. После успешной постройки моста жители города решили пропустить туда не человека, а собаку. Таким образом, они хотели обмануть дьявола. Им это получилось. И с тех пор мост стоит до сегодняшнего времени.
Гм - Вы видели когда-либо чтоб так мосты строили??? ну ну
Ну, ну.
"Ещё каких-нибудь 150 лет тому назад, когда поезд въезжал на мост, машинист снижал скорость и начинал подавать непрерывные тревожные гудки, а пассажиры обращали взоры ко Всевышнему, шепча про себя молитвы: "Пронеси, о господи!".
Уж очень часто в те годы мосты не выдерживали нагрузки и вместе с поездами обрушивались в воду. Движение по железным дорогам было не безопасным, обвалы мостов в Европе и Америке были довольно частыми. В Америке, в Филадельфии, рухнул в воду мост в 1811 году, его восстановили, но через пять лет он снова развалился. По данным статистики, в Соединенных Штатах Америки даже в более поздние годы - с 1878 по 1887 гг. - произошло более 250 аварий мостов. Не лучше обстояло дело и в других странах.
В чём дело? Почему одни мосты стояли долгие годы, а другие обрушивались? Ответить на этот вопрос нетрудно. В то время мостостроение, как наука, вовсе не существовала. Инженеры при сооружении мостов руководствовались только своим опытом, своей интуицией, а не точным расчетом.
Разумеется, одной интуиции для инженера недостаточно, тем более, когда речь идет о большом сооружении. Ведь на мост оказывают влияние самые различные силы и все их надо учесть! Как подбирать фермы моста? Как будет вести себя тот или иной материал, из которого решили строить мост?
На эти и многие другие вопросы инженерная наука того времени не могла дать точный ответ. Даже фермы мостов никто не умел рассчитывать. Над вопросами мостостроения работали виднейшие инженеры и механики мира. Но только молодой русский инженер Дмитрий Иванович Журавский впервые создал теорию мостостроения, вооружил инженеров строгой системой и методами расчетов."
"После окончания с отличием института в 1840 году молодого инженера направили на строительство Петербургско-Московской железной дороги. Российским инженерам предстояло преодолеть очень большие трудности при постройке железной дороги, которые не встречались в других странах. Это должна была быть по тем временам самой большой железной дорогой в мире длиной в 656 км. Ее трасса пролегала по непроходимым и трудным местам. Достаточно сказать, что на этой дороге предстояло построить 184 моста и 68 других искусственных сооружений. Нужно было произвести 97 миллионов кубометров одних только земляных работ. И российские инженеры отлично справились со своей задачей.
Молодой инженер Дмитрий Журавский сначала участвовал в изыскательских работах. Когда он отлично проявил себя на них, ему поручили проектировать мосты. Строительство каждого моста для того времени было настоящим подвигом, тем более если мост был больших размеров и предназначался для железной дороги. ЖуравскиЙ горячо взялся за это дело. Но уже в первые дни возникли труднейшие проблемы, буквально на каждом шагу приходилось самостоятельно разрешать самые сложные задачи.
Журавскому всё пришлось делать впервые. Естественно, вопрос о материалах не возникал - камень и дерево - чугунные и стальные мосты появились значительно позже. И молодой инженер вначале пошёл по проторенной тропе, решив строить деревянные мосты раскосной системы американского инженера Гау - системы запатентованной и, как все авторитеты утверждали, самой совершенной. Но беда в том, что даже сам Гау не знал, как рассчитывать свои фермы и поэтому тяжи и раскосы он делал одних и тех же размеров.
Дмитрий Иванович очень скоро понял, что вслепую строить мосты нельзя, следует учитывать усилия в фермах во время движения поезда, давление на мост сильного ветра и т. д. Для этой цели он построил макет будущего моста из набора одинаковых ферм в полном соответствии с патентом Гау."
"В дальнейшем Дмитрий Иванович, как правило, все свои расчеты проверял экспериментально. Он справедливо считал, что "вычисления без контроля опыта часто уходят в область фантазии".
...
Дмитрий Иванович Журавский долгое время возглавлял железнодорожное дело в России, сперва как вице-президент Главного общества российских железных дорог, а с 1877 года - как директор департамента железных дорог. При нём было проложено 4800 км новых железнодорожных путей в различных уголках России. Несмотря на большую занятость на административной работе, Журавский не покидал живой инженерной деятельности. В 1869 году, когда было прервано сообщение между Москвой и Петербургом (сгорел знаменитый мост через реку Мста), Журавский предложил весьма интересный и смелый проект его восстановления. Друзья отговаривали Дмитрия Ивановича от этого рискованного проекта, который мог в случае неудачи подорвать авторитет вице-президента. Но Дмитрий Иванович сам взялся руководить работами и в тридцатиградусный мороз в очень короткое время восстановил мост."
"Страсти вокруг моста через Иртыш около Ханты-Мансийска улеглись, каким быть мосту, решено. Околомостовые дебаты, продолжавшиеся год, вертелись вокруг дилеммы: строить висячий мост или балочный? Валентин Солохин, генеральный директор АО "Мостострой-11", построивший мост через Обь, - нынешнюю гордость России, сражался за висячий: прецедент для страны, да и красота небывалая. Проектировщики настаивали на балочном - дешевле, мол. Дешевле, никто не спорит. Но глаз не радует и сердце не греет - обычный частокол. Причем семь опор придется забивать в реку, губить Иртыш.
После рассмотрения материалов тендера на проектирование моста через Иртыш на совещании у губернатора округа принято решение строить мост арочный.
Весь мир давно строит арочные мосты. Великаны арочники "живут" в Австралии (построенный в 1938-м в Сиднее арочный мост пролетом 507 метров) и в Америке (пролетом 510 метров).
С арочными мостами отношения у России непростые.
...
Тендер выиграл проектный институт "Трансмост" (г. Санкт-Петербург).
...
Рассматривался еще один вариант арочного моста с пролетом 330 метров. Утвердили бы на совещании этот проект, Россия стала бы обладательницей пятого по величине арочного моста в мире.
...
После подведения итогов тендера Александр Филипенко сказал Солохину: "Валентин Федорович, три года на строительство моста - и ни дня больше!".
...
Первоначальные сроки, намеченные на 10 августа 2004 года, пришлось сдвинуть - никто не ожидал, что с этим мостом будет столько волокиты: долго спорили, где быть створу перехода (утвердили в июне), год ушел на выбор варианта моста. Вернее, не на выбор - на споры. Проект будет готов в марте. Но мостовики попросили проектировщиков дать основания двух-трех опор к декабрю, чтобы начать работу. "Нам нужна зима, - говорит Солохин. - Зимой мостовикам проще всего в реке работать. Лето - пора непредсказуемая. Вдруг вода высоко поднимется да не спадет долго? Прошлое лето нам много сюрпризов преподнесло".
...
Истории той 57 лет. "Когда в 1944 году немцев вышибли с Кавказа, Сталин приказал быстро построить мост через Керченский пролив, - рассказывает Солохин. - Построили быстро, как заказывали. Поезда пошли через пролив. И неожиданно погода выкинула фортель: подул ветер с севера. Азовское море взгромоздилось ледяными торосами, а ветер продолжал дуть. В итоге ветер сорвал лед, и тем льдом мост срезало. Строившие мост инженеры на заседание Совмина отправились как на плаху. Снисхождения от Сталина не ждал никто. А Иосиф Виссарионович попросил показать дело. Мостовики решили, что это конец. Полистал, захлопнул: "Наши мостостроители научились строить мосты через любые реки. Я не сомневаюсь, что они научатся строить и через проливы". И ушел. Для тех мостовиков этот день был вторым рождением. Многие до сих пор живы"."
----------------------------
ВОТ ТАК СТРОЯТ МОСТЫ!
АНАЛОГИЯ С СОФТОСТРОЕНИЕМ НАПРАШИВАЕТСЯ САМА СОБОЙ. ;-)
Вы не сможете построить сначала маленький мост для пешеходов, а потом ЛЕГКО переделать его в большой для самосвалов. А в девелопменте софта не так. Вы можете создать систему с ограниченным набором фич, первую версию, которая полезна ограниченному кругу лиц и не имеет всех запрошенных фич. А потом ПРАКТИЧЕСКИ БЕЗ ДОПОЛНИТЕЛЬНЫХ ПЕРЕРАБОТОК добавлять фичи он-деманд, постепенно наращивая мощь и полезность системы. С мостом вы так не сделаете.
ПРоцесс в каждой отдельно взятой итерации не отличается или слабо отличается от того, что написал Извратоучитель (ну не все стадии часто нужны, но в принципе оно и есть). Но, в который раз повторяю, программный продукт лучше создавать итеративно. Мосты создавать итеративно нельзя.
Кроме того, мост штука монументальная. Бизнес-приложения, о которых мы собственно и говорим, штука изменяющаяся вместе с компанией, с рынком, с бизнес-средой. Поэтому изменений на стадии проекта объективно гораздо больше, чем при создании моста. Кроме того, как выглядит мост можно показать на макете. Создать полнофункциональный макет софта практически невозможно и совершенно нерентабельно (хотя ессно прототипирование - один из способов решения проблем с требованиями)
>Вы не сможете построить сначала маленький мост для пешеходов, а потом ЛЕГКО переделать его в большой для самосвалов.
"Не мы, а вы." ;)
>А в девелопменте софта не так.
А как? Все переделать? Так одно и тоже.
>Вы можете создать систему с ограниченным набором фич, первую версию, которая полезна ограниченному кругу лиц и не имеет всех запрошенных фич.
"Фичи", милейший надо закладывать изначально. хотя бы их возможность. Но поскольку вы не знаете, какие они будут, то и заложить их возможность не сможете. У вас же ИТЕРАТИВНЫЙ ПРОЦЕСС.
>А потом ПРАКТИЧЕСКИ БЕЗ ДОПОЛНИТЕЛЬНЫХ ПЕРЕРАБОТОК добавлять фичи он-деманд, постепенно наращивая мощь и полезность системы.
Если изначально такая расширяемость и масштабируемость не заложена, то это будут заплатки.
>С мостом вы так не сделаете.
Вот же как вам понравился мост!
>ПРоцесс в каждой отдельно взятой итерации не отличается или слабо отличается от того, что написал Извратоучитель (ну не все стадии часто нужны, но в принципе оно и есть). Но, в который раз повторяю, программный продукт лучше создавать итеративно.
Если инчаче не умеете, то да.
>Мосты создавать итеративно нельзя.
Почему? Первая итерация - проектирование. торая итерация, например, сваи. Это укрупненно, конечно. ;)
>Кроме того, мост штука монументальная.
Да? Они иногда и рушаться.
>Бизнес-приложения, о которых мы собственно и говорим, штука изменяющаяся вместе с компанией, с рынком, с бизнес-средой.
Да. Особенно две линейки, например, MS Windows: NT и 95.x.
А сколько ждали выход Win2k? Там, навреное, вы думаете plug&play вот так просто взяли и добавили? ;)
>Поэтому изменений на стадии проекта объективно гораздо больше, чем при создании моста. Кроме того, как выглядит мост можно показать на макете. Создать полнофункциональный макет софта практически невозможно и совершенно нерентабельно (хотя ессно прототипирование - один из способов решения проблем с требованиями)
А зря. Для этого и существует прототипирование. Не полная картина, но отдельные достаточно сложные и не совсем определенные части показывает.
Вы бы хотя бы одну статью прочитали, или хотя бы определение итеративной разработки.
Заявление
"Почему? Первая итерация - проектирование. торая итерация, например, сваи. Это укрупненно, конечно. ;)" -
просто бред.
> Если изначально такая расширяемость и масштабируемость не заложена, то это будут заплатки.
Если она не заложена, я уволю сеньора который такую х... архитектуру сделал. Если мы говорим к примеру о веб приложениях, то такие принципы как Separation of concerns, Database Abstraction и модульность должны быть в любом мало мальски приличном приложении (мы не говорим о веб сайтах). И такие практики как code generation, TDD и рефакторинг, к примеру, позволяют делать типовые вещи просто и быстро, оставляя дизайн приложения настолько простым, насколько возможно. Если приложение простое, добавить к нему новые фичи можно ПРОСТО и быстро, без значительных изменений.
Может вы поэтому ТАК боитесь новых требований во время разработки, что не знаете как так все задизайнить и организовать чтоб менять было просто? Ну так учитесь, друг мой.
И не надо примеров с операционными системами. Это эксепшн.
>"Фичи", милейший надо закладывать изначально. хотя бы их возможность. Но поскольку вы не знаете, какие они будут, то и заложить их возможность не сможете.
Мне жаль ваших клиентов. Я им сочувствую. Искренне.
Ну, что ж, образованнейший FF. Удачи. Не забудьте рамочку надо рабочим столом повесить с бумажкой. Чтобы было чем перед клиентами или руководством прикрываться. А то высыпаете ворох названий и умных слов. Увы, я такими очень часто сталкивался. И, к сожалению, сталкиваюсь.
Угу. Спасибо. Вам тоже удачи. Мне тоже с такими приходится сталкиваться. В рамочку мне нечего вешать и прикрываться слава богу не приходится. Мы сотрудничаем. А вы похоже только деньги зарабатываете. Ваше право.
Страницы
8 февраля 2006 года, 11:26
>Очень интересно услышать про организации.
Зачем? Вы же знаете, где работате или где работали?
>Оки, конкретные ответы на конкретные вопросы. ПОтому что такие к моей безмерной радости появились.
А оно вам надо? ;)
>>Недавно был модным, насколько я помню, extreme programming. А сколько возились с RUP?
>И то и другое успешно используется в большом количестве проектов. XP не БЫЛ модным, он есть реально работающий процесс. Если вы его не пробовали или он вам не понравился - ваше дело. Мне лично он принес и приносит конкретные результаты. А конкретный результат - это довольные клиенты.
Клиенты разные бывают. Некоторые получив в предыдущих заказах неудовлетвоительный результат, бывают очень довольны, когда им хоть что-то сделают работающее.
Я, например, всегда пытаюсь поставить себя на место заказчика и понять, что бы меня удволетворило, а что нет. А вы?
>>>Да? Допустим, спроектировали базу. Некотрые умники ее нормализовали по самое немогу. Потом подумали и решили, что нет расширяемости неких объектов-элементов (ну, не предусмотрели). И пришли к выводу, что надо ломать. А уже какой-нибудь middle сделан. Ай-ай-ай. И времени нет. И заказчик недоволен. Я б на месте заказчика знаете что сделал? ;)
>Для начала. Танцевать надо не от базы,
а от домейна.
Ой, не ругайтесь так. Что у вас есть такое - "домейн"?
>Тогда не будет проблем с изменением базы, если изменяется домейн. Мидл тайер не должен быть завязан на схему базы, а только на домейн.
Что вы говоирте? Вы еще скажите, что у вас система портируется на любые DBMS. Ну, да, если табличек максимум пять. ;)
>Ну а как маппить домейн в базу данных надеюсь вы знаете.
Да-да. Похоже, вы говорите о EJB? Я вам по секрету скажу. Только тссссссссссс. Все красиво на простейших вариантах. Чуть сложнее - и, ой, какая головная боль людей настигает.
>Для этого существует как минимум несколько жизнеспособных техник - O/RM и Code Generation. Если вы их не используете, мне жаль ваших программистов, которые пишут DAO руками. Поверьте, искренне жаль.
Вы в своих системах миллионы объектов в стресс-тестах использовали? И как? ;)
>>Чистый HTML? Или, например, JSP? ;)
>JSP не лучший способ делать UI.
Зато "крутой". Или уже нет? Значит, я отстал от жизни. А как же Struts и иже сним?
>Ну если и JSP, то там не должно быть логики. Если ее нет, то изменяется все элементарно.
Элементрано? Переделка генерации HTML - это элементарно?
>Если она там есть, мне опять же жаль ваших программистов.
;) Не надо в крайности впадать и напихивать туда функциональность. И вы думаете, что я так делаю? ;)
>>>На каждом по 4 квартины. Ну, пару двухкомнатных, остальные трешки. Высоты и ширины попожжа нарисуем, коммуникации тоже. Ну, примерно 40 человек нам хватит. Для начала детально проработаем первую квартиру, остальное потом достроим. Все, можно начинать работать."
>>Не смешите мои тапочки. Если вы так проектируете и делаете систему, то ... No comments.
>Я кажется догадываюсь почему вы так упорно сопротивляетесь. Вы не верите что изменения требований в процессе создания софта - это норма.
Это обычное явление.
>Но это действительно норма. Изменения требований это объективный процесс, которые неизбежен во многих проектах (не во всех, подчеркиваю, но во многих).
Есть контаркт, в котором хотя бы оговорены базовые вещи. Если вы не способны грамотно составить контракт, то и получаете кучу головной боли, когда заказчик на ходу меняет основные требования, а не только бантики-рюшечки.
>И очень глупо верить, что ваш план, который вы составили полгода назад, будет так же верен сейчас. Это не так. Это не так даже если требования не меняются. Вам ли это не знать.
Для этого и существует подговтовка (можно это и так назвать) к заключению контаркта, проектированию системы и пр, и пр. Но когда у людей не пропадает юношеский задор (даже с возрастом) и им море по колено (мы, мол, все можем), то они сразу с головой в омут ныряют. А я ленив. Я не хочу получать лишнюю головную боль. Мне мой имидж серьезного человека дорого - я не хочу позориться в последствии. И я хочу не просто получить деньги, а еще и моральное удовлетворение, что сделано достаточно хорошо и мне не стыдно за проделанную работу.
8 февраля 2006 года, 12:12
>>Вы не верите что изменения требований в процессе создания софта - это норма. >Но это действительно норма.
>О, спасибо. Оказывается, у меня обычный, т.е. нормальный процесс ваяния софта! А я-то думал... А нет это ли Полковник вам пытается доказать?
Это общепринятый процесс. В силу многих причин. Некотрые люди прилюдно ковыряют в носу. Но это же не означает норму, правда? ;)
Не на любое кол-во, но на штук 5-6 точно. На те которые ORM Тул поддерживает, Hibernate, Слыхали о таком? Видимо нет, в контексте про EJB
>Да-да. Похоже, вы говорите о EJB? Я вам по секрету скажу. Только тссссссссссс. Все красиво на простейших вариантах. Чуть сложнее - и, ой, какая головная боль людей настигает.
EJB сами юзайте, если вам нужен геморрой. В энтерпайс приложениях его уже мало кто использует, разве что 3.0 более-менее красивым стало. Я имел ввиду тулы типа Hibernate.
>Элементрано? Переделка генерации HTML - это элементарно?
Да, это элементарно. Если у вас это не так - это ваши проблемы.
> Вы в своих системах миллионы объектов в стресс-тестах использовали? И как? ;)
Вы намекаете, что нельзя добиться нормального перформанса если не писать DAO руками? Можно добиться.
У меня создается впечатление, что вы не в курсе как сейчас решаются типичные проблемы создания масштабируемых приложений. Об ОР маппинге не знаете, предлагете EJB, HTML вам сложно генерить, котя это должны быть JSF или хотя бы темплейты (если мы о яве говорим) и тогда это просто. В качестве процесса кроме вотерфола вам ничего ен подходит и даже слушать об этом не хотите... Уверен что к юнит тестам у вас тоже сугубо отрицательное отношение. И представляю что вы скажете от TDD ("Как? Писать тесты до кода? Это невозможно!") Может вы перестали учится или еще что, я не знаю. Но если это так, ваша компания никогда не сделает ничего выдающегося. И ваш имидж серьезного человека не спасет отца русской демократии.
Вот он, корень наших разногласий. Вы говорите, что процесс общепринятый, но НЕПРАВИЛЬНЫЙ. ЧТо требования НЕ ДОЛЖНЫ менятся (интересно, скажите это клиенту, что вот типа контракт, и если захотит чего поменять, фиг вам, а не поменять. А если не фиг, то вы с вас возьмем мноооого денег, потому как все переделывать придется). Я же говорю, что изменение требований это ЕСТЕСТВЕННЫЙ процесс при разработке софта, и разработчики должны АДАПТИРОВАТЬСЯ к нему при помощи различных практик, а не убеждать клиента, что это порочно и вообще ничего не сделать если не зафиксировать требования.
Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
8 февраля 2006 года, 12:49
>>Что вы говоирте? Вы еще скажите, что у вас система портируется на любые DBMS. Ну, да, если табличек максимум пять. ;)
>Не на любое кол-во, но на штук 5-6 точно. На те которые ORM Тул поддерживает, Hibernate, Слыхали о таком? Видимо нет, в контексте про EJB
А вы пробовали портировать? ;) И что-нибудь более-менее сложное делать?
>>Да-да. Похоже, вы говорите о EJB? Я вам по секрету скажу. Только тссссссссссс. Все красиво на простейших вариантах. Чуть сложнее - и, ой, какая головная боль людей настигает.
>EJB сами юзайте, если вам нужен геморрой.
Как это, как это? Все ж кричат, что это rulez forever.
>В энтерпайс приложениях его уже мало кто использует, разве что 3.0 более-менее красивым стало. Я имел ввиду тулы типа Hibernate.
Еще недавно все было наооборот. ;)
>>Элементрано? Переделка генерации HTML - это элементарно?
>Да, это элементарно. Если у вас это не так - это ваши проблемы.
Ну, да. Шрифт поменять - несложно. ;)
>> Вы в своих системах миллионы объектов в стресс-тестах использовали? И как? ;)
>Вы намекаете, что нельзя добиться нормального перформанса если не писать DAO руками? Можно добиться.
И заработать очень большую головную боль. Даже оптимизаторы SQL в DBMS накалываются. Хотя там люди уже десятилетиями все вылизывают.
>У меня создается впечатление, что вы не в курсе как сейчас решаются типичные проблемы создания масштабируемых приложений. Об ОР маппинге не знаете, предлагете EJB, HTML вам сложно генерить, котя это должны быть JSF или хотя бы темплейты (если мы о яве говорим) и тогда это просто. В качестве процесса кроме вотерфола вам ничего ен подходит и даже слушать об этом не хотите...
Ваша начитанность поражает. Серьезно. ;) Только все ли это вы используете? ;)
>Уверен что к юнит тестам у вас тоже сугубо отрицательное отношение.
Нормальное.
>И представляю что вы скажете от TDD ("Как? Писать тесты до кода? Это невозможно!")
Тесты или протипы? ;)
>Может вы перестали учится или еще что, я не знаю.
Я просто скептически отношусь к моде. И всегда пытаюсь понять истинный смысл и возможности.
>Но если это так, ваша компания никогда не сделает ничего выдающегося.
Что значит - выдающееся? Вот у нас в стране собрались OS делать (или уже делают) для конкуренции с MS Windows и совместимую (насколько я понял) с оной. Выдающееся? Безусловно. Только одно "но". Надеюсь, вы понимаете?
>И ваш имидж серьезного человека не спасет отца русской демократии.
На этот пост я и не претендую. А вот вы, похоже, собираетесь спасти всю мировую демократию? Ну, что ж. Удачи.
---------------------------
>FF
8 февраля 2006 года, 12:55
>>Это общепринятый процесс. В силу многих причин.
>Вот он, корень наших разногласий. Вы говорите, что процесс общепринятый, но НЕПРАВИЛЬНЫЙ. ЧТо требования НЕ ДОЛЖНЫ менятся (интересно, скажите это клиенту, что вот типа контракт, и если захотит чего поменять, фиг вам, а не поменять. А если не фиг, то вы с вас возьмем мноооого денег, потому как все переделывать придется).
Простите, но это именно так. Иначе вы - плохой бизнесмен, если заключив контракт на поставку и производство, допустим, тысячи холодильников, ваш заказчик через какое-то время потребует не холодильники, а телевизоры, а вы молча согласитесь и будете срочно из холодильника делать телевизор.
Я не говорю, например, об изменении цвета, установки других компрессоров, каког-нибудь no frost. Это возможно. Но не кардинально.
>Я же говорю, что изменение требований это ЕСТЕСТВЕННЫЙ процесс при разработке софта, и разработчики должны АДАПТИРОВАТЬСЯ к нему при помощи различных практик, а не убеждать клиента, что это порочно и вообще ничего не сделать если не зафиксировать требования.
Это называетя - бесхребетность. У заказчика может быть очень буйная фантазия. И что, каждый раз все переделывать? Конечно, можно попытаться предусмотреть, что взбредет в голову заказчику. Но не все.
>Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
Точно. И работа по ночам. И, как следствие, ухудшение того же кода и пр., и пр. Потому что люди - не железные. Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и говорить: "чего еще изволите? мы за теже деньги можешь еще много чего переделать и добавить."
Наверное, я чего-то не понимаю. Ну, FF, вам и карты в руки.
Удачи.
Объясните это компаниями типа майкрософт, которые (да, даже они!) вводят у себя итеративную разработку на основе SCRUM. Объясните это тысячам других компаний, которые внедрили agile development. Они это сделали не просто так, а потому что увидели реальную выгоду. Никто не внердяет что -либо только потому что это модно. Цель у всех одна - доля рынка, кеш флоу и т.п.
>>>Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
>Точно. И работа по ночам. И, как следствие, ухудшение того же кода и пр., и пр. Потому что люди - не железные. Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и говорить: "чего еще изволите? мы за теже деньги можешь еще много чего переделать и добавить."
>Наверное, я чего-то не понимаю. Ну, FF, вам и карты в руки.
Да, вы действительно чего-то не понимаете. Вы не пробовали эти практики, а я пробовал. Мы говорим на разных языках. Возможно вы не знаете, что одно из правил XP - 40 часовая рабочая неделя. Как это согласуется с вашим утверждением "И работа по ночам"? Рефакторинг направлен на улучшение существующего кода, и это опять же не согласуется с вашим утверждением "как следствие, ухудшение того же кода"
>Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и
говорить: "чего еще изволите?
И опять же это не так. Главная задача разработчика - СОВМЕСТНО С ЗАКАЗЧИКОМ РЕШИТЬ ЕГО ПРОБЛЕМЫ. Ключевое слово "СОВМЕСТНО". Если вы утвердили требования, и не показываете клиенту систему на протяжении полугода, а потом бац - во, мы все сделали. Платите. Заплатят. Вы будете довольны. А заказчик возможно не будет доволен, потому что в работе обнаружится множество мелких и средних недочетов, что-то забыли учесть, что-то сделали не так как ОЖИДАЛОСЬ. Именно ожидалось, потому что это, как ни печально, самое важное. Сделать так, чтобы ОЖИДАНИЯ заказчика совпали с тем что вы ему отдаете в конце проекта. Agilde DEvelopment на сегодняшний день помогает достичь именно этого.
8 февраля 2006 года, 13:57
>>Это называетя - бесхребетность.
>Объясните это компаниями типа майкрософт, которые (да, даже они!) вводят у себя итеративную разработку на основе SCRUM. Объясните это тысячам других компаний, которые внедрили agile development. Они это сделали не просто так, а потому что увидели реальную выгоду. Никто не внердяет что -либо только потому что это модно. Цель у всех одна - доля рынка, кеш флоу и т.п.
И всегда сказать кастомеру, что, мол, мы используем то, то и то. И кастомер проникается этой крутостью. Вот все в ISO бросились. Понятно, что кастомер, начитавшийся вской всячины, сделает выбор в пользу того, кто имеет ISO. ;) А вот как там на самом деле дела обстоят - это уже второй вопрос. Это как бренд.
>>>Именно отсюда пошло XP, Refactoring и прочие практики, направленные на адаптацию к часто изменяющимся требованиям.
>>Точно. И работа по ночам. И, как следствие, ухудшение того же кода и пр., и пр. Потому что люди - не железные. Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и говорить: "чего еще изволите? мы за теже деньги можешь еще много чего переделать и добавить."
>>Наверное, я чего-то не понимаю. Ну, FF, вам и карты в руки.
>Да, вы действительно чего-то не понимаете.
Но все делаю довольно успешно. ;)
>Вы не пробовали эти практики, а я пробовал.
Пробовал кое-что. Достаточно тот же RUP привести как пример. очень хитро все - как хочешь так и делай по большому счету. И смысл тогда?
>Мы говорим на разных языках. Возможно вы не знаете, что одно из правил XP - 40 часовая рабочая неделя. Как это согласуется с вашим утверждением "И работа по ночам"?
А это и есть обычное явление. Как ни прикрывайся словами.
>Рефакторинг направлен на улучшение существующего кода, и это опять же не согласуется с вашим утверждением "как следствие, ухудшение того же кода"
Есть еще другой принцип: лучшее - враг хорошего. Сколько потом после рефакторинга необходимо исправлять? Конечно, идеальный случай, когда все очень просто сделано, как прямая линия. Но в жизни все несколько иначе.
>>Главное же - залатать дырки быстрее и прибежав к кастомеру мило улыбаться и
говорить: "чего еще изволите?
>И опять же это не так. Главная задача разработчика - СОВМЕСТНО С ЗАКАЗЧИКОМ РЕШИТЬ ЕГО ПРОБЛЕМЫ.
Это идеальная ситуация. Но о своих проблемах большинство заказчиков очень мало знает. А тем более о возможных проблемах.
>Ключевое слово "СОВМЕСТНО". Если вы утвердили требования, и не показываете клиенту систему на протяжении полугода, а потом бац - во, мы все сделали.
Если достаточно серьезный проект, то ранее, чем через месяца три даже показывать ничего нельзя. Потому что это этап ПОДГОТОВИТЕЛЬНЫЙ, это и исследование возможных используемых технологий, это и прототипирование. Потому что действительно заранее нельзя знать, с какими проблемами можно столкнуться. А если вы в угоду заказчика чего-то там наклепали, чтобы отчитаться, то это - ваши проблемы. В конечном итоге и получится продукт, сделанный "на коленке".
Видел я это много раз. И когда сам что-то делаю, то сразу заказчика предупреждаю: "Вот столько-то времени вы ничего не увидите". Если заказчик разумный - он поймет. Если нет, то проводится ликбез. Если и это не помогает, а деньги заработать хочется, то делается простейшая вещь. Работа идет как надо, а заказчику время от времени показывается что-то, делаемое параллельно и фейковое. С таким заказчиком проходит такой финт хорошо Увы, это приводит к лишним расходам.
>Платите. Заплатят. Вы будете довольны. А заказчик возможно не будет доволен, потому что в работе обнаружится множество мелких и средних недочетов, что-то забыли учесть, что-то сделали не так как ОЖИДАЛОСЬ. Именно ожидалось, потому что это, как ни печально, самое важное. Сделать так, чтобы ОЖИДАНИЯ заказчика совпали с тем что вы ему отдаете в конце проекта.
Ожидания? Так вы ж сами говорили, что эти ожидания в процессе сильно меняются. ;) "Пойди туда, не знаю куда, принеси то, не знаю что".
>Agilde DEvelopment на сегодняшний день помогает достичь именно этого.
Возможно. А психологию заказчика-исполнителя он учитывает? А несовершенство технологий и возможные проблемы он учитывает. ПО-НАСТОЯЩЕМУ. А не процент риска?
Все, извините. Есть дела.
Пример этой разницы в студию.
Со стороны Полковника объяснения как сделать так, чтоб получить малорискованный результат и доказательства того, что это возможно (работодатель). Со стороны оппонентов мысль, что мол собственное понимание проблемы превыше всего(работники).
Разница в том что работник может спорить и экспериментировать, признавать догмы или отвергать, тратить время на собственные ошибки ( не признавая их или оправдывая сложившимися обстоятельствами). Ни один работник не будет нести финансовой ответственности за совершенные действия. По крайней мере за программинг или взаимоотношения с клиентом. Каждый работодатель не может себе позволить проводить эксперименты. Он будет следовать только проверенными методами которые точно гарантируют достижение цели, пусть даже на это уйдет немного больше времени чем при атаке “в лоб”., но это должен быть предсказуемый результат.
Отсюда и разница во взглядах. , когда с одной стороны слышится “Все так работают и нам не стоит напрягаться против этого”, с другой стороны заявления “Так работают только те кто не умеет четко работать”. Лично я на стороне Полковника. Мне нужен сто процентный результат, а его гарантией является четкая методика, проверенная технология, и соответствующий спрос с персонала. С другой стороны я прекрасно понимаю что персонал измеряет долю своего участия не прибылью, а степенью усталости или говоря по другому, тем сколько он потратил собственного времени на проект. Соответственно во время на проект он может потратить время на переработку тех элементов которые были неправильно поняты/согласованы с заказчиком. Ему по барабану- за это заплатит работодатель. А вот работодатель, предпочтет чтоб его персонал затратил большее время на выяснение подробностей по каждой фичке проекта, но затем персонал сможет ее сделать так, что она будет сдана с первого подхода без внесения изменений/доработок. И для этого есть четко отработанная методика. Со стороны персонала, следование данным методикам – пустая трата времени. Причина банальная – вероятность того, что неправильное понимание потребностей клиента, ВЕСЬМА МАЛА. Так и есть. Но эта “ВЕСЬМА МАЛА” при определенных обстоятельствах может поставить предприятие на колени или вообще его прибить, а это выходит за рамки понимания любого работника который не несет коммерческих рисков. Ему по барабану “Я работал - заплати”.
Что вы, Полковник, я софт прилюдно не ваяю, разве что в командировке, бывает, то-другое правлю; ковыряю ли я при этом в носу - не помню.
>У заказчика может быть очень буйная фантазия
О, всегда, как только заказчик заюзает пробную версию!
>Сделать так, чтобы ОЖИДАНИЯ заказчика совпали с тем что вы ему отдаете...
Ну это типа, как выпить всю водку (заработать все бабки, удовлетворить всех женщин и т.д.).
>О своих проблемах большинство заказчиков очень мало знает...
Только не говорите об этом заказчику!
Вы не правы. Я фаундер. Так что говорить что я представлю сторону работника в корне неверно. Я несу полную финансовую ответственность за все свои действия. Мы успешно проводим эксперименты (ессно, взвешенные, а не "давайте заюзаем этих пять новых тулов и все будет в шоколаде"). Процессы и подходы должны развиваться и улучшаться.
Я вас не совсем понимаю. Никто не утверждает, что надо ничего у заказчика не спрашивать, что-то там на коленке сделать и потом переделыват. Весь смысл в восприятии процесса создания софта. Он отличается от обычных инженерных дисциплин, это не строительство дома или моста. Это объективно итеративный процесс с часто изменяющимися требованиями. И для управления таким процессом нужные другие методы, отличные от методов и практик обычных инженерных дисциплин.
Работодатель действительно хочет минимизировать расходы и сократить риски. И ИМЕННО ЭТО позволяют сделать новые подходы. А такие вещи как BDUF, Waterfall и первый релиз через полгода риски увеличивают, и увеличивают серьезно.
9 февраля 2006 года, 10:44
>>Некотрые люди прилюдно ковыряют в носу
>Что вы, Полковник, я софт прилюдно не ваяю, разве что в командировке, бывает, то-другое правлю; ковыряю ли я при этом в носу - не помню.
Поздравляю. ;)
>>У заказчика может быть очень буйная фантазия
>О, всегда, как только заказчик заюзает пробную версию!
Вот поэтому надо четко договариваться. Чтобы умерить пыл и фантазию заказчика.
>>Сделать так, чтобы ОЖИДАНИЯ заказчика совпали с тем что вы ему отдаете...
>Ну это типа, как выпить всю водку (заработать все бабки, удовлетворить всех женщин и т.д.).
Снова надо договориться обо всей водке, всех бабках, всех женщинах. Хотя бы максимально попытаться. ;)
>>О своих проблемах большинство заказчиков очень мало знает...
>Только не говорите об этом заказчику!
Я и не говорю. ;)
---------------------------------------->FF
9 февраля 2006 года, 11:18
>2Извратоучитель
>Вы не правы. Я фаундер. Так что говорить что я представлю сторону работника в корне неверно. Я несу полную финансовую ответственность за все свои действия. Мы успешно проводим эксперименты (ессно, взвешенные, а не "давайте заюзаем этих пять новых тулов и все будет в шоколаде").
Увы, но так очень часто бывает. Не у вас, возможно.
>Процессы и подходы должны развиваться и улучшаться.
Кто бы спорил?
>Я вас не совсем понимаю. Никто не утверждает, что надо ничего у заказчика не спрашивать, что-то там на коленке сделать и потом переделыват.
Вы несколько ранее говорили о том, что все определяется в процессе разработки. А это уже подразумевает постоянные переделки.
>Весь смысл в восприятии процесса создания софта. Он отличается от обычных инженерных дисциплин, это не строительство дома или моста.
Конечно отличается. Там стройматериалы, а здесь нечто возвышенное и эфемерное? ;)
>Это объективно итеративный процесс с часто изменяющимися требованиями.
Плохо договариваетесь, если требования часто изменяются.
>И для управления таким процессом нужные другие методы, отличные от методов и практик обычных инженерных дисциплин.
Естественно. Там люди точно знают, что будут строить мост. А здесь - сегодня "мост", а завтра "туннель"?
ЧЕМ ОТЛИЧАЕТСЯ?
Решили строить мост - понтонный -начали, потом уточнили - на сваях - вбили, проворовались, отложили, приступили - решили подвесной... закончили туннелем, которым никто не пользуются ибо паром оказался дешевле или река к тому времени изменила русло.
ЧЕМ ОТЛИЧАЕТСЯ?
Итам и там - текст и его интерпретация.
Ну, ну.
"Ещё каких-нибудь 150 лет тому назад, когда поезд въезжал на мост, машинист снижал скорость и начинал подавать непрерывные тревожные гудки, а пассажиры обращали взоры ко Всевышнему, шепча про себя молитвы: "Пронеси, о господи!".
Уж очень часто в те годы мосты не выдерживали нагрузки и вместе с поездами обрушивались в воду. Движение по железным дорогам было не безопасным, обвалы мостов в Европе и Америке были довольно частыми. В Америке, в Филадельфии, рухнул в воду мост в 1811 году, его восстановили, но через пять лет он снова развалился. По данным статистики, в Соединенных Штатах Америки даже в более поздние годы - с 1878 по 1887 гг. - произошло более 250 аварий мостов. Не лучше обстояло дело и в других странах.
В чём дело? Почему одни мосты стояли долгие годы, а другие обрушивались? Ответить на этот вопрос нетрудно. В то время мостостроение, как наука, вовсе не существовала. Инженеры при сооружении мостов руководствовались только своим опытом, своей интуицией, а не точным расчетом.
Разумеется, одной интуиции для инженера недостаточно, тем более, когда речь идет о большом сооружении. Ведь на мост оказывают влияние самые различные силы и все их надо учесть! Как подбирать фермы моста? Как будет вести себя тот или иной материал, из которого решили строить мост?
На эти и многие другие вопросы инженерная наука того времени не могла дать точный ответ. Даже фермы мостов никто не умел рассчитывать. Над вопросами мостостроения работали виднейшие инженеры и механики мира. Но только молодой русский инженер Дмитрий Иванович Журавский впервые создал теорию мостостроения, вооружил инженеров строгой системой и методами расчетов."
Вам это ничего не напоминает, деволперы? ;-)
Молодой инженер Дмитрий Журавский сначала участвовал в изыскательских работах. Когда он отлично проявил себя на них, ему поручили проектировать мосты. Строительство каждого моста для того времени было настоящим подвигом, тем более если мост был больших размеров и предназначался для железной дороги. ЖуравскиЙ горячо взялся за это дело. Но уже в первые дни возникли труднейшие проблемы, буквально на каждом шагу приходилось самостоятельно разрешать самые сложные задачи.
Журавскому всё пришлось делать впервые. Естественно, вопрос о материалах не возникал - камень и дерево - чугунные и стальные мосты появились значительно позже. И молодой инженер вначале пошёл по проторенной тропе, решив строить деревянные мосты раскосной системы американского инженера Гау - системы запатентованной и, как все авторитеты утверждали, самой совершенной. Но беда в том, что даже сам Гау не знал, как рассчитывать свои фермы и поэтому тяжи и раскосы он делал одних и тех же размеров.
Дмитрий Иванович очень скоро понял, что вслепую строить мосты нельзя, следует учитывать усилия в фермах во время движения поезда, давление на мост сильного ветра и т. д. Для этой цели он построил макет будущего моста из набора одинаковых ферм в полном соответствии с патентом Гау."
---------
ОН ДОШЕЛ ДО МАКЕТИРОВАНИЯ!!!
...
Дмитрий Иванович Журавский долгое время возглавлял железнодорожное дело в России, сперва как вице-президент Главного общества российских железных дорог, а с 1877 года - как директор департамента железных дорог. При нём было проложено 4800 км новых железнодорожных путей в различных уголках России. Несмотря на большую занятость на административной работе, Журавский не покидал живой инженерной деятельности. В 1869 году, когда было прервано сообщение между Москвой и Петербургом (сгорел знаменитый мост через реку Мста), Журавский предложил весьма интересный и смелый проект его восстановления. Друзья отговаривали Дмитрия Ивановича от этого рискованного проекта, который мог в случае неудачи подорвать авторитет вице-президента. Но Дмитрий Иванович сам взялся руководить работами и в тридцатиградусный мороз в очень короткое время восстановил мост."
----------
-30 ниже нуля! - вот как строят(ли) мосты!
"Страсти вокруг моста через Иртыш около Ханты-Мансийска улеглись, каким быть мосту, решено. Околомостовые дебаты, продолжавшиеся год, вертелись вокруг дилеммы: строить висячий мост или балочный? Валентин Солохин, генеральный директор АО "Мостострой-11", построивший мост через Обь, - нынешнюю гордость России, сражался за висячий: прецедент для страны, да и красота небывалая. Проектировщики настаивали на балочном - дешевле, мол. Дешевле, никто не спорит. Но глаз не радует и сердце не греет - обычный частокол. Причем семь опор придется забивать в реку, губить Иртыш.
После рассмотрения материалов тендера на проектирование моста через Иртыш на совещании у губернатора округа принято решение строить мост арочный.
Весь мир давно строит арочные мосты. Великаны арочники "живут" в Австралии (построенный в 1938-м в Сиднее арочный мост пролетом 507 метров) и в Америке (пролетом 510 метров).
С арочными мостами отношения у России непростые.
...
Тендер выиграл проектный институт "Трансмост" (г. Санкт-Петербург).
...
Рассматривался еще один вариант арочного моста с пролетом 330 метров. Утвердили бы на совещании этот проект, Россия стала бы обладательницей пятого по величине арочного моста в мире.
...
После подведения итогов тендера Александр Филипенко сказал Солохину: "Валентин Федорович, три года на строительство моста - и ни дня больше!".
...
Первоначальные сроки, намеченные на 10 августа 2004 года, пришлось сдвинуть - никто не ожидал, что с этим мостом будет столько волокиты: долго спорили, где быть створу перехода (утвердили в июне), год ушел на выбор варианта моста. Вернее, не на выбор - на споры. Проект будет готов в марте. Но мостовики попросили проектировщиков дать основания двух-трех опор к декабрю, чтобы начать работу. "Нам нужна зима, - говорит Солохин. - Зимой мостовикам проще всего в реке работать. Лето - пора непредсказуемая. Вдруг вода высоко поднимется да не спадет долго? Прошлое лето нам много сюрпризов преподнесло".
...
Истории той 57 лет. "Когда в 1944 году немцев вышибли с Кавказа, Сталин приказал быстро построить мост через Керченский пролив, - рассказывает Солохин. - Построили быстро, как заказывали. Поезда пошли через пролив. И неожиданно погода выкинула фортель: подул ветер с севера. Азовское море взгромоздилось ледяными торосами, а ветер продолжал дуть. В итоге ветер сорвал лед, и тем льдом мост срезало. Строившие мост инженеры на заседание Совмина отправились как на плаху. Снисхождения от Сталина не ждал никто. А Иосиф Виссарионович попросил показать дело. Мостовики решили, что это конец. Полистал, захлопнул: "Наши мостостроители научились строить мосты через любые реки. Я не сомневаюсь, что они научатся строить и через проливы". И ушел. Для тех мостовиков этот день был вторым рождением. Многие до сих пор живы"."
----------------------------
ВОТ ТАК СТРОЯТ МОСТЫ!
АНАЛОГИЯ С СОФТОСТРОЕНИЕМ НАПРАШИВАЕТСЯ САМА СОБОЙ. ;-)
Где есть цыфры, символы или эквиваленты и ими оперируют - это уже не искуство, а инженеринг или наука. Так почему нужно изобретать "особенности"?
Ничего особенного нет.
1. Иследование среды ( не важно что это бизнес-процес или погодные условия)
2. Иследование обьекта (даже кортофельного поля или существующего ПО)
3. Определения требуемых свойст продукта (пусть даже кукурузы)
4. Анализ соответствия среды и свойств
5. Определение долгосрочных целей
6. Определение краткосрочных целей
7. Описание составляющих и элементов краткосрочных целей
8. Определение единного с заказчиком подхода к решению задачи (именно подтверждение того что вы одинаково понимаете задачу)
9. Определение способов достижения краткосрочных целей
10. Расчет необходимых ресурсов (финансовых и людских)
11. Определение требуемых инструментов (тип экскаватора или ПО версионности один черт)
12. Определение требований к рабочей среде (помещение персонал бизнес-процес/влажность, отопление или экология)
13. Получение гарантий обеспечения требуемых ресурсов (предоплата/кредит и так далее)
14. Создание рабочей среды (разработки ПО/уборки пшеницы).
15. Проведение работ по достижению поставленной цели.
16. Сдача продукта отвечающего требованиям пункта 3 и выполненого по методике согласованной в пункте 8.
17. Систематизация заявок (полученных в процессе достижения цели), на внесение доработок, улучшающих качество продуктов.
18. Согласование сроков объема и стоимости работ по внедрению изменений.
Все очень просто.
Напоминает, напоминает.
Хотелось бы услышать, что FF по этому поводу скажет.
Все что написано выше совершенно верно.
Отличие не в этом.
Отличие в деталях и итеративности процесса.
Вы не сможете построить сначала маленький мост для пешеходов, а потом ЛЕГКО переделать его в большой для самосвалов. А в девелопменте софта не так. Вы можете создать систему с ограниченным набором фич, первую версию, которая полезна ограниченному кругу лиц и не имеет всех запрошенных фич. А потом ПРАКТИЧЕСКИ БЕЗ ДОПОЛНИТЕЛЬНЫХ ПЕРЕРАБОТОК добавлять фичи он-деманд, постепенно наращивая мощь и полезность системы. С мостом вы так не сделаете.
ПРоцесс в каждой отдельно взятой итерации не отличается или слабо отличается от того, что написал Извратоучитель (ну не все стадии часто нужны, но в принципе оно и есть). Но, в который раз повторяю, программный продукт лучше создавать итеративно. Мосты создавать итеративно нельзя.
Кроме того, мост штука монументальная. Бизнес-приложения, о которых мы собственно и говорим, штука изменяющаяся вместе с компанией, с рынком, с бизнес-средой. Поэтому изменений на стадии проекта объективно гораздо больше, чем при создании моста. Кроме того, как выглядит мост можно показать на макете. Создать полнофункциональный макет софта практически невозможно и совершенно нерентабельно (хотя ессно прототипирование - один из способов решения проблем с требованиями)
"Не мы, а вы." ;)
>А в девелопменте софта не так.
А как? Все переделать? Так одно и тоже.
>Вы можете создать систему с ограниченным набором фич, первую версию, которая полезна ограниченному кругу лиц и не имеет всех запрошенных фич.
"Фичи", милейший надо закладывать изначально. хотя бы их возможность. Но поскольку вы не знаете, какие они будут, то и заложить их возможность не сможете. У вас же ИТЕРАТИВНЫЙ ПРОЦЕСС.
>А потом ПРАКТИЧЕСКИ БЕЗ ДОПОЛНИТЕЛЬНЫХ ПЕРЕРАБОТОК добавлять фичи он-деманд, постепенно наращивая мощь и полезность системы.
Если изначально такая расширяемость и масштабируемость не заложена, то это будут заплатки.
>С мостом вы так не сделаете.
Вот же как вам понравился мост!
>ПРоцесс в каждой отдельно взятой итерации не отличается или слабо отличается от того, что написал Извратоучитель (ну не все стадии часто нужны, но в принципе оно и есть). Но, в который раз повторяю, программный продукт лучше создавать итеративно.
Если инчаче не умеете, то да.
>Мосты создавать итеративно нельзя.
Почему? Первая итерация - проектирование. торая итерация, например, сваи. Это укрупненно, конечно. ;)
>Кроме того, мост штука монументальная.
Да? Они иногда и рушаться.
>Бизнес-приложения, о которых мы собственно и говорим, штука изменяющаяся вместе с компанией, с рынком, с бизнес-средой.
Да. Особенно две линейки, например, MS Windows: NT и 95.x.
А сколько ждали выход Win2k? Там, навреное, вы думаете plug&play вот так просто взяли и добавили? ;)
>Поэтому изменений на стадии проекта объективно гораздо больше, чем при создании моста. Кроме того, как выглядит мост можно показать на макете. Создать полнофункциональный макет софта практически невозможно и совершенно нерентабельно (хотя ессно прототипирование - один из способов решения проблем с требованиями)
А зря. Для этого и существует прототипирование. Не полная картина, но отдельные достаточно сложные и не совсем определенные части показывает.
Заявление
"Почему? Первая итерация - проектирование. торая итерация, например, сваи. Это укрупненно, конечно. ;)" -
просто бред.
> Если изначально такая расширяемость и масштабируемость не заложена, то это будут заплатки.
Если она не заложена, я уволю сеньора который такую х... архитектуру сделал. Если мы говорим к примеру о веб приложениях, то такие принципы как Separation of concerns, Database Abstraction и модульность должны быть в любом мало мальски приличном приложении (мы не говорим о веб сайтах). И такие практики как code generation, TDD и рефакторинг, к примеру, позволяют делать типовые вещи просто и быстро, оставляя дизайн приложения настолько простым, насколько возможно. Если приложение простое, добавить к нему новые фичи можно ПРОСТО и быстро, без значительных изменений.
Может вы поэтому ТАК боитесь новых требований во время разработки, что не знаете как так все задизайнить и организовать чтоб менять было просто? Ну так учитесь, друг мой.
И не надо примеров с операционными системами. Это эксепшн.
>"Фичи", милейший надо закладывать изначально. хотя бы их возможность. Но поскольку вы не знаете, какие они будут, то и заложить их возможность не сможете.
Мне жаль ваших клиентов. Я им сочувствую. Искренне.
Страницы