Выводы Уотса Хамфри
2019-10-03 08:46![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vak- Единственно полезный взгляд на процесс разработки - оный процесс это цепочка фильтров по вылову ошибок. Если фильтр работает плохо - мы его убираем. Если в процессе возникают задержки, увеличивающие время жизни ошибок - мы их убираем. ??? PROFIT!!!
- Дизайн и код ревью полезны в единственном случае - если они находят реальные ошибки сильно раньше, чем их найдет тест. Если ваши ревью ошибок не находят - то это срань а не ревью и их надо отменять.
- Плотность внесения ошибок программистом на тысячу строк кода, как и аналитиком на страницу документа - постоянны для отдельного человека, и требовать от них "не ошибаться" (допуская, что они честно стараются делать свою работу хорошо) бесполезно. Надо строить процесс так, чтобы он эти ошибки как можно раньше ловил, а не истерить.
- В частности, "традиционный" конвейер с отделами "анализ", "программисты", "тестировщики" - это сраный пиздец драматически увеличивающий среднее время жизни ошибки. Врата ада раскрываются, если добавить к этому "отдел архитектуры". Эта структура складывается сама собой по мере естественного роста организации. Выжигать каленым железом.
- Не надо делать "гранд дизайн" в начале, пытаясь заранее продумать до мелочей то, что мы слабо себе представляем - тем самым мы увеличиваем время обнаружения ошибок дизайна и их количество.
- Не надо писать код "впрок", если мы не собираемся немедленно его проверять и использовать.
- Начинать с простого, и рефакторить, усложняя дизайн по мере необходимости - это хорошо, мы не пишем впрок код которым будем пользоваться сильно потом. Фантазировать - плохо.
- Прототипы proof of the concept для проверки дизайна - это хорошо - помогает найти ошибки раньше.
- Хорошо - это когда в плане задач или потоке работ следующая сразу полагается на результаты предыдущей в полном объеме, это сокращает "время жизни" ошибок.
- Ошибки интеграции дорогие, и именно поэтому план должен быть устроен так, чтобы выйти на интеграцию как можно раньше, пусть и с частичной функциональностью.
(https://www.facebook.com/100000008953278/posts/2729618327048439)
- Дизайн и код ревью полезны в единственном случае - если они находят реальные ошибки сильно раньше, чем их найдет тест. Если ваши ревью ошибок не находят - то это срань а не ревью и их надо отменять.
- Плотность внесения ошибок программистом на тысячу строк кода, как и аналитиком на страницу документа - постоянны для отдельного человека, и требовать от них "не ошибаться" (допуская, что они честно стараются делать свою работу хорошо) бесполезно. Надо строить процесс так, чтобы он эти ошибки как можно раньше ловил, а не истерить.
- В частности, "традиционный" конвейер с отделами "анализ", "программисты", "тестировщики" - это сраный пиздец драматически увеличивающий среднее время жизни ошибки. Врата ада раскрываются, если добавить к этому "отдел архитектуры". Эта структура складывается сама собой по мере естественного роста организации. Выжигать каленым железом.
- Не надо делать "гранд дизайн" в начале, пытаясь заранее продумать до мелочей то, что мы слабо себе представляем - тем самым мы увеличиваем время обнаружения ошибок дизайна и их количество.
- Не надо писать код "впрок", если мы не собираемся немедленно его проверять и использовать.
- Начинать с простого, и рефакторить, усложняя дизайн по мере необходимости - это хорошо, мы не пишем впрок код которым будем пользоваться сильно потом. Фантазировать - плохо.
- Прототипы proof of the concept для проверки дизайна - это хорошо - помогает найти ошибки раньше.
- Хорошо - это когда в плане задач или потоке работ следующая сразу полагается на результаты предыдущей в полном объеме, это сокращает "время жизни" ошибок.
- Ошибки интеграции дорогие, и именно поэтому план должен быть устроен так, чтобы выйти на интеграцию как можно раньше, пусть и с частичной функциональностью.
(https://www.facebook.com/100000008953278/posts/2729618327048439)
no subject
Date: 2019-10-04 11:20 (UTC)Странно видеть условие в будущем времени в тексте, смысл которого в том, что мы не знаем будущего.
Real systems have no top. Если вершина и есть, ее не видно. Формально описывать неописанные сущности полезно. Целенаправленно избегать описания - это не думать о белой обезьяне.
Неиспользуемый код удаляется из бинарных модулей множеством тривиальных способов, не требующих внимания, и как минимум несколькими требующими минимального.
Писать код, забегая вперед, - это не менее продуктивно потраченное время, чем поедание шоколада в кафетерии.
(Съеденный шоколад, конечно, не предъявляется заказчику.)