О медленном программировании

Original author: Jeffrey Ventrella
  • Translation
От переводчика: при разработке Web-payment.ru, сайта с мониторингом обменников и множеством разделов о платежных системах, я на интуитивном уровне использовал принципы, описанные в этой статье. Подсознательно я их знал, но не мог сформулировать. Предлагаю вам ознакомиться с интересным подходом, которым поделился опытный программист, автор многих книг Jeffrey Ventrella.
Мой папа часто говорил мне: «Помедленнее, сынок, ты делаешь дело слишком быстро».

Мне довелось поработать во многих высокотехнологичных стартапах в заливе Сан-Франциско. Сейчас мне 52 и я программирую медленно и внимательно. Меня можно считать кем-то вроде дизайнера, пищущего код. Читая пост дальше, вы и сами это поймете.

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

Но ничего не вышло


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

Полный бред


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

Точно так же, сколько бы вы не программировали, у вас никогда не получится создать инструмент, который позволил бы вам полноценно разрабатывать ПО с той же скоростью, что и команда манки-кодеров.

Аритмия


Моё медленное программирование в среде быстрых программистов было похоже на какую-то форму аритмии. То есть мой ритм написания кода просто растворился в итерациях других кодеров, которые строчили его как из пулемета. Мой стиль программирования предполагает абсолютно разную длительность работы над проектами самой разной сложности. Каждая ветвь начинается с исследования, проб и ошибок, хаков и временных переменных. По сути, все это можно сравнить с конструированием лесов вокруг строящегося здания. Постепенно картина вырисовывается. Немного позже, я возвращаюсь к работе, расставляю все точки над «i» и наношу последние штрихи. Результатом каждого такого сеанса творчества является что-то вроде готового к использованию кода. (Я никогда не оставляю «в мастерской» ничего лишнего после работы). Добавление в репозиторий ветки разрабатываемого кода равносильна появлению новой стратегии, схемы проекта или архитектурного объекта.

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

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

image

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

Движение за медленное программирование


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

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

Популярность разработки ПО при поддержке венчурного капитала здесь, в заливе Сан-Франциско, сейчас растет с сумасшедшей скоростью. Деньги, которые выступают в роли движущей силы, предъявляют неестественно завышенные требования к процессу развития творческой мысли, который на деле лучше всего отдать на откуп естественному биологическому ритму эволюции. Быстрее не всегда значит лучше. На самом деле, медленнее иногда означает быстрее — в те моменты, когда все обещанное выполняется на практике. О том, как цифровые технологии узурпируют наши природные временные ритмы рассказывается в книге Дугласа Рушкова Present Shock.

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

Вот почему я считаю, что нам нужны взрослые люди, женщины, педагоги и творческие люди внутри цикла разработки приложений. Больше человечных людей, меньше людей-объектов. Говорю не о влиянии таких людей на процесс извне, когда мы сажаем их в техподдержку, или поручаем им украсить дизайн интерфейса. Я имею в виду внутреннюю сторону процесса, необходимость добиваться того, чтобы программы находили отклик у всего человеческого общества в целом.

Как же я рад, что я не машинистка, печатающая вслепую


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

Моя жена часто выходит во двор и спрашивает меня: «Ты кодишь?». И часто я отвечаю, что «Да», однако на самом деле, в такие моменты я, как правило, обрезаю ветки секатором или вожусь с компостом.

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

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

