TODO or not TODO?
От: andy1618 Россия  
Дата: 20.10.08 15:37
Оценка:
Тут на работе разразилась небольшая священная война по вопросу, допустимо ли использовать метки "TODO/FIXME" в коде?
Типичный пример — ситуация, когда в многослойном приложении некая функциональность в "чужом" слое пока не реализована и поэтому приходится обходиться костылями, что-нибудь в духе:

int GetMaxItemCount()
{
    return int.MaxValue;
    // TODO: use alienLayer call when it is implemented:
    //return alienLayer.GetMaxItemCount();
}

Вопрос: как у вас принято оформлять подобные куски кода?
Re: TODO or not TODO?
От: dorofeevilya Россия  
Дата: 20.10.08 16:39
Оценка: 6 (3) +2
Здравствуйте, andy1618, Вы писали:

A>Тут на работе разразилась небольшая священная война по вопросу, допустимо ли использовать метки "TODO/FIXME" в коде?

A>Типичный пример — ситуация, когда в многослойном приложении некая функциональность в "чужом" слое пока не реализована и поэтому приходится обходиться костылями, что-нибудь в духе:

A>
A>int GetMaxItemCount()
A>{
A>    return int.MaxValue;
A>    // TODO: use alienLayer call when it is implemented:
A>    //return alienLayer.GetMaxItemCount();
A>}
A>

A>Вопрос: как у вас принято оформлять подобные куски кода?

Я бы не стал возвращать заведомо неверное значение. Лучше кинуть NotImplementedException() из alienLayer.GetMaxItemCount(). Неободимость в TODO отпадает сама собой. Если необходимо, чтобы программа работала хоть как-то (без эксепшенов), то лучше будет выделить интерфейс из класса объекта alienLayer и реализовать stub, который будет возвращать временную подделку (int.maxValue). А объект alienLayer лучше внедрять как зависимость извне класса. Таким образом, метод GetMaxItemCount() окажется полностью реализованным:
int GetMaxItemCount()
{
    return alienLayer.GetMaxItemCount();
}


Возвращаясь к вопросу о TODO, я считаю, что в этом нет ничего плохого, если его использовать там, где это необходимо.
Re: TODO or not TODO?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.10.08 17:38
Оценка: +2
Здравствуйте, andy1618, Вы писали:

A>Тут на работе разразилась небольшая священная война по вопросу, допустимо ли использовать метки "TODO/FIXME" в коде?


Да.

A>Типичный пример — ситуация, когда в многослойном приложении некая функциональность в "чужом" слое пока не реализована и поэтому приходится обходиться костылями, что-нибудь в духе:


Угу. Одна из типичных ситуаций (мы живём в реальном мире, где важны сроки, и порой оказывается, что успеваешь нормально сделать только наскоро) — что-то реализовано поверхностно, недостаточно оптимально, и подобный комментарий служит хорошо видимым указанием на места, которые при следующем "подходе к снаряду" следует проанализировать в первую очередь. Это не тезис к "индусскому" коду, но систематически оказывается, что смотришь на свой код годовой давности и понимаешь, что раньше написал не лучше того индуса;( Ещё не менее типично — недостаточно оформленные требования заказчика, когда надо сделать хоть как-то, чтобы дать ему дальше возможность решить "в основном хорошо, но вот вам список уточнений".

Даже просто погрепать по подобным меткам — уже полезно для анализа.
Ещё частая стандартная метка — "XXX" — когда просто понимаешь, что что-то делаешь криво, но описываешь при этом не то, как исправить, а что не так (даже просто собственную неуверенность в коде).

Редакторы типа vim обычно выделяют такие метки отдельным цветом.

A>Вопрос: как у вас принято оформлять подобные куски кода?


Вот именно что подобным комментарием. Очень облегчает жизнь и самому себе, и другим будущим коллегам, которым придётся читать это и сопровождать.
The God is real, unless declared integer.
Re: TODO or not TODO?
От: abibok  
Дата: 20.10.08 17:52
Оценка: 6 (3) -1 :)
Используйте принцип "you ain't gonna need it", позволяет избежать многих проблем. Если какая-то функция существует только в виде TODO-заглушки, значит эта функция на данный момент не нужна и ее следует удалить до тех пор, пока она реально не понадобится. Если вы все же написали такую функцию, то для нее уже существует unit-test (вы ведь всегда пишете тесты перед тем как добавлять функциональность?) Значит этот тест должен валиться. Failed test + заглушка вместо функции = хороший кандидат на рефакторинг.
Re[2]: TODO or not TODO?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.10.08 18:05
Оценка: +2
Здравствуйте, abibok, Вы писали:

A>Используйте принцип "you ain't gonna need it", позволяет избежать многих проблем. Если какая-то функция существует только в виде TODO-заглушки, значит эта функция на данный момент не нужна и ее следует удалить до тех пор, пока она реально не понадобится. Если вы все же написали такую функцию, то для нее уже существует unit-test (вы ведь всегда пишете тесты перед тем как добавлять функциональность?) Значит этот тест должен валиться. Failed test + заглушка вместо функции = хороший кандидат на рефакторинг.


Эх, если бы было всё так просто.
Я вот взял текущий "проект" и прогрепал его на упомянутые волшебные слова. И что вижу:

1. TODO:
1.1. Чтобы вернуть ответ, если запрос синтаксически крив (стандарт рекомендует, но не требует, в этом случае вернуть хоть что-то внятное) — разбирать не все данные пути запроса (Via), а только самые последние. На практике за K лет разработки продукта никому не потребовалось. Видимо, TODO было поспешной меткой и следует заменить на XXX. :)
1.2. Сделать выбор прокси в зависимости от того, какое живое. Да, код на это заготовлен, но к реальному применению можем дойти через несколько лет (пока не определено).

2. FIXME: нету (хм...)

3. XXX — больше всего:
3.1. Ничего не пишется в лог при ошибке закрытия пайпа к подчинённому процессу. Случай, мягко говоря, редкий и означает тотальную порчу системного окружения.
3.2. Не вызывается немедленная очистка удалённой сессии (реально где-то через полминуты сработает). Начнёт проявляться при такой нагрузке, до которой ещё семь вёрст до небес, и всё лесом.
3.3. Чистить счётчики keepalive только при начале сессии или при каждом переходе в стабильное состояние? Сейчас просто нет данных, как это решить.
3.4. Надо переслать сообщение на сторону B, но что если её нет? Жаловаться? Пока что просто игнорируем.

