Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Экстремальное программирование (eXtreme Programming)

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки

Открыть новую тему     Написать ответ в эту тему

drimplex



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Предлагаю в этой теме собирать материалы по этому подходу к программированию.
 
Мой стиль программирования соответствует методам XP:
 
1. Формируется ТЗ (крупные задачи разбиваются на более мелкие)
2. Собственный стандарт ступенчатого выравнивания кода
3. Выделяется задача для решения
4. Процесс свободного творчества - сразу код. Никаких блок-схем, никаких предварительных расчетов.
5. Тестирование, отладка, проверка соответствия решения поставленной задаче
6. Возврат к п.3, если еще есть задачи
7. Сдача проекта
 
Один из методов XP: рефакторинг - если на стадии 5 становится понятно, что код глючит и как он работает уже совсем непонятно никому - создаем новый проект и маленькими кусочками переписываем код со старого, детально разбираясь, как он работает и устраняя ошибки. В редких случаях рефакторинг применяется к своим же старым проектам, которые нужно переделать под новые задачи, но код написан настолько давно и содержит так мало комментариев, что его работа совершенно непонятна.
 
Ключевой вопрос: здесь есть еще представители этого направления?
 
Добавлено:
Хорошая вводная статья, посвященная экстремальному программированию:
http://www.informicus.ru/default.aspx?id=95&SECTION=6

Всего записей: 28 | Зарегистр. 25-08-2007 | Отправлено: 11:21 31-12-2014
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Дык, материалов достаточно много, проблема в том, что на практике качество ПО, как правило, никому не нужно (включая заказчика и самого программиста), поэтому все методологии остаются красивой презентацией.

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 12:22 01-01-2015
drimplex



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
landy,  
"на практике качество ПО, как правило, никому не нужно (включая заказчика и самого программиста)" > у кого как.
 
С новым годом!

Всего записей: 28 | Зарегистр. 25-08-2007 | Отправлено: 14:24 01-01-2015
rrromano



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
П. 4 мне кажется волюнтаризмом. Как я понял, мы просто все паттерны проектирования и прочие вещи в мусорку выкидываем? Думаю, в подавляющем большинстве получится рукожопый код. Даже если функциональная декомпозиция на этапе 1 будет подробной.
 
Добавлено:
К вопросу о качестве кода. Мне, как разработчику, оно важно. Ибо мне же его и сопровождать. И показывать.

Всего записей: 283 | Зарегистр. 20-09-2006 | Отправлено: 16:41 01-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
у кого как.


Цитата:
К вопросу о качестве кода. Мне, как разработчику, оно важно. Ибо мне же его и сопровождать.

Понятно, что можно найти конкретные примеры, иллюстрирующие любые варианты. Мой тезис касается индустрии в целом. Не только ПО.
 
Если ты, как разработчик, с первого раза выкатишь рабочий код - за его доработки тебе просто никто не будет платить => ты роешь себе яму. Т.е. выгода двойная - ты экономишь ресурсы на этапе разработки и суммарно получаешь больше денег.

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 21:33 01-01-2015
drimplex



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
rrromano, я использую в работе и шаблоны и куски исходного кода отлаженных проектов и чужие исходники изучаю. В моем случае получается рабочий код, требующий минимума отладки. Разрисовать его в блок-схему, но когда ее смотри человек, который ее хотел - у него закипает мозг и он понимает, что проще послушать мое объяснение на пальцах как это работает.
 
Качество кода соответствует моим внутренним стандартам. Обычно они выше распространенных. Я делаю КРАСИВЫЙ код, решающий задачу, который просто и приятно читать и понимать, даже если его увижу только я один.  
 
Добавлено:
landy, я делаю иначе. Поэтапная разработка. Заказчик дает ТЗ. Я выделяю и согласую базовые функции. Делаю, получаю оплату. Далее ТЗ и то что заказчику нужно вообще может измениться! Либо я предлагаю добавить что-то более простое и эффективное, что решает его задачи другим методом. Делаю добавление - получаю следующий платеж и так далее
 

Всего записей: 28 | Зарегистр. 25-08-2007 | Отправлено: 15:15 04-01-2015 | Исправлено: drimplex, 15:19 04-01-2015
xpin2013



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
drimplex

