^Заставляет задуматься to/S, как мы привыкли обходиться^ без ммкрпгррймгпй Как нам далось? Поверь / commitstrip :: Смешные комиксы (веб-комиксы с юмором и их переводы)

дед кабриолет дед кабриолет
commitstrip Комиксы 
^Заставляет задуматься to/S, как мы привыкли обходиться^ без ммкрпгррймгпй Как нам далось? Поверь мне, TDD реально изменит всё. Это изменит всё! vk.com/commitstrip 1—Не нужно ждать ^ использования ES6 ^всё готово сейчас' Всё готово |/\_ сейчас! ^ ДП1 В ч п 1,commitstrip,Смешные
Подробнее
^Заставляет задуматься to/S, как мы привыкли обходиться^ без ммкрпгррймгпй Как нам далось? Поверь мне, TDD реально изменит всё. Это изменит всё! vk.com/commitstrip 1—Не нужно ждать ^ использования ES6 ^всё готово сейчас' Всё готово |/\_ сейчас! ^ ДП1 В ч п 1
commitstrip,Смешные комиксы,веб-комиксы с юмором и их переводы
Еще на тему
commitstrip

commitstrip(387)

Смешные комиксы

Смешные комиксы(173351)

Развернуть
Комментарии 24 17.08.201602:07 ссылка 8.8
Какой то профессиональный юмор?
WRZESZCZ WRZESZCZ 17.08.201602:46 ответить ссылка 3.3
Test Driven Development - одна из идеологий разработки решений экстремального прогрвммирования. Грубо говоря, это когда требования пишутся через ряд тестов, которые решение должны выполниться успешно.

Я это так понимаю, но лучше взгляни на Вики. Там лучше описано.

https://en.m.wikipedia.org/wiki/Test-driven_development
ALD960 ALD960 17.08.201602:56 ответить ссылка ↑ 1.5
Википедия как то странно выглядит...
WRZESZCZ WRZESZCZ 17.08.201603:04 ответить ссылка ↑ 0.5
Видимо, товарищ с мобильника отвечал, линк на мобильную версию вики.
Оно же для десктопа: https://en.wikipedia.org/wiki/Test-driven_development
ValD ValD 17.08.201603:28 ответить ссылка ↑ 0.0
Оно же для десктопа, но по русски: https://ru.wikipedia.org/wiki/Разработка_через_тестирование
kain_pl kain_pl 17.08.201610:07 ответить ссылка ↑ 0.1
Да, про манагеров, которым сначала на конференциях ездят по ушам про всякие "модные тенденции", а потом они старательно мешают работать разработчикам, пытаясь эти "сакральные знания" воплотить.
ValD ValD 17.08.201602:57 ответить ссылка ↑ 8.5
Новомодные методологии не всегда зло, если 7 раз подумать над рациональностью их использования в текущем проекте учитывая сроки. А другая крайность - это Huyak-huyak driven development, что вполне может прокатить на малых проектах.
Gyromitra Gyromitra 17.08.201603:57 ответить ссылка ↑ 1.3
коней на переправе не меняют. ТЗ -> созтавления плана действия -> естимейт (оценки сроков) -> согласование с заказчиком -> выполнение. Вклинивать нововведение на последнем пункте, это по сути откат ко второму. И чем больше работы уже сделано, тем больнее будет внедрятся изменение.
Wolfdp Wolfdp 17.08.201605:03 ответить ссылка ↑ 2.0
Иногда стоит выбор: каким-то образом долго и муторно адаптировать легаси-код с его метастазами по всему проекту, написанный студентом в девяностых, либо по-быстрому переписать велосипед с учётом новых стандартов/использовать готовую проверенную 7 раз либу. Так что иногда действительно проще "переделать всё".
Gyromitra Gyromitra 17.08.201605:24 ответить ссылка ↑ -0.2
Да но решение переделывать всё принимается не во время выполнения, а во время составления плана. И если уж на этом моменте решили не переделывать, то лучше, как сказали выше, "не менять коней на переправе". Конечно всякое бывает, но если вам пришлось переделывать, то ошибки вы допустили на предыдущих этапах.
Romin Romin 17.08.201607:51 ответить ссылка ↑ 0.9
я, конечно, не настаиваю, но более жизненный вариант:

