Как известно, наш проект Jelastic создан с целью облегчить жизнь разработчикам, и, конечно же мы всегда прислушиваемся к их пожеланиям, изучаем их психологию, и другие аспекты. Ниже мы публикуем статью одного из ведущих компьютерных публицистов — Нейла МакАлистера — которая ранее публиковалась в InfoWorld и нашем английском блоге.
Некоторые из положений статьи могут показаться спорными (например, мы в каком-то смысле сами «оффшорные» с нашей разработкой в России и Украине), но все они крайне интересны.
Оказывается, даже столь рациональные люди с развитой логикой, как разработчики, верят мифам. Некоторые программисты верят в то, во что они хотят верить, вопреки всему.
Например, классическим заблуждением является мнение, что можно ускорить разработку проекта за счет добавления большего количества разработчиков. Фредерик Брук развеял этот миф еще в 1975 году в своей книге «Мифический человеко-месяц».
Брук считал, что добавление разработчиков в уже достаточно развитый проект никак не ускорит процесс. Напротив, это замедлит процесс разработки еще больше. По сути это опровергает множество общепринятых понятий относительно управления программными проектами.
Конечно, некоторые примеры Брукса кажутся сегодня устаревшими, но общая идея и сейчас актуальна. Его доводы уж очень убедительны. 37 лет спустя, мифическое продолжает преобладать среди программистов. Мы продолжаем делать те же ошибки.
Вот несколько примеров современных мифов о программировании, многие из которых берут начало с более давних заблуждений.
Миф №1: Оффшорная разработка программного опеспечения
В наши дни ни один здравомыслящий человек не подумает о запуске крупного программного проекта без «оффшорной» стратегии. Все крупные поставщики ПО так делают, более того инвесторы из Силиконовой Долины настаивают на таком подходе. Звучит все вполне логично: можно задействовать больше разработчиков за меньшие деньги. Значит можно закончить проект пораньше, да еще и сэкономить.
Но погодите! Это классический пример заблуждения из «Мифического человеко-месяца». Мы же уже знаем, что задействование большего количества людей, да еще и удаленно, только сделает хуже.
По словам Брукса: «Добавление людей к разработке ПО увеличивает общее усилие в трех направлениях: дезинтеграция, обучение новых людей и дополнительная коммуникация».
Предположим, что усилия, необходимые для обучения нового удаленного персонала такие же, как и для доморощенных разработчиков (опасные предположения). Проблем с коммуникацией в аутсорсинге гораздо больше. Язык, культура и часовые пояса только добавляют накладные расходы. Более того, удаленные команды разработчиков часто склонны к высокой текучести кадров, так что связь редко улучшается с течением времени.
Аутсорс — это не магия. На самом деле, трудно сделать какие-то однозначные выводы по этому поводу. Этот бесплатный обед может в конечном итоге стоить больше, чем Вы рассчитывали.
Миф №2: Хорошие разработчики работают сутками
Всем известный стереотип: программисты «кодят» и день и ночь напролет, пицца и энергетик – их лучшие друзья, они работают по выходным и редко бывают дома.
Конечно, в этом есть немало правды. Согласно медицинским исследованиям программисты на пятом месте среди «лишенных сна» профессий. Долгий рабочий день не редкость, особенно в игровой индустрии.
Но так не должно быть. Есть множество доказательств, что такой подход не увеличивает производительность. На самом деле это больше вредит, чем приносит пользы.
Чаще всего программные проекты опаздывают с запуском в связи с неправильно поставленными сроками, нечетко определенными этапами или дополнительными задачами, которые возникли в процессе разработки. Так как добавляются небольшие задержки, программисты вынуждены работать в экстра режиме, но их усилия тратятся на достижение целей, которые уже не могут быть достигнуты. Запуск проекта откладывается еще больше и теряется боевой дух команды.
Некоторых разработчиков устраивает работа «до упада», но большинство имеют семьи, друзей и личную жизнь, как и все люди. Они были бы рады уходить из офиса в 18.00. Так, что вместо того, чтобы поощрять кодеров за сверхурочные работы, лучше сосредоточится на том, почему они должны задерживаться и как это исправить. Они оценят это гораздо больше, чем бесплатную пиццу в час ночи.
Миф №3: Крутые разработчики в 10 раз продуктивнее остальных
Хороших разработчиков очень трудно найти, но великие кодеры – это легенды, или, по крайней мере, легенды местного масштаба.
Если Вы верите в сказки, то поговаривают, что где-то там есть настолько опытные хакеры, которые на порядок продуктивнее, чем средний программист.
Естественно, рекрутеров и менеджеров по найму будут убивать, чтобы найти этих легендарных «полубогов кода». Тем не менее, по большей части, они остаются неуловимыми, как снежный человек. Вероятно, их просто не существует.
Большинство разработчиков находятся где-то посередине. Если Вы видите суперпродуктивного кодера в Вашем коллективе, значит, скорее всего, остальные разработчики очень слабенькие.
Более того, исследования Брука доказывают, что код на выходе не дает полной оценки производительности. Даже лучшие из лучших тратят только около 50% рабочей недели на кодирование и отладку.
Ждать супердевелопера – это плохая стратегия. Лучше создать суперкоманду из средних кодеров, которые будут дополнять друг друга. Так Вы будете иметь гораздо больше талантов.
Миф №4: Современные инструменты обеспечивают лучшие результаты
ПО – это технологический бизнес, и так хочется верить, что технологии могут решить все проблемы. Было бы неплохо, если бы новый язык программирования, фреймворк или среда разработки сократили расходы, уменьшили сроки выхода на рынок, а также улучшили качество кода.
Много компаний пытались использовать нетрадиционные языки, чтобы обойти своих конкурентов. Первая версия социальной сети Yammer написана на Scala. Twitter начал жизнь как Ruby on Rails приложение. Reddit и Yahoo Store оба были построены с помощью Lisp.
К сожалению, большинство таких экспериментов недолговечны. Yammer переключился на Java, когда Scala не смог обеспечивать нормальное функционирование. Twitter переключился с Ruby на Scala, а потом на Java. Reddit переписали свой код на Phyton. Yahoo Store мигрировали на С++ и Perl.
Это не значит, что выбор инструментов не имеет значения. В частности, в серверных средах, где масштабируемость также важна, как производительность. Но, как видим, многие компании перешли от более модных решений к традиционным.
Например, когда в США разрабатывали Ada в 1970, главной целью была так называемая революция в программировании – но увы. Сегодня это нишевой инструмент в лучшем случае.
Конечно, это не остановит никого из изобретателей новых языков программирования, и это нормально. Только не обманывайте себя. Когда Вашей целью является создание качественного ПО, ловкость, гибкость, изобретательность и мастерство побеждают технологии в два счета. По этому, выбор зрелого инструмента не повредит.
Миф №5: Чем больше глаз проверит код, тем меньше багов
У опенсорсных разработчиков есть афоризм: «При достаточном количестве глаз все ошибки лежат на поверхности». Это иногда называют законом Линуса, но действительно придумал это Эрик С. Реймонд, один из основателей движения открытых источников.
Идея состоит в том, что открытый исходный код имеет естественное преимущество перед проприетарным программным обеспечением, потому что любой разработчик может просмотреть код, найти недостатки и исправить их в случае необходимости.
Увы, это принятие желаемого за действительное. Большинство проектов с открытым кодом сегодня имеют гораздо больше пользователей, чем участников. Многие пользователи даже не просматривают исходный код, это означает, что число глаз для большинства проектов преувеличена. Более того, нахождение ошибок еще не означает их устранение.
Одно из исследований, проведенное в 2009 году, показало, что файлы кода, которые были исправлены многими отдельными разработчиками, содержали гораздо больше ошибок, чем те, над которыми работали команды программистов. Как известно: «у семи нянек дитя без глаза».
Миф №6: Крутые разработчики оптимизируют код по максимуму
Работа профессиональной гоночной команды состоит в том, чтобы их автомобиль прибыл к финишу раньше всех остальных. Сама машина очень важна, но это лишь железо, которое требует кропотливой работы водителя и механика. Вы думаете, что это верно для компьютерного кода тоже? К сожалению, ручная оптимизация не всегда лучший способ, чтобы получить максимальную производительность от вашего алгоритма. На самом деле, сегодня это большая редкость.
Одной из проблем является то, что предположения программистов о том, как их собственный код на самом деле работает, часто ошибочные. Языки высокого уровня ограждают программиста от оборудования. В результате, кодеры могут пытаться оптимизировать код таким образом, что это часто бесполезно, и зачастую даже вредит проекту.
Возьмем, к примеру, XOR алгоритм подкачки, который использует битовые операции, чтобы поменять значения двух переменных. Когда-то это было эффективно. Но современные высокопроизводительные процессоры не работают с XOR-подкачкой. Если вы пытаетесь оптимизировать ваш код таким способом сегодня, это реально работает медленнее.
Многоядерные процессоры так же усложняют дело. Чтобы воспользоваться ими, вам нужно написать многопоточный код. Параллельную обработку трудно сделать правильно. Оптимизация, которая ускоряет один поток, может случайно прервать другие. Чем больше потоков, тем сложнее программа для оптимизации. То, что процедура может быть оптимизирована не означает, что это обязательно должно быть сделано. Большинство программ тратят 90% своего времени запуска на обработку всего лишь 10% кода.
Во многих случаях Вам лучше просто доверять своим инструментам. Не тратьте время на ненужную ручную оптимизацию, лучше позаботьтесь об эффективности кода.
Миф №7: Хороший код — «элегантный» код
Как и большинство инженеров, программисты любят говорить о простом или «элегантном» решении проблем. Беда в том, что это плохой способ судить о программном коде.
Что эти термины на самом деле означают? Есть ли простое или «элегантное» решение? Этот «элегантный» код эффективно работает, или это тот код, который использует наименьшее количество строк?
В некотором смысле, поиск наиболее «элегантного» решения проблемы программирования еще один вид преждевременной оптимизации.
Хороший код может быть не так прост или «элегантен». Лучший код работает, работает хорошо, и без багов. Зачем просить большего?
Автор: jelastic