Надоело продолжать. Всё в том же духе: вопросы о том, чего пока не знаем. И чем тут помогут юнит-тесты, если неизвестно, как их строить?
The God is real, unless declared integer.
Re[3]: TODO or not TODO?
От: abibok  
Дата: 20.10.08 23:35
Оценка: 12 (2) +2 -2
N>Надоело продолжать. Всё в том же духе: вопросы о том, чего пока не знаем. И чем тут помогут юнит-тесты, если неизвестно, как их строить?

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

При написании тестов до кода, ситуация "о, а вот тут в спецификации пробел, нужно уточнять у заказчика" проявляется намного раньше и решается намного проще, чем когда программисты реализовали систему так как они себе ее представляли (а не так как должно быть) и набили кода "на будущее".

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

Если в проекте накопилось много таких мест, разумный PM должен сказать "замораживаем добавление новых функций до тех пор, пока не начнем точно знать что делает наша программа (не что должна по бумагам, а что реально делает написанный код) и какие у нее ограничения".
Re: TODO or not TODO?
От: BigBoss  
Дата: 21.10.08 00:29
Оценка: 2 (1) +1
Здравствуйте, andy1618, Вы писали:

A>Тут на работе разразилась небольшая священная война по вопросу, допустимо ли использовать метки "TODO/FIXME" в коде?

A>Типичный пример — ситуация, когда в многослойном приложении некая функциональность в "чужом" слое пока не реализована и поэтому приходится обходиться костылями, что-нибудь в духе:

A>
A>int GetMaxItemCount()
A>{
A>    return int.MaxValue;
A>    // TODO: use alienLayer call when it is implemented:
A>    //return alienLayer.GetMaxItemCount();
A>}
A>

A>Вопрос: как у вас принято оформлять подобные куски кода?

Это не проблема кода, это проблема проекта. Хотя "чужие" и "alien" тоже заставляют задуматься о месте кое-кого в команде
Разумеется нужно немедленно прояснить ситуацию, по правилам, принятым у вас на работе. Для этого есть шеф, митинги разного уровня и прочее. А вообще, вполне себе рядовая, рабочая и неисключительная ситуация. И никакой это не повод для комита кода, который не пройдет первого же теста.
Re: TODO or not TODO?
От: jazzer Россия Skype: enerjazzer
Дата: 21.10.08 01:43
Оценка: 11 (4) +6
Здравствуйте, andy1618, Вы писали:

A>Тут на работе разразилась небольшая священная война по вопросу, допустимо ли использовать метки "TODO/FIXME" в коде?

A>Вопрос: как у вас принято оформлять подобные куски кода?

Я у себя в коде постоянно их ставлю, просто чтобы не терять мысль, пока пишу что-то другое (потому что если постоянно отвлекаться — никогда не закончишь).
Ставлю обычно в виде /// \todo — тогда их понимает doxygen, он даже генерит специальную страницу позора, где все такие комментарии собирает.
Просто надо стараться, чтоб в финальном production code никаких подобных заглушек не было по возможности.
Ну и при review тебя должны спросить о каждом таком комментарии и попросить обосновать, почему это не должно делаться прямо сейчас и должно ли делаться вообще.

Также я ставлю такие комментарии в случае, когда хочу позже что-то попробовать или улучшить, например:

/// \todo consider using perfect hash here
/// \todo check if strong exception guarantee is possible here
/// \todo read default value from environment (TBD: naming and format)
/// \todo make more generic (support B and C, not only A)


Т.е. в production вполне можно идти и с текущей версией, но всякие идеи по поводу дальнейшего развития/улучшения имеет смысл записывать прямо в том месте, где это улучшение должно произойти — чтобы избежать рассинхронизации (как часто бывает в случае с внешними списками todo) и чтобы оно было перед глазами того, кто соберется использовать/менять этот код.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: TODO or not TODO?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.10.08 07:33
Оценка: +4
Здравствуйте, abibok, Вы писали:

N>>Надоело продолжать. Всё в том же духе: вопросы о том, чего пока не знаем. И чем тут помогут юнит-тесты, если неизвестно, как их строить?


A>И такая вот неизвестность будет продолжаться до тех пор, пока вы будете вести разработку по-старому. Юнит тесты очень сложно прикручиваются к уже существующему проекту, который изначально разрабатывался без них.


Я понимаю, что Вы хотите сказать. К сожалению, это всё не имеет значения до тех пор, пока не выработалась чёткая спецификация, что именно надо сделать. А она никогда полностью не выработается — продукт, для которого спецификация окончательно устоялась, в наших условиях может быть только мёртвым, никому не нужным продуктом. А когда неизвестно, чего надо делать (заказ поступил во время разработки 15-й версии, включен в планы на 16-ю, первый вариант, на который сказали "о, это уже то что нам надо", увидев первый прототип — 17-я, а чтобы нормально использовать — 18-я) — никакие юнит-тесты Вам не помогут решить этот вопрос, не надейтесь.

Сразу поясню нашу специфику (мало ли как оно у вас?) — одна система на несколько сотен заказчиков (порой с мелкими патчами на 1-2 заказчика, которые невыгодно держать в общем коде), процесс взаимодействия длительный и подходом hit-and-run не ограничивается в принципе.

A>При написании тестов до кода, ситуация "о, а вот тут в спецификации пробел, нужно уточнять у заказчика" проявляется намного раньше и решается намного проще, чем когда программисты реализовали систему так как они себе ее представляли (а не так как должно быть) и набили кода "на будущее".


Я Вам завидую — Вы можете получить у заказчика точные и окончательные данные до того, как он вообще увидел первый работающий прототип. Для меня эта ситуация — фантастика.

A>Метки в коде опасны тем, что пока вы их не ищете, вы о них не знаете. Если делаются какие-то серьезные изменения, запустить тесты и увидеть где что сломалось легко. А вот пройти по всем меткам и разобраться "а не пришло ли время обратить особое внимание на этот фрагмент кода" и "а если мы все-таки заменим эту заглушку полоценной реализацией, в каких местах программа станет вести себя неожиданно иначе?" уже сложно, а на практике невозможно.


Мнэээ... Вы это серьёзно? Так сложно в crontab вставить что-то типа

