разработчик
0,0
рейтинг
24 октября 2012 в 16:20

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

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).



Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.

Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».

Сделай, чтобы было


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

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

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

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

В то же время, в процессе разработки мы обнаружили новые задачи в предметной области. Нам нужна была функция, которая вычисляла охват URL в Твиттере, то есть количество уникальных пользователей, которые увидели этот URL. Это сложная задача, которая может потребовать сотен обращений к БД и миллионов операций. Первоначальная реализация, работавшая на одной машине, могла потратить больше минуты на обработку одного URL. Стало ясно, что нужно распараллеливать вычисления в распределённой среде, чтобы работать быстро.

Одна из ключевых идей, легших в основу Storm, состояла в том, что «проблема охвата»
и проблема «обработки потока сообщений» могут быть объединены в одну простую абстракцию.

Сделай, чтобы было красиво


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

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

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



Чем больше на графике точек, тем больше шансы, что вы найдёте оптимальную кривую. Если точек слишком мало, велик риск того, что ваша кривая будет или слишком плохо описывать реальные данные, или её формула будет слишком сложной. А это — ненужные потери времени и сил.

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

Работая над Storm, я выделил маленький набор ключевых абстракций: потоки (streams), изливы (spouts), задвижки (bolts) и топологии (topologies). Я смог разработать новый алгоритм гарантированной обработки данных, который избавил от промежуточных брокеров сообщений — той части системы, которая причиняла больше всего страданий. То, что две такие разные на первый взгляд проблемы, как проблема охвата и обработка потока сообщений решались так элегантно одним способом, говорило о том, что я нащупал нечто выдающееся.

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

Сделай, чтобы было быстро


После того, как вам удалось создать красивое решение, можно приступать к профилированию и оптимизации.

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

«Сполоснуть и повторить»


Разработка через cтрадание — непрерывный процесс. Красивая и эффективная система открывает новые возможности и ставит новые задачи, а значит снова придётся «делать, чтобы было» уже в новых областях, и изменять дизайн на основе полученной информации, чтобы соответствовать новым точкам на графике.

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

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

Вывод


В разработке через страдание сценарии использования — это всё. Они ценятся на вес золота. А единственный способ их раздобыть — начать писать код, и неважно насколько он будет красивым в первое время.

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

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

