195,96
рейтинг
18 октября 2013 в 13:26

Разработка → 3 способа разработки перевод

Разработка, Направленная на Создание Мусора


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

Главным продуктом РНСМ являются бессмысленности, написанные по столь «ценным» идеям: концепты, графики, описания дизайна и прочие продукты, создаваемые для одной лишь цели — быть выброшенными в корзину.

Это работает так:

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


Тем временем, еще один Визионер из топ-менеджмента выпивает лишнюю рюмку с ребятами из маркетинга и ему в голову приходит Блестящая Идея…

Разработка, Направленная на Создание Мусора могла бы быть карикатурой, если бы не случалась в жизни столь часто. Что-то типа 19-ти из 20-ти продуктов, выпускаемых на рынок большими фирмами, являются провальными (да, 87% статистики берётся с потолка). Оставшийся 1 из 20-ти является успешным по каким-то совершенно случайным причинам, типа совсем плохих конкурирующих продуктов или нового рынка.

Главный вывод из применения РНСМ легко сделать, но трудно принять: идеи не стоят ничего. Без исключений. Нет никаких «блестящих идей». Каждый, начинающий дискуссию с восклицания «ох, а ещё мы можем сделать вот ЭТО!» должен быть избит окрущающими со всей страстью и энергией, которую они берегли для звонящих в двери свидетелей Иеговы. Все эти Креативные Ребята с их «гениальными идеями» выглядят как человек, сидящий в кафе у подножья горы, попивающий свой горячий шоколад и объясняющий окружающим: «Эй, у меня есть отличная идея — мы могли бы забраться на эту гору! И построить коттедж на вершине! С двумя саунами! И садом! Его можно будет подключить к солнечным батареям! Чуваки, это круто! В какой же цвет мы его покрасим? Зелёный! Нет, синий! Так, идите и постройте его, а я останусь в этом кафе и нарисую пару графиков для нашего проекта!»

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

А теперь, после победы над Драконом Полной Неуместности, мы атакуем Демона Сложности.

Разработка, Направленная на Создание Сложности


Хорошие инженеры и маленькие фирмы теоретически способны создавать достойные продукты. Но подавляющее большинство продуктов всё ещё слишком сложно и менее успешно, чем они могли бы быть. Это потому, что команды специалистов упорно внедряют у себя процесс разработки, который я называю Разработка, Направленная на Создание Сложности (РНСС).

Работает он так:

  • Менеджеры верно находят интересные и важные проблемы с реальным экономическим эффектом от их решения. На этом этапе они уже на шаг впереди компаний, практикующих РНСМ из предыдущего параграфа.
  • Команда разработчиков с энтузиазмом начинает строить прототип системы, а затем базовую функциональность основного продукта. Всё идёт по плану, работа спорится, вещи делаются логичными и элегантными.
  • К этому времени менеджмент приходит с ещё более интересными и важными проблемами. Да, их труднее решить (кое-что вообще придётся переделывать), но ведь если мы это сделаем, то будем ещё на два шага впереди конкурентов, ведь так?
  • Разработчики делают то, что должны делать разработчики — разрабатывают. Разрабатывают, разрабатывают, разрабатывают и ещё раз разрабатывают. Менеджеры приходят со своими интересными и важными задачами снова и снова. И разработчики разрабатывают снова и снова. Чтобы получить в итоге идеальную, солидную, массивную, ОГРОМНУЮ СЛОЖНОСТЬ.
  • Продукт выходит на рынок, рынок чешет репу и спрашивает «Что, вот это всё правда надо было делать так сложно?». Люди начинают кое-как пользоваться продуктом, тратя своё время и деньги чтобы разобраться в его невообразимой сложности, но что делать, если альтернатив нет?
  • Менеджмент получает позитивные отзывы от крупнейших заказчиков — их менеджмент верит, что если уж всё так сложно и так много времени надо потратить на обучение и использование — значит это точно хороший продукт (?!).