1 8 10 1,4,7,10 *    egrep -rw 'XXX|TODO|FIXME' /project/src | mail -s 'check incompleting tags' bugtracker@pupkinsoft.com


?

Я не могу считать "уже сложно, а на практике невозможно" то, что делается одной строчкой конфига и затем аккуратной отработкой тикета в местной тикетной системе.

A>Если в проекте накопилось много таких мест, разумный PM должен сказать "замораживаем добавление новых функций до тех пор, пока не начнем точно знать что делает наша программа (не что должна по бумагам, а что реально делает написанный код) и какие у нее ограничения".


Разумный PM должен обеспечить вместе со своим руководством то, чтобы заказчик был доволен. А он не будет доволен, если с него сначала потребуют спецификацию того, что он сам не понимает, а затем представят неадекватную версию и скажут "чего хотел — то и жри".
The God is real, unless declared integer.
Re[2]: TODO or not TODO?
От: andy1618 Россия  
Дата: 21.10.08 13:04
Оценка:
Здравствуйте, abibok, Вы писали:

A>Если вы все же написали такую функцию, то для нее уже существует unit-test (вы ведь всегда пишете тесты перед тем как добавлять функциональность?) Значит этот тест должен валиться. Failed test + заглушка вместо функции = хороший кандидат на рефакторинг.


Спасибо, идея интересная! У нас, действительно, часто используется подход с failed tests в качестве напоминалки.
Re[2]: TODO or not TODO?
От: andy1618 Россия  
Дата: 21.10.08 13:15
Оценка:
BB>Это не проблема кода, это проблема проекта. Хотя "чужие" и "alien" тоже заставляют задуматься о месте кое-кого в команде

Да, в данном случае "aliens" — это сторонняя фирма-разработчик, и рычаги воздействия на них существенно слабее, чем могли бы быть в пределах одной компании.


BB>Разумеется нужно немедленно прояснить ситуацию, по правилам, принятым у вас на работе. Для этого есть шеф, митинги разного уровня и прочее. А вообще, вполне себе рядовая, рабочая и неисключительная ситуация. И никакой это не повод для комита кода, который не пройдет первого же теста.


Не совсем понял последние 2 предложения. В терминах исходного вопроса — допускаете ли вы коммит кода с метками "TODO" в транк репозитория?
Re[5]: TODO or not TODO?
От: abibok  
Дата: 21.10.08 17:27
Оценка:
N> К сожалению, это всё не имеет значения до тех пор, пока не выработалась чёткая спецификация, что именно надо сделать.

XP и TDD как раз и предназначены для разработки в условиях отсутствия четких спецификаций, постоянно меняющихся требований и приоритетов, а также случаев когда заказчик сам не знает толком чего хочет и узнает свой бизнесс процесс прямо во время разработки программы. То есть для нормальных и наиболее распространенных условий работы с заказчиками. Наличие четких спецификаций до начала разработки — это характерная черта waterfall. На практике это почти всегда знак обреченного на провал проекта.

N> А она никогда полностью не выработается — продукт, для которого спецификация окончательно устоялась, в наших условиях может быть только мёртвым, никому не нужным продуктом.


При использовании XP спецификацией продукта являются его юнит- и интеграционные тесты. Они четко показывают что продукт должен уметь делать на данной итерации и в каких use case'aх он будет использоваться. Причем эта спецификация всегда актуальна в отличие от формальной бумажной, которая создается в момент наименьших знаний о продукте и тут же устаревает. Актуальность поддерживается автоматически, потому что мы требуем 100% прохождения существующих тестов и написания новых тестов перед исправлением багов или добавлением новой функциональности.

N> А когда неизвестно, чего надо делать (заказ поступил во время разработки 15-й версии, включен в планы на 16-ю, первый вариант, на который сказали "о, это уже то что нам надо", увидев первый прототип — 17-я, а чтобы нормально использовать — 18-я) — никакие юнит-тесты Вам не помогут решить этот вопрос, не надейтесь.


Практика показывает, что очень даже помогают. Вы можете предложить более эффективный способ разработки в таких условиях?

N> Сразу поясню нашу специфику (мало ли как оно у вас?) — одна система на несколько сотен заказчиков (порой с мелкими патчами на 1-2 заказчика, которые невыгодно держать в общем коде), процесс взаимодействия длительный и подходом hit-and-run не ограничивается в принципе.


Представляю себе какой геморрой поддерживать эту разветвленную систему в рабочем состоянии, синхронно править баги и вносить общие изменения во все ветки, не боясь что-то поломать. Если бы разработка велась по ХР — никаких проблем, а как вы с этим справляетесь? Не пробовали собирать статистику типа "среднее время межу внесением бага в код и началом его исправления"?

N> Я Вам завидую — Вы можете получить у заказчика точные и окончательные данные до того, как он вообще увидел первый работающий прототип. Для меня эта ситуация — фантастика.


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

Слово "окончательные данные" мне не нравится. Изменять требования в процессе разработки — это естественно, хорошо и правильно. Заказчика нужно поощрять за это, потому что в конечном итоге это означает больше заработанных денег для нас и больше шансов что заказчик захочет работать с нами и дальше.

A>>Метки в коде опасны тем, что пока вы их не ищете, вы о них не знаете. Если делаются какие-то серьезные изменения, запустить тесты и увидеть где что сломалось легко. А вот пройти по всем меткам и разобраться "а не пришло ли время обратить особое внимание на этот фрагмент кода" и "а если мы все-таки заменим эту заглушку полоценной реализацией, в каких местах программа станет вести себя неожиданно иначе?" уже сложно, а на практике невозможно.


N>Мнэээ... Вы это серьёзно? Так сложно в crontab вставить что-то типа


N>
N>1 8 10 1,4,7,10 *    egrep -rw 'XXX|TODO|FIXME' /project/src | mail -s 'check incompleting tags' bugtracker@pupkinsoft.com
N>


N>Я не могу считать "уже сложно, а на практике невозможно" то, что делается одной строчкой конфига и затем аккуратной отработкой тикета в местной тикетной системе.


