Листал на днях книжку по экстремальному программированию (XP).
Много парадоксальных идей, с большой частью из них согласен, но вот одна идея меня просто убила.
Идея в том, чтобы откладывать решение проблем, как можно более поздний срок.
Правда, там же сразу оговорка о том, что это только сработает, если стоимость изменений в проекте растет не как обычно (экспонециально), а меньшими (лучше меньше, чем линейные).
Так вот вопрос, насколько реально добиться того, чтобы стоимость изменений не росла эспонециально (от времени, от объема проекта)?
И что для этого надо делать?
И вообще, что All думает по поводу правила вынесенного в subj?
Re: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте DarkGray, Вы писали:
DG>Так вот вопрос, насколько реально добиться того, чтобы стоимость изменений не росла эспонециально (от времени, от объема проекта)? DG>И что для этого надо делать?
ну, во-первых при проектировании постараться отделить мух от котлет, чтобы изменения в одной части программы не приводили к лавинообразному росту изменений в других частях, а во-вторых, правильно выбирать средство разработки — работа в том же CBuilder, который позволяет быстро стартануть, обычно и приводит к тому, что "чем дальше в лес, тем ну его нафиг"
DG>И вообще, что All думает по поводу правила вынесенного в subj?
самое интересное, что в реальной жизни оно так и получается, НО _возможность_ завтрашних изменений надо закладывать в программу вчера
Re[2]: [XP] не делай сегодня то, что можно сделать завтра
O$>ну, во-первых при проектировании постараться отделить мух от котлет, чтобы изменения в одной части программы не приводили к лавинообразному росту изменений в других частях, а во-вторых, правильно выбирать средство разработки — работа в том же CBuilder, который позволяет быстро стартануть, обычно и приводит к тому, что "чем дальше в лес, тем ну его нафиг"
Проектирование и XP — вещи не совместимые. Только вот Фоулер их умудряется совмещать и от этого только выигрывает. Так что слепо следовать методологии не стоит. Люди — это главное и от их способностей и надо отталкиваться.
Re[2]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте Odi$$ey, Вы писали:
DG>>И вообще, что All думает по поводу правила вынесенного в subj?
O$>самое интересное, что в реальной жизни оно так и получается, НО _возможность_ завтрашних изменений надо закладывать в программу вчера
не Алексей, как я понимаю фишка XP том сабже. Ведь мы тратим время на закладку изменений — а их и не будет.
Вернее изменения будут — но не такими какими их ждали... В общем я все более верю в XP день ото дня.
А лес и билдер — это так зать зависит от конкретного человека — надо стараться
не заходить в лес на любом средвсе разработки и в любом темпе разработки — такие
люди есть — сам видел.
* thriving in a production environment *
Re[3]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте Mishka<T>, Вы писали:
MT>Здравствуйте Odi$$ey,
O$>>ну, во-первых при проектировании постараться отделить мух от котлет, чтобы изменения в одной части программы не приводили к лавинообразному росту изменений в других частях, а во-вторых, правильно выбирать средство разработки — работа в том же CBuilder, который позволяет быстро стартануть, обычно и приводит к тому, что "чем дальше в лес, тем ну его нафиг"
MT>Проектирование и XP — вещи не совместимые.
Это смотря что понимать под проектированием — если роспись до последней венечки окончательного варианта программы — то да, но если вообще не думать о возможных направлениях развития и не учитывать их сразу, с первой же строчки кода, то программу придется выкинуть и начать писать заново гораздо раньше чем хотелось бы.
Re[3]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте Mishka<T>, Вы писали:
MT>Здравствуйте Odi$$ey, MT>Проектирование и XP — вещи не совместимые. Только вот Фоулер их умудряется совмещать и от этого только выигрывает. Так что слепо следовать методологии не стоит.
Хорошая мысль. Я тут как-то прочитал статейку: "What is XP?" с их сайта. Интересный подход, особенно что касается кодирования одновременно с написанием тестов для кода, и 2 программеров за одним компом. Интересно, стул у них тоже один на двоих?
Но только не усмотрел там одной, но далеко не последней фигуры- проектировщика, он же постановщик задач, он же Software Architect. Кто определяет архитектуру системы, строит модели, разрабатывает интерфесы и определяет границу песочницы для кодера? Судя по всему это не Customer, он скорее всего эксперт в предметной области. Может заинтересованная публика прояснит, неясность?
BS, Sergey
Re[4]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте Sergey Kulik,
SK>Но только не усмотрел там одной, но далеко не последней фигуры- проектировщика, он же постановщик задач, он же Software Architect. Кто определяет архитектуру системы, строит модели, разрабатывает интерфесы и определяет границу песочницы для кодера? Судя по всему это не Customer, он скорее всего эксперт в предметной области. Может заинтересованная публика прояснит, неясность?
Нет там такой фигуры Кодеров тоже нет. Точнее он тебе и кодер, он тебе и архитектор. Идея такая — пишешь код, затем переписываешь, потом опять переписываешь и т.д. Ну вот типа при n стремящемся к бесконечности, должно получиться идеальное решение. То бишь — сначала пишем, потом думаем. Иногда это правильно, но иногда — нет. Так что слепо следовать XP можно только в отдельных случаях. А, например, при разработке framework, так сделать не получиться, там надо сначала 10 раз подумать, а только потом 1 раз реализовать.
Я б сравнил рефакторинг и дизайн так:
Дизайн — ищем скелет, наращиваем на него мышцы.
Рефакторинг — ростим груду мышц, затем пытаемся в них найти скелет.
Поэтому вывод — там где в приложении нет скелета, не зачем его изначально искать и надо пользовать XP. Если в приложении должен быть скелет — найди его при помощи дизайна.
Re[4]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте Sergey Kulik, Вы писали:
SK>Хорошая мысль. Я тут как-то прочитал статейку: "What is XP?" с их сайта. Интересный подход, особенно что касается кодирования одновременно с написанием тестов для кода, и 2 программеров за одним компом. Интересно, стул у них тоже один на двоих? ;)
Насчёт стула не знаю, а вот тесты да. Как можно без тестов, если ты например пишешь какой-нибудь компонент, тебе же его надо туда сюда погонять.
SK>Но только не усмотрел там одной, но далеко не последней фигуры- проектировщика, он же постановщик задач, он же Software Architect. Кто определяет архитектуру системы, строит модели, разрабатывает интерфесы и определяет границу песочницы для кодера? Судя по всему это не Customer, он скорее всего эксперт в предметной области. Может заинтересованная публика прояснит, неясность?
Проектировщик, постановщик и архитектор это не совсем одно и тоже. Что такое проектировщик я вообще затрудняюсь сказать. Когда я работал в НИИ эти люди писали бумаги, из которых разработчику нужно было вычленить постановку задачи и понять суть. Это было 10% от объёма выпускаемых документов. Но тогда проекты писались скорее не для внутренноего использования, а для заказчика, так что всё было нормально. К тому же было замечено, что чем меньше проектировщик знает о деталях реализации, тем лучше. По крайней мере не будет в проекте вещей явно попахивающих нафталином. Или же как нам один профессор делал постановку иммитационной модели, пытаясь оптимизировать некоторые структуры данных и взаимосвязи, основываясь на своём опыте и своих подходах к моделированию. Нам же это всё жутко мешало, т.к. не вписывалось в наш инструментарий.
Постановщик задач — нужная и полезная фигура в команде и чем выше его класс, тем лучше для всех. Если его нет, то его функции по любому будут выполнять разработчики, которые обычно этим заниматься не любят и не хотят. Хорошо, если удасться у заказчика найти человека способного всё доходчиво объяснить, но даже в этом случае с ним лучше общаться специалисту, умеющему, во-первых, проводить интервью с заказчиком и, во-вторых, документировать полученную информацию в виде, удобном для обсуждения с разработчиком. Но такой человек тоже не является проектировщиком. Он конечно может рисовать схемы БД и всё такое, но вся информация должна много раз уточняться и дополняться.
Архитектор. Архитекторы бывают разные :) Бывают System Architect. Видимо, это и есть главное лицо. В принципе, его можно было бы назвать проектировщиком, если бы само по себе это определение не было бы столь затаскано и избито. Этот человек как раз и разрабатывает архитектуру системы (или подсистемы). Если команда не большая, то он же может заниматься и интерфейсами для кодеров и сам кодить. В больших командах за подсистемы отвечают тим-лидеры.
Бывают и другие архитекторы, Software Architect. В его обязанности входит ковыряние в новых технологиях, разработка универсальных или общих для разных подсистем программ, растолковывание всего этого другим участникам команды. Он определяет техническую политику команды, т.е. не что писать, а как и на чём и готовит для этого почву.
Всё это, конечно, моё ИМХО, основанное на личном опыте и, конечно, очень часто (если не всегда) вышеперечисленные функции с успехом совмещаются.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте IT, Вы писали:
IT>Здравствуйте Sergey Kulik, Вы писали:
IT>Насчёт стула не знаю, а вот тесты да. Как можно без тестов, если ты например пишешь какой-нибудь компонент, тебе же его надо туда сюда погонять.
Насчет стула была шутка, что касается тестов, тесты конечно вещь правильная и нужная.
IT>Проектировщик, постановщик и архитектор это не совсем одно и тоже. Что такое проектировщик я вообще затрудняюсь сказать. Когда
Я тоже затрудняюсь, дать ему строгое определение, потому что на- сколько я знаю, его нет в природе. Хотя может оно и было в советское время, но сейчас, когда пишут на джоб сайтах — нужен проектировшик, понимают нечто очень близкое к данному Вами определению System Architect. Возможно, я несколько спутал термины, спасибо за разъяснение.
BS
Re[5]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте Mishka<T>, Вы писали:
MT>Нет там такой фигуры :))) Кодеров тоже нет. Точнее он тебе и кодер, он тебе и архитектор. Идея такая — пишешь код, затем переписываешь, потом опять переписываешь и т.д. Ну вот типа при n стремящемся к бесконечности, должно получиться идеальное решение. То бишь — сначала пишем, потом думаем. Иногда это
Интереснооо .... ну прямо какая-то самоорганизующаяся система.То что кодер и архитектор два в одном, в принципе не плохо. Хотя такая организация может стрельнуть только в случае, если разр. система состоит из кучу слабо связанных компонентов, тогда коллизии связанные с утряской интерфейсов минимальны, к примеру разработка библиотек — идеально подходит.
MT>Я б сравнил рефакторинг и дизайн так: MT>Дизайн — ищем скелет, наращиваем на него мышцы. MT>Рефакторинг — ростим груду мышц, затем пытаемся в них найти скелет.
А ссылочку не кинешь, где можно об этом почитать? Желательно на русском.
MT>Поэтому вывод — там где в приложении нет скелета, не зачем его изначально искать и надо пользовать XP. Если в приложении должен быть скелет — найди его при помощи дизайна.
Мне кажется, что скелет должен быть всегда, хотя бы потому что, не имея его, трудно понять, как развивать систему дальше. А этот вопрос как правило возникает, иногда даже когда система еще не закончена. В противном случае все сводится к переписыванию переписанного.
BS
Re[6]: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте Mishka<T>, Вы писали:
MT>Здравствуйте Sergey Kulik,
SK>>Но только не усмотрел там одной, но далеко не последней фигуры- проектировщика, он же постановщик задач, он же Software Architect. Кто определяет архитектуру системы, строит модели, разрабатывает интерфесы и определяет границу песочницы для кодера? Судя по всему это не Customer, он скорее всего эксперт в предметной области. Может заинтересованная публика прояснит, неясность?
MT>Нет там такой фигуры Кодеров тоже нет. Точнее он тебе и кодер, он тебе и архитектор. Идея такая — пишешь код, затем переписываешь, потом опять переписываешь и т.д. Ну вот типа при n стремящемся к бесконечности, должно получиться идеальное решение. То бишь — сначала пишем, потом думаем. Иногда это правильно, но иногда — нет. Так что слепо следовать XP можно только в отдельных случаях. А, например, при разработке framework, так сделать не получиться, там надо сначала 10 раз подумать, а только потом 1 раз реализовать.
Не совсем, архитектора в привычном смысле нет, но проэктирование системы есть. Та же метафора это фактически нечеткая архитектура. Просто она сразу не проробатывается полностью, потому как считается что за время проекта все равно что то изменится. И кстати никто не мешает совмешать проэктирование с XP. Только надо оставлять возможность менять архитектуру на лету Вернее по идеи она постоянно меняется вместе с кодом.
MT>Я б сравнил рефакторинг и дизайн так: MT>Дизайн — ищем скелет, наращиваем на него мышцы. MT>Рефакторинг — ростим груду мышц, затем пытаемся в них найти скелет. MT>Поэтому вывод — там где в приложении нет скелета, не зачем его изначально искать и надо пользовать XP. Если в приложении должен быть скелет — найди его при помощи дизайна.
Согласен, сначала дизайн. Но никто не говорит что это противоречит XP.
Да пребудет с тобой Великий Джа
Re: [XP] не делай сегодня то, что можно сделать завтра
Здравствуйте DarkGray, Вы писали:
DG>Листал на днях книжку по экстремальному программированию (XP). DG>Много парадоксальных идей, с большой частью из них согласен, но вот одна идея меня просто убила.
DG>Идея в том, чтобы откладывать решение проблем, как можно более поздний срок. DG>Правда, там же сразу оговорка о том, что это только сработает, если стоимость изменений в проекте растет не как обычно (экспонециально), а меньшими (лучше меньше, чем линейные).
DG>Так вот вопрос, насколько реально добиться того, чтобы стоимость изменений не росла эспонециально (от времени, от объема проекта)? DG>И что для этого надо делать?
DG>И вообще, что All думает по поводу правила вынесенного в subj?
Не откладывай на завтра то, что можно сделать послезавтра!!!
ICQ #311116826
Re: [XP] не делай сегодня то, что можно сделать завтра
* thriving in a production environment *
Кодеров тоже нет. Точнее он тебе и кодер, он тебе и архитектор. Идея такая — пишешь код, затем переписываешь, потом опять переписываешь и т.д. Ну вот типа при n стремящемся к бесконечности, должно получиться идеальное решение. То бишь — сначала пишем, потом думаем. Иногда это правильно, но иногда — нет. Так что слепо следовать XP можно только в отдельных случаях. А, например, при разработке framework, так сделать не получиться, там надо сначала 10 раз подумать, а только потом 1 раз реализовать.
Если нам не помогут, то мы тоже никого не пощадим.
Вернее по идеи она постоянно меняется вместе с кодом.