Перевод: Nathan Marz
Илья Сименко @ilya42
карма
526,7
рейтинг 0,0
разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

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

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

  • +2
    > когда уместнее KISS, а когда DRY
    Зачем вы противопоставляете перпендикулярные вещи? В идеале они идут в связке и друг другу ни в коей мере не мешают а даже наоборот
    • +5
      В идеале — да. А в реальной ситуации бывают перегибы, и тогда начинаются противоречия. Чтобы не быть голословным: KISS vs DRY.
      • 0
        Языковые ограничения… Слава Богу, можно хотя бы выполнить DRY ценой небольшого отступления от KISS.
  • +12
    Кажется, Натан Марц рубит фишку.
    Сравнение дизайна итоговой архитектуры с апроксимацией особенно удачно.
    • 0
      С апроксимацией нет никакой новой идеи.

      «Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения.»

      Что есть «несущественные стороны»? Это субъективно не важные характеристики. «Не важные» — это зависит от целей человека и целей его моделирования. Например, бумажная модель будущего дома в точности показывает пропорции и возможно цвета поверхностей. Но материал и размеры не важны, поэтому размер маленький, а модель из бумаги, а не бетона.

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

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

      Что является в его понимании страданием? Это по сути YAGNI. Т.е. страдания — это способ оценки что действительно важно, а что нет. То, без чего можно обойтись — не делают. Я, например, интуитивно использую другую аналогию. Каждая строчка кода — зло, программирование — зло, и красоты нет в этом процессе. Т.е. использую принцип сопротивления написанию кода. И тогда оценка качества кода сводится не к выбору лучшего решения, а выбору наименее худшего.

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

                image
                • 0
                  А что не так в моем комментарии. Вы что, не изучали ни ГОСТ, ни ISO, ни IEEE стандарты на архитектуру ПО, и не знаете в чем разница между архитектурой и алгоритмом? Я в своем первом комментарии сказал, что сейчас прибегут и будут доказывать, что слова Степанова ошибочны, а вы начали что-то говорить про пересказ Макконела и о том, что я рассуждаю что правильно, и что нет.
                  • 0
                    Слушайте, вы сильно смахиваете на Шелдона Купера тем, что не различаете сарказм от не-сарказма. Мне и вправду нечего вам сказать, разве что жалеть времени, которую потратил на чтение и ответы к вашим комментариям. И напоследок, пожалуйста, не разбросайтесь умными аббревиатурами. Если бы на архитектуру софта был бы единый стандарт, то мы бы с вами не прочитали бы этот и многочисленные посты такого рода, и не впали бы в кому диалог.
                    Если будете отвечать и на этот комментарий, то прошу прежде досконально обьяснить, что вы понимаете под изучением ГОСТ, ISO, IEEE стандартов на архитектуру ПО. Уж очень прощу.
                    • –1
                      Я эти стандарты привел не потому что там единственно верный вариант архитектуры софта(тем более они стандартизируют в основном не архитектуру, а ее проектирование, но тут я виноват, не правильно сформулировал в прошлом комментарии), а потому что там терминология ясно определена. Под изучением стандартов я имею в виду изучение этих стандартов в рамках университетского курса. Там есть конкретные стандарты, и ПО по ним иногда требуется сертифицировать, поэтому их обычно изучают в ВУЗе.
                      К слову этот пост тоже не об архитектуре, а о методологии разработки ПО.
                      • 0
                        Где в этих стандартах говорится о проектировании ПО?
                        >> … и ПО по ним иногда требуется сертифицировать...
                        Это совсем другое, если некий ГОСТ требует, чтобы военное ПО было безопасным, это не значит, что этот ГОСТ рассказывает как проектировать это само ПО.

                        Такое ощущение, что вы смотрели только «трейлеры» к предметам, а самого «фильма» так и не смотрели.
                        • 0
                          >что этот ГОСТ рассказывает как проектировать это само ПО.
                          Самые боянистые ГОСТ 34 и IEEE 1471 описывают процесс проектирования. Естественно это не учебник, а просто формальное описание процесса.
                          Но я то не о том, я ГОСТы вообще привел в пример просто как место, где четко описывается определения алгоритма и архитектуры, в качестве ответ на фейспалм о фразе, говорящей о том, что архитектура и алгоритм это не одно и то же.
                          • 0
                            Говорить, что архитектура и алгоритм не одно и тоже, тоже самое, что и сказать, что холодильник и еда — это не одно и тоже. Имею в виду, что «да это же и моей бабушке понятно, черт возьми, так в чем же проблема»? А проблема в том, что вы пытаетесь показаться умным, может и не на голом месте, может и вы разработали несколько успешных проектов или что-то в этом роде, но прощу, не пытайтесь доказать разработчику, что процесс — это код и данные.
                            • 0
                              Ну так бы и сказали, что я капитанствую, а не начинали бы завуалированно говорить про то, что: «интерфейс тоже не похож на них». Это ведь тоже в своем роде капитанство. Я и не говорил, что процесс — это код и данные. Я даже не говорил, что код вообще имеет какое-то значение. Я говорил про то, что зачастую о более высокой важности интерфейса перед алгоритмами говорят люди, у которых самый сложный алгоритм в приложении, это — бинарный поиск, естественно для них интерфейс важнее чем алгоритмы, потому что алгоритмы им в общем-то вообще не нужны. У них может быть много кода, но код сам по себе действительно не особо важен, важно чтобы он выполнял свою задачу, без выполнения задачи любой интерфейс бесполезен.
                              • 0
                                ОК, думаю «по рукам» будет уместнее, не скажу, что было приятно подиалогировать, но конец мне понравился. Всего доброго.
  • +10
    Эх, все это замечательно, но всю малину обычно портит вопрос, который тебе задают в самом начале: «За сколько времени вы это сделаете и какими ресурсами?»
    Очень сомневаюсь, что у господина Каца Марца изначально имелся на него ответ. Хоть сколько-нибудь достоверный.
    • +12
      А на него может быть только один нормальный ответ: «Мне нужно X времени и Y ресурсов, чтобы ответить на ваш вопрос».
    • +2
      Видимо у Марца не было такого человека над душой. И слава б-гу.
  • +4
    Ничего нового здесь нет. Если сравнить со «старыми» архитектурными решениями, то смысл «разработки через страдания» сведется к разработке прототипа системы, который потом можно будет выбросить и начать разработку с нуля, основываясь на опыте и знаниях о предметной области, когда разрабатывался прототип.

    Только дело вот в чем, или даже больше — дела.

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

    2. Если вы работаете над проектом в некой фирме, то у вас конкретные проблемы — со сроком, в основном. В идеале, проект должен быть разработан через, описанное выше, прототип. Но проблема в том, что «почти» всем фирмам не хватает времени/денег/нервов, и вскором времени прототип превращается в рабочий бета и все последующие разработки ведут к исправлению багов… прототипа.

    3. Чтобы превосходно представить предметную область нужно очень много времени (мы же говорим о достаточно больших и сложных системах), а время нужно не только на теоритические размышления или митинги (которые так любят idle-разработчики), а еще и на постоянные разработки для увеличения знаний. По статистике, это время превосходит в 3-4 раза времени, которое фирма предполагает потратить на разработку готового продукта.

    Вот и идите разрабатывайте через страдание или как его там, лично я разрабатываю через «рвание жопы», «очередной хреновый митинг», «выслушивание трепа idle-коллег», «фикс опупенного количества багов, исправление которых явлвяется причиной появлению других»…

    P. S. За статью/перевод благодарен, отличная работа.
    • +17
      Обобщая опыт свой, сочините блогозапись «Разработка через рвание жопы» и тем прославьтеся.
      • 0
        И еще поставлю свое фото «с выпученными глазами и голливудскими большими зубами» :)
      • +6
        • +1
          Остроумно, но там всё же несколько другое: задницею там называют тупого руководителя или лидера.
    • +1
      Вопрос — а стоит ли работать в конторах, где так хреново с планированием? Продукты наверняка соотвутствующего «качества» выходят…
      • 0
        Вопрос хороший, отвечу так: если вы найдете НЕ такую контору — я сниму все шляпы, которые когда у меня были.
        • +2
          If you cannot change your job — change your job. В том смысле, что от вас в организации процесса тоже очень многое зависит. А если вы никак не можете (именно «не можете», а не «не пробовали») повлиять на рабочий процесс, и он вам не нравится — валите из этого места.
          • 0
            Правильно, уже свалил :)
        • 0
          Ну из 4-х контор, где я работал, в 2-х планировали нормально, ибо уважали себя и своих сотрудников.
          • 0
            Согласен, с планированием может и не быть проблем, но готов спорить, что у вас не было такого, чтобы разрабатывать проект полгода, а потом с «легкостью», дружно всей конторой бросить и начать заново, «более правильно».
            • +1
              С небольшими проектами так было неоднокаратно. Что касается большого, то однажды был случай, когда был принят курс на рефакторинг бОльшей части код. Под это заложили время, выделили ресурсы. Руководство не слепые — они видят, что разработка за 10 лет стала в несколько раз медленее и нужно что-то с этим делать.
              • 0
                Круто, а где вы работаете?
                • 0
                  Deutsche Bank RDC
              • –1
                10 лет? А на каком языке его тогда писали? 10 лет назад и возможности быстрого написания качественного кода были сильно меньше…
                • 0
                  У нас проекту около 13 лет. В 2003 его переписали с C++ на C#. Периодически довольно большие куски переписываются с нуля, «более правильно» — когда оказывается, что требования или возможности компьютеров изменились тем или иным образом, делающим более эффективной другую архитектуру программы.
                • 0
                  Java
                  • 0
                    Дальновидный выбор…
              • 0
                Это очень хорошо — что проекты «живут» по 10+ лет и находятся ресурсы на их рефакторинг…
  • +4
    Every Day I'm Suffering…
    • +1
      Forever Alone Continued…
  • +4
    Вопрос сам по себе очень сложен, нельзя, я повторюсь, НЕЛЬЗЯ, на мой взгляд, так однобоко оценивать процесс разработки.

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

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

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

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

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

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

    Можно всю жизнь заниматься рукопашным боем и изучать основы самообороны и никогда их не применить. Можно всю жизнь проектировать алгоритмы и системы на все случаи жизни и не воплотить ни один масштабный проект или даже работающее в прикладной области решение. Но совершенно неверно говорить о том, что это все зло и пустая трата времени, так как пустой траты времени просто не существует, любое время и любое дело конвертируется в опыт. Другой вопрос — целевое назначение трудовложений, и уже с этой позиции можно рассуждать совершенно иначе, вплоть до концепции тотального делегирования задач, как наиболее эффективного решения и триумфа логики минимизации энергозатрат.
    • 0
      Дело наверно в том, что у вас с автором разные психотипы: вы по разному мыслите. В вас чувствуется аналитик, в Марце — практик. И вы — несовместимы.
      Прелесть в том, что общаясь в краткосрочной переспективе вы дополняете друг друга — в вашу голову придет мысль, которая Марцу и в страшном сне не привидится. И наоборот — вон сколько мыслей в вас зародила статья. Получается что вы оба правы — Jedem das Seine.
      В краткосрочной переспективе вы ломаете друг другу шаблоны и это полезно. В долгосрочной работать вместе — ад, но это уже другая тема…

  • +1
    не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий

    Это тройное отрицание разрушило мой мозг. Так до конца и не уверен, что правильно понял эту фразу.
    • 0
      Тогда вам и вся остальная статья будет неподвластной.
      Можно просто заменить технологию на мороженое и все будет ок (плюс некоторые переделки):
      Не купите мороженого, если вам хорошо, когда мороженого нет.
      Что эквивалентно: "не купите мороженого, от отсутствия которого вы не впадете в кому".
      • 0
        Вот основной посыл как раз таки мне понятен, т.к. сам его давно исповедую.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Не покупайте чемодан только из-за того, что он продается со скидкой — у вас дома и так есть две дюжины таких же чемоданов. И не оправдывайте себя тем, что через 20 лет семья будет такой большой, что имеющихся чемоданов не хватит для поездки на море. Тогда и кУпите.
        • +1
          + (особенно касается (пост)советских) Не оправдывайте себя тем, что через 20 лет чемодан невозможно будет купить — если так, то он, скорее всего, будет бесполезен.
  • +3
    Описанный подход очень напоминает принцип YAGNI.
    Кроме того, принципы YAGNI, KISS и DRY прекрасно могут уживаться вместе.
  • 0
    Внезапно осознал, что мы на своем проекте используем именно эту методоологию разработки, но иногда — «разработку через задницу». Очень хорошие действенные модели максимально приближенные к реальному миру
  • 0
    Кто-нибудь использовал Storm на практике? Какие плюсы и минусы?
    • 0
      Пожалуйста, кто-нибудь напишите статью по Storm framework. Распределённые вычисления в реальном времени это превосходно клево!!!
  • +2
    >Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».

    Я всегда пишу код руководствуясь этии принципом. Сначало нужно сделать чтобы работало хоть как-то, затем чтобы работало хорошо, и затем что работало быстро. Третий этап в практике бывает нужен редко, но все-таки бывает. Это определяется нагрузочным тестированием. А в том случае когда надо написать что-то,, что совсем неясно как должно работать.то добавляется нулевой этап — напиши хоть -что-то.

    Название «разработка через страдание» мне категорически не нравиться. Я считаю что это просто практический подход.Конечно логично улушчать те вещи которые создают больше всего проблем, но ИМХО это просто здарвый смысл, а не еще одна методология
  • 0
    Он придумал? А я думал, еще Кнут сказал: «Сделай, чтоб работало, потой — чтобы работало правильно, и только потом, чтобы работало быстро»
    • +3
      Мне тоже показалось, что мантру "make it run, make it right, make it fast", я встречал достаточно давно
      • 0
        Вот это да! Вот и попался еще один «крутой-девелопер», автор перевода, напиши этому кретину, чтобы был более внимательним.
  • 0
    Посмотрел в татье перевод слова «suffering». Скорее «боль». В общем, название ассоциируется с методом «болевой диагностики» в советской стоматологии. «Ж… ой прочувствовать», типа того…
  • 0
    «Разработка через страдание фигнёй»…
  • 0
    Привет, Agile!
    • 0
      Ага, возникает вопрос, чел просто прочел Domain Driven Design или все-таки сам додумался. Потому как методология прям как дословно из книжки Эванса. Например фраза «обобщения без глубокого понимания предметной области».

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