Если это было две-три метки, которые после извещения по почте были тут же исправлены — нет проблем. На практике же никто их исправлять не кинется, а после десятого извещения подобные письма никто даже не будет читать. Кроме того, это не решает главной проблемы. Ну знаем мы, что в проекте 50 меток FIXME, и что? Какую из них пора начинать исправлять? Вы можете постоянно держать в голове смысл всех таких помеченных мест и причины почему они были так помечены? Или каждый раз делать ревью всех и разбираться? Я вот не могу так, у меня память короткая как у рыбы. Очень быстро подсаживаешься на ощущение доверия к программе "я знаю что сейчас программа работает правильно, и если я сделаю вот это маленькое изменение, она не нигде сломается". Если мне нужно постоянно помнить о каких-то исключениях, особых предположениях, не до конца написанных функциях, это сильно напрягает.

N>Разумный PM должен обеспечить вместе со своим руководством то, чтобы заказчик был доволен. А он не будет доволен, если с него сначала потребуют спецификацию того, что он сам не понимает, а затем представят неадекватную версию и скажут "чего хотел — то и жри".


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

Разработка — это как езда на машине. Можно выбрать пункт назначения и ломануться к нему напрямик с завязанными глазами. Пробраться через бурелом и, оказавшись посреди болота, понять что находимся далеко от того места, куда должны были попасть. А можно поступать иначе. Поставить цель "доехать до ближайшего ориентира". Время от времени посматривать на дорогу, думать "где мы сейчас? а не уходим ли мы в сторону?" и чуть-чуть поворачивать руль. Вот на пути пробка — изменить маршрут. Вон там мост разобран — объезд. А вот заказчик позвонил и говорит что мы должны ехать не в Н-ск, а в М-ск. Ну и не проблема, доедем не напрягаясь.
Re[6]: TODO or not TODO?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.10.08 18:28
Оценка: 6 (1)
Здравствуйте, abibok, Вы писали:

Много всего написал, поэтому отвечу кратко — there is no silver bullet.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: TODO or not TODO?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.10.08 19:04
Оценка: 11 (2) +2
Здравствуйте, abibok, Вы писали:

N>> К сожалению, это всё не имеет значения до тех пор, пока не выработалась чёткая спецификация, что именно надо сделать.

A>XP и TDD как раз и предназначены для разработки в условиях отсутствия четких спецификаций, постоянно меняющихся требований и приоритетов, а также случаев когда заказчик сам не знает толком чего хочет и узнает свой бизнесс процесс прямо во время разработки программы. То есть для нормальных и наиболее распространенных условий работы с заказчиками. Наличие четких спецификаций до начала разработки — это характерная черта waterfall. На практике это почти всегда знак обреченного на провал проекта.

Всё это Обстракция (если не речекрякство). Возьмём простой пример — некий код реализован, например, линейным алгоритмом с линейным потреблением памяти. Возможно при условиях, которые ещё неизвестно, возникнут ли, что это станет узким местом, и придётся менять на оптимизированный (но какой из — ещё неизвестно, потому что зависит от, грубо говоря, будущего всей отрасли). Программист пишет метку-комментарий о том, что здесь может быть неоптимально и при пересмотре кода надо на это обратить внимание. Какую альтернативу Вы собираетесь предложить этому с учётом всех разнообразных XP и TDD? Пожалуйста, приведите конкретное решение, без общих слов.

N>> А она никогда полностью не выработается — продукт, для которого спецификация окончательно устоялась, в наших условиях может быть только мёртвым, никому не нужным продуктом.

A>При использовании XP спецификацией продукта являются его юнит- и интеграционные тесты. Они четко показывают что продукт должен уметь делать на данной итерации и в каких use case'aх он будет использоваться.

На данной — хорошо. А на следующих? Хрустальный шар, извините, в комплект не входит.

A> Причем эта спецификация всегда актуальна в отличие от формальной бумажной, которая создается в момент наименьших знаний о продукте и тут же устаревает.


Формальную бумажную всё равно придётся делать. Так не лучше ли не ругать её за сам факт существования, а поддерживать в актуальном состоянии?

N>> А когда неизвестно, чего надо делать (заказ поступил во время разработки 15-й версии, включен в планы на 16-ю, первый вариант, на который сказали "о, это уже то что нам надо", увидев первый прототип — 17-я, а чтобы нормально использовать — 18-я) — никакие юнит-тесты Вам не помогут решить этот вопрос, не надейтесь.

A>Практика показывает, что очень даже помогают.

Нет, не показывают. Юнит-тесты не могут протестировать то, необходимость тестирования чего не предполагалась в момент их написания (например, совместимость с устройством YYY компании XXX, в реализации которого стандарт ужесточён или искажён), или то, что не может быть для них однозначно определено как тестируемое условие (среди группы других конфликтующих условий).

A> Вы можете предложить более эффективный способ разработки в таких условиях?


То, о чём я говорю, полностью ортогонально использованию или неиспользованию XP.

N>> Сразу поясню нашу специфику (мало ли как оно у вас?) — одна система на несколько сотен заказчиков (порой с мелкими патчами на 1-2 заказчика, которые невыгодно держать в общем коде), процесс взаимодействия длительный и подходом hit-and-run не ограничивается в принципе.

A>Представляю себе какой геморрой поддерживать эту разветвленную систему в рабочем состоянии, синхронно править баги и вносить общие изменения во все ветки, не боясь что-то поломать. Если бы разработка велась по ХР — никаких проблем, а как вы с этим справляетесь?

О, расскажите мне, как "по XP" здесь будет "никаких проблем". Мне действительно интересно.:) Например, кастомер Z хочет совместимость с багами устройства S версии 12.2.14. Мы ему это делаем. Никому другому это нафиг не надо (и этому же кастомеру через год тоже будет не надо, потому что в S хоть и тормоза сидят, но после десятого тикета таки начинают чесаться), так что тот грязный хак, который нужен для этой совместимости, не должен попасть в общий код. Чтобы приблизить задачу к реальности — у Z три установки, и на две других это ставить не надо, потому что сломается совместимость с устройством Q. И чем мне тут поможет XP? Волшебник в голубом вертолёте прилетит и исправит S?

A> Не пробовали собирать статистику типа "среднее время межу внесением бага в код и началом его исправления"?


Пробовали. Только при чём тут _баги_? Как раз о багах речь и не идёт, а идёт — об обоснованных промежуточных решениях в условиях недостатка информации. А статистику по багам собирать бессмысленно, потому что есть и такие заказчики, которые по полгода боятся чихнуть на работающую систему, а уж тривиальный апгрейд для починки бага требует многомесячной моральной подготовки.