Web-payment.ru
Отраслевое финтех СМИ
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 57

    +18
    Статья интересная, но на мой взгляд автор все-таки уходит в другую крайность от тяп ляп и в продакт. Вспоминается эпизод в «автостопом по галактике», про разбившийся корабль менеджеров и рекламных агентов, где они бесконечно планировали и проводили совещания вместо того чтобы просто нарубить дров и собрать еду. Перепланирование, так же плохо как и попытка все решить наскоком.
    Перефразируя Энштейна «объяснять надо просто настолько это возможно, но не проще», «разрабатывать надо быстро насколько это возможно, но не быстрее», в смысле скорость разработки должна быть максимальной, но только пока она не влияет на качество разработки.
    • UFO just landed and posted this here
        +1
        Мой стиль программирования предполагает абсолютно разную длительность работы над проектами самой разной сложности. Каждая ветвь начинается с исследования, проб и ошибок, хаков и временных переменных. По сути, все это можно сравнить с конструированием лесов вокруг строящегося здания. Постепенно картина вырисовывается. Немного позже, я возвращаюсь к работе, расставляю все точки над «i» и наношу последние штрихи.

        Планирование != проектирование. Одно дело провести планнинг на целый день и потом в первый же час разработки найти деталь, которая ломает все планы, и совсем другое дело попробовать несколько подходов, увидеть достоинства и недостатки, «переспать с идеей» и наконец выбрать оптимальный путь.

        Мне кажется, речь в статье идёт не о планировании, речь идёт о "жадном" решении задач. Буквально на днях услышал такой метод распределения задач на спринт: все оценивают, сколько времени у них займёт выполнение задачи, и тот, кто дал минимальную оценку, берётся её выполнять.

        Бред.

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

          Или написать статью «О медленном проектировании». В ней рассказать о тех, кто спроектировал архитектуру, но не спроектировал интерфейс, сделав его неудобным. Или наоборот — удобный интерфейс при слабой архитектуре. Быстрое прототипирование, обернулось быстрым прототипированием прототипов.
        +32
        Как-то ожидал увидеть success-story медленной разработки, но увидел только утверждение «медленно — хорошо. точка.»
        И, судя по всему, автор забывает, что бизнесу нужен не качественный продукт, а продукт с максимальным показателем отношения качества к цене разработки и в каких-то рамках по цене, качеству и срокам. Т.е. плохой продукт реально может быть более выгоден бизнесу, чем хороший.
          0
          Иногда, сделав изначально слишком хороший продукт даже за тоже время/деньги, есть риск в бизнесе проиграть. Идеальный продукт не глючит и его не нужно дорабатывать, следовательно заказчику нет смысла платить за сопровождение и доработки, следовательно можно потерять изрядную сумму от этого заказчика (правда получив некий плюс к репутации).
            +2
            Идеальный продукт можно сделать в идеальном мире. В реальном же мире можно сделать продукт в два раза дороже и в два раза медленнее, который (если повезет) глючит немного меньше. Пока конкуренты сделали одну версию, протестировали ее на рынке и поняли, что этот подход не работает и надо все фичи выкинуть и сделать с нуля по-другому.
              +2
              Не идеальный продукт, я имел в виду немного другое. Например, делал я как-то я во фрилансе некоторый парсер данных в один интернет магазин, сделал по-правильному, чтобы парсер висел, постоянно проверял обновление и допарсивал новые данные, а оказалось что заказчик вообще-то рассчитывал на одновременный перенос данных, а за доработку парсера, чтобы он мог обновлять данные, хотел заплатить ещё примерно столько же позже. В результате, я получил некий абстрактный плюс в «репутацию», но потерял в деньгах.

              В большом бизнесе примерно также, подозреваю, что сделать не ломающиеся и не требующие расходников пылесосы возможно, но производители никогда на это не пойдут.
                0
                Сорри, невнимательно прочитал ваш комментарий. Теперь понял, о чем вы.
                  0
                  Это не тот случай, вы просто недопоняли требования. Я, кстати, в подобной ситуации не стал бы такого делать, потому что стараюсь вести себя как lazy quantifier в регэксах — нужно делать то, что оговорено, а любую неясность уточнять. В конце концов, и клиент, и я, оба хотим заработать больше денег, потратив меньше времени.
                +1
                Если «медленный» подход позволяет достичь большей надёжности, имеет смысл применять его в критичных к этому задачах.
                Доработка продукта — не обязательно исправление багов, сопровождение включает в себя также фичи и улучшения, не связанные с конкретно реализацией: изменился процесс, законодательство, стало больше серверов и так далее.
                +2
                Но совсем куча г-на — это тоже плохо. Нужен баланс. Техдолг никто не отменял.
                  +3
                  Я вот, честно, не знаю как в остальных отраслях, да и программированием мою занятость назвать нельзя, но я часто вижу и натыкаюсь на проекты, где меня просят писать как можно более поддерживаемый, продуманный код, который можно реюзать еще много раз. Притом все понимают, что это затратно по времени. И даже платят мне (спустя месяцы продакшена) еще + 10-20% от стоимости изначального проекта (учитывая что оплата была почасвоая), если бекендерам всё понравилось. Я пишу на html/jade + less/sass. Это редкость, разве, для других?
                    +2
                    Всего должно быть в меру. Некоторое время назад, я очень дорожил «чистотой» своего кода, что сводилось к довольно высоким затратам на проект (и более того, те, кто сейчас продолжают мою работу, идут по тому же пути). Сейчас, несколько пересмотрев свои взгляды, могу сказать, что если мы говорим о работе, то я выдаю результат ASAP, порой действительно не вдаваясь в глубокое проектирование. Однако когда я прихожу домой и открываю свои проекты, я скрупулёзен и педантичен в каждой строчке своего кода. Просто стоит разделять программирование «для себя» и «процесс разработки продукта, приносящего деньги» для заказчика. Это не значит, что в коде для клиента всё должно быть тяп-ляп, просто избавьте себя от рефакторинг-ононизма до момента релиза продукта, это сэкономит вам кучу времени, заказчику — затраты, а компании принесет деньги.
                      0
                      Да, найти «золотую середину» — дорогого стоит.
                      Кстати, интересный случай, когда проектирование (функциональное) делает один человек, а кодирует другой. Здесь поддерживать баланс между скоростью разработки спецификации/кода и качеством на выходе должны оба.
                      +1
                      И это ОЧЕНЬ грустно.
                      Настоятельно рекомендую к прочтению книгу Г.Форда «Моя жизнь».
                      5 лет подготовки к производству трактора и потом 20+ лет производства без единого изменения.
                      Таких тракторов (и таких людей) сейчас уже не делают.
                        –1
                        Очень не хотелось бы пользоваться одним IT-продуктом 20 лет без изменений
                          +1
                          А как же ВАЗ 2107?
                          +1
                          Мне кажется автор ничего не забывает. Ведь «плохой продукт» также требуется спроектировать и умышленно пойти на потерю качества ради скорости создания продукта. Т.к. если плохой продукт будет получаться сам-собой, только потому что я херачу по 100 строк в минуту, то кроме плохого продукта в довесок я получу еще и непонимание как он работает и совсем в нем запутаюсь. Я лично использую медленное программирование при создании плохих продуктов и в свободное время (если есть) всегда стараюсь спроектировать действительно хорошее решение на черный день. И когда мне говорят «всё офигенно, но база не выдерживает нагрузку», я говорю, что ничего удивительного, выделите время и я это исправлю.
                            +2
                            плохой продукт реально может быть более выгоден бизнесу, чем хороший
                            Обычно лишь в краткосрочной перспективе. Если плохой продукт затем приходится сопровождать, то низкое качество исходного продукта может легко вылиться в то, что называется maintenance nightmare, и стоимость такого сопровождения может перекрыть изначальную экономию.
                            +16
                            :) Теперь у меня появилась теоретическая база, чтобы объяснять команде, почему я так медленно работаю.
                              +5
                              Мдаа, без success story действительно выглядит как-то не очень убедительно все это. То что автору некомфортно работать в таком ритме еще не значит, что все остальные работают плохо.
                                –3
                                Автор столкнулся с командой говнобыстрокодеров, которые фигачили всё в мастер, не используя ветки? Сочувствую.

                                Принцип каждый может изменить что угодно и никто ни за что не отвечает тоже странноват — это просто уничтожение ответственности. Хотя бы за куски / компоненты д.б. личная ответственность. Но только для тех, у кого имеются наружные признаки мужчины конечно.
                                  +7
                                  я ровестник автора, мне его позиция очень близка, спасибо за статью
                                    +3
                                    *ровесник.
                                    +5
                                    Только бывает так что пока кто-то долго и вдумчиво разрабатывает и проектирует что-то, другой на костылях и велосипедах успевает написать прототип, несколько раз его переписать учитывая предыдущие ошибки, допилить, и выпустить готовое ПО. И пока конкуренты только выпустят первую версию своего продукта, «быстропишущий» разработчик уже будет иметь свои позиции в бизнесе, и будет знаком с ошибками и проблемами которые невозможно учесть до эксплуатации.
                                      +10
                                      Да, сталкивался с ситуациями когда куча народа неделю и больше обсуждает и планирует функционал (причем каждый тянет в свою сторону), который за пару дней силами одного разработчика можно сделать, отладить, выкинуть, пару раз переписать и выдать уже готовый и отлаженный продукт, учитывающих косяки, которые никаким планированием не поймать. ИМХО, чрезмерное планирование, такое же зло, как и быдлокодирование без всякого плана.
                                        +1
                                        Все зависит от сложности системы. Одни прототипы можно легко выбрасывать и переписывать, другие — нет. Недавно столкнулся с ситуацией, когда прототип умудрялись тянуть на костылях и велосипедах больше года, и процентов 90 функциональности было реализовано, но в конце оказалось, что получившаяся архитектура в принципе неспособна потянуть оставшиеся 10%. Ничего не подозревающий заказчик, наблюдая за прогрессом, ждал результат очень скоро. Система формировалась на глазах… Было очень непросто объяснить ему, что на 10% потребуется еще 100% времени. А вот если бы эти разработчики (индусы, кстати, хз, совпадение ли) хоть недельку в самом начале провели с секатором в размышлениях — кто знает… Прототипы могут затягивать — с ними все время кажется, что цель приближается… Отчасти это вопрос удачи — выдержат ли костыли в фундаменте полную функциональность или все рухнет в самом конце.
                                          0
                                          Это вы про Билли?
                                        • UFO just landed and posted this here
                                            0
                                            быстрое программирование ещё ничего. а вот оголтелое — уже проблема!
                                              –1
                                              > Каждая ветвь начинается с исследования, проб и ошибок, хаков и временных переменных

                                              Мне стало страшно. Временные переменные хороши, когда у тебя нет даже намека на план решения задачи. Но позже уже вступает в дело опыт и выучка — за что профи и платят, собственно. А если каждый раз начинать с хаков, то, видно, задачи все время совсем необычные, и опыт не помогает?
                                                0
                                                Хаки нужны, чтобы проверить теорию. Система контроля версий позволяет удалять их бесследно. Иногда придумываешь несколько вариантов развития архитектуры, причем друг с другом несовместимые и на качественную реализацию каждого нужен, скажем, месяц. А система уже до того немаленькая, что любые попытки продумать последствия в голове взрывают мозг. При этом каким-то местом ощущаешь, что правильный вариант только один. В этом случае лично мне проще начать делать один из вариантов «напролом» — без инкапсуляции, с глобальными переменными, если так быстрее и т.п. Обычно уже в этот же день натыкаешься на на какую-то концептуальную проблему, типа «класс двигателя внутреннего сгорания для корректной работы требует ссылку на таблицу с днями рождения водителей» (пример надуман). Сразу понимаешь — идея плоха изначально, трат времени не достойна, откатываемся…
                                                  0
                                                  Да, как для случая со сверхсложными проектами, это, возможно, и вариант. Но стадия проектирования для того и есть, чтобы не приходилось бежать впереди паровоза, строча как из пулемета хаки и быстрый кривые кусочки кода, служащие для проверки идеи. Наоборот, когда сели, продумали, что класс ДВС будет состоять из того и того, а вся машина собрана так и так, нужно потрудиться (впрочем — от сложности проекта зависит), чтобы ДВС не работал без таблицы с д.р. А если так и получится, что будет понятно, почему, и понятно же, стоит костыли творить, или так оно и быть должно (вопреки нутряной логике простого, не знакомого с темой, человека).
                                                +3
                                                В программировании, как и во многих других видах деятельности, бывает нужна и быстрая тупая, и вдумчивая работа. Не стоит пренебрегать ни той, ни другой, хотя, конечно, у каждого есть свои предпочтения. Мне тоже больше по душе «медленное программирование».

                                                PS. Не пойму, за что так не любят частицу «ни».
                                                  +2
                                                  На мой взгляд, от поспешности в разработке в итоге проигрывают практически все, если это конечно не работа над типовым сайтом-визиткой, а что-то более сложное.

                                                  Я не вижу примеров быстрой разработки «на выброс» среди производителей-лидеров, какую бы область я не посмотрел.

                                                  Самые классные и запоминающиеся игры делают всякие близзарды, валве, бетесды и т.д. И каждую свою игру они разрабатывают по много нет и не спешат с выпуском.

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

                                                  Я к тому, что спешка с выпуском продукта оказывается выгодной в короткосрочном плане, но в долгосрочном плане она практически всегда не выгодна вообще никому. Если продукт не особенно хорош, то через какое-то время про него просто забывают. С другой стороны, я до сих пор не могу поставить рядом с хл1 и хл2 какую-либо современную игру по уровню сюжета, продуманности мира… Всё, что было выпущено другими разработчиками за все эти годы — какая-то далекая от реальности фантастика, в которую очень трудно поверить.

                                                  Хотя, в плане приложений-сервисов тут всё намного проще и удобнее для разработчиков: всегда можно выпустить мини-проект и проверить его, а потом уже доработать остальные фичи. Но это всё равно не должно являться актом спешки. Мини-проект тоже хорошо бы сделать сразу качественным, чтобы не переписывать потом этот код, а просто дальше развить в более сложное приложение.
                                                    +2
                                                    Я, конечно, понимаю, что сейчас на меня налетят люди, говорящие «исключение только подчеркивает правило» (фу, не понимал никогда этого), но. Альфа майнкрафта была написана за неделю, если что. Вы этого, возможно, не видите, но постоянно появляются много очень крутых инди игрушек, которые делаются по нормальным Lean методологиям (т.е. фигак-фигак и в продакшен раз в месяц, а дальше смотреть на фидбек игроков).
                                                      0
                                                      Представляю себе производителя какого-либо оборудования (например, роутеров), работающего по такому принципу и каждый месяц размещающего на своем сайте новую прошивку, а лучше схему доработки предыдущих версий плат.
                                                      Хотя что представлять, ТАКИЕ производители уже есть ))
                                                      Или производителя автомобилей.
                                                      Просто в данном случае, как никогда, верно высказывание «Истина всегда конкретна».
                                                        0
                                                        Не стоит путать, кстати, выход на совершенно несуществующий рынок (например, особый жанр игрушки) и выход на сформированный и всем понятный рынок, скажем, роутеров. Если вы хотите сделать супер крутую сетевую железку, аналогов которой пока что нету вообще, то делать ее два года только чтобы проверить она вообще нужна кому-нибудь или нет вы не будете. Вы сделаете ее на соплях побыструхе — корпус в виде коробки от обуви, 5 ардуин там, договоритесь с парочкой датацентров заинтересованных, будете ее пилить вместе с владельцами датацентров, выпуская прошивки раз в месяц и фикся баги.
                                                          0

                                                          Такое постоянно происходит на рынке железа — вендоры рассылают свои прототипы роутеров, стораджей разным конторам типа Гугла и фб с просьбой потестить и дать фидбек

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

                                                          Я для себя проекты тоже делаю по методике «херак-херак и в продакшн». Потому что они не отпрвятся в космос. И от вдумчивого кропления над каждой закорючкой лучше не станут.
                                                            +2
                                                            Дело в том, что существует два (как минимум) типа задач, решаемых программами:
                                                            * с высокой стоимостью ошибки (медицина, полеты, прочее управление реальными физическими объектами)
                                                            * с высокой стоимостью простоя (большая часть современных стартапов и веба)

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

                                                          Да для многих плевое дело — у многих в мозгу на рефлексивном уровне лежит 3-5 каркасных заготовок для создания «скелета» программы, которые накатываются на любой новый проект пусть это будет и со стороны смотреться как котеджик собраный из жб панелей для небоскребов или высотка построенная из тротуарного кирпича. Но то такое — гораздо хуже что такие люди практически всегда очень болезненно относятся к тому что видят решения отличающиеся от их собственных, у них очень часто встречается претензия к коду которая сводится к тому тезису «Я бы написал не так».
                                                          • UFO just landed and posted this here
                                                              +2
                                                              В нынешнее время принято кодить бездумно и считать программу написанной (а себя программистом), как только избавишься от синтаксических ошибок, и пройдут тесты. Уже не модно учить матан и дискретку, когда можно за пять дней научиться на рельсах фигачить интернет-магазин для локального гастронома. У людей совершенно нет понимания, что такое программирование в принципе. Нет ответственности за проделанную работу. Если бабушка скажет «мой внучок — программист», то это принимается на аксиому. А популяризацией юниттестов мы создаем уверенность в том, что если программа примерно справилась с парой входных данных, то она уже готова. А что, если такой подход распространить в другие сферы нашей жизни? Давайте не будем учить правила дорожного движения и внимательно смотреть на знаки — давайте просто будем сто раз проезжать по одной и той же улице, пока однажды не прибудем в конец без кишек на колесах. Мержим это в продакшн, а прослойку между креслом и рулем нарекаем программистом. Кстати, водительские права еще хотя бы аннулировать можно, а вот для того, чтоб заставить написать в своем резюме «этот проект был не просто сделан, а сделан через жопу, и без меня он бы работал быстрей и не глючил» механизма нет. Дада, продолжайте писать много кода, вписывать в резюме много парадигм, технологий, языков программирования — все равно мало кто поймет, программист вы все таки или нет.
                                                                +1
                                                                А что, интернет-магазин для локального гастронома должен лично Линус Торвальдс писать? Вы сами-то пойдёте фигачить интернет-магазины локальных гастрономов?
                                                                  0
                                                                  В нынешнее время даже не понимают о чем статья… Прочитал несколько первых комментариев, поплевался. И полез вниз писать свой, прочитал Ваш коммент, и обрадовался… Не перевелись люди, которые понимают, что главное не скорось… Смотришь на современные программы и только вздыхаешь с выходом каждой новой версии… Пошло набивание версий, а исправление и оптимизация кода разработчикам неведомо.
                                                                  Согласен, что можно и быстро написать код, но за счет того, что нем будет куча недочетов и учитывая это придется еще не раз переписать его, порой, с нуля… Все равно получается медленное программирование, если не оставить, наплевав на все, код как есть…
                                                                    0
                                                                    Часто приходится вычислять интегралы на листочке по работе?
                                                                    +1
                                                                    Напомнило пост: habrahabr.ru/post/153225/ и одну притчу о двух программистах (дословно не знаю, не нашел):
                                                                    Жили два программиста, один написал быстренько программу и выпустил на рынок. А другой долго и упорно писал качественную прогу.
                                                                    В итоге через год первый получил фидбеки на свою первую прогу — поправил её, заработал кучу бабла, нанял других прогеров и они переписали её без ошибок и всё круто.
                                                                    А второй выпустил через год свой продукт, но он уже никому не нужен был, потому что все пользовались прогой первого программиста.
                                                                      0
                                                                      В итоге через год первый получил фидбеки на свою первую прогу — поправил её, заработал кучу бабла, нанял других прогеров и они переписали её без ошибок и всё круто.
                                                                      Это в идеале, а на самом деле никто ничего править и доводить до идеала не будет, причина — «просто потеряют время и дадут фору конкуренту, а тот просто обгонит разработчиков».
                                                                        0
                                                                        Просто первый был бизнесмен, а второй — программист.
                                                                        Потому у них были разные цели (хотя из пересказа это неочевидно).
                                                                        Первый всего лишь заработал кучу денег, второй — получил огромное удовольствие от работы.
                                                                        Вам, видимо, важнее деньги :)
                                                                          0
                                                                          Не буду спорить ни с одним из утверждений. На то она и притча, что каждый сам выносит из нее урок :)
                                                                      • UFO just landed and posted this here

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