Пользователь
0,0
рейтинг
22 марта 2010 в 19:56

Управление → 5 стадий некомпетентности программиста перевод

GTD*
Раз за разом я вижу отблески самого себя в «молодых» программистах. Они сражаются с теми же концепциями, что и я когда-то, попадают в те же ментальные ловушки и, в общем-то, делают те же ошибки. Написав пост 4 wrong ways, я задумался, насколько распространены эти ошибки, и можем ли мы их категоризировать. Я попадался в каждую из этих ловушек хотя бы раз, в некоторые по нескольку и видел те же ошибки у других.


Новичок-энтузиаст


Новичок полон страсти к его единственному языку программирования, которым, несомненно, является VB, PHP или actionscript. Наконец, овладев синтаксисом этого языка, он чувствует, что полностью изучил его. Новичок пишет невероятно быстро, но получается один огромный файл с кучей глобальных переменных. Это очень продуктивная стадия, если всё, что вам нужно — это игра «змейка» или несколько небольших утилит.

Отличительные особенности кода: Каждая программа — один файл, содержащий сотню глобальных переменных, ни одна из которых не длиннее четырех символов.
Ошибочное мнение: Программирование — это очень просто.
Подкупающая черта: Мелкий трепет каждый раз, когда он открывает IDE и пристально смотрит на пустой проект, полный потенциала.
Читает: Fan fiction.
Скорее всего скажет: «Вы только посмотрите на эту крутую флэш-игру, что я только что закончил!»

Подающий надежды гений


После нескольких лет программирования, освоив второй язык, подающий надежды гений твердо уверен, что он — Мессия мира программирования. Он убежден, что всё, что он не понимает (т.е. почти всё) — бесполезно, устарело или просто пустая трата времени.

Отличительные особенности кода: Использует собственную реализацию класса Vector. Начинает имена классов со своих инициалов.
Ошибочное мнение: Всему миру нужно научиться гораздо большему от него, чем ему от всего мира.
Подкупающая черта: Его так просто обидеть и заставить уйти в глухую оборону, упомянув что-либо, в чем он плохо разбирается.
Читает: Свой собственный блог.
Скорее всего скажет: «Ха, ну конечно же, все знают что функциональные языки программирования бесполезны для решения *каких бы то ни было* *реальных* задач!»

Поборник абстракции (Abstraction Freak)


Через некоторое время все программисты начинают осознавать, что они начинают каждую новую flash-игру, копируя 90% старой. Неожиданно им кажется, что они могут написать «супер»-движок, и тогда создание новой игры станет вопросом подбора спрайтов и написания конфигурационного файла, содержащего правила! Воодушевленный успехом, программист начинает верить, что архитектура любой программы должна быть обобщена, потом обобщена и, наконец, обобщена еще раз… К несчастью, придерживаясь этого правила слишком долго, программисты превращаются в поборников абстракции.

Отличительные особенности кода: Добавляет пять новых классов каждый раз, когда реализует новую функцию программы, и каждый из этих классов содержит в названии примененный шаблон проектирования и никакой информации о том, к какой функции программы они относятся. Любая бизнес-логика приложения спрятана в каком-то конфигурационном xml-файле где-то в репозитории.
Ошибочное мнение: Написать программу, которая интерпретирует набор конфигурационных файлов, неуклюже и с кучей ошибок описывающих программу, лучше, чем написать программу, которую нужно написать.
Подкупающая черта: Выражение болезненной концентрации на его лице в то время, как он борется с параличом анализа кода, незадолго до того как переписать функцию входа в систему четвертый раз за месяц.
Читает: Шаблоны проектирования, от корки до корки, каждый день вместо обеда.
Скорее всего скажет: «Я думаю, что мы должны начать новый проект по учету рабочего времени с написания обобщенного фрэймворка для приложений...»

Ветеран


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

Отличительные особенности кода: Первые десять строк любой функции, даже геттера или сеттера, содержат исключительно assert'ы. Все исключительные ситуации и негативные сценарии тщательно обрабатываются, комментарии щедро раскиданы повсюду.
Ошибочное мнение: Делать вещи «правильно» — это то же самое, что и сделать то, что нужно, только лучше.
Подкупающая черта: Аура взвешенности и спокойствия, которая даёт понять что даже в случае жуткой необходимости он не будет работать быстрее, оставляющая ощущение что ему бы лучше работать мастером бонсай, а не программистом.
Читает: joelonsoftware.com (да, даже после того, как Джоел перестал писать)
Скорее всего скажет: «Ну, я не смогу назвать сроки, пока я не подготовлю должным образом оценку на следующей неделе, но это будет… будет… [втягивает воздух сжатыми губами]… В общем, на реализацию предпросмотра перед печатью потребуется не меньше четырех человеко-месяцев, без тестирования и документации, конечно же.»