Знаете, читая Вас, мне вспоминается Джоэловский постинг про "пять миров". То, что Вы говорите, очень вероятно, хорошо подходит для "внутреннего ПО". Только вот в чём проблема — у меня оно ближе ко встроенному по большинству характеристик, кроме ограничения ресурсов... и все Ваши рассказы про магическую сущность XP вызывают только законное недоумение.

N>> Я Вам завидую — Вы можете получить у заказчика точные и окончательные данные до того, как он вообще увидел первый работающий прототип. Для меня эта ситуация — фантастика.


A>Вовсе нет, никто не имеет точных и окончательных данных. В самом начале заказчик в общем и туманном виде описывает что должна делать программа и какая функциональность для него наиболее приоритетна в самое ближайшее время. Первый работающий прототип появляется довольно быстро (все сроки зависят от конкретной команды и проекта) и заказчик реально начинает им пользоваться, пусть даже этот прототип практически ничего не умеет. Все уточнения появляются в качестве фидбека по текущему прототипу: "вот это должно работать иначе", "вот это уже не нужно и от него нужно избавиться", "вот это хотелось бы добавить в следующей итерации", "вот здесь приоритеты поменялись и теперь фича Б важнее фичи А". Очень интересно наблюдать как плавно эволюционирует проект. Еще одно очень важное преимущество: заказчик постоянно _умеет_ пользоваться программой, потому что он работал с ней начиная с самого первого прототипа, и все ему знакомо.


Ну ну. Я уж не вспоминаю, что наверняка есть какие-то другие программы подобного рода, после которых выработаны совсем другие привычки — это Вы проигнорировали, ладно. Но Вы не заметили, что я начал рассказ с того, что сейчас идёт 15-я версия? Большинство заказчиков её увидали не раньше 11-й, когда было в основе сформировано практически всё. Так что речь идёт не о разработке с нуля, а об изменениях и дополнениях (возможно, фундаментальных, но всё же — не с нуля). Ну а про эволюцию можете не рассказывать — сам наблюдаю постоянно. Но вернёмся к нашим баранам. Что Вы делаете, если есть предвидение развития (что какая-то возможность, даже если не объявлена заказчиком сейчас, будет запрошена через несколько итераций)? Опишите, пожалуйста, именно этот случай. То, что Вы до сих пор рассказывали — тривиально и комментариев не требует, а интересна тема оценки будущего развития.

A>Слово "окончательные данные" мне не нравится. Изменять требования в процессе разработки — это естественно, хорошо и правильно. Заказчика нужно поощрять за это, потому что в конечном итоге это означает больше заработанных денег для нас и больше шансов что заказчик захочет работать с нами и дальше.


;)))

A>Если это было две-три метки, которые после извещения по почте были тут же исправлены — нет проблем. На практике же никто их исправлять не кинется, а после десятого извещения подобные письма никто даже не будет читать. Кроме того, это не решает главной проблемы. Ну знаем мы, что в проекте 50 меток FIXME, и что? Какую из них пора начинать исправлять?


Вы говорили, что это невозможно сделать? Я показал, как это возможно (да, грубо и технически). Теперь Вы переводите вопрос в административную плоскость — о дисциплине работы.

A> Вы можете постоянно держать в голове смысл всех таких помеченных мест и причины почему они были так помечены?


Вы не поверите, но обычно достаточно прочитать такой комментарий, чтобы понять, почему он был написан.:)) Разумеется, я не веду речь про комментарий из одного знака "XXX". Реальные случаи — например: "XXX может стать неэффективным при >100 одновременных событий типа XQ — насколько это вообще реально?" Ничего держать в голове, кроме обычных воспоминаний разработчика, не нужно.

A> Или каждый раз делать ревью всех и разбираться? Я вот не могу так, у меня память короткая как у рыбы. Очень быстро подсаживаешься на ощущение доверия к программе "я знаю что сейчас программа работает правильно, и если я сделаю вот это маленькое изменение, она не нигде сломается". Если мне нужно постоянно помнить о каких-то исключениях, особых предположениях, не до конца написанных функциях, это сильно напрягает.


А и не надо про них постоянно помнить. Но вот когда придёт время анализировать этот конкретный кусок кода — оно и всплывёт.

A>Разработка — это как езда на машине. Можно выбрать пункт назначения и ломануться к нему напрямик с завязанными глазами. Пробраться через бурелом и, оказавшись посреди болота, понять что находимся далеко от того места, куда должны были попасть. А можно поступать иначе. Поставить цель "доехать до ближайшего ориентира". Время от времени посматривать на дорогу, думать "где мы сейчас? а не уходим ли мы в сторону?" и чуть-чуть поворачивать руль. Вот на пути пробка — изменить маршрут. Вон там мост разобран — объезд. А вот заказчик позвонил и говорит что мы должны ехать не в Н-ск, а в М-ск. Ну и не проблема, доедем не напрягаясь.


Красиво сказано, аж прослезился. Так Вы ответите на мои вопросы — что Вы делаете с предположениями, осмысленность которых заранее неизвестна и не может быть специфицирована ни одной стороной?
The God is real, unless declared integer.
Re[7]: TODO or not TODO?
От: abibok  
Дата: 21.10.08 19:15
Оценка:
AVK>Много всего написал, поэтому отвечу кратко — there is no silver bullet.

Я вижу проект с проблемами, которые не решить более упорной/тщательной/сверхурочной работой программистов. Предлагаю решение, которое в данной ситуации сработает лучше других подходов, потому что оно специально для таких случаев разрабатывалось и эффективность его в таких вот случаях доказана практикой. А в ответ — "нет серебряной пули, поэтому даже пробовать не будем".

"Нет серебряной пули" — это философия из области того же waterfall. Дайте нам все и сразу, идеальное решение или не лезьте со своими идеями вообще. А в жизни идеальное не требуется, вполне хватает "good enough".

Для забивания гвоздей нужны молотки, для закручивания шурупов — отвертки. Глупо всегда пользоваться одним только молотком лишь из-за того, что универсального инструмента нет. Если не забивать шурупы молотком, не возникнет вопроса "некоторые шурупы гнутся и вываливаются — что делать?" В нашем случае, если бы разработка велась по XP, вопрос про метки в коде даже не возник бы.
Re[8]: TODO or not TODO?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.10.08 19:24
Оценка:
Здравствуйте, abibok, Вы писали:

