Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
> когда уместнее KISS, а когда DRY
Зачем вы противопоставляете перпендикулярные вещи? В идеале они идут в связке и друг другу ни в коей мере не мешают а даже наоборот
Зачем вы противопоставляете перпендикулярные вещи? В идеале они идут в связке и друг другу ни в коей мере не мешают а даже наоборот
Кажется, Натан Марц рубит фишку.
Сравнение дизайна итоговой архитектуры с апроксимацией особенно удачно.
Сравнение дизайна итоговой архитектуры с апроксимацией особенно удачно.
С апроксимацией нет никакой новой идеи.
«Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения.»
Что есть «несущественные стороны»? Это субъективно не важные характеристики. «Не важные» — это зависит от целей человека и целей его моделирования. Например, бумажная модель будущего дома в точности показывает пропорции и возможно цвета поверхностей. Но материал и размеры не важны, поэтому размер маленький, а модель из бумаги, а не бетона.
По сути можно всегда выделять из потока информации существенную информацию и шум. Поиск существенной информации — это и есть в какой-то мере абстрагирование. Поиск аналитической формулы, наиболее точно описывающей набор точек, называют задачей регрессии. Т.е. такая формула — это сжатое представление набора точек. Грубо говоря, формулу передать можно меньшим числом байт.
Это только один из вариантов моделей поиска закономерностей. Все другие практически делают то же самое. Ищут существенное, что можно передать меньшим числом байт, возможно с потерей точности. Что делает нейронная сеть? Она переводит большое разнообразие точек в намного меньшее количество информации, хранящееся в ее весах, когда она обучится. При этом, если выбрать большую, чем требуется нейронную сеть (с бОльшим количеством нейронов и весов, то такая сеть может «переобучиться» — т.е. обучиться шумам. И тогда на новых данных, которых не было на этапе обучения, она будет показывать плохую точность.
Преобразование Фурье? То же самое. Сложную кривую превращает в ряд коэффициентов. И чем их меньше, тем больше «сглаживание». Название метода «сокращения длины описаний» говорит сам за себя.
То, что описал в этой статье Натан Марц — это его интуитивное понимание и аналогии. Как работает ТДД? Где-то так же: сначала «чтобы было», на второй фазе — рефакторинг — т.е. сокращение описания (вынесение в базовые классы и т.д.), наведение «красоты» (избавление от магических чисел, например). Ну и тесты перед этим, чтобы задать ограничения.
Что является в его понимании страданием? Это по сути YAGNI. Т.е. страдания — это способ оценки что действительно важно, а что нет. То, без чего можно обойтись — не делают. Я, например, интуитивно использую другую аналогию. Каждая строчка кода — зло, программирование — зло, и красоты нет в этом процессе. Т.е. использую принцип сопротивления написанию кода. И тогда оценка качества кода сводится не к выбору лучшего решения, а выбору наименее худшего.
В общем, всё — одно и то же
«Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения.»
Что есть «несущественные стороны»? Это субъективно не важные характеристики. «Не важные» — это зависит от целей человека и целей его моделирования. Например, бумажная модель будущего дома в точности показывает пропорции и возможно цвета поверхностей. Но материал и размеры не важны, поэтому размер маленький, а модель из бумаги, а не бетона.
По сути можно всегда выделять из потока информации существенную информацию и шум. Поиск существенной информации — это и есть в какой-то мере абстрагирование. Поиск аналитической формулы, наиболее точно описывающей набор точек, называют задачей регрессии. Т.е. такая формула — это сжатое представление набора точек. Грубо говоря, формулу передать можно меньшим числом байт.
Это только один из вариантов моделей поиска закономерностей. Все другие практически делают то же самое. Ищут существенное, что можно передать меньшим числом байт, возможно с потерей точности. Что делает нейронная сеть? Она переводит большое разнообразие точек в намного меньшее количество информации, хранящееся в ее весах, когда она обучится. При этом, если выбрать большую, чем требуется нейронную сеть (с бОльшим количеством нейронов и весов, то такая сеть может «переобучиться» — т.е. обучиться шумам. И тогда на новых данных, которых не было на этапе обучения, она будет показывать плохую точность.
Преобразование Фурье? То же самое. Сложную кривую превращает в ряд коэффициентов. И чем их меньше, тем больше «сглаживание». Название метода «сокращения длины описаний» говорит сам за себя.
То, что описал в этой статье Натан Марц — это его интуитивное понимание и аналогии. Как работает ТДД? Где-то так же: сначала «чтобы было», на второй фазе — рефакторинг — т.е. сокращение описания (вынесение в базовые классы и т.д.), наведение «красоты» (избавление от магических чисел, например). Ну и тесты перед этим, чтобы задать ограничения.
Что является в его понимании страданием? Это по сути YAGNI. Т.е. страдания — это способ оценки что действительно важно, а что нет. То, без чего можно обойтись — не делают. Я, например, интуитивно использую другую аналогию. Каждая строчка кода — зло, программирование — зло, и красоты нет в этом процессе. Т.е. использую принцип сопротивления написанию кода. И тогда оценка качества кода сводится не к выбору лучшего решения, а выбору наименее худшего.
В общем, всё — одно и то же
Сейчас набежит куча погромистов разрабатывающих программы по готовым простейшим алгоритмам и будет говорить, что интерфейсы важнее алгоритмов.
А кто-то будет долго рассуждать, как правильно нужно распределять ресурсы, как проектировать и т.д. А в итоге окажется, что кто-то просто пересказывает Макконнела (ну или Фаулера, кто там этой, как его, архитектурой балуется?).
Алгоритмы и архитектура это совсем не одно и то же.
Интерфейс тоже не похоже на них, и вообще, может вы и начнете «долго рассуждать, что правильно, а что нет», но до этого предлагаю перечитывать мой комментарий выше как минимум 6 раз и пытаться вникать, вникать, вникать…
А я в свою очередь предлагаю вам перечитать комментарий, на который я отвечал, чтобы понять контекст в котором я говорил, и пытаться вникать, вникать, вникать…
А что не так в моем комментарии. Вы что, не изучали ни ГОСТ, ни ISO, ни IEEE стандарты на архитектуру ПО, и не знаете в чем разница между архитектурой и алгоритмом? Я в своем первом комментарии сказал, что сейчас прибегут и будут доказывать, что слова Степанова ошибочны, а вы начали что-то говорить про пересказ Макконела и о том, что я рассуждаю что правильно, и что нет.
Слушайте, вы сильно смахиваете на Шелдона Купера тем, что не различаете сарказм от не-сарказма. Мне и вправду нечего вам сказать, разве что жалеть времени, которую потратил на чтение и ответы к вашим комментариям. И напоследок, пожалуйста, не разбросайтесь умными аббревиатурами. Если бы на архитектуру софта был бы единый стандарт, то мы бы с вами не прочитали бы этот и многочисленные посты такого рода, и не впали бы в кому диалог.
Если будете отвечать и на этот комментарий, то прошу прежде досконально обьяснить, что вы понимаете под изучением ГОСТ, ISO, IEEE стандартов на архитектуру ПО. Уж очень прощу.
Если будете отвечать и на этот комментарий, то прошу прежде досконально обьяснить, что вы понимаете под изучением ГОСТ, ISO, IEEE стандартов на архитектуру ПО. Уж очень прощу.
Я эти стандарты привел не потому что там единственно верный вариант архитектуры софта(тем более они стандартизируют в основном не архитектуру, а ее проектирование, но тут я виноват, не правильно сформулировал в прошлом комментарии), а потому что там терминология ясно определена. Под изучением стандартов я имею в виду изучение этих стандартов в рамках университетского курса. Там есть конкретные стандарты, и ПО по ним иногда требуется сертифицировать, поэтому их обычно изучают в ВУЗе.
К слову этот пост тоже не об архитектуре, а о методологии разработки ПО.
К слову этот пост тоже не об архитектуре, а о методологии разработки ПО.
Где в этих стандартах говорится о проектировании ПО?
>> … и ПО по ним иногда требуется сертифицировать...
Это совсем другое, если некий ГОСТ требует, чтобы военное ПО было безопасным, это не значит, что этот ГОСТ рассказывает как проектировать это само ПО.
Такое ощущение, что вы смотрели только «трейлеры» к предметам, а самого «фильма» так и не смотрели.
>> … и ПО по ним иногда требуется сертифицировать...
Это совсем другое, если некий ГОСТ требует, чтобы военное ПО было безопасным, это не значит, что этот ГОСТ рассказывает как проектировать это само ПО.
Такое ощущение, что вы смотрели только «трейлеры» к предметам, а самого «фильма» так и не смотрели.
>что этот ГОСТ рассказывает как проектировать это само ПО.
Самые боянистые ГОСТ 34 и IEEE 1471 описывают процесс проектирования. Естественно это не учебник, а просто формальное описание процесса.
Но я то не о том, я ГОСТы вообще привел в пример просто как место, где четко описывается определения алгоритма и архитектуры, в качестве ответ на фейспалм о фразе, говорящей о том, что архитектура и алгоритм это не одно и то же.
Самые боянистые ГОСТ 34 и IEEE 1471 описывают процесс проектирования. Естественно это не учебник, а просто формальное описание процесса.
Но я то не о том, я ГОСТы вообще привел в пример просто как место, где четко описывается определения алгоритма и архитектуры, в качестве ответ на фейспалм о фразе, говорящей о том, что архитектура и алгоритм это не одно и то же.
Говорить, что архитектура и алгоритм не одно и тоже, тоже самое, что и сказать, что холодильник и еда — это не одно и тоже. Имею в виду, что «да это же и моей бабушке понятно, черт возьми, так в чем же проблема»? А проблема в том, что вы пытаетесь показаться умным, может и не на голом месте, может и вы разработали несколько успешных проектов или что-то в этом роде, но прощу, не пытайтесь доказать разработчику, что процесс — это код и данные.
Ну так бы и сказали, что я капитанствую, а не начинали бы завуалированно говорить про то, что: «интерфейс тоже не похож на них». Это ведь тоже в своем роде капитанство. Я и не говорил, что процесс — это код и данные. Я даже не говорил, что код вообще имеет какое-то значение. Я говорил про то, что зачастую о более высокой важности интерфейса перед алгоритмами говорят люди, у которых самый сложный алгоритм в приложении, это — бинарный поиск, естественно для них интерфейс важнее чем алгоритмы, потому что алгоритмы им в общем-то вообще не нужны. У них может быть много кода, но код сам по себе действительно не особо важен, важно чтобы он выполнял свою задачу, без выполнения задачи любой интерфейс бесполезен.
Эх, все это замечательно, но всю малину обычно портит вопрос, который тебе задают в самом начале: «За сколько времени вы это сделаете и какими ресурсами?»
Очень сомневаюсь, что у господинаКаца Марца изначально имелся на него ответ. Хоть сколько-нибудь достоверный.
Очень сомневаюсь, что у господина
Ничего нового здесь нет. Если сравнить со «старыми» архитектурными решениями, то смысл «разработки через страдания» сведется к разработке прототипа системы, который потом можно будет выбросить и начать разработку с нуля, основываясь на опыте и знаниях о предметной области, когда разрабатывался прототип.
Только дело вот в чем, или даже больше — дела.
1. Если вы разрабатываете проект для вас, то есть хотите реализовать некую идею, то ограничений на время у вас нет, если только вы не ставите их, а если таковых нет — то можно бесконечно долго совершенствовать проект, делая красивее, делая быстрее, делая… Но этого никогда не бывает, лишь в редких случаях мы возвращаемся к работающему, но «уродливому» коду, чтобы, выражаясь мягко, отрефакторить.
2. Если вы работаете над проектом в некой фирме, то у вас конкретные проблемы — со сроком, в основном. В идеале, проект должен быть разработан через, описанное выше, прототип. Но проблема в том, что «почти» всем фирмам не хватает времени/денег/нервов, и вскором времени прототип превращается в рабочий бета и все последующие разработки ведут к исправлению багов… прототипа.
3. Чтобы превосходно представить предметную область нужно очень много времени (мы же говорим о достаточно больших и сложных системах), а время нужно не только на теоритические размышления или митинги (которые так любят idle-разработчики), а еще и на постоянные разработки для увеличения знаний. По статистике, это время превосходит в 3-4 раза времени, которое фирма предполагает потратить на разработку готового продукта.
Вот и идите разрабатывайте через страдание или как его там, лично я разрабатываю через «рвание жопы», «очередной хреновый митинг», «выслушивание трепа idle-коллег», «фикс опупенного количества багов, исправление которых явлвяется причиной появлению других»…
P. S. За статью/перевод благодарен, отличная работа.
Только дело вот в чем, или даже больше — дела.
1. Если вы разрабатываете проект для вас, то есть хотите реализовать некую идею, то ограничений на время у вас нет, если только вы не ставите их, а если таковых нет — то можно бесконечно долго совершенствовать проект, делая красивее, делая быстрее, делая… Но этого никогда не бывает, лишь в редких случаях мы возвращаемся к работающему, но «уродливому» коду, чтобы, выражаясь мягко, отрефакторить.
2. Если вы работаете над проектом в некой фирме, то у вас конкретные проблемы — со сроком, в основном. В идеале, проект должен быть разработан через, описанное выше, прототип. Но проблема в том, что «почти» всем фирмам не хватает времени/денег/нервов, и вскором времени прототип превращается в рабочий бета и все последующие разработки ведут к исправлению багов… прототипа.
3. Чтобы превосходно представить предметную область нужно очень много времени (мы же говорим о достаточно больших и сложных системах), а время нужно не только на теоритические размышления или митинги (которые так любят idle-разработчики), а еще и на постоянные разработки для увеличения знаний. По статистике, это время превосходит в 3-4 раза времени, которое фирма предполагает потратить на разработку готового продукта.
Вот и идите разрабатывайте через страдание или как его там, лично я разрабатываю через «рвание жопы», «очередной хреновый митинг», «выслушивание трепа idle-коллег», «фикс опупенного количества багов, исправление которых явлвяется причиной появлению других»…
P. S. За статью/перевод благодарен, отличная работа.
Обобщая опыт свой, сочините блогозапись «Разработка через рвание жопы» и тем прославьтеся.
Вопрос хороший, отвечу так: если вы найдете НЕ такую контору — я сниму все шляпы, которые когда у меня были.
If you cannot change your job — change your job. В том смысле, что от вас в организации процесса тоже очень многое зависит. А если вы никак не можете (именно «не можете», а не «не пробовали») повлиять на рабочий процесс, и он вам не нравится — валите из этого места.
Согласен, с планированием может и не быть проблем, но готов спорить, что у вас не было такого, чтобы разрабатывать проект полгода, а потом с «легкостью», дружно всей конторой бросить и начать заново, «более правильно».
Круто, а где вы работаете?
10 лет? А на каком языке его тогда писали? 10 лет назад и возможности быстрого написания качественного кода были сильно меньше…
У нас проекту около 13 лет. В 2003 его переписали с C++ на C#. Периодически довольно большие куски переписываются с нуля, «более правильно» — когда оказывается, что требования или возможности компьютеров изменились тем или иным образом, делающим более эффективной другую архитектуру программы.
Это очень хорошо — что проекты «живут» по 10+ лет и находятся ресурсы на их рефакторинг…
Every Day I'm Suffering…
Вопрос сам по себе очень сложен, нельзя, я повторюсь, НЕЛЬЗЯ, на мой взгляд, так однобоко оценивать процесс разработки.
Это напоминает игру в шахматы по фактической расстановке фигур в самом общем смысле этой метафоры. Само стремление к прогнозированию является естественным для человеческого мышления. Я думаю, что здесь упущен огромный момент, связанный с негативными факторами отказа от прогнозирования. Я во многих комментариях пишу практически однотипные вещи, но отказ от прогнозирования в пользу более простой модели — поведение на основе фактической информации — это чистейшее первичное абстрагирование от проблем. Проще не видеть и не хотеть видеть какие-либо нюансы, а просто делать лишь бы было. Это похоже на езду на велосипеде с закрытыми глазами, сконцентрировавшись на равновесии и не думая о дороге.
… Скорее всего автор вкладывал не совсем тот смысл, который описан в тексте. Мне кажется, что в словах «Во время первых двух фаз надо уменьшать асимптотическую сложность алгоритмов» заложен значительно более глубокий смысл, который пытался передать автор на основе своего богатого опыта проб и ошибок, нежели могут передать эти слова. Шаг первый и шаг второй неразрывно связаны с прогнозированием и глубоким анализом ситуаций, характеризующих алгоритм. Либо автор не видит в них этапа прогнозирования, либо не признает его, считая для себя его очень несущественным.
Ведь мы не думаем над тем, как держать вилку в руке, хотя кинематика телодвижений, сигнальная синхронизация и работа мышечных волокон просто чудовищно сложна. Это абстрагирование позволяет нам сделать вывод — держать вилку в руке это настолько просто и незначительно, что не имеет смысла об этом думать и тратить на это время.
Я считаю, что верно не отказываться от прогнозирования в пользу быстрых решений, но правильно осознавать саму способность прогнозировать через моделирование в нашем воображении. Это лишь форма позволяющая привнести значительно больше лаконичности решению, нежели строго локализованное «здесь и сейчас» это работает, а завтра будет завтра, и якобы это неактуально и никого не волнует. Правда в том, что завтра все же будет, вопрос только в том, каким оно будет, и как правило многие аспекты масштабирования прогнозируются, но скорее всего срабатывает банальный принцип абстрагирования от сложности решения в пользу минимизации энергозатрат — перенести все на завтра, отложить на потом.
Это сложный вопрос, требующий глубокого комплексного анализа процесса развития и реализации, совокупности условий возникновения и среды разработки. Все это, на мой взгляд, не позволяет достаточно однобоко сказать — так как делаю я здорово и вот результат, а так как делает кто-то не совсем здорово, потому что результата нет.
Можно всю жизнь заниматься рукопашным боем и изучать основы самообороны и никогда их не применить. Можно всю жизнь проектировать алгоритмы и системы на все случаи жизни и не воплотить ни один масштабный проект или даже работающее в прикладной области решение. Но совершенно неверно говорить о том, что это все зло и пустая трата времени, так как пустой траты времени просто не существует, любое время и любое дело конвертируется в опыт. Другой вопрос — целевое назначение трудовложений, и уже с этой позиции можно рассуждать совершенно иначе, вплоть до концепции тотального делегирования задач, как наиболее эффективного решения и триумфа логики минимизации энергозатрат.
Методология разработки через страдание отбрасывает попытки предсказать проблемы, с которыми вы пока не столкнулись. Она признаёт, что обобщения без глубокого понимания предметной области ведут к чрезмерной сложности и потерянным усилиям. Архитектура всегда должна подчиняться реальным, а не выдуманным требованиям.
Это напоминает игру в шахматы по фактической расстановке фигур в самом общем смысле этой метафоры. Само стремление к прогнозированию является естественным для человеческого мышления. Я думаю, что здесь упущен огромный момент, связанный с негативными факторами отказа от прогнозирования. Я во многих комментариях пишу практически однотипные вещи, но отказ от прогнозирования в пользу более простой модели — поведение на основе фактической информации — это чистейшее первичное абстрагирование от проблем. Проще не видеть и не хотеть видеть какие-либо нюансы, а просто делать лишь бы было. Это похоже на езду на велосипеде с закрытыми глазами, сконцентрировавшись на равновесии и не думая о дороге.
… Скорее всего автор вкладывал не совсем тот смысл, который описан в тексте. Мне кажется, что в словах «Во время первых двух фаз надо уменьшать асимптотическую сложность алгоритмов» заложен значительно более глубокий смысл, который пытался передать автор на основе своего богатого опыта проб и ошибок, нежели могут передать эти слова. Шаг первый и шаг второй неразрывно связаны с прогнозированием и глубоким анализом ситуаций, характеризующих алгоритм. Либо автор не видит в них этапа прогнозирования, либо не признает его, считая для себя его очень несущественным.
Ведь мы не думаем над тем, как держать вилку в руке, хотя кинематика телодвижений, сигнальная синхронизация и работа мышечных волокон просто чудовищно сложна. Это абстрагирование позволяет нам сделать вывод — держать вилку в руке это настолько просто и незначительно, что не имеет смысла об этом думать и тратить на это время.
Я считаю, что верно не отказываться от прогнозирования в пользу быстрых решений, но правильно осознавать саму способность прогнозировать через моделирование в нашем воображении. Это лишь форма позволяющая привнести значительно больше лаконичности решению, нежели строго локализованное «здесь и сейчас» это работает, а завтра будет завтра, и якобы это неактуально и никого не волнует. Правда в том, что завтра все же будет, вопрос только в том, каким оно будет, и как правило многие аспекты масштабирования прогнозируются, но скорее всего срабатывает банальный принцип абстрагирования от сложности решения в пользу минимизации энергозатрат — перенести все на завтра, отложить на потом.
Это сложный вопрос, требующий глубокого комплексного анализа процесса развития и реализации, совокупности условий возникновения и среды разработки. Все это, на мой взгляд, не позволяет достаточно однобоко сказать — так как делаю я здорово и вот результат, а так как делает кто-то не совсем здорово, потому что результата нет.
Можно всю жизнь заниматься рукопашным боем и изучать основы самообороны и никогда их не применить. Можно всю жизнь проектировать алгоритмы и системы на все случаи жизни и не воплотить ни один масштабный проект или даже работающее в прикладной области решение. Но совершенно неверно говорить о том, что это все зло и пустая трата времени, так как пустой траты времени просто не существует, любое время и любое дело конвертируется в опыт. Другой вопрос — целевое назначение трудовложений, и уже с этой позиции можно рассуждать совершенно иначе, вплоть до концепции тотального делегирования задач, как наиболее эффективного решения и триумфа логики минимизации энергозатрат.
Дело наверно в том, что у вас с автором разные психотипы: вы по разному мыслите. В вас чувствуется аналитик, в Марце — практик. И вы — несовместимы.
Прелесть в том, что общаясь в краткосрочной переспективе вы дополняете друг друга — в вашу голову придет мысль, которая Марцу и в страшном сне не привидится. И наоборот — вон сколько мыслей в вас зародила статья. Получается что вы оба правы — Jedem das Seine.
В краткосрочной переспективе вы ломаете друг другу шаблоны и это полезно. В долгосрочной работать вместе — ад, но это уже другая тема…
Прелесть в том, что общаясь в краткосрочной переспективе вы дополняете друг друга — в вашу голову придет мысль, которая Марцу и в страшном сне не привидится. И наоборот — вон сколько мыслей в вас зародила статья. Получается что вы оба правы — Jedem das Seine.
В краткосрочной переспективе вы ломаете друг другу шаблоны и это полезно. В долгосрочной работать вместе — ад, но это уже другая тема…
не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий
Это тройное отрицание разрушило мой мозг. Так до конца и не уверен, что правильно понял эту фразу.
Тогда вам и вся остальная статья будет неподвластной.
Можно просто заменить технологию на мороженое и все будет ок (плюс некоторые переделки):
Не купите мороженого, если вам хорошо, когда мороженого нет.
Что эквивалентно: "не купите мороженого, от отсутствия которого вы не впадете в кому".
Можно просто заменить технологию на мороженое и все будет ок (плюс некоторые переделки):
Не купите мороженого, если вам хорошо, когда мороженого нет.
Что эквивалентно: "не купите мороженого, от отсутствия которого вы не впадете в кому".
Описанный подход очень напоминает принцип YAGNI.
Кроме того, принципы YAGNI, KISS и DRY прекрасно могут уживаться вместе.
Кроме того, принципы YAGNI, KISS и DRY прекрасно могут уживаться вместе.
Внезапно осознал, что мы на своем проекте используем именно эту методоологию разработки, но иногда — «разработку через задницу». Очень хорошие действенные модели максимально приближенные к реальному миру
Кто-нибудь использовал Storm на практике? Какие плюсы и минусы?
>Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».
Я всегда пишу код руководствуясь этии принципом. Сначало нужно сделать чтобы работало хоть как-то, затем чтобы работало хорошо, и затем что работало быстро. Третий этап в практике бывает нужен редко, но все-таки бывает. Это определяется нагрузочным тестированием. А в том случае когда надо написать что-то,, что совсем неясно как должно работать.то добавляется нулевой этап — напиши хоть -что-то.
Название «разработка через страдание» мне категорически не нравиться. Я считаю что это просто практический подход.Конечно логично улушчать те вещи которые создают больше всего проблем, но ИМХО это просто здарвый смысл, а не еще одна методология
Я всегда пишу код руководствуясь этии принципом. Сначало нужно сделать чтобы работало хоть как-то, затем чтобы работало хорошо, и затем что работало быстро. Третий этап в практике бывает нужен редко, но все-таки бывает. Это определяется нагрузочным тестированием. А в том случае когда надо написать что-то,, что совсем неясно как должно работать.то добавляется нулевой этап — напиши хоть -что-то.
Название «разработка через страдание» мне категорически не нравиться. Я считаю что это просто практический подход.Конечно логично улушчать те вещи которые создают больше всего проблем, но ИМХО это просто здарвый смысл, а не еще одна методология
Он придумал? А я думал, еще Кнут сказал: «Сделай, чтоб работало, потой — чтобы работало правильно, и только потом, чтобы работало быстро»
Мне тоже показалось, что мантру "make it run, make it right, make it fast", я встречал достаточно давно
Посмотрел в татье перевод слова «suffering». Скорее «боль». В общем, название ассоциируется с методом «болевой диагностики» в советской стоматологии. «Ж… ой прочувствовать», типа того…
«Разработка через страдание фигнёй»…
Привет, Agile!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка через страдание