согласование с заказчиком -> естимейт (оценки сроков) -> соcтавление плана действия -> ТЗ -> выполнение
Uberzaetc Uberzaetc 17.08.201607:55 ответить ссылка ↑ -0.2
А что ты будешь согласовывать с заказчиком не имея ТЗ?
У тебя получается следующее:
З. У меня для вас работа, плачу n-денег
И. За неделю сделаем
И. надо подумать как потратить деньги
З. Напишите мне винду
И. совершает суицид
radteh radteh 17.08.201608:20 ответить ссылка ↑ 1.6
И. выкатывает болгенос, все довольны, хэпи энд ^_^
villy villy 17.08.201609:09 ответить ссылка ↑ 0.5
Просто ВольфДП имел в виду ТЗ как набор запросов заказчика, а УберЗаец - ТЗ как формальный документ в ворде.
achiatma achiatma 17.08.201610:35 ответить ссылка ↑ 0.0
А это очень просто. Заказчик думает, что представляет конечный результат, но на самом деле совершенно его не представляет. Манагер хочет продать товар и согласен на любой бред, что несет заказчик. Пишется какое-то совершенно формальное и идиотское ТЗ. В процессе реализации этого ТЗ начинают всплывать нюансы, заказчик начинает объяснять, что когда он говорил про теплые котлеты, то имел в виду плавленный сыр. А дальше начинаются свистопляски из компромиссов и костылей. А потом манагеры говорят, что подогнали крутого клиента, а инженеры опять все обосрали.
Я такой геморрой часто вижу, слава богу сам в него редко вляпываюсь. Некоторые на нем учатся, некоторые не учатся, а некоторые, бля, ставят в пример со словами "но вот раньше ж все-таки что-то ж вышло. Можно так же херово все организовать и в этот раз".
kerno kerno 17.08.201614:34 ответить ссылка ↑ 0.6
Обожаю эти истории про "манагеров". Хотя, может просто везло работать с нормальными ПМами... Если мне придут и скажут "хочу котлет", я задам уточняющие вопросы, плана "сколько и из какого мяса", озвучу сколько будет стоить игредиенты и займет готовка, и по отмашке буду лепить.

Если я вижу что ТЗ не дружит с логикой, аля "хочу котлеты из салата и огурцов", то озвучиваю это и отказываюсь реализовывать, пока мне не предоставят хотябы рецепт готовки. И естественно, при несогласованности ТЗ с заказчиком и девелоперами, прилетает как раз ПроджектМенеджеру.
Wolfdp Wolfdp 17.08.201621:43 ответить ссылка ↑ 0.0
согласовывать буду мутные фантазии заказчика. потому что заказчик, приходящий с готовым ТЗ - это что-то из области влажных фантазий теоретиков

впрочем, я уже понял, что таким как я здесь не рады
Uberzaetc Uberzaetc 17.08.201615:51 ответить ссылка ↑ 0.2
ТЗ -- по сути стартовая точка в изготовлении продукта (в нашем случае -- программы). Он может правится во время любого следующего этапа, по согласованию, в случае выявления тех или иных ньюансов/проблем/изменений. Составить исключительное ТЗ на старте, естественно из области фантастики. Плюс как правило прилетаю изменения от самих заказчиков. Но они не вклинивают с ходу, а обсуждаются с девами/тестерами, подводится итог насколько меняется истемейт/стоимость, озвучивается заказчику и только тогда(!) меняют план выполнения. До этого что-то менять в плане нельзя.

Если нет составленого задания, то как ты постоишь план действий? Как будешь подбирать используемые технологии, если даже не знаешь требований логики? Как будешь подбирать технологии?

