Разработчик игр
0,0
рейтинг
25 августа 2010 в 14:45

Управление → Некоторые малоизвестные факты о программировании перевод

GTD*
Будучи программистом я многое узнал о том, как создаётся программное обеспечение. Вот несколько фактов, которые могут вас удивить.

Программист тратит 10-20% своего времени на написание собственно кода, и большинство программистов пишут всего 10-12 строк кода в день, которые попадают в конечный продукт, независимо от их уровня. Хорошие программисты тратят большую часть оставшихся 90% времени на размышления, исследования и эксперименты в поисках наилучшего решения. Плохие программисты тратят это время на отладку, случайные изменения в коде и последующую проверку его на работоспособность.

«Хороший токарь работает в несколько раз лучше среднего, но хороший программист стоит в 10000 раз больше, чем обычный»
Билл Гейтс.

Хороший программист в 10 раз более продуктивен, чем средний. Отличный программист в 20-100 раз более продуктивен, чем средний. И это не преувеличение — исследования, проводящиеся с 1960-х годов, чётко это показывают. Плохой программист не просто непродуктивен: он не только не выполняет свою работу, но ещё и создаёт проблемы, которые приходится решать другим.

Лучшие программисты тратят очень немного времени на написание кода. По крайней мере того, который попадает в конечный продукт. Программисты, тратящие много времени на код либо слишком ленивы, либо слишком безграмотны, либо слишком высокомерны, чтобы искать существующие решения старых проблем. Отличные программисты — мастера определения и использования стандартных подходов. Хорошие не боятся постоянного рефакторинга в поисках идеальной архитектуры. Плохие же пишут код, которому недостаёт концептуальной целостности, лаконичности, иерархичности, шаблонов проектирования, и его невероятно сложно рефакторить. Проще выбросить плохой код на помойку и начать заново, чем что-то менять в нём.

Программы подчиняются закону энтропии, как и всё остальное во Вселенной. Непрерывные изменения вызывают разрушение программ, которое нарушает целостность изначальной архитектуры. Это неизбежно, но программисты, не принявшие во внимание вопросы целостности, пишут программы, которые разрушаются настолько быстро, что становятся ненужными ещё до своего завершения. Энтропическая ошибка целостности, вероятно, самая распространённая ошибка, приводящая к провалу проектов. А вторая по распространённости — это создание программы, идущей вразрез с желаниями клиента. Разрушение программ замедляет прогресс разработки экспоненциально, поэтому многие проекты приходят к лавинообразно нарастающим срывам бюджета и сроков, и это продолжается до тех пор, пока их окончательно не уничтожат.

В исследовании 2004-го года было обнаружено, что большая часть программных проектов (51%) сталкиваются с критическими проблемами (срыв сроков, превышение бюджета, невыполнение обязательств, нарушения функционала и т.п. — прим. пер.), а 15% полностью проваливаются. Это лучше, чем в 1994-м, когда последних было 31%.

Хотя большая часть программ создаётся командами, это не есть демократическая деятельность. Обычно всего один человек является ответственным за архитектуру, остальные — лишь кодеры.

Программирование — тяжёлый труд. Это очень напряжённая умственная деятельность. Хорошие программисты думают о работе 24 часа 7 дней в неделю. Они пишут лучший код в душе и в своих снах. Поскольку самая важная работа делается вдали от клавиатуры, разработку программных проектов нельзя ускорить, заставляя людей больше работать в офисе, или добавив новых людей в проект.

