Kaizen epic fail. Или как научиться доводить вещи до конца.

[9zloy]

Читал хабр и немного думал. Вот наткнулся на хорошую цитату:

"использование таких библиотек, как Hiberante, например, сильно увеличивает разрушительный потенциал одного разработчика"

Почему хорошую? Потому что ее правдивость доказана практикой. Мы используем NHibernate, ASP.NET и JavaScript. О, это убойная смесь опасных технологий! Особенно когда с помощью ASP.NET в страницу фигячат 50 килобайт ненужного яваскрипта.

5 месяцев назад

Вот были у нас проблемы с производительностью системы месяцев 5 назад. Кастомеры жалуются. Проверили - да, есть проблемы. Полезли изучать. С нескрываемым удивлением обнаружили следующие факты:

Размер страницы (только HTML кода!) обычного листа составлял 400 Кб. Тогда как в далекие благодатные времена он был 120 Кб.
Количество запросов к базе данных перевалило за 100 (на одну сессию). Тогда как в далекие яркие времена их было около 30.

Ну хорошо. HTML почистили, стало 200 Кб вместо 400. И запросов стало 60 вместо 100. Улучшилась производительность. Кастомеры вздохнули с облегчением. А команда провела собрание, на котором ввиду явного присутствия человеческого фактора постановили:

1. Сделать наконец нормальные автоматические перфоманс-тесты, которые будут запускаться каждый день, а не когда отдельно попросишь специального человека.
2. Сделать автоматические тесты на размер страниц, чтобы сразу видеть увеличение оного.
3. Сделать автоматические тесты на количество запросов к базе, чтобы говорить "а-та-та!" разработчикам за бездумное обращение со святым хранилищем.

Весьма здравые вещи. Каков же был результат данных постановлений?

4 месяца назад

Автоматические тесты на перфоманс были написаны, благополучно подключены к круиз контролю и запускались каждый день. Результаты складывались в тайную базу, URL которой знал только один посвященный, а остальным до него не было дела. Постепенно  в тестах что-то сломалось и запускаться каждый день они перестали.

Тест на размер страниц решили не делать, ибо понадеялись на пункт 1. Да и сказали что сложно это, и не надо особо.

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

Это результат промежуточный. А вот результат конечный.

Наши дни

Пару недель назад опять кастомеры недовольны стали. Говорят что-то у вас в последнем релизе все так медленно, что даже не с руки системой пользоваться. И опять мы расчехлили тяжелые орудия и полезли в код. И что же мы обнаружили с чуть более чем нескрываемым изумлением?

Размер страницы 350 Кб. Количество запросов в базу под 90.

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

Очевидно, на перфоманс никому не пофиг. Все его хотят. И хотят его быстрым. Но хотят не настолько, чтобы тратить свое драгоценное время на проверку собственного кода. "Мой код не может быть медленным/плохим/некрасивым" (нужное подчеркнуть) - так говорят все плохие программисты. Плохих у нас нет (я надеюсь). Следовательно, их код может быть медленным. Они это знают, но сами это не проверяют. Это и понятно, потому как скучно и лень. Но мы же запланировали сделать ав-то-ма-ти-чес-ку-ю проверку. Это значит что сделать надо один раз, а потому тихо следить за тестами. Не сделали. Не довели до конца.

Так вот мне что интересно.

1. Почему не довели до конца?
2. Как сделать так, чтобы до конца доводилось в будущем.

Идеи? Предложения? Пожелания? Помидоры в автора? Сахарок в кофе?

P.S. Идеи есть у меня, но хотелось бы высказать их, участвуя в дискуссии на заданную тему.