РНСС характеризуется командами людей, остервенело и фанатично решающими частные задачи, не нужные 99% пользователей. РНСС-продукты получаются громоздкими, амбициозными, сложными и непопулярными. Множество опенсорс-продуктов появилось на свет в стремлении получить простое решение там, где было только сложное. Для некоторых инженеров невероятно трудно остановиться в стремлении расширить функционал продукта «на случай если вдруг кому-то ещё понадобиться вот это». Они хотят сделать людям добро, не задумываясь, нужно ли оно им и существуют ли вообще эти люди где-нибудь в мире.

Хороший пример РНСС — Блютус. Это сложный, надуманный набор протоколов, который пользователи ненавидят. Он продолжает существовать благодаря массивному пакету патентов, которые просто невозможно не нарушить, создавая альтернативу. Блютус идеально безопасен, что близко к бессмысленности для протокола столь малого радиуса действия. В то же время он страдает от недостатка стандартного API для разработчиков, вынуждая каждого изобретать ни с чем не совместимый велосипед в своём приложении.

На IRC-канале #zeromq Wintre однажды написал как он был разъярён, когда много лет назад обнаружил, что аудиоплеер XMMS 2 обладает хорошей системой плагинов, но не умеет играть музыку.

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

Главные выводы из РНСС, опять-таки легко сделать, но трудно принять:
  • Создавать продукт, который вам не нужен прямо сейчас — бессмысленно. Не важно насколько вы умны и талантливы, если вы делаете никому не нужную чушь, о которой никто не просил.
  • Проблемы бывают разного масштаба. Некоторые из них просты, другие — нет. Странно, но часто решение именно простых, пустячных проблем — как раз то, что нужно людям. С другой стороны разработчикам не интересно работать над банальностями и пустяками, им подавай Вызов, Проблему. Если пустить разработку на самотёк — разработчики будут работать над точно интересными им, но не факт что полезными пользователям задачами.
  • Инженеры и архитекторы любят всякие там Архитектуры, Паттерны, здесь что-то обобщить, а тут оптимизировать, а там выпендриться хаком — и всё это неумолимо ведёт к росту сложности. Критически важно иметь рычаг воздействие на такие вещи. Это может быть, например, жесткий дедлайн, заставляющий разработчика сделать маленькое, простое решение, работающее «здесь и сейчас», вместо гениального и общего, которое не будет закончено никогда.


Разработка, Направленная на Создание Простоты


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

РНСП работает так:

  • Мы собираем множество интересных проблем в какой-то сфере и располагаем их по возрастанию — от простых к сложным, пытаясь найти какие-то общие паттерны.
  • Мы берём и решаем простейшую, элементарную проблему, причём делаем это минимально затратным способом — «патчем». Каждый патч решает ровно одну проблему, и ровно одним, минимально затратным способом.
  • Мы вводим одну-единственную метрику качества патча: «Может ли это быть сделано ещё проще, всё ещё решая данную проблему?». Сложность можно измерять в количестве информации, которую пользователю придётся узнать (или угадать) чтобы воспользоваться патчем. Чем меньше, тем лучше. Идеальный патч решает проблему, не требуя от пользователя совершенно никаких знаний и умений.
  • Наш процесс разработки начинается с патча, который решает проблему «нам нужен proof of concept» и развивается в мощный продукт, состоящий из сотен или тысяч патчей, дополняющих и исправляющих друг друга.
  • Мы не делаем ничего, что не является патчем. Мы строим правила процесса разработки таким образом, чтобы каждая задача решалась одним патчем, решающим эту и только эту, осознанную и описанную проблему.
  • Мы строим «цепочку поставок» задач, в которую пользователи добавляют свои проблемы, а разработчики — решают их. Эта цепочка обладает хорошим «стоп механизмом», не дающим разработчикам улететь на крыльях своей фантазии в заоблачные дали — а попробуй это сделать, когда есть конкретный живой человек, ждущий быстрого решения проблемы.
  • Разработчики вправе работать над любыми проектами и предоставлять патчи к любому компоненту. Никто не владеет проектом единолично — есть «главный» репозиторий со своими формальными критериями приёма патчей, но если они кому-то не нравятся — любой может сделать свой форк. Один и тот же проект может иметь соревнующиеся форки, побуждая каждый из них развиваться лучше.
  • Проект предоставляет некоторый набор документированных интерфейсов, позволяя другим компонентам (клиентам, плагинам) их использовать. Создание хорошего API — способ получить много продуктов-спутников, сформировать экосистему и завоевать рынок.
  • Мы выводим цепочку поставок задач внешним пользователям и клиентам и обеспечиваем цикл частых релизов, так что пользовательская проблема может поступить к нам извне, быть проанализирована, оценена и исправлена патчем всего за несколько часов.
  • В каждый момент времени начиная с первых патчей наш продукт готов к поставке. Это важно, поскольку значительная часть патчей (10-30%) будут неверными и только давая доступ к продукту пользователям мы можем понять что пошло не так и нуждается в исправлении.


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

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

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

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

