[Перевод] Эпистемология качества программного обеспечения
Допустим, вы приняли руководство новой командой. У вас есть картбланш на внедрение любой выбранной вами политики, чтобы сделать работу сотрудников более продуктивной, а код — менее «глючным». Что же вы предпримете?
На продаже ответа на этот вопрос сделана не одна карьера. Внедрите парное программирование! Перейдите на Haskell! Используйте UML для всего на свете! Этим технологиям посвящают книги и конференции — при этом нет уверенности, стоят ли они затраченных усилий, как скоро дадут эффект и работают ли они вообще.
Исследования показывают, что на качество нашей работы в наибольшей степени влияет человеческий фактор. Почему же мы делаем такую большую ставку на технические решения? Об этом в своей колонке рассуждает Гиллель Уэйн*, консультант по формальной верификации и автор книги Practical TLA+. Под катом — наш перевод авторского материала.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
В программной инженерии бывает непросто определить, что именно решит наши проблемы. Можно поговорить с экспертами, но эксперты расходятся во мнениях. Можно положиться на собственный опыт, но он ограничен. (Никто не пробовал всё и не сравнивал всё со всем.) Можно опросить людей, но «популярность» — это не то же самое, что «правильность». (Почти половина американцев считает астрологию наукой.) Так откуда же мы можем узнать, что мы в действительности знаем?
Надеюсь, что по мере развития этой области научное изучение и эмпирические исследования в конечном итоге заменят фольклор. Хотя мы все еще находимся на ранней стадии развития программной инженерии (по сравнению, скажем, с машиностроением), лишь немногие из изученных нами технических решений оказывают значимое влияние на качество программного обеспечения. Статическая типизация? Одно из исследований, представленных на FSE 2014, указывает, что доказательств пользы или вреда от статической типизации не найдено. Стандарты кодирования и линтеры? В другом документе, опубликованном на ICSM 2008, говорится, что это может принести вред. Ревизия кода (code review)? Да, согласно статье 2016 года, опубликованной в журнале Empirical Software Engineering, это действительно работает. Но мы не можем ставить успех своей команды в зависимость лишь от «увеличения количества ревизий кода».
Я твердо убежден, что технические решения действительно помогают. Но мы часто рассматриваем выбор технических инструментов и процессов как критическое решение, которое создает или разрушает коллектив. Известные представители отрасли могут утверждать, что Lisp — это «секретное оружие», что пользователи Python «неэтичны» или что необходимо использовать TDD, чтобы быть «профессионалом». Но если бы эти технические решения имели такое большое значение, разве это на нашло бы своего отражения в исследованиях? Вместо этого мы видим незначительный или условный эффект в некоторых ситуациях и не видим существенного эффекта ни в одной из них. Технические решения — это не то, за что стоит отдать жизнь.
Это еще не все плохие новости. Эмпирические данные постоянно показывают, что некоторые факторы действительно имеют значение — это те факторы, которые не только существенно влияют на качество кода, но и на нас самих. Нам нужно лишь расширить свои представления о том, что действительно важно при создании программного обеспечения. Вместо технических факторов мы должны говорить о человеческих.
Сколько вы спите в течение ночи? Когда вы в последний раз работали более 40 часов в неделю? Счастливы ли вы на своей работе? Именно эти вопросы больше всего влияют на качество программного обеспечения. Исследования в различных дисциплинах постоянно показывают, что разница между техническими и человеческими решениями — это разница между результатами их применения. В первом случае исследования утверждают: «Мы предполагаем, что есть небольшое влияние», а во втором: «Мы уверены, что есть значительная разница». Эти выводы вполне логичны: программирование — это результат работы нашего разума, и все, что ставит под угрозу наш разум, будет вредить нашим навыкам программирования.
Так что же это за доказательства? Я рад, что вы спросили. Наиболее четко зафиксированные факторы — это сон, рабочее время и стресс. Вот лишь некоторые из множества различных исследований.
Сон
Существует два вида недосыпания. Под бессонницей мы часто подразумеваем острую депривацию сна (acute sleep deprivation, ASD): это бодрствование в течение 24 часов и более. Большинство людей уже знают, что это плохо. Начинающие программисты, согласно исследованию 2018 года, опубликованному в IEEE Transactions on Software Engineering, теряют большинство своих навыков, испытывая ASD, и мы можем с полным основанием предположить, что старшие разработчики — иными словами, другие люди — также не застрахованы от этого. По данным статьи, опубликованной в 2007 г. в журнале «Neuropsychiatric Disease and Treatment» («Нейропсихиатрические заболевания и лечение»), ASD также влияет на способность принимать решения и на состояние здоровья в долгосрочной перспективе.
Более тонкой проблемой является хроническое недосыпание (chronic sleep deprivation, CSD) — недостаточная продолжительность сна в течение нескольких ночей подряд. В статье 2007 года показано, что CSD снижает умственную работоспособность по всем показателям. Хуже того, чтобы полностью избавиться от влияния CSD, может потребоваться несколько восстановительных ночей со сном продолжительностью более восьми часов в сутки.
Конечно, снижение производительности в тестах не обязательно приводит к снижению производительности на работе. Вот почему в ходе исследований также велись наблюдения за недосыпающими людьми на рабочем месте. В книге 2008 года «Patient Safety and Quality: An Evidence-Based Handbook for Nurses» («Безопасность и качество пациентов: руководство для медсестер на основе фактических данных») безоговорочно утверждается, что медсестры, испытывающие недостаток сна, совершают больше серьезных ошибок.
В довершение ко всему, согласно той же статье 2007 года в журнале «Neuropsychiatric Disease and Treatment», большинство людей, страдающих от недостатка сна, не знают, что они работают хуже. Отдельные разработчики не всегда могут сказать, что они делают больше ошибок в программировании, что затрудняет самоконтроль. Это означает, что опасности еще более тонкие, долгосрочные и их легко не заметить.
Продолжительность рабочего времени
Ежедневно мы работаем около восьми часов. Возможно, меньше. Согласно отчету Института экономики труда (Institute of Labor Economics) за 2017 год, сотрудники колл-центров считают, что их качество обслуживания падает примерно через четыре часа работы. Есть признаки того, что когда мы работаем долго, наша производительность также падает. Например, согласно отчету Business Roundtable от 1980 года, выяснилось, что производительность строительных бригад, работающих по 50 часов в неделю, через 8–10 недель снижается до 80 и менее процентов. Другими словами, за 50-часовую неделю они выполняли такой же объем работ, какой хорошо отдохнувшая, с хорошим темпом работы бригада выполняла бы за 38 часов. Еще быстрее производительность труда падает при 60-часовой рабочей неделе: по оценкам исследователей, после двух месяцев 60-часовой рабочей недели строительные бригады в совокупности выполнят меньше, чем за два месяца 40-часовой рабочей недели. И наконец, согласно публикации 2004 года Центра по контролю и профилактике заболеваний (Center for Disease Control and Prevention, CDC), вся эта дополнительная работа разрушает ваш организм.
Стресс
Наконец, подумайте о стрессе. Трудно сосредоточиться, когда вы волнуетесь, злитесь или отвлекаетесь. Вполне логично, что в состоянии стресса вы работаете не так продуктивно и не так скрупулезно. Национальный институт охраны труда и здоровья (National Institute for Occupational Safety and Health), входящий в состав CDC, показал, что медсестры, испытывающие стресс, работают значительно менее продуктивно и значительно чаще допускают серьезные ошибки. Вот пример, более близкий к нашей отрасли. Компания Gamasutra провела в 2015 году исследование о режиме «кранч» в разработке видеоигр, который они определяют как длительную сверхурочную работу. При этом выяснилось, что игры, созданные в режиме «кранч», не только выматывали команды разработчиков, но и демонстрировали худшие результаты по всем остальным показателям, как-то: критические оценки, общие продажи и тому подобное — по сравнению с играми, разработчики которых сократили объем работ, чтобы уложиться в сроки, или решили продлить график производства. Между тем, исследование 2014 года, опубликованное в журнале PeerJ, показало, что счастливые разработчики просто быстрее решают проблемы.
С одной стороны, некоторые исследования показывают, что такие технические решения, как выбор языка и практика тестирования, могут оказывать определенное влияние на качество работы команды разработчиков. С другой стороны, множество исследований показывает, что сон, нагрузка и стресс оказывают значительное влияние на производительность. Почему же в блогах, презентациях в ходе конференций и в книгах по программной инженерии так много говорится о первом и так редко о втором? Почему же такие факторы, как сон, рабочее время и стресс — это не то, о чем мы думаем в первую очередь?
Баланс между работой и личной жизнью и хорошее самочувствие влияют на нас более тонким образом, чем технические методы. Легко указать на ошибку и сказать: «Этого не могло произойти в Rust». Гораздо сложнее указать на ошибку и сказать: «Этого бы не произошло, если бы программист не находился в состоянии стресса и недосыпания». Не существует цепи обратной связи, которая отталкивала бы разработчиков от слишком большого стресса и слишком малого количества сна.
Напротив, есть много вещей, которые подталкивают нас к этому. Это, такие вещи, как изменение масштабов. Или, например, нехватка персонала. Или пожары на производстве, или вносимые в последнюю минуту изменения, или предстоящий релиз, или плохое начальство, или культура компании. Потому что проще предъявлять повышенные требования к людям, чем бороться с болезнью системы.
А заблаговременные меры по снижению стресса — дело дорогое. Субсидирование детского сада или найм дополнительного разработчика — все это выходит за рамки бюджета. Но хотя долгосрочные расходы, связанные со стрессом на рабочем месте, еще больше, они не фигурируют в качестве статьи расходов в бухгалтерском учете. Таким образом, у компаний появляется стимул причинять вред своим сотрудникам — и в конечном итоге страдать от этого.
***
Вернемся в начало и еще раз представим, что вы приняли руководство новой командой. У вас есть картбланш на внедрение любой выбранной вами политики, чтобы сделать работу команды более продуктивной, а код — менее «глючным». Что же вы предпримете? Вы можете выбрать новый язык программирования, или перевести все на микросервисы, или следовать самому горячему тренду в области процессов. Или вы можете делать то, что имеет значение. Вы можете составить расписание. Вы можете сделать так, чтобы никто не работал более восьми часов в день. Можно отпускать людей с работы на 20 минут раньше, чтобы избежать часа пик. Вы можете максимально упростить для родителей возможность брать выходной, когда их дети болеют. Вы можете дать людям почувствовать, что они важны, потому что люди действительно важны. Ни один метод, инструмент или язык не имеет такого значения, как наш собственный разум.
Почему же такие факторы, как сон, рабочее время и стресс — это не то, о чем мы думаем в первую очередь?
