Выводы Уотса Хамфри

[vak]

- Единственно полезный взгляд на процесс разработки - оный процесс это цепочка фильтров по вылову ошибок. Если фильтр работает плохо - мы его убираем. Если в процессе возникают задержки, увеличивающие время жизни ошибок - мы их убираем. ??? PROFIT!!!
- Дизайн и код ревью полезны в единственном случае - если они находят реальные ошибки сильно раньше, чем их найдет тест. Если ваши ревью ошибок не находят - то это срань а не ревью и их надо отменять.
- Плотность внесения ошибок программистом на тысячу строк кода, как и аналитиком на страницу документа - постоянны для отдельного человека, и требовать от них "не ошибаться" (допуская, что они честно стараются делать свою работу хорошо) бесполезно. Надо строить процесс так, чтобы он эти ошибки как можно раньше ловил, а не истерить.
- В частности, "традиционный" конвейер с отделами "анализ", "программисты", "тестировщики" - это сраный пиздец драматически увеличивающий среднее время жизни ошибки. Врата ада раскрываются, если добавить к этому "отдел архитектуры". Эта структура складывается сама собой по мере естественного роста организации. Выжигать каленым железом.
- Не надо делать "гранд дизайн" в начале, пытаясь заранее продумать до мелочей то, что мы слабо себе представляем - тем самым мы увеличиваем время обнаружения ошибок дизайна и их количество.
- Не надо писать код "впрок", если мы не собираемся немедленно его проверять и использовать.
- Начинать с простого, и рефакторить, усложняя дизайн по мере необходимости - это хорошо, мы не пишем впрок код которым будем пользоваться сильно потом. Фантазировать - плохо.
- Прототипы proof of the concept для проверки дизайна - это хорошо - помогает найти ошибки раньше.
- Хорошо - это когда в плане задач или потоке работ следующая сразу полагается на результаты предыдущей в полном объеме, это сокращает "время жизни" ошибок.
- Ошибки интеграции дорогие, и именно поэтому план должен быть устроен так, чтобы выйти на интеграцию как можно раньше, пусть и с частичной функциональностью.

(https://www.facebook.com/100000008953278/posts/2729618327048439)

Comments

[juan_gandhi]

Гениально насчет роли конвейера в удлинении срока жизни ошибок.

Насчет ревью тоже красиво. И рефакторинга, от простого к большому.

[vit_r]

Увы, но в правильной реализации это никогда не было конвейером, так что в основе открытия лежит лажа.

[bowhill]

А концепцию безошибочной фигни он не рассматривает? Зря.

Вообще продукт и его разработка — совсем не только проблема багов. Хотя с некоторых точек зрения это может выглядеть и так.

[vak]

Да откуда бы в программировании взялась безошибочная фигня.

[bowhill]

Фигни хватает, осталось сделать её безошибочной.

[brmail]

да запросто, особо индусы любят - идет код, обернутый в трай-кетч, и по случаю ошибки он ничего никому не говорит. Хорошо если вернет Null вместо значения, его потом поймать можно, а уж когда возвращается пустой объект, вместо того же объекта, но с данными... Причем не всегда, а только когда "ну не шмогла", причем "не шмогла" происходит не часто, но обязательно случится после отправки в продакшен

[vit_r]

Я практически это и написал - автор меня забанил.

[bowhill]

Кто забанил, Хамфри или автор интерпретации? Первым вариантом можно гордиться.

[vit_r]

Автор изложения. Гуры обычно циничны и не на публику выдают вполне адекватные вещи.

[fenikso]

Позвольте, но куда тогда деть всех этих людей? :)))

[norian]

что самое главное быстро ловить баги - это точка зрения кюэйев

к счастью, не единственная

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

[lxe]

если мы не собираемся... использовать

Странно видеть условие в будущем времени в тексте, смысл которого в том, что мы не знаем будущего.

Real systems have no top. Если вершина и есть, ее не видно. Формально описывать неописанные сущности полезно. Целенаправленно избегать описания - это не думать о белой обезьяне.
Неиспользуемый код удаляется из бинарных модулей множеством тривиальных способов, не требующих внимания, и как минимум несколькими требующими минимального.

Писать код, забегая вперед, - это не менее продуктивно потраченное время, чем поедание шоколада в кафетерии.
(Съеденный шоколад, конечно, не предъявляется заказчику.)