Парни из Петербургской группы ALT.NET пригласили меня поговорить по поводу принципов проектирования. Разговор получился не только об этом. Мы затронули отношение разработчиков к качеству кода, методологии ведения проекта и многое другое...
Скачать этот выпуск подкаста (62.3 Мб)
Ссылки из обсуждения:
Саня, спасибо за рекламу;)
ОтветитьУдалить@hazzik
ОтветитьУдалитьНа здоровье.
Скучно.
ОтветитьУдалить@Oleg
ОтветитьУдалитьЧто по вашему мнению надо было сделать по-другому?
мне подкаст показался не скучным.
ОтветитьУдалитьлюди просто обсуждают тенденции в среде.
там кто-то частенько употреблял слово дельта не к месту.
дельта - это разность. т.е. дельта программистов - это разность программистов в двух группах.
Все очень правильно и интересно, спасибо! Только, разделение XP и Scrum несколько некорректно, на мой взгляд. Scrum это процесс, итеративный инкрементальный процесс разработки, он не содержит предписаний инженерных практик, которые же содержит в свою очередь XP. Collective code ownership, interchangeable team все это достигается через техники XP - TDD, парное программирование, continues integration и так далее. Scrum и XP идут вместе и очень тесно, более того, использование одного без другого становится несколько нелогичным.
ОтветитьУдалить@Aleksei
ОтветитьУдалитьЯ тоже самое говорил.
Но разве можно говорить об XP, если используется Scrum + многие вещи из XP, но нет парного программирования?
ОтветитьУдалить@Idsa
ОтветитьУдалитьЧто значит "можно говорить об XP"?
То есть можно ли говорить, что мы практикуем XP, если у нас есть его элементы, но нет ключевого - парного программирования (которое заменяется регулярными ревью).
ОтветитьУдалить@Idsa
ОтветитьУдалитьГоворить можно :)
Я вообще не за чистоту идеологий. Надо всегда использовать только то, что работает сейчас. Если сейчас невозможно использовать парное программирование, то не надо по этому поводу расстраиваться или пытаться подогнать текущий процесс под эту практику.
Окей, мысль понял :)
ОтветитьУдалитьТолько вот...
>>Если сейчас невозможно использовать парное программирование
У нас, скорее наоборот - "возможно не использовать парное программирование" :) Подход: "один человек пишет код, двое делают ревью по частым коммитам" нам кажется эффективнее. И времени меньше тратится, и в коде в итоге ориентируются три человека.