Home

Автор: Петтер Мален (Petter Måhlén)

Оригинал статьи: https://labs.spotify.com/2014/04/11/qualities-of-quality/

Перевод: Ольга Алифанова

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

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

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

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

Очень близкие по духу мысли: Martin Fowler’s Design Stamina Hypothesis,статья, которую вам стоит прочитать и осознать. Я не буду резюмировать ее здесь, просто прочитайте ее. Серьезно, прочитайте. Готово? Отлично, теперь потратьте 4,43 минуты на видео Ward Cunningham explaining (technical) debt. Даже если вы уже видели это видео раньше, вы не зря потратите время.

Каннингем говорит о том, что брать на себя технический долг – хорошая идея, если вы говорите "я недостаточно хорошо понимаю эту отрасль и поэтому не знаю, правильные ли фичи я делаю, и правильные ли абстракции я использую для этих фич". Первый тип долга – это то, о чем говорит Эрик Райс в Lean Startup-движении, и то, с чем мы боремся в Spotify мантрой Думай, Делай, Выпускай, Меняй. Второй тип долга – это то, что вы должны постоянно выплачивать, когда приобретаете нужное понимание своей отрасли. Плохо брать на себя технический долг, не следуя хорошим инженерным практикам и, например, не очищая свой код, когда он наконец заработал. Ваши абстракции должны быть просты для понимания, даже если они неверны. Выплата долга – это исправление вашего дизайна по мере того, как вы все лучше понимаете, каким он должен быть. Она не имеет отношения к исправлению багов или "спагетти-коду".

Две самых важных мысли, высказанных Фоулером, с моей точки зрения – это узкий интервал времени во время которого можно создать значимый компромисс между качеством дизайна/внедрения и скоростью, и как только вы миновали эту точку, вы больше не можете игнорировать качество внедрения, так как это замедлит вашу работу. Вы можете потерять в качестве внедрения ради скорости только в очень коротких проектах. Возможно, если вы ожидаете, что система проживет больше пары недель, неплохо бы обратить внимание на качество внедрения с самого начала развития проекта. Я полагаю, что тут есть исключения – к примеру, если вам кровь из носу нужно, чтобы эта фича вошла в релиз. Но в Spotify мы не боремся за жизнь, а выясняем, как сделать наилучший сервис по стримингу музыки в истории человечества. Это трудно, поэтому нам нужно убедиться, что мы можем быстро адаптировать наш продукт, и мы учимся это делать.

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

Пара замечаний про баги, которые я включил и в качество продукта, и в качество внедрения. С точки зрения продукта все очевидно – баги ухудшают пользовательский опыт, а вот с качеством внедрения все не настолько прозрачно. Первый аспект – это, конечно, то, что куда проще разрабатывать что-то, основанное на цельном компоненте, а не на библиотеке. Если сервисы и библиотеки лишены багов, куда проще убедиться, что пользовательский опыт будет положительным. Но есть и второй аспект. Баги снижают производительность множеством способов – тут подробнее об этом. Если кратко, неисправленные баги в вашем коде ведут к дополнительным встречам, работе по управлению багами, дублирующимся репортам по одним и тем же багам, и переключению контекста. Итак, в большинстве случаев лучшее, что вы можете сделать – это исправлять все, на что вам жалуются. Это также ведет к более позитивному пользовательскому опыту – приятный бонус!

Качество и его влияние на скорость релиза часто путают с подключаемостью, настраиваемостью, возможностью для расширения какого-либо технического решения. Эти вещи часто называют овер-инжинирингом. Для меня овер-инжиниринг – это инженеры, добавляющие мусорные фичи, которые никому не нужны. Известный отчет 2002 года Стэндиш Груп про использование фич заключил, что 64% продуктовых фичей практически никогда не используются. Учитывая,что фичи взаимодействуют таким образом, что код становится менее гибким, лучшее, что вы можете сделать, чтобы повысить производительность своей команды – это внимательно рассматривать каждую фичу, которая заходит в продукт, над которым вы работаете. Особенно если автор этой фичи – вы сами. В Spotify продакт-оунеры следят за своей тенденцией раздувать масштабы благодаря "Think It", но никто в общем-то не проверяет, ограничиваем ли мы, разработчики, себя, когда пишем код. Овер-инжиниринг – это не создание чего-то очень качественного с точки зрения внедрения, это создание чего-то со слишком большим количеством фич. Я занимаюсь разработкой почти двадцать лет, и не думаю, что когда-либо сталкивался с командой, которая серьезно задумывалась бы о качестве внедрения, но я множество раз попадал в ситуации, когда мы тратили кучу времени на ту или иную фичу.

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

• Безжалостно сокращать количество фич, и
• Всегда обращать пристальное внимание на качество внедрения – но если нужен компромисс ради качества продукта, идите на него.

Обсудить в форуме