7 мифов о программировании

    imageКак известно, наш проект Jelastic создан с целью облегчить жизнь разработчикам, и, конечно же мы всегда прислушиваемся к их пожеланиям, изучаем их психологию, мышление и другие аспекты. Ниже мы публикуем статью одного из ведущих компьютерных публицистов — Нейла МакАлистера — которая ранее публиковалась в InfoWorld и нашем английском блоге.
    Некоторые из положений статьи могут показаться спорными (например, мы в каком-то смысле сами «оффшорные» с нашей разработкой в России и Украине), но все они крайне интересны.

    Оказывается, даже столь рациональные люди с развитой логикой, как разработчики, верят мифам. Некоторые программисты верят в то, во что они хотят верить, вопреки всему.
    Например, классическим заблуждением является мнение, что можно ускорить разработку проекта за счет добавления большего количества разработчиков. Фредерик Брук развеял этот миф еще в 1975 году в своей книге «Мифический человеко-месяц».
    Брук считал, что добавление разработчиков в уже достаточно развитый проект никак не ускорит процесс. Напротив, это замедлит процесс разработки еще больше. По сути это опровергает множество общепринятых понятий относительно управления программными проектами.
    Конечно, некоторые примеры Брукса кажутся сегодня устаревшими, но общая идея и сейчас актуальна. Его доводы уж очень убедительны. 37 лет спустя, мифическое мышление продолжает преобладать среди программистов. Мы продолжаем делать те же ошибки.
    Вот несколько примеров современных мифов о программировании, многие из которых берут начало с более давних заблуждений.

    Миф №1: Оффшорная разработка программного опеспечения

    В наши дни ни один здравомыслящий человек не подумает о запуске крупного программного проекта без «оффшорной» стратегии. Все крупные поставщики ПО так делают, более того инвесторы из Силиконовой Долины настаивают на таком подходе. Звучит все вполне логично: можно задействовать больше разработчиков за меньшие деньги. Значит можно закончить проект пораньше, да еще и сэкономить. image
    Но погодите! Это классический пример заблуждения из «Мифического человеко-месяца». Мы же уже знаем, что задействование большего количества людей, да еще и удаленно, только сделает хуже.
    По словам Брукса: «Добавление людей к разработке ПО увеличивает общее усилие в трех направлениях: дезинтеграция, обучение новых людей и дополнительная коммуникация».
    Предположим, что усилия, необходимые для обучения нового удаленного персонала такие же, как и для доморощенных разработчиков (опасные предположения). Проблем с коммуникацией в аутсорсинге гораздо больше. Язык, культура и часовые пояса только добавляют накладные расходы. Более того, удаленные команды разработчиков часто склонны к высокой текучести кадров, так что связь редко улучшается с течением времени.
    Аутсорс — это не магия. На самом деле, трудно сделать какие-то однозначные выводы по этому поводу. Этот бесплатный обед может в конечном итоге стоить больше, чем Вы рассчитывали.

    Миф №2: Хорошие разработчики работают сутками

    Всем известный стереотип: программисты «кодят» и день и ночь напролет, пицца и энергетик – их лучшие друзья, они работают по выходным и редко бывают дома.
    Конечно, в этом есть немало правды. imageСогласно медицинским исследованиям программисты на пятом месте среди «лишенных сна» профессий. Долгий рабочий день не редкость, особенно в игровой индустрии.
    Но так не должно быть. Есть множество доказательств, что такой подход не увеличивает производительность. На самом деле это больше вредит, чем приносит пользы.
    Чаще всего программные проекты опаздывают с запуском в связи с неправильно поставленными сроками, нечетко определенными этапами или дополнительными задачами, которые возникли в процессе разработки. Так как добавляются небольшие задержки, программисты вынуждены работать в экстра режиме, но их усилия тратятся на достижение целей, которые уже не могут быть достигнуты. Запуск проекта откладывается еще больше и теряется боевой дух команды.
    Некоторых разработчиков устраивает работа «до упада», но большинство имеют семьи, друзей и личную жизнь, как и все люди. Они были бы рады уходить из офиса в 18.00. Так, что вместо того, чтобы поощрять кодеров за сверхурочные работы, лучше сосредоточится на том, почему они должны задерживаться и как это исправить. Они оценят это гораздо больше, чем бесплатную пиццу в час ночи.

    Миф №3: Крутые разработчики в 10 раз продуктивнее остальных

    Хороших разработчиков очень трудно найти, но великие кодеры – это легенды, или, по крайней мере, легенды местного масштаба.
    imageЕсли Вы верите в сказки, то поговаривают, что где-то там есть настолько опытные хакеры, которые на порядок продуктивнее, чем средний программист.
    Естественно, рекрутеров и менеджеров по найму будут убивать, чтобы найти этих легендарных «полубогов кода». Тем не менее, по большей части, они остаются неуловимыми, как снежный человек. Вероятно, их просто не существует.
    Большинство разработчиков находятся где-то посередине. Если Вы видите суперпродуктивного кодера в Вашем коллективе, значит, скорее всего, остальные разработчики очень слабенькие.
    Более того, исследования Брука доказывают, что код на выходе не дает полной оценки производительности. Даже лучшие из лучших тратят только около 50% рабочей недели на кодирование и отладку.
    Ждать супердевелопера – это плохая стратегия. Лучше создать суперкоманду из средних кодеров, которые будут дополнять друг друга. Так Вы будете иметь гораздо больше талантов.

    Миф №4: Современные инструменты обеспечивают лучшие результаты

    ПО – это технологический бизнес, и так хочется верить, что технологии могут решить все проблемы. Было бы неплохо, если бы новый язык программирования, фреймворк или среда разработки сократили расходы, уменьшили сроки выхода на рынок, а также улучшили качество кода.
    Много компаний пытались использовать нетрадиционные языки, чтобы обойти своих конкурентов. Первая версия социальной сети Yammer написана на Scala. Twitter начал жизнь как Ruby on Rails приложение. Reddit и Yahoo Store оба были построены с помощью Lisp.
    К сожалению, большинство таких экспериментов недолговечны. Yammer переключился на Java, когда Scala не смог обеспечивать нормальное функционирование. Twitter переключился с Ruby на Scala, а потом частично на Java. Reddit переписали свой код на Phyton. Yahoo Store мигрировали на С++ и Perl.
    Это не значит, что выбор инструментов не имеет значения. В частности, в серверных средах, где масштабируемость также важна, как производительность.image Но, как видим, многие компании перешли от более модных решений к традиционным.
    Например, когда в США разрабатывали Ada в 1970, главной целью была так называемая революция в программировании – но увы. Сегодня это нишевой инструмент в лучшем случае.
    Конечно, это не остановит никого из изобретателей новых языков программирования, и это нормально. Только не обманывайте себя. Когда Вашей целью является создание качественного ПО, ловкость, гибкость, изобретательность и мастерство побеждают технологии в два счета. По этому, выбор зрелого инструмента не повредит.

    Миф №5: Чем больше глаз проверит код, тем меньше багов

    У опенсорсных разработчиков есть афоризм: «При достаточном количестве глаз все ошибки лежат на поверхности». Это иногда называют законом Линуса, но действительно придумал это Эрик С. Реймонд, один из основателей движения открытых источников.image
    Идея состоит в том, что открытый исходный код имеет естественное преимущество перед проприетарным программным обеспечением, потому что любой разработчик может просмотреть код, найти недостатки и исправить их в случае необходимости.
    Увы, это принятие желаемого за действительное. Большинство проектов с открытым кодом сегодня имеют гораздо больше пользователей, чем участников. Многие пользователи даже не просматривают исходный код, это означает, что число глаз для большинства проектов преувеличена. Более того, нахождение ошибок еще не означает их устранение.
    Одно из исследований, проведенное в 2009 году, показало, что файлы кода, которые были исправлены многими отдельными разработчиками, содержали гораздо больше ошибок, чем те, над которыми работали команды программистов. Как известно: «у семи нянек дитя без глаза».

    Миф №6: Крутые разработчики оптимизируют код по максимуму

    imageРабота профессиональной гоночной команды состоит в том, чтобы их автомобиль прибыл к финишу раньше всех остальных. Сама машина очень важна, но это лишь железо, которое требует кропотливой работы водителя и механика. Вы думаете, что это верно для компьютерного кода тоже? К сожалению, ручная оптимизация не всегда лучший способ, чтобы получить максимальную производительность от вашего алгоритма. На самом деле, сегодня это большая редкость.
    Одной из проблем является то, что предположения программистов о том, как их собственный код на самом деле работает, часто ошибочные. Языки высокого уровня ограждают программиста от оборудования. В результате, кодеры могут пытаться оптимизировать код таким образом, что это часто бесполезно, и зачастую даже вредит проекту.
    Возьмем, к примеру, XOR алгоритм подкачки, который использует битовые операции, чтобы поменять значения двух переменных. Когда-то это было эффективно. Но современные высокопроизводительные процессоры увеличивают производительность за счет одновременного выполнения нескольких инструкций с использованием конвейеров. Если вы пытаетесь оптимизировать ваш код таким способом сегодня, это реально работает медленнее.
    Многоядерные процессоры так же усложняют дело. Чтобы воспользоваться ими, вам нужно написать многопоточный код. Параллельную обработку трудно сделать правильно. Оптимизация, которая ускоряет один поток, может случайно прервать другие. Чем больше потоков, тем сложнее программа для оптимизации. То, что процедура может быть оптимизирована не означает, что это обязательно должно быть сделано. Большинство программ тратят 90% своего времени запуска на обработку всего лишь 10% кода.
    Во многих случаях Вам лучше просто доверять своим инструментам. Не тратьте время на ненужную ручную оптимизацию, лучше позаботьтесь об эффективности кода.

    Миф №7: Хороший код — «элегантный» код

    image Как и большинство инженеров, программисты любят говорить о простом или «элегантном» решении проблем. Беда в том, что это плохой способ судить о программном коде.
    Что эти термины на самом деле означают? Есть ли простое или «элегантное» решение? Этот «элегантный» код эффективно работает, или это тот код, который использует наименьшее количество строк?
    В некотором смысле, поиск наиболее «элегантного» решения проблемы программирования еще один вид преждевременной оптимизации.
    Хороший код может быть не так прост или «элегантен». Лучший код работает, работает хорошо, и без багов. Зачем просить большего?
    Jelastic
    Jelastic DevOps PaaS для хостеров и ISV
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 30

      +4
      По моему в большинство этих мифов итак никто не верит
        –4
        «И так» в данном случае пишется с пробелом. Искренне недоумеваю, как можно допускать такие ошибки, ведь у слова «итак» совсем другое значение.
          0
          Согласен. Случайно пропустил пробел.
            +1
            Почему бы вам не устроиться учителем русского языка? Такой талантище пропадает.
            0
            Если бы в эти мифы верили рядовые девелоперы, то это было бы половиной беды.
            Проблема в том, что в эти мифы в основном верят тим-лиды и менеджеры.
            И вот тут начинается самое интересное…
            Кто работал(работает) в крупных компаниях — поймет о чем я.
            0
            Как и многие другие статьи о философии программирования и абстрактном «как нужно программировать» — тут тоже все зависит в первую очередь от задачи. Это касается пунктов 4, 6, 7.

            Миф №4: Современные инструменты обеспечивают лучшие результаты
            напрямую зависит от задачи. Многие задачи давно реализованы и нет смысла выдумывать велосипед. А уж выбор языка программирования для проекта тем более.

            Миф №6: Крутые разработчики оптимизируют код по максимуму
            Я много раз слышал от качественных, на мой взгляд, разработчиков (в том числе книгах, конференциях, форумах) о том, что даже комментарии и лишние пустые строки (актуально для скриптовых языков) иногда увеличивают время запуска или работы приложений. И это тоже оптимизация «по максимуму». Вот «крутые» программисты просто обычно знают как «работает» их язык программирования и исходя из этого «оптимизируют по максимуму»

            Миф №7: Хороший код — «элегантный» код
            Опять же зависит от проекта. В крупных проектах с большой командой разработчиков на «элегантность» тратится много времени, хотя это часто больше связано с понимаемостью и читаемостью кода, нежели «смотрите как я умею».
            С другой стороны мелкий, пусть даже коммерческий проект, цель которого отработать один раз или периодически, но вероятность последующих исправлений которого крайне мала.

            Резюмирую:
            И Ваши и мои размышления имеют место жить во многих ситуациях, но далеко не во всех.
              0
              Спасибо за Ваш отзыв. Да, действительно, Ваши замечания вполне справедливы.
                0
                А вообще программисты — те еще задроты :D
                  0
                  :) бывают исключения
                    0
                    exception? try-catch?
                      +5
                      Теперь ясно что вы имели ввиду комментарием выше :)
              +1
              А теперь, товарищ КО, вспомните бедных ученых, которые вынуждены писать софт себе сами. А пишут они на том, что знают — поэтому-то до сих пор основная масса математических пакетов — на фортране. И многие из них о современных библиотеках не знают. И об оптимизации они слыхом не слыхивали. И код у нас обычно такой, что черт ногу сломит.
              Но зато работает и поставленные задачи выполняет. И это хорошо, т.к. ждать нужного софта от «крутых программистов» — себе дороже. Так и помереть можно, а софта хрен дождешься…
                0
                Думаю что в статье речь шла о профессиональных программистах. Вы же ИМХО описываете программистов-любителей.
                  0
                  К профессиональному программисту ученый не пойдет, т.к. программист этот сделает явно не то, что ученому надо. Или сделает то, но за такую цену, что проще застрелиться!
              0
              «Twitter переключился с Ruby на Scala, а потом на Java.»

              Можно ссылку на это? Единственное, что я смог найти — это то, что они пишут некоторые части на java, но про отказ от scala — ни чего.
                0
                Да, все верно, они используют Scala + Java www.readwriteweb.com/hack/2011/07/twitter-java-scala.php. Немножко некорректно сформулировано предложение, поправим. Спасибо.
                  0
                  Мало того, что предложение было сформулировано неправильно, Ваши выводы совершенно не соответствуют тезисам из статьи по линьку, который Вы поставили выше.

                  Twitter частично перешел на Skala и это связано не с особенностями языка Руби, а совершенно другими соображениями.

                  Для справки, полно сайтов с огромной посещаемостью, которые были написаны и по-прежнему живут в Руби. hulu.com, vimeo.com, и т.д.

                  Вы наверно хотели сказать, что язык сам по себе не может писать хорошие программы — для хороших програм нужен хороший програмист. Я правильно понял?
                    0
                    Это всего лишь несколько примеров компаний, которые вернулись к более традиционным решениям. Никто не говорит, что сайт на Руби — это плохо. В этих мифах много спорных моментов, каждый имеет свою точку зрения по этому поводу. Конечно, от программиста тоже многое зависит.
                +5
                Не убедили.
                Даже более того единственный миф в этой статье содержится в первом предложении и не пронумерован:
                Как известно, наш проект Jelastic создан с целью…
                Я готов поспорить, что большинству это не просто неизвестно, а глубоко параллельно и будет забыто через 30 минут после прочтения. Так что вот он настоящий МИФ.
                  0
                  «Корпорация МИФ» атакует…
                  +4
                  > XOR-подкачкой
                  swap в данном случае не означает подкачку
                  речь идет о замене значений двух переменных между собой типа a ^= b ^= a
                  en.wikipedia.org/wiki/XOR_swap_algorithm
                    0
                    Надеюсь, это перевод, а не креатив автора ;(
                      0
                      Да, перевод, хотя значка не видно. :(
                      Автор оригинальной статьи, похоже, прочитал Брукса по-диагонали (причем первое издание) и решил поделится радостью с окружающими…

                      И ладно бы он понял, что прочитал, но ведь иногда просто ересь пишет…
                      >>Миф №1: Оффшорная разработка программного обеспечения
                      >>Звучит все вполне логично: можно задействовать больше разработчиков за меньшие деньги. Значит >>можно закончить проект пораньше, да еще и сэкономить.
                      >>Но погодите! Это классический пример заблуждения из «Мифического человеко-месяца».

                      А вот и не погодим. Брукс говорил, что добавление людей В ЗАВЕРШАЮЩУЮ стадию проекта может еще дальше отодвинуть дату завершения. Если решение об аутсорсе принимается до начала проекта, и вы выбираете между местной командой в 10 человек и аутсорсной в 20 человек за те же деньги, то при прочих равных (квалификация) аутсорсеры справятся быстрее.

                      >>Миф №4: Современные инструменты обеспечивают лучшие результаты
                      Если память не изменяет, это заявил Брукс в первом издании, а во втором извинился, что был не прав. Развитие IDE и различных библиотек / фреймворков ускорило разработку в разы.

                      >>Миф №5: Чем больше глаз проверит код, тем меньше багов
                      Тому, кто считает, что это миф — надо прочитать что такое Code Review.

                      >>Миф №7: Хороший код — «элегантный» код
                      Если автор не дает определение «хорошего» кода, то это просто демагогия. В этом плане могу посоветовать книжку «Чистый код».

                      0
                      Миф #1: Программирование — это искусство
                      Миф #2: Один язык лучше другого, а лопата лучше молотка.
                        +3
                        >>Миф №3: Крутые разработчики в 10 раз продуктивнее остальных

                        Не всё так однозначно — хорошие разработчики действительно работают на порядок лучше чем плохие.
                        Дело тут во многом: поставленный процесс разработки, использование правильных инструментов, своевременное проектирование, рефакторинг, тестирование, отладки и т.п.

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

                        В команде разработчиков должны быть лидеры с хорошим уровнем знаний и опыта, для того, чтобы остальные члены команды обучались.
                          +1
                          А ещё если квалификация разработчика совсем не адекватна сложности проекта, то он просто со 100% вероятностью заходит в тупик (полный срыв всех возможных сроков, невозможность исправить проблемы без полного переписывания кода, выход за предельно возможный бюджет) и время и деньги улетают в трубу.
                            0
                            Да есть такая тема, если разработчик уткнулся в предел своей текущей квалификации, то он может потратить недели на безуспешные попытки решения задачи, которую другой разработчик решит за пару дней. И нет никакого мифа в том, что не все команды состоят из ведущих разработчиков.
                            Тем более, что это было бы тупо неэффективно, т.к. на простых задачах сеньоры будут скучать, да и прирост производительности там будет не столь ощутим, ведь чем проще задача, тем ниже влияние квалификации.
                        • UFO just landed and posted this here
                            0
                            Можно еще добавить список этими мифами о программировании: writeabout.tech/programming/25-most-popular-myths-about-programming-and-developers

                            Only users with full accounts can post comments. Log in, please.