Здравствуйте, Codealot, Вы писали:

I>>Я уже говорил, что 100% соответствие не существует.

C>Это я говорил. Ты же пытался доказывать, что существует. Во всяком случае, до того, как ты сделал разворот на 180 градусов и сам этого не заметил

Цитирую себя http://rsdn.org/forum/job/7724820.1(

Автор: Ikemefula
Дата: 08.05.20

здесь кстати некий Codealot поставил минус):

Небольшой ликбез по контролю качества — качество, как степень соответствия требованиям, есть вероятностная величина которая никогда не бывает 100%. 0 — да. 100 — никогда.

Никакое количество тестов не гарантирует 100% отсутствие проблем. Такая гарантия заведомо недостижима. При чем не только в разработке, а в инженерии вообще Ни в производстве микроэлектроники, ни в производстве иголок, ни в нарезании хлеба на порции.

Парадокс — из этого никак не следует ненужность тестов, испытаний и тд

Похоже, тебе кажется, что все умные вещи сказаны и придуманы тобой

C>Возьми наконец свои яйца в кулак и признай, что облажался.

Обычно советуют браться за голову, а не за яйца. Но тебе виднее — хватайся за что ближе, твоё право.

Здравствуйте, Ikemefula, Вы писали:

I>Цитирую себя http://rsdn.org/forum/job/7724820.1(

Автор: Ikemefula
Дата: 08.05.20

здесь кстати некий Codealot поставил минус):

Это было уже после того, как ты сделал разворот на 180 градусов За это и минус.
А вот это — до:

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

I>Обычно советуют браться за голову, а не за яйца. Но тебе виднее — хватайся за что ближе, твоё право.

Тебе браться за голову уже нет смысла.

Ну так что, будешь дальше изворачиваться или всё же признаешь, что облажался?

Здравствуйте, Codealot, Вы писали:

C>Это было уже после того, как ты сделал разворот на 180 градусов За это и минус.

У меня ощущение, что ты читаешь ровно столько, сколько цитируешь.

C>А вот это — до:
C>

C>Вероятно, Фаулер использовал слишком общее слово. Рефакторинг в его подаче это безопасные изменения структуры решения, безопасные — не изменяют ни одного из наблюдаемых аспектов поведения. То есть, оптимизация структуры под задачи не трогая поведение.

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

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

Здравствуйте, Ikemefula, Вы писали:

I>У меня ощущение, что ты читаешь ровно столько, сколько цитируешь.

На совсем откровенную графоманию, где ты пытаешься замутить воду, я не отвечаю.

I>"не изменяют ни одного из наблюдаемых аспектов" — все тесты, которые ты написал должны быть зелёными, даже если это тесты на микротайминги или ручные тесты.

Тесты — это один крайне узкий пример наблюдаемых аспектов поведения, так что отмазка не принимается. Если ты имел в виду только тесты — надо было и писать про тесты, а не про "ни один наблюдаемый аспект поведения" и "любые внешние проверки, в любом количестве".

А теперь давай, напиши, что ты имел в виду совсем не то, что ты написал.

Здравствуйте, Codealot, Вы писали:

I>>"не изменяют ни одного из наблюдаемых аспектов" — все тесты, которые ты написал должны быть зелёными, даже если это тесты на микротайминги или ручные тесты.

C>Тесты — это один крайне узкий пример наблюдаемых аспектов поведения, так что отмазка не принимается. Если ты имел в виду только тесты — надо было и писать про тесты, а не про "ни один наблюдаемый аспект поведения" и "любые внешние проверки, в любом количестве".

Ты с задержкой в пять недель пересказываешь мне мои же высказывания. Это у тебя подход к самообразованию?
Цитирую себя http://rsdn.org/forum/job/7716124.1

Автор: Ikemefula
Дата: 27.04.20

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

То есть, кроме тестов можем использовать что угодно, абы помогло:

1 логи
2 инварианты, пред-, пост-условия
3 Аудит, если есть, тогда доступны подробности: "18.02 юзер такой то открыл профиль, исправил пол с женского на мужской, сделал две транзации идентификаторы прилагаются, исправил пол с мужского на женский."
Это почти как логи, только на стороне бизнес-логики.
4 Всевозможные метрики, счетчики которые собираются во время работы приложения или компонента
5 Собственно, самый простой случай — пользователь получил доступ к новой версии и пишет "ой, а тут раньше было, а сейчас нету"

Это все наблюдаемые аспекты и это не тесты. Случай 5 как раз и демонстрирует, что те самые 100% недостижимы.

Сюда можно добавить что угодно, если это поможет работе.