Цитата:
я использую в работе и шаблоны и куски исходного кода отлаженных проектов  

Это не плохо, но что в этом Экстремального? Добавлю - в коллективной разработке использование шаблонов защищает только Вас, но не тех кто с ними не знаком. Приведу пример из вчерашнего прошлого.
 
Я использую свои собственные индексы очень давно, и даже не подозревал, что они могут сломаться.  
Я всегда в случае удалений в цикле делаю цикл в обратном направлении:

Код:
table1.Last;
while not table1.Bof do begin
  if table1id.value=x then
    table1.delete;
  table1.prior;
end;

В этом случае индекс никогда не ломался, пока я не встретился с другим циклом, такие циклы я никогда не писал.

Код:
table1.First;
while not table1.Eof do
  if table1id.value=x then
    table1.delete
  else
    table1.next;

В этом случае мой индекс ломался, когда удалялась последняя запись, а в таблице записи ещё оставались. Дело в том, что после удаления из таблицы, таблица находилась в состоянии Eof. В этом случае из индекса удалялся нулевой элемент (это надо было в том случае если таблица пустая).
 
Так как я никогда не пользовался вторым циклом, я и не знал, что у кого-то мой индекс может сломаться, так что хорошие привычки не всегда помогают писать коллективный код.

Всего записей: 291 | Зарегистр. 16-01-2014 | Отправлено: 18:39 04-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
я делаю иначе. Поэтапная разработка. Заказчик дает ТЗ. Я выделяю и согласую базовые функции. Делаю, получаю оплату.

А теперь представь - ты получил полное ТЗ и решил проблему заказчика с первого раза. Больше денег ты не увидишь (да и за первый этап тоже, скорее всего, со скрипом)

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 23:58 04-01-2015
drimplex



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
landy,
"ты получил полное ТЗ и решил проблему заказчика с первого раза" - и если ему все понравилось я получил 1. благодарного клиента 2. потенциал других заказов от него 3. возможные рекомендации меня как разработчика, который решает задачи быстро, с первого раза и безглючно.
"за первый этап тоже, скорее всего, со скрипом" - для этого договор надо делать.

Всего записей: 28 | Зарегистр. 25-08-2007 | Отправлено: 04:57 05-01-2015
rrromano



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
я использую в работе и шаблоны и куски исходного кода отлаженных проектов и чужие исходники изучаю. В моем случае получается рабочий код, требующий минимума отладки. Разрисовать его в блок-схему, но когда ее смотри человек, который ее хотел - у него закипает мозг и он понимает, что проще послушать мое объяснение на пальцах как это работает.

Это замечательно. Но если проект большой, то это крах. Потому что начинать надо с извлечения требований и трансформации их в удобоваримое ТЗ, понятное обеим сторонам. И тут начинаются нюансы - выбор архитектурных решений, функциональная декомпозиция, проектирование интерфейса и т. д. Не очень подходящее решение на данном этапе может привести к тому, что после написания большей части кода придется или переделывать все, или лепить костыли.
Мой идеальный вариант - требования изначальные, потом общее видение (цели, задачи, общее описание решения, ключевые особенности (особые требования, исключения и ограничения). Далее - некое ТЗ со сценариями (вариантами использования), при необходимости прототипами интерфейса и т. д. Потом проектирование (вспоминаем про паттерны проектирования, они тут как раз часто очень к месту), если надо - проектирование БД на логическом уровне. Потом непосредственно кодирование и реализация БД, тестирование, сдача, сопровождение. Это грубо.
 
Добавлено:

Цитата:
я получил 1. благодарного клиента 2. потенциал других заказов от него 3. возможные рекомендации меня как разработчика, который решает задачи быстро, с первого раза и безглючно.

Именно так и получается. Так я получил свой второй заказ. И последующие ).

Всего записей: 283 | Зарегистр. 20-09-2006 | Отправлено: 11:40 05-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Именно так и получается. Так я получил свой второй заказ. И последующие ).