AVK>>Много всего написал, поэтому отвечу кратко — there is no silver bullet.


A>Я вижу проект с проблемами, которые не решить более упорной/тщательной/сверхурочной работой программистов. Предлагаю решение, которое в данной ситуации сработает лучше других подходов, потому что оно специально для таких случаев разрабатывалось и эффективность его в таких вот случаях доказана практикой. А в ответ — "нет серебряной пули, поэтому даже пробовать не будем".


Так как предыдущие ответы были мне — объясните, пожалуста, как Вы вообще на таком расстоянии, не видя, что мы делаем, почему и зачем, не зная ни предметной области, ни специфики, ни текущих ресурсов и кодовой базы, нашли у нас проблемы и сразу — решение, причём с гарантией его эффективной работы?

A> В нашем случае, если бы разработка велась по XP, вопрос про метки в коде даже не возник бы.


Повторю вопрос из предыдущего письма: XP даёт хрустальный шар?
The God is real, unless declared integer.
Re[8]: TODO or not TODO?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.10.08 19:30
Оценка: :)
Здравствуйте, abibok, Вы писали:

AVK>>Много всего написал, поэтому отвечу кратко — there is no silver bullet.


A>Я вижу проект с проблемами, которые не решить более упорной/тщательной/сверхурочной работой программистов.


А я пока ничего не вижу. И при этом не пытаюсь гадать.

A> Предлагаю решение, которое в данной ситуации сработает лучше других подходов


Не считай всех вокруг ммм... неосведомленными. Думаю, твой оппонент знаком с XP, возможно даже лучше тебя. Ну или по крайней мере следовало это уточнить, прежде чем бросаться агитировать за советскую власть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: TODO or not TODO?
От: abibok  
Дата: 21.10.08 23:08
Оценка: 20 (2) +2
N>Всё это Обстракция (если не речекрякство).
Нет, это опыт заваленных проектов и сгоревших от работы в режиме "прибили гвоздями тут — отвалилось в трех местах там" членов команды.

> Возьмём простой пример — некий код реализован, например, линейным алгоритмом с линейным потреблением памяти. Возможно при условиях, которые ещё неизвестно, возникнут ли, что это станет узким местом, и придётся менять на оптимизированный (но какой из — ещё неизвестно, потому что зависит от, грубо говоря, будущего всей отрасли). Программист пишет метку-комментарий о том, что здесь может быть неоптимально и при пересмотре кода надо на это обратить внимание. Какую альтернативу Вы собираетесь предложить этому с учётом всех разнообразных XP и TDD? Пожалуйста, приведите конкретное решение, без общих слов.


Конкретное решение: не занимайтесь преждевременной оптимизацией. Заказчик говорит: система должна потреблять не более X памяти при нагрузке Y. Делаем тест, на данном этапе тест проходит — все, забываем про этот код. Изменятся требования, тест обновим и он перестанет проходить. Вот тогда и станем смотреть в чем дело. К этому моменту код функции может уже сто раз быть переписан или вообще выброшен. Или программист думал, что данный алгоритм будет основным потребителем памяти, а на деле оказывается что оптимизировать нужно в первую очередь совсем другое место.

A>>При использовании XP спецификацией продукта являются его юнит- и интеграционные тесты. Они четко показывают что продукт должен уметь делать на данной итерации и в каких use case'aх он будет использоваться.

N>На данной — хорошо. А на следующих? Хрустальный шар, извините, в комплект не входит.

Определимся с тем, что должно быть реализовано в следующей итерации — будем писать тесты для новой функциональности. На текущей итерации нужно реализовать и доказать тестами только то, что требовалось на текущей итерации. Что будет потом — you ain't gonna need it. Заметьте, XP не отменяет планирования и проектирования, но это слишком большая тема чтобы спорить здесь. В книжках расскажут гораздо лучше и нагляднее, чем я смогу это сделать.

N>Формальную бумажную всё равно придётся делать. Так не лучше ли не ругать её за сам факт существования, а поддерживать в актуальном состоянии?


Разве я ругаю факт существования бумажной документации? Никто не спорит, что она нужна. Вопрос в том чего хочет заказчик. Хочет актуальную документацию для каждой итерации — нет проблем, включаем эту задачу в план итерации, назначаем приоритет, отодвигаем реализацию новых фич. Как правило, реальному заказчику это не нужно, good enough получить хорошую документацию в конце проекта (или для major release). Тогда и приоритеты другие.

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

A>>Практика показывает, что очень даже помогают.

N>Нет, не показывают.

Ну раз вы так уверены, то и спорить не о чем.

N> Юнит-тесты не могут протестировать то, необходимость тестирования чего не предполагалась в момент их написания (например, совместимость с устройством YYY компании XXX, в реализации которого стандарт ужесточён или искажён), или то, что не может быть для них однозначно определено как тестируемое условие (среди группы других конфликтующих условий).


Юнит-тесты — это не застывший кусок кода, который страшно трогать. Они постоянно изменяются, уточняются, рефакторятся и т.д. Появилась необходимость поддержки специфического поведения YYY — добавили тест. В чем сложности? Вопрос о том, что принципиально можно тестировать юнит-тестами и как тестировать то, что плохо поддается тестированию, это отдельная тема, не будем распыляться.

A>> Вы можете предложить более эффективный способ разработки в таких условиях?

N>То, о чём я говорю, полностью ортогонально использованию или неиспользованию XP.

Мне кажется, вы пытаетесь представить как ХР может решить ваши проблемы, не меняя процесса разработки. Действительно, в этом случае никак. Я говорю о том, что если проект изначально разрабатывается про процессу ХР, то многие проблемы никогда не возникнут и их не нужно будет решать.

N>О, расскажите мне, как "по XP" здесь будет "никаких проблем". Мне действительно интересно. Например, кастомер Z хочет совместимость с багами устройства S версии 12.2.14. Мы ему это делаем. Никому другому это нафиг не надо (и этому же кастомеру через год тоже будет не надо, потому что в S хоть и тормоза сидят, но после десятого тикета таки начинают чесаться), так что тот грязный хак, который нужен для этой совместимости, не должен попасть в общий код. Чтобы приблизить задачу к реальности — у Z три установки, и на две других это ставить не надо, потому что сломается совместимость с устройством Q. И чем мне тут поможет XP? Волшебник в голубом вертолёте прилетит и исправит S?


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