C>А теперь давай, напиши, что ты имел в виду совсем не то, что ты написал.

Что, телепатия не работает?

Здравствуйте, Poopy Joe, Вы писали:

PJ>Здравствуйте, _ABC_, Вы писали:

_AB>>Интересно, когда до тебя дойдет, что всегда софт разрабатывается на основе предположений той или иной степени детализированности и подтвержденности...
PJ>Интересно до тебя дойдет, что таким тоном ты будешь общаться сам с собой, в основном? Можешь просто не тратить усилий на набивание текста.
На себя посмотри...

Здравствуйте, Ikemefula, Вы писали:

I>Ты с задержкой в пять недель пересказываешь мне мои же высказывания. Это у тебя подход к самообразованию?

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

Здравствуйте, Codealot, Вы писали:

I>>Ты с задержкой в пять недель пересказываешь мне мои же высказывания. Это у тебя подход к самообразованию?

C>Это у меня попытка вдолбить в твою голову, что ты делал диаметрально противоположные высказывания. Но, увы, похоже что в твою голову ничего вдолбить невозможно.

По моему ты выдрал фразу из контекста и на ней строишь домыслы. У тебя вообще особенность читать ровно столько, сколько цитируешь.

На самом деле у самого Фаулера довольно много пространства для интерпретаций — он не указывает какие проверки и в каком количестве. Он говорит про пользователя и программиста.
А соответсвенно, что мне, программисту, взбредёт в голову, то я имею право использовать, абы мне это помогло. И сколько я таких подходов использую — сколько угодно, абы помогло.
Вот это и есть "любые проверки, в любом количестве". Это же очевидно. Эта часть прямое следствие из сказаного Фаулером. Ты это понимаешь?

Вопрос только в том, где проводить границу между "уже почти" и "уже точно". Про это Фаулер тоже говорит, но неявно, косвенно. Я считаю, надо отталкиваться от требований к качеству, от требований к продукту а так же от целей, возможностей и бюджетов проекта. Одно из условий, которые приводит Фаулер, это быстрые результаты. Т.е. не "ждем неделю", а гораздо чаще. Сотоварищи Фаулера уточняют эту часть, указывают, что тесты нужно запусать вплоть до нескольких раз минуту.
Тем не менее, к тестам все не сводится. Уже писал про это.

Здравствуйте, Ikemefula, Вы писали:

I>По моему ты выдрал фразу из контекста и на ней строишь домыслы. У тебя вообще особенность читать ровно столько, сколько цитируешь.

Опять врёшь. Унылый ты и скучный, попробуй придумать что-нибудь поумнее.

Здравствуйте, Codealot, Вы писали:

I>>По моему ты выдрал фразу из контекста и на ней строишь домыслы. У тебя вообще особенность читать ровно столько, сколько цитируешь.

C>Опять врёшь. Унылый ты и скучный, попробуй придумать что-нибудь поумнее.

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

Здравствуйте, Ikemefula, Вы писали:

I>Попробуй аргументы поискать, со временем это начнет получатся. Возьми, например, предпосленее мое сообщение в этой ветке и попробуй внятно описать, с чем конкретно ты не согласен.

Никакие аргументы не проймут человека, который врет как дышит. Видимо, Пелевин про таких как ты писал — "мнение автора может не совпадать с его точкой зрения".

Здравствуйте, ry, Вы писали:

ry>Здравствуйте, Codealot, Вы писали:

C>>Не дадут тебе делать понятную систему с грамотной архитектурой. В большинстве компаний, всё сводится к добавлению новых фич костыльно-подпорочным методом и замазыванию дыр при помощи говна и палок. Даже в больших и богатых компаниях.
ry>И это абсолютно правильный и адекватный подход.

С точки зрения продажника и того, кто имеет доступ к доходам — конечно! Если что-то приносит доход, то зачем создавать риск этот денежный поток нарушить или вообще прерывать? Не трогай и делай то, что я говорю!

С точки зрения программиста, который обычно не имеет доступа к финансам конторы, это пустая трата его времени и сил.

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

Я призываю думать о себе и делать себе хорошо в первую очередь. А цинизм в отношении того, что эти ваши "паттерны и архитектурки никому нафиг не нужны" — наивность на самом деле.

Здравствуйте, Vladek, Вы писали:

V> У тебя (программиста) нет поводов беспокоиться о продажах, если тебе этого ничего не даёт.
Тут ты не самый хитрый. Ушлые начальники как в игре Реверси сразу пытаются занять этот угол и постулировать, что именно разработчики (и не только программисты) должны делать такой продукт, который понравится покупателям.

