Выводы Уотса Хамфри
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-03 22:27 (UTC)к счастью, не единственная
например, код любой достаточно большой системы со временем становится настолько сложным, что его невозможно поддерживать - и скорость этого процесса зависит от качества архитектуры в первую очередь