A>> Не пробовали собирать статистику типа "среднее время межу внесением бага в код и началом его исправления"?

N>Пробовали. Только при чём тут _баги_?

При том, что у меня, например, не получается сразу писать безошибочный код, который прямиком идет в релиз. Время от времени по неопытности, невнимательности или из-за неверных представлений о том, что должна делать данная фича, я пишу ошибочный код (баги). Давайте считать правильный код, который делает не то что нужно, тоже ошибочным. Чем больше времени проходит между написанием такого кода, обнаружением проблемы и началом исправлений, тем сложнее отладка и тем дороже эти исправления обходятся. С этим вы будете спорить? Использование TDD позволяет существенно сократить это время. Для оценки "здоровья" проекта и общего качества процесса разработки полезно иметь разные метрики. Среднее время до исправления бага — одна из таких метрик. Если проект пишется в стиле "давай-давай побольше кода, потом на этапе тестирования все отладим", время будет большим и это серьезный сигнал опасности.

N> Как раз о багах речь и не идёт, а идёт — об обоснованных промежуточных решениях в условиях недостатка информации.


Отлично, еще одна метрика — время, необходимое для добавления новой функциональности или выделения существующей в независимый модуль для code reuse. Если код не поддается тестированию, сильно связан и вообще мы в нем не уверены, время будет большим. Снова сигнал — проект скоро станет неподдерживаемым.

N> А статистику по багам собирать бессмысленно, потому что есть и такие заказчики, которые по полгода боятся чихнуть на работающую систему, а уж тривиальный апгрейд для починки бага требует многомесячной моральной подготовки.


Это говорит о том, что проекты у вас ведутся стихийно. Метрики нужно постоянно собирать и знать, чтобы иметь возможность улучшать процесс разработки (кстати, одно из ключевых требований ISO 9001). Потому заказчики и боятся чихнуть на работающую систему, что никто не знает чего от нее ожидать, как поведет себя в нестандартной ситуации. А вы им корректность программы (даже хотя бы соответствие спецификации) доказать не можете. Потому что тесты и метрики — это бессмысленная трата времени, верно?

N>Знаете, читая Вас, мне вспоминается Джоэловский постинг про "пять миров". То, что Вы говорите, очень вероятно, хорошо подходит для "внутреннего ПО". Только вот в чём проблема — у меня оно ближе ко встроенному по большинству характеристик, кроме ограничения ресурсов... и все Ваши рассказы про магическую сущность XP вызывают только законное недоумение.


В ХР нет ничего магического. Это небольшой набор разумных и давно известных рекомендаций, следование которым облегчает разработку. Иметь тесты для кода — это плохо? Вести разработку короткими итерациями — это плохо? Тесно общаться с заказчиком, чтобы уточнять задачи и приоритеты — это плохо? Почему тогда предложение использовать ХР (или хотя бы TDD) вызывает недоумение, тем более "законное"?

N>Ну ну. Я уж не вспоминаю, что наверняка есть какие-то другие программы подобного рода, после которых выработаны совсем другие привычки — это Вы проигнорировали, ладно.


Не понял, что вы здесь хотели сказать и что именно я проигнорировал.

N> Но Вы не заметили, что я начал рассказ с того, что сейчас идёт 15-я версия?


Прикручивать юнит-тесты к старому проекту с большим количеством написанного кода — сложное и неблагодарное занятие, я об этом уже говорил.

N> Что Вы делаете, если есть предвидение развития (что какая-то возможность, даже если не объявлена заказчиком сейчас, будет запрошена через несколько итераций)? Опишите, пожалуйста, именно этот случай. То, что Вы до сих пор рассказывали — тривиально и комментариев не требует, а интересна тема оценки будущего развития.


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

Заказчик сам может генерить такие идеи в любой момент "хорошо бы вот это, а еще можно вот такое добавить". Здорово, когда заказчик так активно участвует в процессе разработки. Все идеи и пожелания (что ваши, что заказчика) записываются и им назначается приоритет. Для реализации в следующей итерации выбираются записи с наибольшим приоритетом. Плюс принимается в расчет то, что итерация должна быть в меру короткой, поэтому если мы хотим сделать и А, и Б, то стоит подумать что из этого важнее. Приоритеты задач не фиксированы, их можно и нужно постоянно пересматривать и сравнивать разные задачи между собой. Вчера мы думали, что А важнее чем Б, а сегодня оказалось что Б нужно делать в первую очередь (ну жизнь заставляет). Внутри текущей итерации — никаких изменений. Что решили, то и делаем. Зато для следующей итерации — полная свобода. Получается что вызывающая ужас фраза "заказчик снова изменил требования" в ХР воспринимается как совершенно заурядная рабочая ситуация. Покрытие кода тестами и постоянный рефакторинг приводят к тому, что код можно легко изменять, не боясь поломать. Добавить новую функциональность почти одинаково легко что в начале проекта, что после двух лет разработки. Сложность системы не накапливается.

Есть большие вещи, которые нужно планировать сразу и далеко вперед, например security и scalability. Такое стратегическое проектирование в ХР никто не отменял, но здесь мы говорим не об этом.

A>>Слово "окончательные данные" мне не нравится. Изменять требования в процессе разработки — это естественно, хорошо и правильно. Заказчика нужно поощрять за это, потому что в конечном итоге это означает больше заработанных денег для нас и больше шансов что заказчик захочет работать с нами и дальше.

N>)))

Кстати при таком подходе совершенно нормальна ситуация, когда заказчик вдруг говорит "все, дальше разрабатывать не надо, текущая реализация меня полностью устраивает и вкладывать лишние деньги пока не имеет смысла". Ведь на каждой итерации заказчик имеет работающую программу, которая выполняет наиболее важные для него функции и выполняет их гарантированно правильно.

А через полгода он может вернуться и сказать "давайте развивать дальше" потому что будет уверен, что для нас эта пауза ничего не значит, нет проблем с тем, что все уже забыли как писался и работает этот код, какие в нем подводные камни. Просто начинаем дописывать как будто только вчера остановились и все так же уверены в стабильности системы.