В мире opensource мы делаем всю эту работу на виду. Нет никакого «ну давайте уже откроем код» момента. Продукты, которые решают открыть код только на некотором этапе отбирают у пользователя возможность проследить всю захватывающую историю с самого начала, создать сообщество вокруг своего продукта с момента его рождения.
Автор: @tangro zeromq

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

  • +2
    KISS
    • +1
      И да, и нет. KISS скорее про сам код, но не о том, откуда берутся идеи, планы и как ведётся разработка продукта в общем.
      • 0
        The KISS principle states that most systems work best if they are kept simple rather than made complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.


        Вообще, изначально это про то, что самолёт должен быть прост в починке. А в разработке софта — это в целом про разработку софта, а не только про код.
    • 0
      Это должно быть первой заповедью и разработчиков, и архитекторов, и вообще всех, вовлеченных в процесс разработки ПО!
  • +14
    Автор легко и непринуждённо убил архитектуру с паттернами — и посоветовал вместо них плодить костыли, названные для благовидности патчами.
    Автор мне нравится.
    • 0
      Именно так. Я полагаю, дефект в его рассуждениях начинается со слов, что идеи — это плохо. Идея как решить проблему — это ведь тоже идея, только в отличие от патча, она подразумевает свободу творчества. И как раз в свободе творчества кроются наиболее элегантные и эффективные решения.
      • 0
        Идея хороша, когда она пришла тебе в голову, ты её реализовал, показал решение остальным и дальше оно было принято\исправлено\дополнено\отброшено. А когда она пришла в голову тебе одному, делать её должен кто-то другой, а не нужна она окажется никому вообще — вот тогда она плоха. Об этом автор и говорит.
        • 0
          Откуда автору известно, что идея окажется никому не нужна? Если он знает это наперёд, то он должен быть богаче Билла Гейтса и Сергея Брина, вместе взятых.
          Более того, он должен уметь путешествовать во времени.
        • 0
          Вообще, это нормально, что идеи генерируют одни, а реализуют — другие.

          Сценарист должен и режиссёрскую, и операторскую работу всегда сам выполнять?
  • +13
    Пожалуйста, Не Пишите Все Слова В Заголовках С Большой Буквы.

    Это английский стиль, по-русски так писать нельзя. В русском языке в заголовках и именах собственных с большой буквы пишется только первое слово. Я серьезно, глаза кровоточат.
    • –17
      какие у вас слабые глаза и психика, тренируйте их.
      От Таких Заголовков Еще Никто Не Умер. И английский стиль в среде IT вполне норм.
    • 0
      Во-первых, это перевод, а в оригинале было «Simplicity Oriented Design», во-вторых, мне показалось правильным так это написать, в-третьих, некоторые вещи на русский лучше не переводить.
      • +1
        Вы что-то путаете.
        У вас ссылка на код, в котором переменные написаны подобным стилем. Обратите внимание — именно переменные. Они пишутся слитно. Поэтому для них есть такое понятие как Naming Convention. По вашей ссылке — это CamelCase en.wikipedia.org/wiki/CamelCase
      • +3
        Раз это перевод на русский, то надо стараться писать с учетом русской грамматики. В русской грамматике все слова с большой буквой считаются ошибкой. Не верите — посмотрите заголовки на любом качественном русскоязычном новостном сайте. А потом сравните с заголовками на англоязычном сайте.

        Пруф:

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

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

          Если Вам нужны пруфлинки — ну почитайте, например, Ильфа и Петрова, в том же «Золотом телёнке» есть не то что заголовки — целые предложения и абзацы капсом. Вы же не будете спорить с тем, что это вполне себе классическое произведение?
          • +1
            Во-первых, речь не про капс и не про пунктуацию, а про правильное оформление заголовков и имен собственных (типа «Креативные ребята»). Во-вторых, вы путаете публицистику и литературу. В публицистике не существует никакого авторского стиля, тем более который мог бы нарушать общепризнанную грамматику языка. За такие экзерcиcы с большими буквами вас бы редактор лишил премии в любом издании, где занимаются именно публицистикой, и никакие разговоры про «авторский стиль» бы не помогли, это я вам совершенно точно говорю.

            Вы просто не вполне в курсе про английскую грамматику, это общепризнанная норма в английском, которая отсутствует в русском. Извините, мне не особо интересно дискутировать на эту тему, я просто поделился некоторой информации из области, которую знаю досконально — если вы не хотите ее принимать, это ваше дело.
            • +1
              Ок, тогда — спасибо за информацию.
          • 0
            > Не знаю, откуда Вы берете эти нормы:
            Есть Розенталь, есть Грамота.ру
            > Мне всегда казалось — Мне всегда казалось, что число пи равно 5, но это никому не интересно.
            • 0
              Между «число пи равно 5» и «буквочка должна быть маленькой» есть объективная разница: первое — математический факт, верность которого можно доказать или опровергнуть наукой. Второе — соглашение группы людей, которые договорились, что им так удобно. Если на основе того что пи равно 5 построить ракету — она упадёт, если написать заголовок капсом — суть текста не меняется. Ну и я всё-таки хотел бы увидеть правило, где было бы написано «известным писателям, типа упомянутых выше Ильфа и Петрова так делать можно, а какому-то tangro с Хабра — не положено, рожей не вышел». Есть такое у Розенталя и грамоты.ру?
              • 0
                От безграмотно составленных ТЗ и документации ракеты тоже падают, увы. Писать безграмотно — это все равно что говнокодить или ходить в грязных штанах. От этого тоже суть не меняется: программа работает, ноги не мерзнут.
                Касательно «авторского» — авторская пунктуация или словоупотребление это не то же самое, что «как хочу, так и пишу, потому что я автор». Если вы отходите от общепринятых языковых норм, вы должны делать это для достижения какой-то цели. А насчет «есть ли такое у Розенталя или грамоты.ру» — проверьте, разве ж Вам кто-то не дает?
  • 0
    Последний способ очень похож на unix подход к разработке — когда создается много простых утилит, которые хорошо делают одно действие. Но для следование такому подходу нужно грамотное и ненавязчивое руководство что бы разбить крупную задачу на атомарные действия.
  • +10
    Мы берём и решаем простейшую, элементарную проблему, причём делаем это минимально затратным способом — «патчем».
    А через полгода сопровождение такого проекта превращается в пытку, каждый новый «патч» занимает все больше и больше времени, ибо впихивать «патчи» уже некуда.
    • +4
      Позвольте процитировать высказывание в тему:
      легаси проект от проекта «с нуля» отличается лишь тем, что легаси — это говнокод сразу, а проект «с нуля» — говнокод чуть-чуть попозже

  • 0
    Ах вот как появился на свет PHP…
    • 0
      Как?
  • +1
    При желании, любой метод разработки можно превратить в ад. И написание патчей не исключение.

    К примеру, можно в каждом патче делать по 5 багов и на каждый баг создавать новую задачу и новый патч.

    Главное не методология а люди.
  • 0
    Есть много проектов, где не нужно решать уникальные задачи, и не нужен R&D. Например игрострой, все что можно уже сделали кчей разных вариантов, уже известны практики разработки, известная сложность, известный компромисы. На начальном этапе уже можно прикинуть, сколько нуна денег и выбрать путь для проекта. Либо это будет простенький говнокод с минимум архитектуры, и попробовать выплестнуть на рынок. Либо будет серьезно прорабатывать архитектуру, потому что проект будет поддерживатся и дизы уверены в его успехе.
  • 0
    Ссылка на оригинал конкретно статьи, а не просто главную 0MQ, как внизу поста.
    • +1
      Ссылку с двоеточиями внутри нельзя вставить в качестве оригинала перевода. Баг уже зарепорчен.
  • +1
    Уж сколько раз писали, что всё зависит от задачи.

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

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

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

      БИНГО!
      • 0
        1. Плохо правила игры читали.
        2. Вам не кажется, что туповато подшучивать над тем, что изначально «отмазано»?
        составляющей его уникальность(ТМ). Конечно, «уникальность продукта» — фраза заезженная и зачастую вызывающая лишь недобрую улыбку

        3. И вообще, вы свежи, аки рис, сваренный три дня назад и оставленный на солнце.
  • 0
    Хорошая статья. Сродни исследованию «что такое хорошо и что такое плохо». К сожалению, описан пока только симптом болезни, а не сама болезнь. Я не видел ни одного исследования которое интересуется вопросом, почему корпорация, созданная ранее и приносящая прибыль в сотни мегабаксов превращается в конце-концов в поле битвы между двумя-тремя группировками внутри корпорации, которых разводит главный смотрящий (обычно генеральный директор который над схваткой и борется только за внимание акционеров и свои бонусы). Процесс который вы описали в первой части это результат не желания сделать лучше своим юзерам а возможность утереть нос другим группировкам. На юзеров все ложили приборы в этом процессе и такой и результат получился. :)
  • +4
    Любопытно, что «жизнь в долг», по горло в кредитах, уже вроде всеми осознаётся как что-то неправильное.

    А вот про жизнь в «технический долг» люди до сих пор всерьёз пишут хвалебные статьи, будто это чуть ли не «серебряная пуля» и вообще здорово и прекрасно. Не думай о будущем, live fast die young.
  • 0
    Мдя… Автор неплохо описывает картинки, но генерит полный бред, когда пытается делать выводы и рекомендации.
  • 0
    "… увольняет консультантов..."

    Ни разу не видел такого! Как правило консультанты переходят в другой проект с повышением. Увы…
  • +1
    Такие статьи обычно пишут люди экспертного уровня, которые отлично разбираются в архитектурах и паттернах. Да, такие люди умеют делать те самые патчи правильно. И они умеют из этих патчей сложить качественный (т.е. не глючный, что весьма не тривиально на самом деле), сложный (в плане комплексный) и нужный продукт. Они пользуются знаниями, не замечая того. Они делают все просто, потому что умеют делать это просто! Да, это KISS. И да, этому надо учиться.

    А теперь вопрос: как этому учиться? Как отличить простое от сложного, если не знаешь, что такое сложное?

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

    А кричать в рупор «забейте на все и делайте простые пачти» — создание дополнительных барьеров для новичков, которые будут смотреть не в том направлении и писать глупости в комментах на Хабре.
  • 0
    Блин, как все это похоже на процесс разработки фирмы, где я сейчас работаю. Особенно, «разработка, направленная на создание мусора». Печально все это…
  • 0
    Patch-driven-development.

    А вообще у меня дежавю. Мне кажется автор переизобретает скрам с его user-story и delivered value каждый спринт. Или это TDD с его минимальными правками для озеленения тестов.

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

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

Самое читаемое Разработка