Здравствуйте, Dziman, Вы писали:

D>Есть далеко ненулевое множество так называемых программистов, которые под рефакторингом понимают "переделать всё просто потому что оно не в моём вкусе".

Старый текст

Автор: AndrewVK
Дата: 18.11.04

по прежнему актуален, да.

Здравствуйте, Dziman, Вы писали:

I>>Ты написал, что у рефакторинга нет business value. Из этого следует, что под рефакторингом ты понимаешь ненужную вкусовщину, то есть — некрасивый код.
D>Он ко мне 'в личку' пришёл и именно так описал рефакторинг

Это скорее всего не он. Это какой то местный дурачок, который ссытся писать на форум и гадит людям в личку.

Здравствуйте, Codealot, Вы писали:

C>Ситуация, когда рефакторинг не делается не то что годами, а десятилетиями — она часто встречается, на самом деле. Достаточно посмотреть на мелко-мягкий, который 8 (!) лет назад решил переколбасить весь интерфейс винды, но при этом у них до сих пор две разные панели управления с частично пересекающейся функциональностью и совершенно разными интерфейсами, и использовать приходится обе — это довольно типичная для больших компаний история.

Переделка GUI это не рефакторинг.

Здравствуйте, Ikemefula, Вы писали:

I>Я же тебе примерно это и расписал.

Нет, тут он прав. Цель проджекта это не business value, цель проджекта правильное следование проекта намеченному плану, вне зависимости от того какой business value в этот план заложен (его там вообще может не быть). Проджект просто не в состоянии этот самый business value оценить, потому что не работает с заказчиками.
А непосредственно о business value должна болеть попа у другого ПМ, у продакта.
Есть еще, кстати, и program manager, так что вы поаккуратнее аббревиатурами кидайтесь.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет, тут он прав. Цель проджекта это не business value, цель проджекта правильное следование проекта намеченному плану, вне зависимости от того какой business value в этот план заложен (его там вообще может не быть). Проджект просто не в состоянии этот самый business value оценить, потому что не работает с заказчиками.

Странный проджект, если не работает с заказчиком План намечается без участия заказчика?

Здравствуйте, Ikemefula, Вы писали:

I>Странный проджект,

Стандартный современный проджект.

I> если не работает с заказчиком

Это как раз работающий с заказчиком проджект — довольно странное в современной разработке явление. Напоминает конторы с софковым стилем разработки, когда проджектом просто обзывают классического начальника отдела.
И для чего тогда, по твоему, нужен продакт, если проджект с заказчиками общается напрямую?

I> План намечается без участия заказчика?

План реализации? Разумеется без, зачем заказчику внутренняя кухня? Заказчику нужны майлстоуны со сроками в роадмапе, да периодические демо, чтобы он видел что процесс идет. А у вас что, на планирование итераций заказчики приходят?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Стандартный современный проджект.

Я бы сказал проджект где то из нулевых Он у тебя как то втёмную работает.

НС>Это как раз работающий с заказчиком проджект — довольно странное в современной разработке явление. Напоминает конторы с софковым стилем разработки, когда проджектом просто обзывают классического начальника отдела.

Вот заказчик вдруг захотел всё и сразу, к кому ему идти менять планы? Или наоборот, начало резко печь совсем другое.

НС>И для чего тогда, по твоему, нужен продакт, если проджект с заказчиками общается напрямую?

Сферы у всех различные.
1 Продакт формулирует нечто, что позже превратится в требования. Обычно от заказчика поступают хотелки. От продакта нужно внятное понимание проблемы. Он один или с БА, формулируют предложения и согласовывают, делают мокапы.
2 Архитектор дополняет эти предложения нефункциональными требованиям, делает пок, прототип или что там надо. Далее, архитектор сам или с командой, делают эстимейты. Продакт с БА так не могут — они не в курсе про нефункциональные требования, ограничения, и эстимейты дать не могут.
3 После согласования у нас уже есть требования, которые снова описывает продакт или БА в более менее внятном виде.
4 Проджет с одной стороны следит за этим процессом, выстраивает пайплайн, с другой стороны, отвечает за планирование. Например "вы тут на два года накидали задач, релиз осенью, потому надо оставить только самое необходимое"

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

I>> План намечается без участия заказчика?

НС>План реализации? Разумеется без, зачем заказчику внутренняя кухня?



> Заказчику нужны майлстоуны со сроками в роадмапе, да периодические демо, чтобы он видел что процесс идет. А у вас что, на планирование итераций заказчики приходят?

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

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