Это может работать только в том (редком) случае, когда ты общаешься непосредственно с тем человеком, чьи проблемы ты решаешь. В индустрии же это не так - ты обычно общаешься с менеджером заказчика, который напрямую заинтересован в длительных сроках и низком качестве твоего кода.

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 12:51 05-01-2015
drimplex



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
landy, "менеджером заказчика, который напрямую заинтересован в длительных сроках и низком качестве твоего кода". результат работы - увольнение рукожопого менеджера, который никому не приносит пользы, а только ресурсы потребляет.
 
rrromano,  
 
"если проект большой, то это крах" - для этого нанимаются специалисты-исполнители, рисующие блок-схемы и работающие с логикой. А грамотный руководитель проекта не тратит на это свое время. Если он вместо планирования задач специалистов и управления начнет рисовать блок-схемы - вот это и будет настоящий крах. У него другие задачи. Практически любой экстремальный программист - потенциальный начальник отдела разработки, особенно если ему не ставят жестких условий по технике реализации, а просто ставят задачу, которую нужно решить в обозначенные сроки с соблюдением стандартов (если это необходимо).
 
"Так я получил свой второй заказ. И последующие )". Об этом и речь!

Всего записей: 28 | Зарегистр. 25-08-2007 | Отправлено: 03:53 06-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
"менеджером заказчика, который напрямую заинтересован в длительных сроках и низком качестве твоего кода". результат работы - увольнение рукожопого менеджера, который никому не приносит пользы, а только ресурсы потребляет.  

Увы, это так только в идеальным мире. В реальном же увольняют обычно программистов, чтобы воду не баламутили. Ты как будто в корпорациях никогда не работал..

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 16:14 06-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Кстати, там еще одно обязательное требование - два программиста должны вместе сидеть за одним компьютером. Много вы сможете кода написать и отладить в таких условиях?

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 22:46 07-01-2015 | Исправлено: landy, 22:47 07-01-2015
rrromano



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
"если проект большой, то это крах" - для этого нанимаются специалисты-исполнители, рисующие блок-схемы и работающие с логикой. А грамотный руководитель проекта не тратит на это свое время. Если он вместо планирования задач специалистов и управления начнет рисовать блок-схемы - вот это и будет настоящий крах. У него другие задачи. Практически любой экстремальный программист - потенциальный начальник отдела разработки, особенно если ему не ставят жестких условий по технике реализации, а просто ставят задачу, которую нужно решить в обозначенные сроки с соблюдением стандартов (если это необходимо).  

То-есть, мы говорим не об опытном ведущем разработчике, а о просто кодере, который, не долго мудрствуя лукаво, пишет (а также поет и танцует, ежели он индус) код на основании готовых спецификаций.
Начальник отдела разработки - это как раз программист, способный посмотреть на задачи с более высокого уровня. Его задача - организовать работу программистов, причем зачастую танцуя между технологиями и проектами. Думаю, в условиях работы над несколькими проектами и с использованием разных языков программирования и какого-нибудь интеграционного решения, экстремальный программист просто завалит все к чертям. Ибо он не организует работу, а рисует код техникой широкого мазка ))).

Всего записей: 283 | Зарегистр. 20-09-2006 | Отправлено: 15:40 08-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
То-есть, мы говорим не об опытном ведущем разработчике, а о просто кодере, который, не долго мудрствуя лукаво, пишет (а также поет и танцует, ежели он индус) код на основании готовых спецификаций

Про таких в исходной мурзилке тоже написано:
 
Процесс XP является неформальным, но требует высокого уровня самодисциплины. Если это правило не выполняется, то XP мгновенно превращается в хаотичный и неконтролируемый процесс. В XP каждый программист считается квалифицированным работником, который профессионально и с большой ответственностью относится к своим обязанностям. Если в команде этого нет, то внедрять XP абсолютно бессмысленно
 
Если пару таких человек на всё предприятие еще можно представить, то набрать всю команду - полнейшая утопия.

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 22:24 10-01-2015
drimplex



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
rrromano,  

Цитата:
"а также поет и танцует, ежели он индус"
- индусы создают интересный код, но обычно кроме них его никто не может понять.
 

Цитата:
"Начальник отдела разработки - это как раз программист, способный посмотреть на задачи с более высокого уровня."
- да! XP'ер смотрит на задачи с наивысшего уровня, потому что он художник. Он видит картину единой.
 