A>>Если это было две-три метки, которые после извещения по почте были тут же исправлены — нет проблем. На практике же никто их исправлять не кинется, а после десятого извещения подобные письма никто даже не будет читать. Кроме того, это не решает главной проблемы. Ну знаем мы, что в проекте 50 меток FIXME, и что? Какую из них пора начинать исправлять?

N>Вы говорили, что это невозможно сделать? Я показал, как это возможно (да, грубо и технически).

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

Вы показали, что можете найти все места в исходниках, которые содержат метки. Хорошо, что дальше? При каждом изменении проекта вы собираетесь выполнять полный цикл code review и тестирования? Если нет, то как вы узнаете что изменение в одном месте (на первый взгляд совершенно невинное) не ломает что-то в другом?

N> Теперь Вы переводите вопрос в административную плоскость — о дисциплине работы.

Нет, дисциплина здесь ни при чем. Количество тестов может измеряться сотнями даже для несложных проектов. Самый дисциплинированный работник не в состоянии выполнить аналогичный объем тестирования вручную при каждом билде. Значит внесенная ошибка будет обнаружена позже, исправление ее обойдется дороже, что означает затягивание сроков сдачи проекта.

A>> Вы можете постоянно держать в голове смысл всех таких помеченных мест и причины почему они были так помечены?

N>Вы не поверите, но обычно достаточно прочитать такой комментарий, чтобы понять, почему он был написан. Разумеется, я не веду речь про комментарий из одного знака "XXX". Реальные случаи — например: "XXX может стать неэффективным при >100 одновременных событий типа XQ — насколько это вообще реально?" Ничего держать в голове, кроме обычных воспоминаний разработчика, не нужно.

Комментарий снача нужно найти, т.е. понять что проблема Х вызвана кодом Y. В вашем проекте это легко сделать? Или каждый раз разбираясь с проявлением X вы будете читать все комментарии и думать "а не этот ли фрагмент стал причиной"? Автор комментария может ошибаться или искренне заблуждаться, окажется что ХХХ не эффективен уже при 5 событиях, а не >100 как это казалось вначале. А как проверить, если тестов нет? При рефакторинге комментарии нужно поддерживать актуальными. Вы можете быть уверены, что условие ">100 событий" все еще верно после данных изменений? А что если нужно проверить поведение программы не только для событий типа XQ, но еще для трех десятков событий и дополнительных условий?

A>> Или каждый раз делать ревью всех и разбираться? Я вот не могу так, у меня память короткая как у рыбы. Очень быстро подсаживаешься на ощущение доверия к программе "я знаю что сейчас программа работает правильно, и если я сделаю вот это маленькое изменение, она не нигде сломается". Если мне нужно постоянно помнить о каких-то исключениях, особых предположениях, не до конца написанных функциях, это сильно напрягает.

N>А и не надо про них постоянно помнить. Но вот когда придёт время анализировать этот конкретный кусок кода — оно и всплывёт.

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

N> Так Вы ответите на мои вопросы — что Вы делаете с предположениями, осмысленность которых заранее неизвестна и не может быть специфицирована ни одной стороной?


Так вы будете читать то что я пишу? Не делать то, что не является необходимым прямо сейчас.
Re[9]: TODO or not TODO?
От: abibok  
Дата: 21.10.08 23:13
Оценка: -1
AVK>А я пока ничего не вижу. И при этом не пытаюсь гадать.
Тогда лучше и не встревать, если по существу сказать нечего.

AVK>Не считай всех вокруг ммм... неосведомленными. Думаю, твой оппонент знаком с XP, возможно даже лучше тебя. Ну или по крайней мере следовало это уточнить, прежде чем бросаться агитировать за советскую власть.

Судя по тому, что оппонент тут пишет и какие вопросы задает — не очень-то знаком. Если то что я говорю выглядит глупостью или неприменимо к данному случаю, давайте просто прекратим обсуждение. Агитировать себе дороже.
Re[3]: TODO or not TODO?
От: BigBoss  
Дата: 22.10.08 02:16
Оценка:
Здравствуйте, andy1618, Вы писали:

BB>>Это не проблема кода, это проблема проекта. Хотя "чужие" и "alien" тоже заставляют задуматься о месте кое-кого в команде

A> Да, в данном случае "aliens" — это сторонняя фирма-разработчик, и рычаги воздействия на них существенно слабее, чем могли бы быть в пределах одной компании.

Бывает. Фирма сторонняя, но проект-то ваш. Если без них нечем заняться -- пишите тесты или документацию, может пригодится потом

BB>>Разумеется нужно немедленно прояснить ситуацию, по правилам, принятым у вас на работе. Для этого есть шеф, митинги разного уровня и прочее. А вообще, вполне себе рядовая, рабочая и неисключительная ситуация. И никакой это не повод для комита кода, который не пройдет первого же теста.


A>Не совсем понял последние 2 предложения.


Смысл первого предложения прост: проект не всегда идет по плану. Любой разработчик, хоть свой хоть чужой, всегда может встать и сказать, что обещанный интерфейс ХХХ будет реализован не через неделю, а через 3. Руководитель проекта либо выбрасывает зависимые фишки, либо находит чем занять зависящих разработчиков на эти 2 недели, либо решает как ускорить разработку ХХХ, либо еще что-нибудь. Решит он эмулировать отсутствующую часть, так скажет кодерам, как именно.
Смысл второго еще проще: Допускается ли коммит заведомо неработающего кода? У нас в случае сомнений принято принято инициировать code review. Если пара человек посмотрят в документацию, потом на твои 2 строчки и скажут "Ты гений, это так и должно работать, можно релизить", то можно. Если скажут, что это работает неправильно, то видимо нельзя.

A>В терминах исходного вопроса — допускаете ли вы коммит кода с метками "TODO" в транк репозитория?


Так я вторично в третий раз отвечаю, это не вопрос "как оформлять подобные куски кода". Это вопрос из области проектирования.
Что до кодирования, то есть описание этой вашей GetMaxItemCount(). Если она работает как описано, то коммитить можно, иначе нет.
Все недокументированное, включая эти TODO, FIXME, BlahBlah и прочие комментарии внутри вашей функции по крупному счету никого не интересуют. Хотя сильно не завидую, если кто-нибудь в поисках баги в своем коде на второй день таки доберется до ваших исходников и выяснит, что причина была в этом самом TODO
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.