«Гуру»


После десятка лет скаканий от одного стереотипа к другому, наш новичок вырос и чувствует себя пустой раковиной от того энтуазиаста, которым он когда-то был. Однажды утром он просыпается и осознает, что огромная куча unit-тестов, assertion'ов, проверок и навыков проектирования, которые выросли вокруг его стиля — просто костыли. Костыли, которые тяготят его и которые ему вовсе больше не нужны! Он отбрасывает их и начинает писать такой простой и «голый» код, какой он только может придумать, лишь бы сделать именно то, что ему нужно! Свобода для новых функций! Свобода кода! Свобода!

Отличительные особенности кода: Пишет только на динамически-типизированных языках с сильно выраженной функциональной составляющей. Его код сильно похож на код новичка, за исключением того, что самого кода меньше, да и наименования переменных имеют смысл.
Ошибочное мнение: Думает, что его просветленность делает из него гуру без кавычек.
Подкупающая черта: Небольшой трепет каждый раз, когда он видит интересную проблему, которую он мог бы решить «всего шестью строками» кода.
Читает: news.ycombinator.com/newest
Скорее всего скажет: «Вы знаете, полиморфное наследование, на самом деле — жалкая замена функциональным литералам и динамическому типизированию.»


И… Вот она, моя карьера программиста как она есть. Мне интересно — кто-нибудь прошел те же стадии?
Перевод: coderoom
Виктор Билык @victorb
карма
133,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +124
    Какие-то они все у вас мудаки получились.
    • +16
      Ну не у меня, всё-таки, это же перевод.
      • 0
        У меня около десятка знакомых программистов, которых я хорошо знаю, все они разные и ни один не подходит под эту классификацию.
    • +9
      Я видел много программистов. Вот эти гуру думающие рекурсивными комбинаторами и спящие с Art of Metaobject Protocol под подушкой — это стереотип. Чтобы получить представление, как работают хорошие программисты и о чем они думают очень советую книжку Coders at Work. На русском её пока нет к сожалению.

      Новички — новички перегибают палку. По-разному. Слишком много оптимизируют, абстрагируют, защищаются от ошибок. Или наоборот, вообще не делают этого. Главное для новичка не запутывать себя принципами «правильного» программирования, не слушать бездумно знатоков, нужно самому разбираться и делать выводы, что работает, а что нет. Я вижу как люди начинают городить абстракции, запутываются. Они и видят что это не работает, но не могут себе признаться в этом. Их научили как «правильно», и все тут.
      • +2
        Думаю, что защита от ошибок не является отличительной чертой новичков.

        Автор (не переводчик) достаточно зло написал, нашел в себе некоторые черты из всех 5 стадий:)
        • +3
          Э не. это вы зря. :)
          Я на заре своей карьеры вдруг резко осознал, что мой код слишком часто падает в ошибки. В результате, один из проектов над которым я работал-превратился в сплошную проверку на ошибку.
          В итоге он точно также работал через маленькое черное отверстие, но все ошибки выводились в виде «Ошибка 1001-1600»
          только таблицы ошибок я так и не составил :))
          • +1
            Зависит от инструментов и ситуации. Я на закате карьеры в Сбере писал на VBscript сортировщик входящих файлов — рассылка по почте, раскладывание по папкам. Вещь важная, поэтому почти над каждой строчкой приходилось фантазировать, какой sh!t может happens. А уж эмулировать те или иные ошибки, чтобы проверить, как работает программа — это отдельная песня.

            И кроме подробного лога, который вела программа, приходилось еще рассылать сообщения админам почтой, на случай если что-то все-таки упадет.
          • 0
            Зависит от инструментов и ситуации. Я на закате карьеры в Сбере писал на VBscript сортировщик входящих файлов — рассылка по почте, раскладывание по папкам. Вещь важная, поэтому почти над каждой строчкой приходилось фантазировать, какой sh!t может happens. А уж эмулировать те или иные ошибки, чтобы проверить, как работает программа — это отдельная песня.

            И кроме подробного лога, который вела программа, приходилось еще рассылать сообщения админам почтой, на случай если что-то все-таки упадет.
    • 0
      Это стадии, которые открыл в себе автор, частный случай.
  • +13
    Себя до конца не узнал ни в одном из образом. Видимо, уже нирвана.
  • +27
    Интересно. Судя по-всему, я пока поборник абстракции.
    • 0
      Узко написано.

      Можно быть поборником абстракции без этих загонов и лишних классов.
    • 0
      Я, судя по всему, тоже. Поборник абстракций, любитель неоправданно сложной архитектуры, предусматривающей дальнейшее превращение змейки в 3D-шутер. Радует то, что осознание проблемы — первый шаг к ее решению.
  • +10
    А по-моему век живи — век учись, а зазнаек везде хватает.
  • +12
    Узнал себя в Abstraction Freak'e, улыбнулся и… задумался
    • НЛО прилетело и опубликовало эту надпись здесь
      • +4
        Я вот думаю. Может и мне поплакать?
        Я переписываю Класс работы с консолью Unix в какой раз…
        • +1
          один класс? тогда вы не он, он же должен был сразу наворотить десяток…
    • +2
      Аналогично. Добило «читает шаблоны проектирования» и про «универсальный движок».
      Желание все на свете обобщить очень мешает, больше времени проводишь где-то в облаках, абстрагируя все на свете, вместо того чтобы писать код, который решит твою проблему.

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

      Нужно выползать из этой стадии потихоньку :)
  • +4
    Застрял на «Ветеране». Не настолько комично, конечно, но отчасти узнаю самого себя.
    И, да, никогда не начинал и не буду начинать имена классов с собственных инициалов. Считаю, что за такое нужно сразу больно бить линейкой по рукам, как в школе.
    Вообще всё несколько преувеличено, на мой взгляд. Но, да, типичные ошибки как на ладони =)
    • 0
      Я тоже не начинал, однако видел, по крайней мере, одного такого человека. Надо ли говорить, что от использования таких классов бежал как от огня.
      • –7
        А я не понимаю. Почему?
        Если, например, своя реализация списка или стека, почему бы не пометить её своими инициалами? Чтобы не путать с тем же STL.
        • +4
          Ничего не знаю о ваших реализациях стека и списка, хотя сам факт их наличия, как бы это сказать, немного смущает. В том же конкретном случае, к инициалам в именах класса прилагались симптоматичные для «подающего надежды гения» забавные конструкции, включая System.exit(1) в catch-блоках, которые, например, тихо и молча тушили tomcat без единого писка в логи.

          Да и вообще, логика такова, что именам классов подобает отражать их назначение и содержание. Если же у списка или стека единственной особенностью является автор, то не понятно их назначение, если же нет — то почему не намекнуть на их назначение или особенности в названии класса?
        • +3
          @author
        • 0
          потому что как правило ваши инициалы не имеют отношения к сущностям и предметным областям описываемым кодом.

          *ваш КО*
      • 0
        В если namespace называть своими инициалами, это ничего? А то я уже о себе плохого мнения стал как-то ((((
    • +1
      А я-таки начинал (для своей СУБД на PHP :))
    • +3
      Я в детстве, когда только начинал программировать(на VB =) ), называл все переменные циклов ilya, по своему имени, потом сократил до i. Очень удивился, когда увидел, что большинство тоже называют переменные буквой i.

      А уже недавно, когда писал открытый проект, наткнулся сруза на двух человек, которые начинали названия классов с фамилии…
    • 0
      А я вот вынужден называть классы с префиксом так как сейчас пытаюсь ковырять юнити 3д и оно не поддерживает неймспэйсы :(
  • 0
    Возникает вопрос «А где тут я то?»
    Уж точно не в финале :)
    • 0
      угу, я тоже где-то между 3 и 4 застрял походу…
      Вообще тут конечно крайние случаи, и все это не исключает в конечном итоге работающей программы, главное исходники не смотреть ;)
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        А вы сходите к админам, ага. С такими словами вы от них никаким пивом не откупитесь. Вы говорите о функциональности, а им приходится набивать шишки об нестабильность.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +2
            + «Если проблему грамотно промариновать, она решается сама...» :)
  • +1
    У меня в коллективе из пяти человек программистов все пятеро попадают под разные категории из статьи :)
  • +2
    В каждом пункте есть я сейчас, я никогда и я иногда. Так что это не общие стадии, а исключительно Ваши.

    Кучи глобальных переменных не было. Вообще назвал переменные непонятно как только в начальную пору школьных олимпиад по информатике.
    По-прежнему считаю, что программирование — это просто. Но что-то в последнее время стал чаще удивляться тому, что некоторые так не считают.
    Fan fiction — отличный жанр.
    На VB, php и actionscript не писал.

    Вектор до сих пор собственный пишу когда надо. Долго искать же.
    Блога никогда не было.
    Никогда не считал, что функциональные языки не для реальных задач (вообще, с чего это).

    Человек, свихнувшийся на абстракциях — это фрик. С чего бы это здравомыслящему человеку лепить тонну классов вместо одной функции? В крайнем случае можно написать в функциональном стиле. Куча xml файлов — это тоже жесть какая-то.

    Вот ветеран — это да, это весёлый образ.

    Почему после него — «гуру», который вовсе и не гуру, а очередной фрик, только уже по динамическому типизированию?
    • 0
      В оригинале так и было «Abstraction freak», а гуру он совсем не зря в кавычках.
      • 0
        Вопрос не в том, почему он гуру, а в том, почему он после ветерана.
        Это, имхо, скорее 3 стадия, ещё до фрика абстракций.
    • 0
      Программирование — это на самом деле сложно. Просто 90% задач не требуют под собой ничего кроме обычного кодирования набора правил.
  • 0
    А я — тот, кто не похож ни на одного из списка, хотя программирую уже лет 5.
  • +2
    очень похоже что я Abstraction Freak ))
    • НЛО прилетело и опубликовало эту надпись здесь
  • +16
    Это напомнило одну историю из Дао Программирования:
    Однажды был мастер программист, который писал неструктурированные программы.
    Программист новичок, пытаясь подражать ему тоже стал писать неструктурированные программы. Когда же новичок попросил мастера оценить его успех, мастер раскритиковал его за то, что он пишет неструктурированные программы, сказав:
    — То что подходит для мастера, не подходит для новичка. Ты должен понять Дао, прежде чем переступать через структуру.
  • +2
    Какие-то сомнительные этапы местами. «После нескольких лет программирования, освоив второй язык» — что, программист развивается через выучивание языков одного за другим? Это фигня какая-то получается…
    • 0
      просто редко кто начинает с изучения нескольких языков одновременно
      • 0
        Редко кто учится в вузе?
        • +1
          В вузе тож не всегда начинают программирование сразу с примеров на нескольких языках. Хотя, бывает, что не может не радовать. Да и программировать программисты частенько до вуза начинают…
          • 0
            Ну, например у нас просто не было единой согласованной программы на этот счёт, поэтому каждый преподавал то, что знал=)
          • 0
            У нас (МЭИ АВТФ) был (1998-2003) по сути 1 основной язык: С++, хотя некоторые лабы писались на c (gcc под linux), bash. Кроме того, приходилось писать на delphi, VB, C++Builder, FoxPro (СУБД). Кроме того: VHDL, ASM. Факультативно Java.
  • +2
    Судя по последнему пункту, все сишники у нас в компании- ветераны :)
  • +2
    А может всё-таки в «Юмор»?
  • 0
    Был поборником абстракции, работаю в одной команде с Ветераном, становиться «Гуру» не хочу :)
  • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    Как фрилансер я просто не смогу получить левелап до Ветерана :)
    • +1
      Это исключительно вопрос наличия толстого бумажника у заказчика и желания у него работать с вами по почасовке. :)
  • +3
    А я настолько обленился, что ушел в дауншифтинг и программирую в уме.
    • 0
      Причем удовлетворение приходит уже после того, как я мысленно доказываю сам себе что да, эта концепция вполне реализуема вот таким вот наиболее оптимальным способом. И за ноутбук уже садиться не хочется.
      • 0
        Часто наблюдаю таких теоретиков.
        Особенно весело наблюдать как после долгого отрыва от реальности внезапно осознают что ни#уя не могут сделать, а могут только теоретизировать.
        Это мило :)

        Но надо признать что трудно их заставить хотя бы попробовать.
  • 0
    Как-то получается, что мне больше подходит «ветеран».
  • +3
    Прочитал все и задумался может я просто не программист, но таких ярко выраженных особенностей в себе не наблюдал. Хотя занимаюсь разработкой ПО уже порядка 10 лет. Правда я никогда не работал в крупных компаниях, возможно поэтому все стадии прошли для меня стороной и сохранился энтузиазм…
    У меня были другие болезни — был ярым C++-шником долгое время, считал все остальное недоязыками. Сейчас конечно более взвешенно отношусь, и использую то что лучше подходит для конкретной задачи.
  • +2
    Знаете, это скорее описание этапов взросления человека, нежели чем описание подъема программиста над собой.
    • +1
      Вообще там написанно, что это 5 стадий НЕкомпетентности, так что про подъем над собой говорить сложно, по-моему…
      • 0
        «В иерархической системе любой работник поднимается до уровня своей некомпетентности» Принцип Питера

  • +4
    Что мне всегда не нравилось в этих обзорах, так это то, что авторы всегда пишут с позиции, как бы позволяющей оценивать самый верхний уровень компетентности. То есть по сути находясь выше даже самого верхнего уровня. Ну а дочитав данную конкретную классификацию до последнего пункта, стало очевидно, что автор — восторженный новичек в каком нибудь динамическом языке (судя по ycombinator.com это скорее всего лисп).

    Дальше можно начать вечный холивор на тему dynamic vs static typing, вот только сейчас это неактуально — динамические языки пытаются ввести опциональные статические аннотации (без которых средний чисто динамически типизированный язык проигрывает среднему статически типизированному по эффективности не то, что в несколько раз — на несколько порядков), в статических языках есть type inference (типизация Хиндли-Милнера) и универсальный тип. Говорить же о том, что first-class functions являются преимуществом какого нибудь языка — это явная глупость, потому что они сейчас есть вообще везде (ну кроме Java, разве что).
    • +1
      Вероятно, автор (оригинала) опустил 6-ю стадию на которой программист пишет подобную статью: )
  • +1
    По моему я ветеран.
    Как же тяжело дописывать и переписывать за поборниками абстракции. Особенно когда в самом коде нет бизнес логики.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Еще один! Да я половину слов не понял из вашего комментария. Кому и почему грустно от появления дикой абстракции в изначально процедурно-ориентированном языке?
        • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    >Начинает имена классов со своих инициалов
    Ничего не вижу в этом плохого, сам те классы, которые переношу между приложениями называют Rk_Что-тоТам, например Rk_Tree, Rk_Transactions.
    Так проще отделить свои классы и их библиотеки от чужих, да и название как бы говорит: этот класс делает то-то и написан тобой.
    • НЛО прилетело и опубликовало эту надпись здесь
    • +8
      Авторство нужно приписывать в комментариях.
      А для логического деления в нормальных языках есть namespace, package в Java, хотя бы просто в отдельную папку положить.
      Да и часто надоедает писать этот префикс перед каждым обращением к класу.
      Хотя каждому свое, этой факт :)
    • +1
      … А теперь представьте, что с Вашим классом работать другому человеку. Для него не очевидно, что этот класс делает «то-то», и уж тем более, его писал не он. Подобные вещи решают ежеминутные задачи конкретного человека, но вносят дизинформационный момент в проект в целом.
      ИМХО.
    • 0
      Если вам так хочется, то для таких вещей люди придумали:
      /**
      *@author Ваши инициалы
      */
      А вот называть классы своими инициалами, действительно очень плохой тон!!!
  • +1
    Т.е. даже гуру ошибается? А гдеже дзен?
    • +1
      Ошибаются все.
      Дзэн не в отсутствии ошибок, а в принятии того факта, что они могут быть.
      • 0
        Осознать ошибки самое сложное. Так если ты их осознал, значит ты их больше совершать не должен. Ошибок не бесконечное число, значит совершенство есть)
        • +2
          Мудрый программист говорит о Дао и следует ему. Средний программист говорит о Дао и ищет его. Глупый программист говорит о Дао и смеется над ним. Если бы не было причины для смеха, то не было бы и Дао.
          Высокие звуки сложны для восприятия. Движение вперед — путь к отступлению.
          Великий талант проявляется в конце жизни. Даже совершенная программа по-прежнему содержит ошибки.


          Из того же Дао программирования :)
  • 0
    А я считаю, что у каждого свой путь. Как нет одинаковых людей, так нет и одинаковых программистов. Потому вчитываясь каждый раз в подобные описания, я вижу лишь личное мнение автора или мешанину из случайно подобранных высказываний.
    • 0
      Я согласен с вами, но не полностью.
      Я считаю что определенно программист проходит такие уровни:
      1 боящийся всего новичек
      2 средний по знаниям прогер, в основном с звездной болезнью
      3 профи

      Дело в том, что некоторые просто задержались на одной стадии и сидят там)
      • 0
        Этапы становления личности — это ведь не описания… Хотя в чем то и я с вами согласен — многие реально замыкаются на одном этапе.
        Кстати, в вашем 3 пункте я бы разбил на два подпункта, но это не столь важно :)
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Т.е. даже гуру ошибается? А гдеже дзен?
    • 0
      Дзен — это когда ты занимаешься программизмом без компа.
  • 0
    Я уже перестал читать joelonsoftware.com. Когда я стану гуру? ;)
  • 0
    Я плакал :) До гуру, судя по всему, ещё не дошёл :)
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Легко можно, при разделении задач на двухдневные.

      Если срока я назвать не могу, называю 3 месяца, заказчик начинает понимать, что лучше дать мне другую.
      • 0
        Вернее, на очень короткие. бывают задачи на 15 минут, из которых 10 минут — на документирование её выполненности.
        • 0
          Поделить большую задачу заранее на 15-тиминутные (или даже двудневные) — без глубокого анализа не возможно, а анализ тож времени требует, и частенько должен включать попытки сделать несколько десятков первых этапов… Проще на него забить, и просто начать постепенно решать задачу.
          • +1
            Я не хотел бы вас с Zakus'ом обижать и уводить в глухую оборону, но молчать больше не могу. :)

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

            От вашего подхода к организации производства сильно несёт кустарщиной. Не обижайтесь, но ваши навыки в этой области сейчас находятся на уровне «подающий надежды гений», перечитайте.
            • 0
              Программирование — исследовательская работа, и как у любой исследовательской работы, сроки выполнения последующих этапов зависят как от результатов предшествующих, так и от исследовательской удачи, наблюдательности и ума исследователя. Кроме того, задача может оказаться вовсе не решаемой на текущем уровне развития технологий.

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

              На самом деле, неверны оба эти описания в своей категоричности, ибо программирование бывает и тем, и тем. Не зря его пытаются поделить на проектирование и кодерство. И Вы говорите больше о втором, я больше о первом. Другое дело, что эти стороны неразделимы, и чистый проектировщик как правило рискует напроектировать то, что следующему за ним кодеру придётся перепроектировать под реалии контекста… И эффективнее, если проектировщик и кодер действуют в одном лице, или хотя бы в тесном взаимодействии.
              • 0
                Согласен, что строятся абстрактные модели, прототипы, проводятся различные испытания, но это всё поддаётся оценке и всё это является неотъемлемой частью любого проекта. То что более-менее похоже на то что раньше уже создавалось оценивается более точно, то что меньше — менее точно. Не нужно из этого делать какой-то особой магии.

                Если бы в этом была некая магия, реализация многих высокотехнологичных коммерческих проектов была бы невозможна, только потому что в принципе-то всё понятно, но программное обеспечение — хрен знает когда. Люди работают, как закончат — так можем двигаться дальше. Такой подход делает невозможным любое планирование. Ну представьте себе NASA которые сидят и не запускают ракету, потому что программисты программируют и нет никаких оценок.

                Слава богу это не так.

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

                Я не люблю аналогии со строительством, но здесь они уместны. Здание начинается с эскиза, потом выбор материалов, чертежи, рассчеты, а потом уже кладут кирпич. Если используются новые материалы — они предварительно тестируются, если новые технологии — проверяются. После этого строят. В этом случае ваша фраза про проектировщика звучит примерно так «Бывают инженеры которые понарисуют таких чертежей, что потом бригадир с рабочими сами додумывают или строят по-своему», «эффективнее если рабочий сам сочиняет что строить». Это не правда. Да, действительно, можно собраться с друзьями и за выходные построить баньку на даче без особого плана, но небоскребы так не строятся. И не спорьте.

                При этом, что банька, что небоскреб, с определенной погрешностью легко оцениваются человеком который руководил/участвовал в проекте постройки баньки или небоскреба.

                А элемент «исследовательской» работы это ни что иное как то время, которое вы тратите на преобретение необходимого опыта для выполнения данной работы. Если вы уже обладаете необходимой квалификацией вы не промахнетесь в 10 раз с оценками.
                • 0
                  Этап исследовательской работы и в НАСА, и в строительстве и много ещё где — действительно часто очень сильно отделён от конкретно проектирования и реализации. В программировании софта для управления ракетами — видимо тоже. И там действительно оправдано написание кучи вариантов этого софта для отработки приёмов и выработки надёжных моделей API, по которым потом понятным и рассчитываемым образом строится ТЗ и кодеры понятным и рассчитываемым образом формируют окончательный вариант софта для конкретного применения.

                  Но не знаю уж к счастью или сожалению, подавляющее количество софта продаваемого пишется одновременно с исследованием его авторами соответствующей предметной области и ресурсов, тестируется фактически на покупателях, и практически никогда не переписывается заново и уже по плану по итогом этого изучения. И это — се ля ви, ибо бизнес.
                  • 0
                    Я пытался аппелировать к элементарной логике — нет оценок/невозможно оценить — нет плана — нет бюджета. А так не бывает, хотя бы потому, что уже готового программного обеспечения вокруг навалом и я сильно сомневаюсь что какая-то статистически-различимая его доля написана по схеме «как будет готово — так будет готово, а пока отлистывайте деньги». По вашему выходит, что заказная разработка ПО может осуществляться только по почасовке? Так это тоже не так.

                    Я могу написать проще — в сфере в которой работаю я могу оценить проект с погрешностью 10-15%. Проект в смежной области я могу оценить более грубо, но и то, скорее всего, смогу накидать смету и сроки которые позволят потом не заводить разговоры с заказчиком в духе «мы вылетели из бюджета».

                    И я, заметьте, не использовал весьма спорных аргументов в духе «подавляющее количество софта пишется так-то», ну, право, ну откуда у вас такие сведения?

                    Оправданий для невозможности оценить хотя-бы грубо (пусть 30%-40% ошибки) при наличии вменяемого технического задания нет. Если это невозможно сделать — никакого бизнеса вообще не будет. И не надо под отсутствие этого навыка подводить научную базу, используя весьма сомнительную аргументацию.
                    • 0
                      В исследовательской сфере — бюджет берётся из грантов, дотаций и премий. Посему — оплата тоже не почасовая. Но риски. И план приблизительный, с априорным закладыванием как вариативности, так и обломов.

                      И лично я уверен, что подавляющая часть готового программного обеспечения сделана именно по схеме «как будет готово», и иметь ТЗ заранее не может в принципе.

                      В сфере заказной разработки — уверен, ситуация обратная: при подписании договоров на разработку весьма часто можно иметь уже проработанное ТЗ, не требующее от исполнителя новых исследований, и целиком опирающееся на уже сформированный у него опыт и его профессиональную и адекватную оценку собственной производитеьности.

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

                Кроме того, есть метод работы, когда твой проект постоянно в рабочем состоянии (можно запустить и он будет работать), а время уходит на его совершенствование. И если не получается сделать вовремя какие-то фичи, то это не критично — в целом проект живой.
                • 0
                  Я уже лет пятнадцать довольно плотно программирую, и практически не встречал таких задач, которые уже ранее делал и могу повторить с закрытыми глазами и заранее рассчитать сроки выполнения. Единственно, в чём помогает накопленный опыт — с одной стороны быстрее искать нужную документацию, следы чужих наработок и разбираться в них, и с другой стороны угадывать некоторые грабли и тонкие места, соответственно заранее их обходя и подкладывая куда надо соломку.

                  Что касается «некоторых фич» — сами понимаете, этот подход применим далеко не всегда. Потому как без некоторых фич проект, может быть, будет и живой, но может оказаться неюзабельным и соответственно, бесполезным.
                  • 0
                    Задача может быть каждый раз совершенно новой, но методы решения отдельных под-задач могут быть идентичными. Более того, можно решать задачу не самым оптимальным (с точки зрения логики) способом, но этот способ будет проверенным и предсказуемым.

                    По поводу «фич» — если фича не выходит, то можно либо потерять только часть вознаграждения, либо договориться решить вопрос другим путем. На моей практике, в большинстве случаев заказчик даже не придирается к некоторым недоработкам, если в целом проект его устраивает. Всегда можно договориться «погонять то что есть, вдруг найдутся проблемы посерьезней». А там глядишь, и все вполне устраивает. Да, это не лучший вариант, но лучшее враг хорошего.
  • 0
    Главное это гармония.
    Дзен здесь.
  • 0
    Я не подпадаю не под одну из категорий, вернее из каждой беру что-то свое =)
    Например шаблонами я тоже увлекаюсь, но что бы лепить их в каждую программу… это уже слишком.
    Люблю изобретать велосипед =)
    Пытаюсь оставлять побольше комментов и юзать doxygen.
  • 0
    >… я задумался насколько распространены эти ошибки, и можем ли мы их категоризировать. Я попадался в каждую из этих ловушек хотя бы раз — в некоторые по нескольку, видел те же ошибки у других.

    Начинали писать о «ментальных ловушках»…

    > Вот она, моя карьера программиста как она есть.

    … закончили этапами карьерного роста.

    Даже не знаю, как оценить статью: забавная с точки зрения «ментальных ловушек» или совершенно плоская с точки зрения анализа эволюции разработчика?
  • 0
    оу… я «гуру»… радоваться или плакать?
  • 0
    > программист начинает верить что архитектура любой программы должна быть обобщена, потом обобщена и, наконец, обобщена еще раз…

    как это знакомо:) такое проходили если не все, то большинство, мне кажется
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    :) Хе-хе. Забавно.
    В первой и второй стадии я точно был. Правда, я тогда не считал себе «Мессией мира программирования» — внутренности различных либ, в которые я заглядывал, этому не способствовали. А класс SV_Vector я даже реализовывал, хотя и не лично для себя, а при выполнении лабораторных.
    А в тот момент, когда я готов был перейти в «абстракционисты», в организации, где я проходил практику, как раз создали и стали использовать фрэймворк, в котором натурально вся логика и все экранные формы описывались xml-конфигами. Поработав с этим ужасом, абстракционистом я не стал.
  • 0
    Всегда боялся стать наркоманом по части абстракции, но в последнее время идея общего движка, работающего исключительно на конфигах и не требующего вмешательства в код, все чаще меня одолевает…
  • 0
    Я узнал себя! Я поборник абстранции, только обхожусь вместо 5 классов одним и не использую дурацкие неуклюжие паттерны типа фабрик и адаптеров.

    И, почитав, следующие стадии — что то не хочется на них переходить ((.
  • +1
    Блин, я по ходу только на третьей стадии :( До гуру ещё работать и работать… Но это же и здорово, когда есть куда стремиться :)
  • 0
    Мне показалось что это не стадии которые проходит программист, а типы которые бывают. Ну, помните, как у Бидструпа с темпераментами. С грустью для себя понял, что я почти полный Abstraction Freak и даже «Паттерны проектирования» читать расхотелось :)
  • 0
    Странно, но не увидел себя ни в одной из категорий.
    Попытки писать код предпринимаю больше 10 лет, занимаюсь в основном скриптоложеством — может быть это «карма» специализации?
    Согласен, что каждый программист — отдельная «вселенная» со своими «тараканами и бабочками».
    Думаю, что часто большинство классификаций — попытка засунуть голову в песок и не решать задачу, если, конечно, клиент платит за результат, а не за классификацию.

    Есть две вещи, которые на приходится обращать внимание почти всегда:
    1. Чужой код обычно хорошо воспринимается, если начать с конца листинга.
    2. Генетически большинство программистов почти ничем не отличаются друг от друга — «все мы люди».

    Компетентность «программиста» часто определяется количеством решенных задач.
    Например при рекрутинге я использую такую схему (зачет/незачет):
    1. Опишите применяемые Вами принципы работы с файловой системой?
    2.… работы с СУБД?
    3.… работы с GUI?

    Да, я не встречал ни одного компетентного программиста, который не разбирается в «железе».
    Да, и, компьютеры не так уж и много могут, логика же двоичная, принципы не изменяются уже 60 лет :)
    Большинству «новичков» я советую больше читать, и, если еще не успели, то прочесть что-нибудь лёгкое на тему архитектуры процессора, например известного Чарльза Петцольда «КОД».
    Лично у меня после осознания «как оно на самом деле работает» пропадало желание наслаждаться «детством», зато появилось ощущение конечности познания и принципиальной возможности самосовершенствования в заданном направлении.

    Странный, конечно, комментарий, но уж — какой получился :)

    • 0
      1. Опишите применяемые Вами принципы работы с файловой системой?

      Кто-нибудь прошёл рекрутинг, не задавая наводящих вопросов? :-D
  • 0
    1С-ники поголовно гуру? =)

    Быть ветераном круто. Это когда твоя прога всегда работает, несмотря на ошибки.
    • 0
      +

      я ветеран
  • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      То же самое :)… Очень люблю функциональные языки программирование — но использую функции редко и с умом. ;)
  • 0
    > Начинает имена классов со своих инициалов.
    Даже и мысли такой не было. Откуда такие идеи появляются???
  • 0
    Чёрт, а что меня ждёт дальше после «гуру в кавычках»?…
  • 0
    Я бы сказал, что такая классификация не совсем верна. Так как не выделена черта классификации) но я понимаю, что сделано это, что называется, just for fan) поэтому было очень приятно увидеть себя почти во всех описанных стадиях)
  • –1
    Приятно узнать что ты «Ветеран».
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Спасибо автору!
    Увидел себя со стороны в разные периоды развития.
    Ждём N стадий компетентности ;)
  • 0
    Спасибо — уже между последними двумя стадиями :) всё остальное прошел :)
  • +3
    1,3,5 стадии проходил, остальное мимо. ))

    «Geek»

    После попыток «творить» приходит осознание «сроков» и «доходности», уже не важно что и на чем писать… Just For Fun )

    Отличительные особенности кода: кода мало, коментариев мало, мат в коде только по делу.
    Ошибочное мнение: вот-вот допишу и потом спать…
    Читает: написанный вечером код, удивляется и смеется с своих коментариев
    Скорее всего скажет: я незнаю этой платформы… прожект писали полгода, документации нет, ничего неработает и через 2 недели дедлайн? интересненько :P
  • 0
    Всё это откровенный стёб :)
  • 0
    скорее ветеран, чем гуру. но все к тому идет :)
  • 0
    Видимо скобочки в конце постов — отметки на линейках
  • 0
    Узнал себя некоторое время назад в поборнике абстракций :)
  • 0
    Вторая стадия. Судя по всему, пожизненно…
  • 0
    Черт,… как же все предсказуемо.
    Многое пересекается. Даже «инициалы», в свое время )

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

    В общем, по задаче.
  • 0
    Мы пойдем другим путем!
    :-)
    P.S. Как ни странно, я ни под одну Вашу категорию не подхожу.
    К сожалению, никак не выберу время написать эссе о своем взгляде на проектирование и программирование.

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