От переводчика. Вероятно, эти факты не являются такими уж малоизвестными или уникальными. Но мне они показались где-то забавными, где-то поучительными, и уж точно стоящими внимания.
Перевод: Дэвид Векслер
Дмитрий @proxor
карма
58,4
рейтинг 0,0
Разработчик игр
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (150)

  • –41
    То ли мне не везет, то ли это все только теория. Мне попадаются только те программисты, которые никогда ничего на листке не рисуют и не чертят, они сразу начинают кодить и через какое то время оказывается что логика где то не сходиться и что то не так.
    • +221
      платишь арахисом, получаешь обезьян
      • +1
        просто великолепный комментарий)
      • –4
        Только вместо обезьян почему-то индусы…
    • +3
      Вам наверно ещё хороших программистов в жизни не попадалось…
    • +5
      Я Вам сочувствую. В моей команде мы постоянно перед тем как начать решать какую-то задачу, садимся за стол без компьютера, каждый берет по листку бумаги, кладем перед собой описание задачи (ТЗ, пользовательские сценарии) и начинаем обсуждать задачи, дробить всю задачу на мелкие, выделять подзадачи и блоки.

      В итоге на бумаге, а самое главное, в голове каждого участника беседы складывается стройное представление последовательности решения задачи, разложены по полочкам подзадачи. И только после этого можно садиться за компьютер и начинать реализовывать проект.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Наличие аналитика, как отдельного сотрудника зависит лишь от размеров компании. Если оборот и задачи компании позволяют загрузить полноценной работой одного или нескольких аналитиков, то смысл от их найма есть.
          • НЛО прилетело и опубликовало эту надпись здесь
    • +12
      Бумага — не признак хорошего программиста, я раньше часто «думал на бумаге», но уже давно этого не делаю. Я часто начинаю проектировать систему в phpMyAdmin, мне так удобно и наглядно. А программировать начинаю с вставки комментариев типа «инициализация структур хранения», «формирование обработанного документа», «создание индекса» и т.п., потом пишутся эти блоки…

      Автор правильно заметил, что кодирование занимает процентов 10% времени, в остальное время думаешь и ищешь решение. Мне, к примеру, лучше всего думается за чисткой картоши и глажкой, благо работаю дома и можно «подумать утюгом» в любое время :)
      • +1
        Т.е. начинаете проектирование с БД?
        • +2
          во многих случаях это оправдано, особенно в вебе, и особенно, если заранее ориентироваться на определенный фреймворк.

          только на счет phpMyAdmin не соглашусь, гораздо удобнее и нагляднее какой-нить визуальный «Database Designer», имхо.
          • 0
            Я не имею ничего против такого подхода, как и любого другого который дает результат.
            Я лично — делаю это в дизайнере базы данных EMS SQL Manager, причем в нем сразу можно нажать одну кнопку и вся схема базы ляжет на реальный MySql сервер.
            Просто сейчас понемногу этот подход меня уже не так устраивает, потому что приходится менять структуру слишком часто. Я хочу что-то такое чтобы я в одном месте поменял нажал одну кнопку и везде где использовалась эта схема, все поменялось. К этому ближе всего XSD, а к ней ближе всего UML. Но пока что не сообразил как все выстроить.
            • +1
              как минимум MicroOLAP Database Designer и DBDesigner умеют создавать базу по схеме.

              symfony с орм Doctrine или Propel умеют генерить базу из схемы в xml или yml из коробки, и кроме того, генерируют ОРМ-классы.

              а вот толковые генератоы UI мне не попадались, для реальных пользователей их слишком сильно приходится допиливать, проще самому админку написать.
              • 0
                Спасибо. Симфонию когда-то давно использовал, но отказался из-за сложности, может что-то изменилось.
                • 0
                  Ну как, она стала еще сложнее для новичков и гораздо проще для тех, кто в теме.
          • 0
            Я когда-то давно пользователся всякого рода программами для проектирования баз данных, но программы часто перегружены излишним функционалом, универсализмом, фичами, которые реально не нужны, а вот по части сторости создания структуры базы данных они, как правило, не выигрываются у phpMyAdmin. Зато phpMyAdmin удобный, заточен под MySQL (другие базы давно не использую), можно поставить на сервере. В общем он мне удобен :)
        • 0
          Да, мне удобно таким образом «визуализировать» систему.
      • +2
        О. Не я один с комментариев сложные алгоритмы начинаю делать :)
        ИМХО это лучший способ, когда не знаешь с чего начать задачу.

        Эдакий Comment Driven Development.
        • +1
          Конечно не один.

          en.wikipedia.org/wiki/Literate_programming

        • 0
          Когда слишком долго тупишь на тему «а как же это написать», начинаю описывать комментариями, функциями-заглушками, потом приходит «прозрение» и всё быстро реализуется.
        • 0
          Программирование псевдокодом это еще называется (см. книгу «Совершенный код»).
          • 0
            Не, о псевдокоде речи не идет. Русский язык далек от псевдокода.
      • 0
        Для этого есть ORM разные. Если модель данных меняется, то тогда удобно применять миграции — очень удобно. Хотя тут, возможно как раз моторика важна — надо мышкой возюкать.
        Я, например, часто беру бумажку и рисую «каляки-маляки», пока в голове разные параметры и объекты крутятся, собираются в разные структуры, «тестируются», разбираются и собираются снова… трудно объяснить, как это происходит, т.к. процесс не формализуемый с не формализованными данными, но потом садишься, и код пишется легко и непринужденно. Еще хорошо думается в ванной и за рулем, хотя заметил, что за рулем это делать небезопасно, т.к. иногда бывает, что отключаешься на пару секунд от восприятия действительности (в ванной или сидя за столом этого не замечаешь), и можно аварийную ситуацию создать.
    • –34
      во насрали)) так держать)) ещё разок, пожалуйста! а хуле?
      • –30
        я все жду когда «reset» заюзать(сохранил ведь шанс на помилование) — хорошо что раньше не заюзал. Срите господа)) Мне все равно а вам приятно. Правда за что первый коммент заминусовали так и не понятно.
        • –16
          всё! горшочек, не вари! жму «reset»))
          • 0
            Походу рановато отресетился :)
    • +1
      Это как раз таки нормальный рабочий процесс. Такие вот бумажкомаратели очень часто тратят кучу времени на всякие графики, схему и прочую бесполезную хрень, в результате чего создают совершенно зубодробительную и избыточную архитектуру, которую потом реализуют в виде тонн говнокода. Я считаю, что если программист не может удержать архитектуру своей системы в голове, значит её, архитектуру, можно и нужно упрощать.
      • +5
        Это когда проект одного программиста, а когда команда? Где та голова, которая будет содержать связи между кусками? Вот ему то и требуется бумажка с моделями, что бы свою команду поделить и процесс программирования шел одновременно у всех, и они бы не мешали друг другу, а так же не задавали глупых вопросов.
        • +1
          Да, тут вы правы. В команде, безусловно, нужен как координатор, так и утверждённая архитектура, иначе будет хаос. Я сейчас в одиночку тяну средней величины проект, поэтому такой однобокий взгляд получился :)
      • 0
        Значит, вам не попадались приложения с действительно сложной архитектурой.
        • +1
          О, поверьте, я бы не стал говорить, если бы не попадались :) В течение года я работал над проектом, который изначально делала аутсорсинговая фирма. Там было несколько толстенных, и абсолютно бесполезных документов, описывающих архитектуру и взаимодействие компонентов (с юзкейсами, sequence диаграммами и прочими атрибутами серьёзной системы. Когда я только пришёл на проект, я очень впечатлился этими фолиантами и даже распечатал их. Как выяснилось позже, я только зря потратил бумагу с тонером, так как эти документы абсолютно ничего не проясняли, и даже наоборот — запутывали. Кроме того, система была спроектирована так, будто разработчики поставили себе целью использовать абсолютно все технологии и паттерны, которые только нашлись в их конспектах с курсов по Java. В результате, фирме-заказчику постоянно приходилось наращивать серверные мощности, из-за того, что по мере заполнения БД этот монстр работал всё медленнее и медленнее. А на то, чтобы сделать глобальный редизайн, не было времени и ресурсов.

          Я, конечно, немножко погорячился в первом камменте :) При работе в команде нужно вырабатывать какие-то общие правила и основы архитектуры. Только всё это должно проходить без фанатизма. А то бывает так, что абстракшн гики разрисовывают красивые иерархии наследования, интерфейсы и прочую муть в то время, когда от них всего лишь требуется написать “Hello world”.
          • +1
            Обычно в таких случаях я детально прорабатываю интерфейсы, а в реализации лежит нечто типа (программирую на Java, потому и пример соответствующий):
            // TODO: develop if necessary
            throw new UnsupportedOperationException(); 
            

  • +45
    Когда читаю такие текста и вижу что Отличный Программист — он как минимум спаситель вселенной.
    Чак Норис курит в стороне, а одной кнопокой они переворачивают жизни людей. А женщины сами падают на колени перед ними.
    • +18
      ах, если б это было так…
    • +13
      в идеале так и должно быть…
      • +10
        с любым человеком, любой деятельности
    • +3
      Вы не поверите, но так и есть!
    • 0
      Нажми на кнопку, получишь результат… (с)
  • 0
    Дэвид Векслер = Кэп.
  • +6
    Статья мотивирует меньше писать, но больше делать. А для этого надо становиться лучше.
    • +10
      Статья мотивирует вначале ДУМАТЬ, чем писАть!
  • +2
    Малоизвестные?! Ну это смотря кому… да любой программист это знает, просто не говорит.
    • +1
      Вот потому видимо малоизвестные, что невысказанные ;-)
    • 0
      Для меня было новым только про 10-12 строк кода ежедневно. Не совсем очевидно, если не задумывать. А про разницу между худшими и лучшими уже раз 10 на Хабре писали.
  • +1
    я себе сформулировал 3 проблемы программистов:
    1. не умеют читать (часто не видишь или не понимаешь то что написано в коде)
    2. не умеют считать (индексы в массивах и номера символов в строках — неиссякаемый источник ошибок)
    3. пишут код методом копирования (копипаст убивает любоцй дизайн и код)
    • +2
      >1. не умеют читать (часто не видишь или не понимаешь то что написано в коде)
      ну ИМХО это ваша проблема что вы не видите что написано в их коде, или иначе они не могут писать, но никак не читать
      >3. пишут код методом копирования (копипаст убивает любоцй дизайн и код)
      сейчас чувствую начнутся холивары (мое мнение копипаст в малых дозах безвреден при любом количестве :) нужно просто видеть картину целиком того что делаешь, чтобы знать где его уместно применить, а где нет)
      • –1
        На этапах багфикса я почти всегда могу свести проблему к 1 из указанных 3 проблем.

        Поскольку участвую в проектах, где занято более 1000 человек, то прихожу к выводу что везде так, ибо 1000 программеров — выборка довольно репрезентативная.
        • +1
          1000 программистов в одном проекте? Можно проект озвучить? :-)
          • 0
            Проект разрабатывался несколько лет и конечно не сразу 1000 программистов поучаствовали. Но в среднем столько приложили к нему руку.
            Проект был связан с разработкой Java ME virtual machine.
            • 0
              Солидно :-) Завидую :-)
              • 0
                Вот пример из жизни 1 мин назад произошел.

                Сидит чувак — втыкает в код. Код не работает. Зовет меня и кричит, что код не работает хрен знает почему, а должен работать.

                Я подхожу. Он тычет пальцем в строку
                int length = (arr[i] > 0? 0: arr[i])

                Ошибка простая — ему показалось, что стоит знак «меньше», а в коде явно написано «больше».

                сработал 1 принцип — программист не умеет читать.
                • +9
                  видимо этому программисту пора в отпуск или хотя бы домой
                • +2
                  Иногда и умея читать можно допускать страшные косяки.
                   if (!length!=3) doSomething();

                  Восклицательный знак после скобки совсем не бросается в глаза, а результат выполения меняется на прямо противоположный

                  К слову строка
                   not length!=3 and doSomething()
                  подобных минусов не имеет
                  • 0
                    >Восклицательный знак после скобки совсем не бросается в глаза, а результат выполения меняется на прямо противоположный

                    поэтому я приучил себя писать
                    if (! length != 3 ) doSomething();
                    Отсутствие ошибок не гарантирует, но как минимум заметить проще.
                    • 0
                      парсер скушал пробел после открывающей скобки :(
                      Жаль не могу теги использовать
                      • 0
                        вот-вот.
                    • 0
                      А еще лучше не использовать двойных отрицаний ) Даже во вложенных if-ах.
                      • 0
                        я писал в целом про читаемость, даже с одним отрицанием выделяю "!" пробелами с двух сторон, чтоб не сливался
                  • +9
                    >К слову строка
                    > not length!=3 and doSomething()
                    > подобных минусов не имеет

                    Строка
                    if (length == 3)
                    минусов не имеет, а два отрицания — от лукавого.
                    • 0
                      Лучше: if (3 == length)
                      Только в оригинале речь идет о другом (length != 3)
        • 0
          Не бедные индийские юноши, случайно? А то и мне кажется подозрительным, что «не умеют читать» :)
          В такой громадине и ни разу не возникло хотя бы проблем совместимости компонентов между собой? Только индексы?
    • 0
      Почитайте книгу про анти-паттерны, там есть это и многое другое.
  • +14
    Плохие же пишут код, которому недостаёт концептуальной целостности, лаконичности, иерархичности, шаблонов проектирования, и его невероятно сложно рефакторить.


    Код ни в коем случае не должен считаться плохим из-за того что в нём не хватает паттернов. Паттерны — это не цель, а средство.
    Иерархичность — есть немало фанатов которые доводят здесь дело до полного абсурда и городят иерархии там где это явно излишне.

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


    Это верно, но опять-таки — главное, без фанатизма. Часто бывает так, что проект переписывается с нуля на том основании что «там всё криво». Хотя на само деле — не все так плохо, просто не любит программист изучать чужой код.
    • +2
      Было бы замечательно, если бы вы написали это автору статьи в виде комментария к оригиналу статьи. Паттерны разумеется не цель, но плохой код обычно их не содержит. С другой стороны, хороший код их содержать не обязан, однако я слышал интересную мысль о том, что хороший программист использует паттерны автоматически, возможно, даже не подозревая о них. Об этом, кстати, в статье тоже есть намёк.

      По поводу помойки скажу одно — я лично видел код, который проще переписать, и не раз :) Но да, конечно без фанатизма.
      • 0
        Лучше всего переписывать его в тот момент, когда приходится вносить в него изменения.
    • 0
      «Иерархичность — есть немало фанатов которые доводят здесь дело до полного абсурда и городят иерархии там где это явно излишне.»

      Это точно. Ну и в любом случае, как по мне, если говорить про иерархичность — было бы здорово следовать принципу «Composition over Inheritance».
  • +12
    По любому, каждый лентяй, прочитав статью подумал: «Да, это про меня».
  • +47
    >Хорошие программисты тратят большую часть оставшихся 90% времени на размышления, исследования и эксперименты.



  • +4
    программисты думают о работе 24 часа 7 дней в неделю

    Сомнительное утверждение, т.к. все таки неэффективно круглосуточно думать о работе. Но статья хорошая, напомнила эту статью из Joel on Software .
    • +2
      Парсер лохонулся. Ссылка не прикрепилась.
      russian.joelonsoftware.com/Articles/HighNotes.html
      • +2
        У Спольски почти все статьи супер, в своё время перечитал все.
    • +1
      Ни разу не сомнительное. Чтобы создать что-то действительно хорошее, надо быть увлеченным идеей, надо её обдумывать по дороге на работу, по дороге домой, надо прогонять множество вариантов в уме (и не обязательно это делать перед монитором).

      Чтобы реализовать что-то действительно «красиво», надо потратить много времени на проектирование и обдумывание, а это проще делать, когда не видишь перед собой экран. В идеале лучше сесть в кресле, закрыть глаза, расслабиться и просто думать. Потом взять листок бумаги и на нём изложить свои мысли. И только после этого садиться за компьютер.

      Более того, обдумывание в режиме 24\7 позволяет не упускать проблему из головы, потому что стоит отвлечься и уже надо заново вспоминать на чем остановился. У меня не раз было такое, что решение проблемы, которую пытался решить несколько недель приходило во сне!
      • +4
        Доска с маркерами офигенно помогает, кстати. Сам не верил, пока не попробовал.
    • 0
      Речь идёт скорее не о работе, а о размышлениях о текущей задаче. Я регулярно ловлю себя на мыслях о текущих проектах, о том, что вот это было бы неплохо сделать так-то, а вот то, наверное, лучше убрать, здесь переписать, а там подправить. Общие абстракции, только и всего. Реально помогает найти правильное решение.
      • 0
        А я регулярно ловлю себя на мысли, что когда использую «оперативную память в голове» в нерабочее время для проектов, то превращаюсь в прокладку между компьютером и стулом.
        При таких делах все валится из рук, не только на работе.
  • +85
    • 0
      гм, в ващем варианте отладка равна кодингу.
      а обычно случаются резкие перекосы как в одну, так и в другую сторону.
      Зависит от первоначального обдумывания и подготовки
      • 0
        думаю, это усредненные значния
        • +1
          Скорее не усредненные, а взятые из головы :-)
    • +23
      В пределе высокоуровнеый программист просто сидит в кресле и медитирует, да.
      • +2
        Венец эволюции, да :)
        • +11
          Это еще не венец. Настоящий гуру не пишет код — он его удаляет. С сохранением функционала, естественно ;)
          • +6
            У математиков наоборот :)

            Хорошему математику нужна доска и мел. Плохому — ещё тряпка
      • 0
        эх, а у нас отчетность по времени :(
        • +1
          хорошо что не по количеству кода
      • +1
        Надо справа в график добавить маленький треугольник медитации надо своим кодом
      • +1
        И в реальной жизни не существует. Это такое же понятие, как КПД=100% или абсолютно чёрное тело.
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0


        Техническая система идеальна, если ее функция выполняется, но самой системы нет. :)
      • 0
        Это называется программирование без сайд-эффетов
    • –3
      Очень и весьма неправдоподобная схема. Хороший программист дает больше (годных) результатов, и плевать какое у него отношение чего к чему. Иначе говоря, если у программера больше кодинга+отладки, чем обдумывания, это еще не значит что он хуже, чем тот который ТАК много (долго?) думает. Есть в конце концов TDD, в котором обдумывание происходит во время кодинга (попробовал — получилось — оставил).

      Опять же, чем выше уровень тем меньше думать над тривиальными решениями, а новые велосипеды сложные задачи не так часто попадаются.

      Считаю что при увеличении уровня пропорции остаются такими же, а растет только количество результатов за единицу времени.
      • 0
        Как вы заметили на схеме результатов нет, поэтому ваш вывод о неправдоподобности неверен.
        Можно добавить третье измерение — качество результата, но там ничего особо интересного не будет — просто растущая кривая.
        • –16
          Качество результата (субъективное понятие) должно быть уже включено в кодинг. Ведь в результате мы считаем полностью готовый код, нет? Иначе это всё равно как сказать «я набираю 300 знаков в минуту, только херня выходит».

          Мне кажется что правильная схема выглядит так:

          И, имхо, это вполне логично, что кодинг, он же результат (!) работы программиста, тем выше, чем выше его скилл. И наоборот, будь ты хоть семи пядей во лбу, без результатов ты только теоретик. Любой практик (пускай и наступающий на свои грабли, но выдающий в итоге больше результата) окажется полезнее чем такой «высокоуровневый» философ.
          • +6
            не путайте кодеров и программистов. для кодера ваша схема верна.
            • +1
              А какие же у программистов цели? разве не получение кода?
              Не путаете ли вы программистов и «архитекторов»?
              • 0
                Зависит от размера проекта и его структуры. Если проект маленький — на человека, или модульный, где отдельные модули пишутся отдельными программистами, то там программистом сам себе архитектор и сам себе кодер.
                • +1
                  Как утверждает википедия
                  «Программист — специалист, занимающийся написанием программ для ЭВМ[1], т.е. программированием.»
                  Собственно написание кода это и есть плод работы данного специалиста.
                  OleGG как-то нездорово дифференцирует «кодеров» (типа обезьяна с печатной машинкой) и «программистов» как высокоуровневых существ управляющих осмысленным поведением первых.
                  Хотя на самом деле это одно и тоже.
              • +2
                мне почему-то казалось, что у программистов цель достичь результата, а не процесс (читайте как способ) достижения результата (код).
                • 0
                  Как правило каждый новый проект на 80% состоит из рутины, которую писать неинтересно, но надо. И если большую часть времени над этой рутиной думать, то ресурсов нужно будет нереально много. При этом поручить рутину младшеньким тоже не правильно — совокупность мелких решений влияет на общий дизайн и нужно учитывать все эти ньюансы.

                  Такое впечатление, что никто из минусовавших не пробовал TDD. Мозгование в TDD не занимает много времени — пиши работающий код с тестами, потом рефактори — а результаты обычно выходят скоро и качественно. Легко тестируемая архитектура и есть обычно самая лучшая. А все эти «неделю мозгую а потом за день напишу больше чем все вместе взятые» — ерунда, таких программистов нужно гнать в шею. Их «рожденный теорией идеальный» код обычно не идеальнее, чем «быстро написанный и отрефакторенный», но определенно в два-три раза дольший по времени.

                  Нет я не говорю что всегда надо писать быстро, но комплексные решения не каждый день перепродумывается, чтобы 6/8 времени в день просиживать на кухне.
                  • 0
                    80% рутины получается как раз если не думать. А если думать, то ее будет процентов 20. Как раз самое то, чтобы дать мозгам отдохнуть (или чтобы посадить на эту рутину студента).

                    И если думать, то и тесты будут куда как более адекватными. Видал я результаты бездумного применения TDD — жалкое, душераздирающее зрелище!
          • 0
            Я лучше пять часов подумаю и потом за 20 минут напишу более функциональный код, чем получился бы, если бы я все 5 часов просто кодировал. Он еще и в двадцать раз короче при этом получится.
            • +1
              Интересный вы работник. Смотрите, 20 минут писанины и 05:20, разницей будет некоторое увеличение функционала. При этом учитывая то, что за 20 минут вы набросаете скажем максимум 150 строчек, то лишнего функционала у вас там слишком много и не будет, плюс это еще неизвестно нужен ли он (сэйлзам) или нет. А теперь скажите, кто ценнее, вы — который за целый день сделал рядовую фичу «архикачественно» или другой который за то же время сделал 8-16 таких рядовых задач? Если кажется что вы всё еще круты, то ответьте на этот же вопрос учитывая что такой же показатель держится целый год (т.е. условно говоря качество кода других не так уж и далеко от идеального, либо его модно быстро модифицировать под новые требования).

              Вы тратите время комманды на то, что интересно лично вам. Другим это тоже было бы интересно, но они в это время заняты рутиной, которая по закону Парето составляет 80% проекта и, соответственно, сдвигает его вперед в 5 раз быстрее чем вы с глубоким копанием.
              • +1
                Вы о программировании говорите, или о формошлёпстве? К формошлёпству ваши слова еще (с очень-очень большой натяжкой) применить можно. К программированию — нельзя.

                Я пишу компиляторы. Так что, соотношение именно такое, как я описал. Или я сяду тупо кодировать какую либо ad hoc оптимизацию, которая мне в башку пришла, или даже известную оптимизацию, но сделаю в лоб, то получится много весьма бестолкового кода. А если я сяду с бумажкой и ручкой, и буду долго думать, то в конце концов получится 100 строк очень качественного, вылизанного кода, которые будут делать ту же оптимизацию, но гораздо эффективнее.

                К вопросу о рутине — я её автоматизирую. Я подумаю пару часов и за 10 минут сделаю автомат, который одну и ту же рутинную операцию потом будет месяцами выполнять, и это намного лучше чем если я каждый день на эту же рутину буду тратить час.
      • 0
        TDD на ранних стадиях действительно увеличивает количество времени на кодинг, но это не должно, по-моему, быть в порядке вещей. В целом я пришел к выводу, что TDD может существенно замедлить работу, т.к. начинаешь уже каждую пустяковую функцию и алгоритм, который первый в голову придет, втыкать(отлаженным) в код. По идее этот недостаток больше относится к платформе, на которой работает программер, а не к самому программисту. Это опять-таки мо1 мнение.
    • +3
      Супер-программисту уже не надо писать код!
      Он думает-думает-думает, а потом компилирует и исполняет его прямо в голове!
      • 0
        и сидит медитирует…
      • +3
        А вот не поймает где-нибудь исключение — и одним супер-программистом меньше.
        • НЛО прилетело и опубликовало эту надпись здесь
      • +2
        за него будут набирать код плебеи)
    • +2
      По графику видно, что как не крути, с работы пораньше не уйдёшь.
      • 0
        Ну, график несколько некорректный. Многочисленные измерения показывают, что средний инженер продуктивен в лучшем случае 4 часа в день. Остальное время он пинает балду, чаи гоняет, делает вид, что думает (без результата), интернет читает, журнальчики. Если всю эту деятельность исключить, то можно уходить домой и раньше.
        • 0
          В идеале (или в европейских странах). А так время на работе у нас const.
  • +14
    Вот самая удачная аналогия программистской работы, с которой я сталкивался.
    • +2
      считаю это шедевром аналогии =)
  • 0
    объясните мне, пожалуйста, как вот это утверждение:

    Программист тратит 10-20% своего времени на написание собственно кода, и большинство программистов пишут всего 10-12 строк кода в день, которые попадают в конечный продукт, независимо от их уровня.


    может сосуществовать вот с этим утверждением:

    Хороший программист в 10 раз более продуктивен, чем средний. Отличный программист в 20-100 раз более продуктивен, чем средний.


    поясню мысль — если любой программист, независимо от уровня, пишет 10-12 строк в день (которые попадают в конечный продукт — !), то откуда вообще берется разделение good — bad — ugly?
    • +5
      продуктивность программиста вообще никак не зависит от количества линий кода
      • 0
        ага, только вот количество линий кода зависит от продуктивности.
        • +3
          В 500 строках может быть «больше» чем в 4000
          Именно по продуктивности.

          Насколько «размазанный» код с кучей ненужных действий и переизобретанием встроенных функций языка возможно писать я просто не представлял, пока не увидел несколько реальных примеров
          • +4
            Это видимо пошло с тех времен, когда какой-то идиот придумал оплачивать работу программистов по объему кода
            • +1
              Да ладно, еще с тех времен, когда издатели додумались платить писателям и поэтом за число строк.
            • –1
              Это пошло с тех времён, когда какой-то идиот придумал copy and paste.
    • 0
      В оригинале написано «большинство программистов», где вы там увидели «любой программист, независимо от уровня»?
      • 0
        надо думать, что плохих программистов заметно больше, чем хороших, а отличных еще меньше, поэтому в понятие «большинство» попадает действительно практически любой программист, ну разве что за исключением совсем уж нулевых вариантов.
    • +1
      Функциональность не пропорциональна числу строк кода.
  • –14
    У трусов популярностью пользуется слудющее изречение: «Искусный полководец одерживает победу без боя. Величайший воин не воюет».
    У туповатых программистов, которые не могу писать в день больше 12 строк хорошего кода, теперь тоже есть, что процитировать.
    • 0
      Считай, что ты низложен:)
    • +1
      вот смотри пример по поводу войны — одержать победу над 5000 вражеских солдат, положив при этом столько же своих, или получить желаемое без потерь вообще — что более продуктивно?)
      • –2
        Если я отвечу, это как-то повлияет на то, что трусы любят изречение?
        • 0
          не знаю… в принципе да… изречение на мой взгляд правильное, но им слишком удобно прикрываться))) хотя мне кажется трус хоть с боем, хоть без боя победы не одержит)
      • +1
        Продуктивнее получить желаемое без войны. Но это уметь надо.
  • 0
    пошёл увольняться…
  • –1
    Я — плохой программист. Пишу много оптимизированного многопоточного SIMD кода. Сложного для понимания и поддержки. Часто много времени трачу на отладку и мало на обдумывания, так как обычно сразу выбираю оптимальный вариант. Без измерений и обоснований.

    • –1
      Вы скорее из другой области, вы — инжинер(-программист). В инженерии все такое, взять те же драйвера.
  • –1
    А можно ссылку на оригинал?
    • +1
      Под топиком, где написано «Дэвид Векслер» и стрелочка нарисована — как раз и есть ссылка на оригинал.
  • –2
    Эта статья заставляет меня верить что я хороший программист.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Восхищаюсь программистами! Еще в Фидо читал рассказ «История одного байта». Производит впечатление!
    • 0
      Ну то про однокристалки с 128 байт ОЗУ и 4К ПЗУ. Там если не будешь экономить байты — вообще ничего не заработает.
  • 0
    Написал 12 строк, чувствую себя профессионалом, до вечера буду думать!
    • +3
      >Написал 12 строк, чувствую себя профессионалом, до вечера буду думать!

      Обычно нужно наоборот. Сперва думать, потом — писать :)
  • 0
    Походу, то ли производительность повышается, то ли погрешности измерений…

    Лет 10 назад читал исследование, по которому получалось, что средний квалифицированный программист пишет 8 итоговых строк проекта за день. Правда, подразумевалось не буквальное написание за день, а отношение числа строк в готовом проекте, поделённое на время написания и число программистов.

    У меня, я как-то, несколько лет назад подсчитывал суммарный объём кода за пару лет работы, как раз 12 строк в день вышло :)
    • 0
      У меня одно время была продуктивность в минус пять сотен строк в день. Код чистил.
      • 0
        Ну, вот поэтому я и брал период за несколько лет :)
        • 0
          У меня как раз за несколько лет такая продуктивность и была. Код с Fortran 77 на C++ частично переписывался (а местами и на C#).
  • 0
    10-12 строк кода — это уже во время сопровождения системы.
    Когда создается новый функционал, кода неизбежно будет много больше.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.