Настоящий Agile

[Мальчик-Одуванчик]

Во многих этих методиках есть зерно здравого смысла. Но иногда просто включить мозг бывает более чем достаточно.

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

Но и на стандартных юнит-тестах это тоже не особо проявляется. Например как TDD помогает бороться с утечками памяти?

[Мальчик-Одуванчик]

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

TDD не заставляет вас сначала написать 100% тестов для всех, предполагаемых API, реализуемых системой. TDD предполагает что вы просто сначала пишете тест, потом код.

Это тоже неверное, на мой взгляД, рассуждение, как и сама парадигма TDD утверждающая что сначала тест должен быть написан дубовый код, на котором тест падает и лишь потом исправлен на его правильное прохождение. Что справедливо когда тест на порядок проще самого кода и никак не учитывает что к такого рода тестам подсознательно программист относится с на порядок же большей неьрежностью. Рефакторинг кода, особенно с использованием темплейтов и их специализаций такой подход покрывает слабо, а на тестировании параллельных процессов, работы под нагрузкой или обработке нештатных ситуаций вообще слабо применим в силу того что сложность самих тестов здесь часто оказаться выше тестируемого кода.
Но здравая идея имеется - заранее, перед написанием кода следует детально продумать как его будет нужно будет тестировать.

[se888]

Но и на стандартных юнит-тестах это тоже не особо проявляется. Например как TDD помогает бороться с утечками памяти?

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

[se888]

Это тоже неверное, на мой взгляД, рассуждение, как и сама парадигма TDD утверждающая что сначала тест должен быть написан дубовый код, на котором тест падает и лишь потом исправлен на его правильное прохождение. Что справедливо когда тест на порядок проще самого кода и никак не учитывает что к такого рода тестам подсознательно программист относится с на порядок же большей неьрежностью. Рефакторинг кода, особенно с использованием темплейтов и их специализаций такой подход покрывает слабо, а на тестировании параллельных процессов, работы под нагрузкой или обработке нештатных ситуаций вообще слабо применим в силу того что сложность самих тестов здесь часто оказаться выше тестируемого кода.
Но здравая идея имеется - заранее, перед написанием кода следует детально продумать как его будет нужно будет тестировать.

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

[mister-X]

Agile, нужен ли девелору? а теории может быть. На практике когда на 4 девелопера наняли 4 тестера, 3 бизнес аналиста, теам ледера, прожект ледера, скрам мастера и 2 химиков как саппорт . За 2 месяца написали 30 сториес типа ' хочу красивую табличку в IE'. а теперь 2 недели разбираемся как стори поинтс в жире посчитать . Никакого дезайна, и некто не знает что дальше? Зато стендап каждый день. Очень это похоже на тот анекдот про бардель где кровати переставляют вместо того чтобы бля...й поменять.

Sent from my SM-G950U using Tapatalk

[se888]

Agile, нужен ли девелору? а теории может быть. На практике когда на 4 девелопера наняли 4 тестера, 3 бизнес аналиста, теам ледера, прожект ледера, скрам мастера и 2 химиков как саппорт . За 2 месяца написали 30 сториес типа ' хочу красивую табличку в IE'. а теперь 2 недели разбираемся как стори поинтс в жире посчитать . Никакого дезайна, и некто не знает что дальше? Зато стендап каждый день. Очень это похоже на тот анекдот про бардель где кровати переставляют вместо того чтобы бля...й поменять.

Sent from my SM-G950U using Tapatalk

Я уже писал выше что ритуалы типа стендапа и артефакты типа стори поинтов это все фуфло. На деле, главным образом работают всего две практики. TDD и pair programming. Это мой личный опыт, как собственника компании (который одновременно и программист), который просрал некую сумму собственных денег на разработке. Спорить и убеждать никого не хочу, лень мне банально. Ветку я стартанул, потому что хотел узнать широко ли практикуют то, что мне близко и интересно в Америках. Оказалось что тоже не очень.

[uncle_Pasha]

Т.е. сама Jira тут ни при чем. Это как ругать плюсы за то, что на них написали Винду.

классическая винда была написана на просто С

Не придирайтесь, лучше дайте определение "классической" винды. Просто интересно.

[Komissar]

Я уже писал выше что ритуалы типа стендапа и артефакты типа стори поинтов это все фуфло. На деле, главным образом работают всего две практики. TDD и pair programming.

Это тоже фуфло. Реально, нужно (1) грамотно составленное ТЗ и (2) вменяемая команда. А уж будут они совокупляться парами, триадами или корпеть над кодом в одиночку - это уже очень второстепенные детали. И будет ли писаться тест или код вперед - тоже фигня.

[alex_127]

Во многих этих методиках есть зерно здравого смысла. Но иногда просто включить мозг бывает более чем достаточно.

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

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

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

Знаете, сколько в свое время Майкрософт потратил на создание Help файлов для Оффиса? А когда вы последний раз читали Хелп для Ворда? (истинный хелп файл, а не погуглить). Так же и с ТДД. Много усилий, редко пригождается.

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

[Komissar]

Не верю короче.

Вы не верите, что у Ворда/Экселя/Пауерпоинта/Аксесса был и есть очень развесистый хелп файл (у каждой аппы плюс интеграции)?!

[alex_127]

Я говорю что это ничего не стоило по сравнению с ман-дев-годами основного продукта и спрашиваю откуда вы это взяли. Ткните в меня ссылкой.

[Komissar]

Я говорю что это ничего не стоило по сравнению с ман-дев-годами основного продукта и спрашиваю откуда вы это взяли. Ткните в меня ссылкой.

"И Вы говорите"(с).

У меня сведения из первых рук, лично. От команд, работавших над оффисными продуктами с начала 90х. Если вы лично не досчитались персонала, то "ткните в меня сцылкой".

[se888]

Это тоже фуфло. Реально, нужно (1) грамотно составленное ТЗ и (2) вменяемая команда. А уж будут они совокупляться парами, триадами или корпеть над кодом в одиночку - это уже очень второстепенные детали. И будет ли писаться тест или код вперед - тоже фигня.

Вы всегда работаете по "грамотно составленному ТЗ"? И заказчик никогда не вносит в него изменения по ходу разработки? На весь проект, какого бы масштаба он ни был вам всегда выдают ТЗ?

[Komissar]

Это тоже фуфло. Реально, нужно (1) грамотно составленное ТЗ и (2) вменяемая команда. А уж будут они совокупляться парами, триадами или корпеть над кодом в одиночку - это уже очень второстепенные детали. И будет ли писаться тест или код вперед - тоже фигня.

Вы всегда работаете по "грамотно составленному ТЗ"? И заказчик никогда не вносит в него изменения по ходу разработки? На весь проект, какого бы масштаба он ни был вам всегда выдают ТЗ?

я нигде не сказал, что (а) это неизменяемое ТЗ и (б) это одним махом ТЗ на весь проект. Но грамотное ТЗ маст би.Иначе все уйдет в пляски - стендапы, скрамы, спринты, тдд, программирование коллективами и т.д.

[alex_127]

Я говорю что это ничего не стоило по сравнению с ман-дев-годами основного продукта и спрашиваю откуда вы это взяли. Ткните в меня ссылкой.

"И Вы говорите"(с).

У меня сведения из первых рук, лично. От команд, работавших над оффисными продуктами с начала 90х. Если вы лично не досчитались персонала, то "ткните в меня сцылкой".

Так я как бы в мсфт тоже сидел лично в конце 90х. Не в офисе - но аппы с хелпами которые с виндой шли.