Здравствуйте, BigBoss, Вы писали:
BB>...У нас в случае сомнений принято принято инициировать code review.
Да, собственно, в процессе code review эта дискуссия и возникла (оно у нас обязательное).
BB>...Хотя сильно не завидую, если кто-нибудь в поисках баги в своем коде на второй день таки доберется до ваших исходников и выяснит, что причина была в этом самом TODO
Это да. Но вот лучше ли будет, если тупо стереть комментарии с "TODO"?
Впрочем, по данному конкретному примеру выше уже предложили подходящее решение — сделать reminder в виде валящегося юнит-теста.
Здравствуйте, abibok, Вы писали:
A>XP и TDD как раз и предназначены для разработки в условиях отсутствия четких спецификаций, постоянно меняющихся требований и приоритетов, а также случаев когда заказчик сам не знает толком чего хочет и узнает свой бизнесс процесс прямо во время разработки программы. То есть для нормальных и наиболее распространенных условий работы с заказчиками. Наличие четких спецификаций до начала разработки — это характерная черта waterfall. На практике это почти всегда знак обреченного на провал проекта.
Заинтересовался вашими данными. Seattle, USA. Значит, работаете там в IT. Очень уверенно рассказываете про то, "как должно быть". Если не секрет, а в какой компании вы работаете, и кем? (я свои догадки публиковать не буду, подожду ответа). Также интересно, что именно из рассказанной вами теории применяется в вашей компании на практике.
N>Формальную бумажную всё равно придётся делать. Так не лучше ли не ругать её за сам факт существования, а поддерживать в актуальном состоянии?
Из моего опыта: НИ ОДНА формальная бумажка НЕ МОЖЕТ быть актуальной. В редкие моменты "надо немедленно отдать на ревью" — может быть, и то вряд ли. Традиционно, только всякие "начальствующие" думают, что формализацией (и формализмами) можно что-то описать. Но это не так. Код проекта — это, пожалуй, единственный верный документ.
В нем вполне нормально живут маркеры вида TODO. Кстати, тот же Eclipse их очень удобно поддерживает.
[skip много чего]
A>Давайте не засорять тему подробностями. По такому описанию проекта я все равно не смогу сказать ничего дельного. Вопрос в подходе. Я говорю: наличие юнит-тестов существенно облегчит разработку и поддержку в вашем случае. Использование других техник ХР облегчит разработку еще больше, но юнит-тесты — это просто must have. Вы с этим не согласны? Разве без тестов проще или быстрее?
Знаете ли, мне такая дискуссия не нравится. Вы выставили себе воображаемое пугало и успешно побороли его. Я изначально совершенно ничего не говорил ни за XP, ни против неё — Вы сначала ввернули её в разговор, а затем начали используя уж не знаю что (свой опыт или что-то другое) — отрицать любые попытки ухода разговора туда, где он был изначально. Я не возражаю, радейте себе за XP — только при чём тут тема данного треда в принципе? Вам не нравится идея комментария со словом TODO? Для Вас это тотальная ересь? Что ж, могу только посочувствовать. Продолжать данную тему не хочу — что такое XP и зачем она нужна и как она применяется я и так в курсе, но предпочитаю агитацию "за советскую власть" не слушать в принципе, или слушать только в отведённых для этого местах.
A>Так вы будете читать то что я пишу? Не делать то, что не является необходимым прямо сейчас.
Я давно "в системе" и это правило знаю, вероятно, значительно дольше Вас. Пусть не сочтут это мерянием длинами, но сейчас всё больше понимаешь, что основная проблема — не отрезать всё Оккамом, а понять, что именно отрезать _не надо_, и насколько надо ценить результаты прошлых исследований. Жаль, что Вы этого не хотите понимать.
Здравствуйте, SkyDance, Вы писали:
N>>Формальную бумажную всё равно придётся делать. Так не лучше ли не ругать её за сам факт существования, а поддерживать в актуальном состоянии?
SD>Из моего опыта: НИ ОДНА формальная бумажка НЕ МОЖЕТ быть актуальной.
Хммм. Не хочу впадать в позу некоторых участников данного треда, но это не более чем отмазка и экономия средств. Специально сошлюсь именно на личный опыт, на собственной шкуре и в том виде, в котором сам видел. На заре своей работы я ещё школьником принял участие в одном проекте (хитрая матстатистика), сдававшимся для вояк. (Писать не допустили, конечно, но тестиков погонял.) Ещё времена СССР. Да, это, наверно, было очень дорого. Но он был документирован по всем правилам ЕСПД и вся "формальная" бумажная документация соответствовала содержимому целиком и полностью, и специальная комиссия тщательно проверяла это соответствие. В документацию, разумеется, входил и исходный текст — отдельной книгой.;)
Больше с таким сталкиваться уже не пришлось — более того, в 90-х типично было, что и исходники никому не были нужны, лишь бы было поставлено на конкретную машину и работало... сейчас хотя бы репозиторий обычно есть и какое-нибудь wiki для документирования основных моментов по заказу типа "тут на странице X всё безнадёжно устарело ещё три версии тому назад, обнови". Но я уверен, что в соответствующих местах и сейчас так делается, что принятие результата без адекватной и полной документации не бывает в принципе.
SD> В редкие моменты "надо немедленно отдать на ревью" — может быть, и то вряд ли. Традиционно, только всякие "начальствующие" думают, что формализацией (и формализмами) можно что-то описать. Но это не так. Код проекта — это, пожалуй, единственный верный документ.
Хех, если бы было всё так просто... начнём с того, что далеко не единственный — Вы видели схему развития, например, Cisco IOS (беря только популярные примеры)? Там не один код, там группа "трейнов" (trains — переводить как-то не хочется) разной направленности и устойчивости, и я сочувствую его разработчикам — переливать ченжсеты между различающимися ветками — занятие крайне чреватое. Далее, "верный" — тоже условно: любой баг уже сбивает его верность, в то время как внешняя документация может описывать, что код должен делать, а не что он делает в результате бага. Тут мне могут сразу возразить про тесты... если бы всё тестами можно было покрыть — это был бы идеальный проект.:) А совсем кошмарик хотите? Вычисления с матрицей с неустойчивым близким к нулю детерминантом и рядом коэффициентов, выбранных случайным образом (такое себе извращение на тему метода стрельбы, осложнённого методом Монте-Карло). Там по коду вообще ни один нормальный человек ничего не поймёт, всё только в документации, и тесты тоже построить невозможно — это тот случай, когда тестом является реальный запуск программы на полном наборе входных данных, и никакое предсказание не поможет (точнее, оно будет стоить столько же, сколько реальный запуск).
SD>В нем вполне нормально живут маркеры вида TODO. Кстати, тот же Eclipse их очень удобно поддерживает.
Ну так я всецело за эти маркеры, отличное средство, что бы там кому-то ни казалось.
Здравствуйте, 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>Вопрос: как у вас принято оформлять подобные куски кода?
"щас спою" (с)
Если чужой уровень ожидается до конца итерации и всё это разные части одного проекта — примерно(адаптируя на ваш случай) так:
public int getMaxItemCount() {
if (Mode.isMock()) {
return Integer.MAX_VALUE;
// after TRYAM-0:
// alienLayer.getMaxItemCount();
} else {
throw new UnsupportedOperationException("No functionality from Alien. See issue TRYAM-0 in the tracker");
}
}
Mode.isMocked() включается по проперти, например, и по умолчанию false.
т.к.:
1. вписывается в use case-ы: отказ alien layer-а по исключению все равно надо обрабатывать. В спеке(srs, истории, тест кейсе и тп), конечно, есть такое поведение.
2. при присутствии общего координации проекта ускоряет работу "чужих" из-за того, что чаще всего отказ обслуживания виден конечному пользователю — тестер/представитель заказчика видит почему фича не работает и кого надо пинать.
3. все такие места в коде находятся легко: в IDE достаточно поискать использование Mode.isMocked(). соответственно легко вычистить, соответственно легко посмотреть как (не) работает в продакшене.
4. если надо показать по любому (презентация, демо и тп. или тесты только на вашу часть) — мод меняется на mock.
5. удобнее отслеживать изменение состояния зависимости. Из-за 2.(отказ обслуживания виден пользователю) "alien" не забудет добавить фичу и скорее всего сам вам сообщит (его push вместо вашего poll), что фича добавлена.
Если чужой уровень когда-то(дата туманна и отдаленна) появится, нет общей координации проекта (т.е. "ускорения чужих" не будет ); если это новая версия библиотеки сторонней библиотеки, например, — тогда эта фича вычеркивается из списка поддерживаемых и код соответственно тоже убирается. Запрос на фичу "Появления в табличке max item" появляется в трекере(если его еще там нет) и линкуется на задачу "Переход на библиотеку МЕГА КРУТЬ 2.0" или "Выпуск версии XX командой YYY".
т.к.
1. прозрачно для заказчика.
— нет иллюзии, что фича работает, и прописано при каком условии она будет добавлена
2. порядка больше
— нет дефектов (типа "показываемый max item всегда равен Integer.MAX_ITEM"), которые относятся к запросам на фичу, которую вы не можете выполнить.
3. yagni.
— возможно в конце итерации заказчик захочет другого
Для отмечания неработающего кода в продакшене (ваш случай) //todo, по моему мнению, инструмент не очень.
Он не первичный — первичен либо список поддерживаемых фич, либо дефектов, а их лучше держать в одном месте... Если же все фичи или дефекты вы держите в todo тогда другое дело, конечно.
Опять же в случае интеграции с чем-то лучше потенциальные проблемы интеграции лучше обрабатывать максимально прозрачно для последующего (максимально прозрачного) поиска виноватых.
Здравствуйте, andy1618, Вы писали:
A>Впрочем, по данному конкретному примеру выше уже предложили подходящее решение — сделать reminder в виде валящегося юнит-теста.
Или вот ещё способ: еженочные билды. Неработающее приложение -- тоже неплохая напоминалка
Но всё-таки по-прежнему не кажется мне в принципе хорошей эта идея, воркароундить ошибки проектирования на более низком уровне. Приходилось уже сталкиваться с проектами, где такие TODO в конце концов релизились.
есть такое поведение.