Максимум что можно оттянуть по работе с ТЗ до последнего (а как правило этого вообще не делают) -- составление и оформление выходной документации. В жизни почему-то есть куча email-переписки, тикеты в jira, а вот единый документ по программе (с подробным описанием функционала и требований) я почему-то видел только на одном проекте.
Wolfdp Wolfdp 17.08.201621:34 ответить ссылка ↑ 0.0
Для этого существует несколько уровней плана. Действительно, составить план для тимы без ТЗ не получится. Я говорил про более общее планирование, уровня всего проекта. А ТЗ - это уже детализация. И, в идеале, все изменения в него должны проходить через процедуру контроля изменений. В реальности, конечно, дописывают по ходу процесса, а окончательное ТЗ, описывающее получившийся продукт, получается в самом конце.
В случае с контролем версий - точно, обычно - как повезет.
Я чувствую, что мы с вами по основным моментам имеем схожий опыт и понимание, будь эта беседа за кружкой - уже давно бы пришли к консенсусу :)
Uberzaetc Uberzaetc 17.08.201621:46 ответить ссылка ↑ 0.0
Ну, это, вроде, только waterfall, есть и другие методологии. Но сути это не меняет - переделывать все всегда дорого и (почти?) всегда не оправдано.
artyhedgehog artyhedgehog 19.08.201601:27 ответить ссылка ↑ 0.0
Та епт. К каждому новому выпуску этот коментарий. Хоть тег такой добавляй.
Torrion Torrion 17.08.201609:22 ответить ссылка ↑ 1.0
В этом комикс в основном профессиональный юмор.
Unholysvesh Unholysvesh 31.08.201611:57 ответить ссылка ↑ 0.0
это джун?
villy villy 17.08.201609:06 ответить ссылка 0.0
это PM
undersun undersun 17.08.201613:25 ответить ссылка ↑ 0.0
Только зарегистрированные и активированные пользователи могут добавлять комментарии.
Похожие темы
программист

программист

перевел сам

перевел сам

artist

artist


Тренды

лето
Похожие посты
ТАК, ЧТО ТАМ У НАС ТВОРИТСЯ В ЗАХВАТЫВАЮЩЕМ МИРЕ ВЕБ-КОМИКСОВ?.. £91 ^ С. У Д и у \ /1 / ОЛИН ЧЕЛОВЕК РОПСЕНШТИЛЬС/ Я, КАЖЕТСЯ, ПОЗНАЛ ТЩЕТУ БЫТИЯ. ПИСТОЛЕТ В СЛИВНОМ _БАЧКЕ.
подробнее»

Смешные комиксы,веб-комиксы с юмором и их переводы ропсенштильс и шизнагсингерзуппе вебкомиксы

ТАК, ЧТО ТАМ У НАС ТВОРИТСЯ В ЗАХВАТЫВАЮЩЕМ МИРЕ ВЕБ-КОМИКСОВ?.. £91 ^ С. У Д и у \ /1 / ОЛИН ЧЕЛОВЕК РОПСЕНШТИЛЬС/ Я, КАЖЕТСЯ, ПОЗНАЛ ТЩЕТУ БЫТИЯ. ПИСТОЛЕТ В СЛИВНОМ _БАЧКЕ.
vk.com/commitstrip GomwitStrip.cow vk.com/mixpixin Яви нам свой дух. пролей на нас свет, помоги нам найти логи сессии Докера, так как мы их проебали... CommitStrip.com
подробнее»

commitstrip Смешные комиксы,веб-комиксы с юмором и их переводы

vk.com/mixpixin Яви нам свой дух. пролей на нас свет, помоги нам найти логи сессии Докера, так как мы их проебали... CommitStrip.com
В общем, я переустановил вам \Vindows. Установил 26 драйверов пакет программ «Премиум» и антивирус на 3 года. _____ V Что??? Пятьдесят тысяч??? По пятьсот за драйвер? Так дорого? И какое еще сохранение данных за тридцать тысяч? В сё же и так было на месте! Спасибо! Не думал что у меня такая была
подробнее»

commitstrip Смешные комиксы,веб-комиксы с юмором и их переводы it-юмор

В общем, я переустановил вам \Vindows. Установил 26 драйверов пакет программ «Премиум» и антивирус на 3 года. _____ V Что??? Пятьдесят тысяч??? По пятьсот за драйвер? Так дорого? И какое еще сохранение данных за тридцать тысяч? В сё же и так было на месте! Спасибо! Не думал что у меня такая была