Цитата:
"...с использованием разных языков программирования и какого-нибудь интеграционного решения, экстремальный программист просто завалит... он не организует работу, а рисует код техникой широкого мазка..."

 
Интеграция - это техника объединения, как и написание картины (объединение красок, холста, художника и кисти дает результат: произведение искусства). Рисование блок-схем и написание кода по их логике - это только разбиение больших задач на более мелкие с последующим решением.
 
Разница между обычным программистом и XP'ером в том, что обычный владеет только техникой разбиения, а XP'ер владеет и техникой объединения, и техникой разбиения - без первого качества руководитель проекта не получится.
 
Что интересно: один обычный программист не может научить другого обычного программиста технике объединения, а вот XP'ер может научить обычного этой технике. Если он знает технологию обучения нелинейному мышлению. Я такую технологию знаю. То есть я могу потенциально из любого программиста сделать руководителя проекта.
 
"Думаю, в условиях работы над несколькими проектами и с..." - это предположение. Вариант узнать что есть на самом деле - описать любому знакомому руководителю проекта те качества XP'ера, которые я здесь описал. И посмотрите, что он скажет. По тому, что Вы пишете - я знаю, что Вы - не руководитель проекта. Это так?
 
Управление - моя тема, я знаю что говорю.


landy, не надо и нельзя набирать большую команду XP'еров.
 
Должна быть малая группа таких кодеров (от 1 до 5 или больше - это экспериментально нужно определять для каждого проекта) - они создают самые сложные и оригинальные элементы - они изобритатели и экспериментаторы - создают принципиально новое - то, что никто до них не делал. Либо делают новое решение существующей задачи (изобретают велосипед), но оно сильно отличается от уже известных (содержит оригинальный элемент, который делает это решение качественно лучше, чем уже известные). У них точно работает синергия (1+1>2, 2+1>3)
 
Вторая часть команды - исполнители, которым ставят задачу и они решают ее станлдартнымси методами (в том числе по готовым шаблонам известных решений) - они только компилируют чужой труд. У них синергия может не работать (1+1=2, 2+1=3). Их должно быть больше чем XP'еров.  
 
Естественно могут быть и такие проекты в которых соотношение обычных исполнителей и XP'еров будет обратным (таких проектов гораздо меньше)

Всего записей: 28 | Зарегистр. 25-08-2007 | Отправлено: 04:25 11-01-2015 | Исправлено: drimplex, 04:36 11-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Что интересно: один обычный программист не может научить другого обычного программиста технике объединения, а вот XP'ер может научить обычного этой технике. Если он знает технологию обучения нелинейному мышлению. Я такую технологию знаю. То есть я могу потенциально из любого программиста сделать руководителя проекта.  

Вот тут подробнее - что это за особенное "мышление" такое, чем простой смертный не владеет и почему оно доступно только "руководителям"? Ты правда считаешь, что РМ сильно умнее обычного разработчика, а не наоборот?

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 13:35 11-01-2015
landy



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Вдогонку - по моему опыту, самые лучшие PM - девочки, которые просто каждый день обзванивают тормозящих участников процесса и направляют приоритеты задач, чтобы не было такого, что одного участника ждут десять других, а он об этом давно забыл/забил, а также заполняет всякие табели. Никаких _особых_ компетенций в разрабатываемом продукте и в IT вообще ей не нужно - для этого есть тимлид и все прочие.
 
Обычный же PM, коих абсолютное и всеподавляющее большинство, занимается только тем, что собирает бессмысленные совещания на 20 человек, на которых никто никого не слушает и теряется полдня, совершенно не контролируя текущие задачи. И он, повторюсь, прямо заинтересован в максимальном затягивании процесса, поскольку нацелен на получение квартальных бонусов по результатам минимального прогресса, а отнюдь не в успешном завершении проекта.

Всего записей: 576 | Зарегистр. 17-01-2003 | Отправлено: 13:55 12-01-2015 | Исправлено: landy, 13:52 20-01-2015
Открыть новую тему     Написать ответ в эту тему

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Экстремальное программирование (eXtreme Programming)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru