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

S>Где именно?

Не знаю, ты же писал. Но в осмысленное предложение те слова не складываются.

S>Да мне всё равно, при помощи каких кнопок он делается, или какие виды рефакторинга знаю я.

В этом и проблема, что тебе всё равно, что ты не знаешь.

S>Я-то хочу понять о чём вы говорите: это же вы рассказываете, что рефакторинг длинным не бывает, и что никак не мешает остальной деятельности.

Прямо так и написал? Где?

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

PJ>Ну это какая-то чушь, уж извини. Изоляция означает, что нет паразитной зависимости, а не то, что информацию нельзя передавать.
....
PJ>А как сделать если есть разные модули которые пишут в свои файлы, ничего друг про друга не знают (и не должны), но при этот если уж откатываем один, то откатывать надо все? Одной строчкой обойдешься?
Извини, но как первое в твоей голове сочетается со вторым?

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

_AB>Глупым демагогом.

Глупое и бездоказательное хамство.

_AB>Своей хватает.

Вот это — наверно первое слово истины, которое ты здесь написал.

_AB>Это нормальный аргумент для суда. Сложившаяся практика, все дела.

Рабство — сложившаяся практика с многотысячелетними традициями....

_AB>Одно положение закона уточняет другие пункты. Так будет точнее.

Может уточнять, а может и просто аннулировать. В данном случае — аннулирует.

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

Память опять тебя подводит.

_AB>Детский сад, штаны на лямках...

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

_AB>
_AB>Открой, да посмотри. Или, как все гордые программисты, считающие, что они — пупы земли и соль народа, не умеешь работать с информацией?

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

_AB>То, что ты нагуглил два латинских слова, не означает, что ты что-то доказал и уж тем более, что ты опроверг мои высказывания, не связанные с этим предложением...

А то, что у тебя вывод вообще никак не связан с предпосылками — означает.

_AB>У тебя нет постов, подтверждающих твою квалификацию

Нет на этом сайте. Собственно, всё. Это к вопросу о твоем умении мыслить рационально. Точнее, полном неумении.

_AB>>1. Пока всё твоё поведение доказывает, что болезни, которые ты себе приписываешь, тебя не касались в принципе
_AB>Первый пункт — мои сомнения в твоих болезнях. Удачи доказать в суде, что слова "пока всё твоё поведение доказывает" являются не мнением с изрядной долей сомнения, а обвинением.

Нет там никаких сомнений. Прямое и безапелляционное утверждение.

_AB>Ни один лингвист тебе такого заключения не даст.

Так ты еще и спец по лингвистике. Вот ведь талантище.

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

Заюлил то как. В оригинале уточнения про мнение не было. Есть такое мнение, что ты уже совсем заврался.

C>>Кстати, ты опять не ответил на прямой вопрос, который я тебе задал.
_AB>Я не обещал, что буду отвечать на все твои вопросы.

Ага. Когда внятного ответа у тебя нет, то ты не отвечаешь.

_AB>Твои слова куда более присущи самовлюбленному нарциссу, при том, что ты сам утверждаешь, что болезни, которые ты себе приписываешь, абсолютно несовместимы с таким поведением

А, то есть ты всё же утверждаешь, что разбираешься в данном вопросе лучше, чем врачи-специалисты, которые ставили диагноз? Или опять начнешь юлить, что ты не ты и мопед не твой?
Кстати, ты забыл добавить "есть такое мнение". На всякий случай.

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

S>Ну вот и я не понимаю, о чём вы говорите, когда пишете, что половина не сделана.

Задача — "сделать отчёт по продажам в PDF". Детали, важные для программиста — это какие данные должны быть в отчёте, критерии отбора, формулы расчёта и т.п. Шаблон того же PDF — будет ли он фиксированным, или должен настраиваться. Если настраиваться, то кем и в каких пределах.
А вот то, делать ли этот отчёт сначала, а систему конфигурации потом, или же наоборот

Если в одной задаче есть сначала и потом, то это две половины. Не слишком сложно?

PJ>>Вот это точно негодный тул, так как по-определению тест должен упасть, пока ты его не исправишь. Или твой тул еще и тест дописывает?
S>Ясно. Вижу, что рефакторинг вы видели только по телевизору. Ознакомьтесь, с тем, как работают реальные, а не воображаемые инструменты: https://www.jetbrains.com/help/resharper/Refactorings__Introduce_Parameter.html
S>Добавление параметра поправит все call sites, включая, естественно, тесты. А иначе нахрена такой рефакторинг нужен?
Ну, я рад, что благодаря jetbrains ты открыл для себя "реальный" рефакторинг, а не застрял на переименовании. Но я не понял, что ты этим хотел сказать? Если функция меняется, то контролирующий ее метод должен упасть. Иначе нафига такие тесты нужны?! А если тест падает, то это неправильный рефакторинг (с) потому что меняет поведение. Видимо он правильный если его делает тул, а так неправильный.

S>(facepalm). Ну ок, пусть будет DTO объект. У нас, к примеру, всё выставлено наружу как JSON. И у этого JSON есть модель — schema. Она, естественно, соответствует той модели, которая внутри. И в этой схеме сказано, что подписка — обязательный атрибут.
Мысль-то продолжи, это я тебе и сам написал, буквально в следующей цитате и было.

PJ>>Конечно является, это часть контракта. Если тебе нужна подписка, то подписка там быть должна. То, что ты сейчас предлагаешь это опять неявное соглашение и предположения. Я тебе говорю, что в одном api не обязательно смешивать мух с котлетами. Подписки отдельно, покупки отдельно. Инвариант один — модель, где либо подписка, либо покупка, а вот производные разные. Либо даже просто новый контракт, но где явно указано, что либо подписка, либо покупка, с разными dto внутри. grpc так позволяет, например, легко делать.
S>Да при чём тут grpc? Вы говорите про самый низкий уровень, неинтересные детали. Речь о том, что от изобретения нового контракта никакая магия не сделает всех клиентов старого контракта совместимыми с новым.
Ну с dto работает самый низкий уровень. Внезапно. Я думал ты знаешь. С другой стороны читаешь ты явно через специальный фильтр, не то, что я пишу.

S>Оплата — это передача денег. Ордер — это заказ. Если, допустим, пользователь Poopy Joe что-то заказал на 100 долларов, то его баланс уменьшился на 100 долларов.
S>Если пользователь заплатил 200 долларов, то его баланс увеличился на 200 долларов. Это вещи, мало связанные между собой.
S>Есть понятные любому менеджеру инварианты: баланс Джо равен сумме всех его платежей минус сумма всех заказов (пренебрегаем коррекциями).
S>Введение нового типа заказа означает, что либо мы ломаем сигнатуру методов по получению заказов, либо у нас ломается инвариант баланса.
S>Естественно, сломать сигнатуру методов — более хороший способ: таким образом мы получаем fail fast, и несовместимые клиенты падают сразу. А не продолжают молча рассинхронизовывать данные, приводя к утечке денег.
Опиши задачу полностью. Вот есть ордер на подписку. Что с этим знанием делали эти 100500 клиентов которые его получали.

PJ>>Опять не могу комментировать, поскольку я не знаю, что там содержится и что клиенту от них надо. Если клиенту важно знать про покупки, то ему надо переписывать, чтобы получить релевантную информацию.
S>Да, именно об этом и речь — надо переписывать.
А сейчас ты противоречишь ранее сказанному. Судя потому что вы вкорячили бесконечную подписку, на сам факт подписки клиентам плевать. Им надо что-то другое.

S>В том, что чудес не бывает, и если мы меняем модель, то это дорого стоит.
Тут нет никаких чудес, это управление зависимостями и "протечками" модели.

S>Ну, не было так не было. Хотя как я понял, версионность как раз была решением, а не проблемой. Впрочем, я уже понял, что мы с вами не договоримся — вы называете багфикс фичей, дополнение рефакторингом, а решение — проблемой. Ну, ваше право, чо. Не удивляйтесь только, что все остальные вас не понимают

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

Если из этой цитаты ты к 20 итерации понял, что версионность не была проблемой, то я думаю со мной все впорядке, ты просто сам с собой говоришь о чем-то. Неудивительно, что если так слушать, то в "уютном мирке" будет постоянная боль и страдания от изменений модели. У верблюда два горба, потому что жизнь трудна.

Здравствуйте, Poopy Joe, Вы писали:
PJ>Если в одной задаче есть сначала и потом, то это две половины. Не слишком сложно?
Это две разные задачи.

PJ>Ну, я рад, что благодаря jetbrains ты открыл для себя "реальный" рефакторинг, а не застрял на переименовании. Но я не понял, что ты этим хотел сказать? Если функция меняется, то контролирующий ее метод должен упасть. Иначе нафига такие тесты нужны?! А если тест падает, то это неправильный рефакторинг (с) потому что меняет поведение. Видимо он правильный если его делает тул, а так неправильный.

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

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

Что ещё вам непонятно в этой простой схеме вещей?

S>>Естественно, сломать сигнатуру методов — более хороший способ: таким образом мы получаем fail fast, и несовместимые клиенты падают сразу. А не продолжают молча рассинхронизовывать данные, приводя к утечке денег.
PJ>Опиши задачу полностью. Вот есть ордер на подписку. Что с этим знанием делали эти 100500 клиентов которые его получали.
Ну, откуда же мы это знаем? Это же внешние клиенты.

S>>Да, именно об этом и речь — надо переписывать.
PJ>А сейчас ты противоречишь ранее сказанному. Судя потому что вы вкорячили бесконечную подписку, на сам факт подписки клиентам плевать. Им надо что-то другое.
Им надо, чтобы сохранялась целостность модели.
Оставить атрибут в выдаче, и сделать какой-то другой метод для экспорта ордеров — у кого-то разъедутся балансы. Заметят это не сразу, а примерно через квартал; будет дорогостоящая эскалация, скандалы на самом верху, компания будет вынуждена в чём-то уступить клиенту (как правило — в деньгах).
Убрать атрибут из выдачи — у кого-то упадёт ночная синхронизация с диагностикой "value cannot be NULL'.
Кто-то из тех, у кого упадёт — это другие команды в пределах нашей же компании. У них своя codebase, очень часто на совершенно других языках, чем у нас. Каждому из них придётся переписать свой код, чтобы он перестал требовать подписку. Где-то для этого достаточно убрать констреинт, где-то нужно перекомпилировать проект, а где-то надо переделать половину кода, потому что его задача — отображать в UI соответствие между подписками и ордерами.
Каждый раз, когда мы планируем внести изменения в компонент, от которого есть зависимость, нам приходится проверять стоимость внесения изменений в dependents. В случаях типа того, который я привёл, эта стоимость получается большой.

PJ>Тут нет никаких чудес, это управление зависимостями и "протечками" модели.


PJ>

PJ>Была у нас проблема с конфигурационными файлами. Если машину внезапно выключить, то не смотря на все отключенные фильтры итд итп, файлы все равно портились.

PJ>Если из этой цитаты ты к 20 итерации понял, что версионность не была проблемой, то я думаю со мной все впорядке, ты просто сам с собой говоришь о чем-то.
Ну, вы же пишете, что "Пока версионности не было, не было и такой проблемы, было одно состояния в одной версии файла у каждого устройства."
По факту, проблема эта была и безо всякой версионности, потому что если машину внезапно выключить, то все файлы поделятся на три группы:
1. успевшие сохранить всё
2. не успевшие сохранить ничего
3. успевшие сохранить данные частично
Испорченные файлы — это, очевидно, п.3. Как сделать атомарной запись одного файла — это упражнение, простите, для джуна. Безо всякого рефакторинга и изменений в остальных модулях — независимо от того, как там устроено взаимодействие компонентов.
Тогда останутся файлы типа 1 и типа 2 — структурно корректные, но, возможно, несогласованные друг с другом.
То, что у вас не стали так делать, означает, что как минимум кто-то в вашей группе был в курсе того, что согласованность важна.
И этот кто-то предложил версионность как решение проблемы несогласованности.
То, что вы считаете, что проблема согласованности возникает только при введении версионности, означает, что это были не вы.
Или есть ещё какая-то подробность, которую вы опустили, и которая делает моё понимание неверным?

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

PJ>Вот с этой начинай, не ошибешься. https://pragprog.com/book/swdddf/domain-modeling-made-functional
PJ>Посмотрел на амазоне, в топ входит, тут уж сам смотри.

Эта книга мне знакома, но все равно спасибо.
Речь, однако, шла о списке. Продолжение можно?

Здравствуйте, Codealot, Вы писали:
C>Не знаю, ты же писал. Но в осмысленное предложение те слова не складываются.
Переполнение буфера.
S>>Я-то хочу понять о чём вы говорите: это же вы рассказываете, что рефакторинг длинным не бывает, и что никак не мешает остальной деятельности.
C>Прямо так и написал? Где?
Ну, значит я неверно вас понял по ходу спора. Если вы считаете, что рефакторинг бывает длинным или дорогим или мешает остальной деятельности — то, может, менеджер иногда и прав, что ставит его приоритет пониже разработки?

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

I>>Это не я, а Фаулер.
PJ>Я даже не знал, что он знает русский.
PJ>По виду похоже скорее на твою интерпретацию Фаулера, как ты ее понял.
PJ>Не говоря уж то, что Фаулер, да и любой другой известный автор, высказывают так же свое мнение, а не абсолютную истину.

Фаулер подал эту методологию и соответсвенно именно он имеет ту самую правильную трактовку.

PJ>Я бы предложил перестать ссылаться на авторитеты и высказывать своем мнение и уж его отстаивать.

Если четко декларированая методология рефакторинга от Фаулера. У тебя какая то другая методология, для который ты использовал то же самое слово — рефакторинг.

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

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

I>>Нет, не любые. Менеджер, даже пиэм, может быть плохим по самым разным причинам. Например, пить водку вместо работы.

C>Ни одного такого не встречал. А любителей микроменеджмента — очень много, с самым разным бэкграундом.

Как интересно, сначала ты выдал "Любые плохие пиэмы". Теперь не любые а только многие. Эдак ты дойдешь до конкретных вместо многих

I>>Очевидно — нет. Есть общая зона ответствености, пересечение. И это не код.

C>А что, уже научились создавать программы без написания кода?

Похоже, ты не представляешь себе менеджера что в код не смотрит

Вот пример, самый свежий, девелопер создаёт тикет:
"во фремворк надо добавить агент вот такойто с такими то значениями"
мотивация
"это надо, потому что все консумеры должны делать такое а тут неудобно и непонятно"
Чудесно, да? Надо, потому что нада

В этом описании business value отсутствует в принципе. Менеджеру ничего не ясно, вообще ничего.

Вот смотри, мой вариант, в единицах business value

Потенциальная деградация производительности из за неверной конфигурации пула соединений
Симптомы — перечень признаков, когда наблюдается именно эта проблема
Аффектаются:
приложения, которые — перечень условий
продукты, которые — перечень условий
сервисы, которые — перечень условий

Фикс фремворка не требуется, консумеры настраивают свои агенты сами, см доку по настройкам

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

Все что требуется от менеджера
1 быть в курсе, насколько критичен перформанс для его проектов или делегировать тому, кто в курсе
2 быть в курсе, есть ли известные ли ему нерешенные проблемы с перформансом или делегировать тому, кто в курсе
3 понять, подходит ли его продукт/приложение/сервис под описание или делегировать тому, кто понимает
4 выставить приоритет для своего проекта

В код смотреть не надо.

> В нашей индустрии, нет кода — нет никакого business value. Точка.

business value это фичи, производительность, надежность, секурити, 'time-to-market' т.е. всё, что непосредственно приносит деньги.

Соответсвенно, Не надо показывать код фичи, достаточно её правильно идентифицировать. Вместо "вот код фичи, которая барахлит" достаточно написать
"typeahead морозит инстансы, последствия — от деградации производительности вплоть до отказа инстанца"
причина — "лавина запросов, т.к. нет никакого back pressure".
Менеджеру понятна первая строчка. Последнюю ему понимать уже необязательно и в код лезть тем более.

И совершенно точно лучше не станет, если тикеты будут вида "перенести конфигурацию http agent оттуда сюда" или "передать параметр keepAlive фремворку", "refactor the smelly code" + ссылка место в коде в репозитрии

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

_AB>>Глупым демагогом.
C>Глупое и бездоказательное хамство.
Я, конечно, понимаю, что ты специалист по глупости, бездоказательным заявлениям и хамству, но в данном случае ты не прав.
Остальное читать не буду, ибо ты пока поднадоел, а тут есть дискуссия поинтереснее.
Если она затухнет, а ты не успокоишься, продолжу в тебя палочкой тыкать.

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


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

S>Если мы посмотрим на систему как на конгломерат модулей, то у неё есть внутренние интерфейсы, которые потребляются модулями только той же системы (исходный код под нашим контролем), и внешние интерфейсы — которые потребляют внешние клиенты. Их исходный код вне нашего контроля, и это принципиально.
Т.е. если файлы никому снаружи не нужны это рефакторинг или нет?

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

S>А вот изменения внешних контрактов рефакторингом не являются — потому (и только потому), что мы не можем поменять все места их вызовов.
Так у меня не менялись места внешних контрактов, но ты выше доказывал, что это никак не рефакторинг. Ты уж либо крестик сними, либо штаны одень.

S>>>Естественно, сломать сигнатуру методов — более хороший способ: таким образом мы получаем fail fast, и несовместимые клиенты падают сразу. А не продолжают молча рассинхронизовывать данные, приводя к утечке денег.
PJ>>Опиши задачу полностью. Вот есть ордер на подписку. Что с этим знанием делали эти 100500 клиентов которые его получали.
S>Ну, откуда же мы это знаем? Это же внешние клиенты.
Прелесть какая. Т.е. ты что-то зачем-то отдаешь клиентам, при этом ты даже не в курсе надо ли им это... А когда отдавать нечего, то просто начинаете врать выдавая фейковые данные...

PJ>>А сейчас ты противоречишь ранее сказанному. Судя потому что вы вкорячили бесконечную подписку, на сам факт подписки клиентам плевать. Им надо что-то другое.
S>Им надо, чтобы сохранялась целостность модели.
Откуда ты знаешь, ты же сказал, что клиенты внешние и ты не знаешь, что они делают и зачем? Может им критически важно знать различие между подпиской и покупкой.

S>Оставить атрибут в выдаче, и сделать какой-то другой метод для экспорта ордеров — у кого-то разъедутся балансы. Заметят это не сразу, а примерно через квартал; будет дорогостоящая эскалация, скандалы на самом верху, компания будет вынуждена в чём-то уступить клиенту (как правило — в деньгах).
Т.е. ваша система получила зависимость от неизвестного чего-то, потому что там что-то может разъехаться, но точно ты не знаешь. Может и не разъехаться. И вообще хз, что там происходит...

S>Убрать атрибут из выдачи — у кого-то упадёт ночная синхронизация с диагностикой "value cannot be NULL'.
Я не предлагал убирать никаких атрибутов, контракт он на то и контракт, чтобы оставаться валидным. Я уж не знаю как еще проще это сказать.

PJ>>

PJ>>Была у нас проблема с конфигурационными файлами. Если машину внезапно выключить, то не смотря на все отключенные фильтры итд итп, файлы все равно портились.

PJ>>Если из этой цитаты ты к 20 итерации понял, что версионность не была проблемой, то я думаю со мной все впорядке, ты просто сам с собой говоришь о чем-то.
S>По факту, проблема эта была и безо всякой версионности, потому что если машину внезапно выключить, то все файлы поделятся на три группы:

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

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

I>Фаулер подал эту методологию и соответсвенно именно он имеет ту самую правильную трактовку.

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

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

I>>Фаулер подал эту методологию и соответсвенно именно он имеет ту самую правильную трактовку.

PJ>Поскольку его тут нет, а тебя он своим голосом не назначал, то мой комментарий остается верным.

Ок, даём слово Фаулеру

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
Its heart is a series of small behavior preserving transformations. Each transformation (called a "refactoring") does little, but a sequence of these transformations can produce a significant restructuring.

и еще

In the book, I make the following definition of “refactoring”

noun: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior

verb: to restructure software by applying a series of refactorings without changing its observable behavior.

Refactoring isn't another word for cleaning up code — it specifically defines one technique for improving the health of a code-base. I use "restructuring" as a more general term for reorganizing code that may incorporate other techniques.

И в самой книге Фаулер объясняет, что же такое внешнее, наблюдаемое поведение
"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
(Рефакторинг, 2003, изд Символ, Спб, стр 62 последний абзац)

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


I>Ок, даём слово Фаулеру
I>

I>Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
I>Its heart is a series of small behavior preserving transformations. Each transformation (called a "refactoring") does little, but a sequence of these transformations can produce a significant restructuring.

Теперь смотрим, что ты сказал

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

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

I>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

Т.е. весь вопрос в том как интепретировать что такое внешнее или внешний вид. Ты уверен, что Фаулер имел ввиду именно твою интепртетацию. Имеешь право, но это не делает тебя гласом истины.

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

I>>"Никто — ни конечный пользователь, ни программист — не сможет сказать по внешнему виду, что что-то изменилось"
I>>(Рефакторинг, 2003, изд Символ, Спб, стра 62 последний абзац)

PJ>Т.е. весь вопрос в том как интепретировать что такое внешнее или внешний вид.

Любые внешние провеки, в любом количестве. А ты предлагаешь закрывать глаза на появление некой фичи, выборочно смотреть исключительно со стороны некоего бизнеса У тебя что, энд-юзеры это часть кода системы?

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


I> Любые внешние провеки, в любом количестве. А ты предлагаешь закрывать глаза на появление некой фичи, выборочно смотреть исключительно со стороны некоего бизнеса У тебя что, энд-юзеры это часть кода системы?

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

Здравствуйте, Poopy Joe, Вы писали:
PJ>Т.е. если файлы никому снаружи не нужны это рефакторинг или нет?
Нет, не рефакторинг. Они снаружи видны. Нужность — штука воображаемая: в вашем же примере они как будто бы были не нужны, и вдруг рраз! И стали нужны.

PJ>Изменил сигнатуру, делаешь что-то внутри с параметром, но тест про это вообще не в курсе. Замечательные тесты, да...
(facepalm). Простите, я уже расписал максимально подробно. Если вам непонятно, как именно рефакторинг взаимодействует с тестами — ну, попробуйте сами что ли.

PJ>Так у меня не менялись места внешних контрактов, но ты выше доказывал, что это никак не рефакторинг. Ты уж либо крестик сними, либо штаны одень.
Не любое изменение, не меняющее внешних контрактов, является рефакторингом.

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

PJ>Откуда ты знаешь, ты же сказал, что клиенты внешние и ты не знаешь, что они делают и зачем? Может им критически важно знать различие между подпиской и покупкой.
Если важно — они всегда могут отличить их друг от друга по дополнительным признакам. Точно так же, как могут отличить подписки на Symantec от подписок на Dropbox.
Что мы знаем точно — это то, что у них не было задачи отличать подписки от покупок. Потому что никаких покупок раньше не было.
Если задача появится — у нас есть способ её решения, который мы предложим.

PJ>Т.е. ваша система получила зависимость от неизвестного чего-то, потому что там что-то может разъехаться, но точно ты не знаешь. Может и не разъехаться. И вообще хз, что там происходит...
А вы как думали? Всеведение — опасная иллюзия. Наиболее хреновые решения в моей практике принимали люди, котрые полагали, что им всё-всё известно.

S>>Убрать атрибут из выдачи — у кого-то упадёт ночная синхронизация с диагностикой "value cannot be NULL'.
PJ>Я не предлагал убирать никаких атрибутов, контракт он на то и контракт, чтобы оставаться валидным. Я уж не знаю как еще проще это сказать.
Вы пока вообще ничего хорошего не предложили. Идея "добавить ещё один контракт" плохая настолько, что у меня нет слов, чтобы подобрать описание для этого.

PJ>Вот эту бы всю энергию разума бы да на чтение.
PJ>По факту докладываю следующее. Это хардварная проблема. Это упомянуто, но, признаю, недостаточно внятно.
)))
PJ>Все файлы записаны, их можно даже считать обратно. Т.е. винда думает, что с файлами все ок.
)))
PJ>Но если машину после этого просто выключить, то в некоторых файлах могут быть нули, некоторые сектора не запишутся.
PJ>И нет, мы не идиоты, все что можно отключить в винде по этому поводу отключено. Вероятно это проблемы дискового кеша.
Ну конечно же это проблемы дискового кэша. Вы что думаете, вы первые в мире, кто столкнулся с такой ситуацией?
PJ>Это происходит нечасто, но происходит. Все остальные выводы которые ты навысасывал так же мимо кассы. Можешь не трудиться фантазировать остальные детали, какие диски брать или как правильно выключать винду и прочее. Считай это бизнес-требованием.
Пока что вы ничего нового не рассказали. Ровно то же самое, чего я ожидал. Единственное — что решения, которые я себе представлял, опираются на упорядоченность записи. Если бывает так, что произведённая позже запись проходит, а произведённая раньше — нет, то придётся покумекать над решением подольше. Сходу ничего придумать не могу — все известные мне технологии восстановления построены на упорядочивании. Если диск ухитряется записать хвост журнала, но теряет его середину, то это сломает каждую из известных мне СУБД.

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

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

I>> Любые внешние провеки, в любом количестве. А ты предлагаешь закрывать глаза на появление некой фичи, выборочно смотреть исключительно со стороны некоего бизнеса У тебя что, энд-юзеры это часть кода системы?

PJ>В такой интерпретации рефакторинг не имеет смысла, вообще. Любая оптимизация по скорости или памяти это наблюдаемый внешний эффект.

А при чем здесь оптимизация по скорости или памяти? Смысл рефакторинга в том, что ты меняешь структуру решения отдельно, а уже потом корректируешь само решение отдельно.

Вместо дублирования фикса в 300 мест, заменяешь 300 мест на вызов функции, где делаешь нужную тебе вещь 1 раз.

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

Оптимизации памяти или процессорного могут выполняться с использованием рефакторинга, главное в один момент времени не делать всё сразу.

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

S>Нет, не рефакторинг. Они снаружи видны. Нужность — штука воображаемая: в вашем же примере они как будто бы были не нужны, и вдруг рраз! И стали нужны.
Еще один... Да всё, всё есть наблюдаемое состояние, если я решу за этим наблюдать. Добавил параметр в метод это изменяет расположение в памяти и, соответственно, размер, и это можно наблюдать. Заменил пузырьковую сортировку быстрой и это можно наблюдать. И даже тест сделать, который это отслеживает. Либо программа не делает ничего, либо результаты рефакторинга можно наблюдать.

PJ>>Изменил сигнатуру, делаешь что-то внутри с параметром, но тест про это вообще не в курсе. Замечательные тесты, да...
S>(facepalm). Простите, я уже расписал максимально подробно. Если вам непонятно, как именно рефакторинг взаимодействует с тестами — ну, попробуйте сами что ли.
Ну да, ты один кто пробовал тесты и понял весь дзен добавления параметра.

PJ>>Прелесть какая. Т.е. ты что-то зачем-то отдаешь клиентам, при этом ты даже не в курсе надо ли им это... А когда отдавать нечего, то просто начинаете врать выдавая фейковые данные...
S> Ну почему же фейковые — более-менее настоящие.
Угу, и чуть-чуть беременные.

S>Если задача появится — у нас есть способ её решения, который мы предложим.
Я верю в вас, генерировать очередные костыли отлично получается.

S>А вы как думали? Всеведение — опасная иллюзия. Наиболее хреновые решения в моей практике принимали люди, котрые полагали, что им всё-всё известно.
Ну да, то ли дело предположения... Наверняка принимать решения лучше всего на основе их.

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

S>Ну конечно же это проблемы дискового кэша. Вы что думаете, вы первые в мире, кто столкнулся с такой ситуацией?
Я написал, что я так думал? Или я просил помощи в решении где это?

S>Пока что вы ничего нового не рассказали. Ровно то же самое, чего я ожидал. Единственное — что решения, которые я себе представлял, опираются на упорядоченность записи. Если бывает так, что произведённая позже запись проходит, а произведённая раньше — нет, то придётся покумекать над решением подольше. Сходу ничего придумать не могу — все известные мне технологии восстановления построены на упорядочивании. Если диск ухитряется записать хвост журнала, но теряет его середину, то это сломает каждую из известных мне СУБД.
Да ладно, сообщение назад это же была задача для джуниора?!

S>Но это непринципиально: кто бы ни был виноват в потере данных, ОС или железо, при старте приложения мы наблюдаем одну и ту же картину — три типа файлов.
Два. Либо все хорошо, либо в (хотя бы в одном из них плохо) и тогда система откатывалась на дефолтное состояние. Никакой несогласованности там не было никогда.

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

PJ>Еще один... Да всё, всё есть наблюдаемое состояние, если я решу за этим наблюдать. Добавил параметр в метод это изменяет расположение в памяти и, соответственно, размер, и это можно наблюдать. Заменил пузырьковую сортировку быстрой и это можно наблюдать. И даже тест сделать, который это отслеживает. Либо программа не делает ничего, либо результаты рефакторинга можно наблюдать.
Я ждал этого вопроса, хотя надеялся, что вы сможете сами себе на него ответить.
Есть определённые соглашения о том, что считается важным, а что нет. Они привычны всем, кроме вас. И, быть может, вашей команды, хотя есть у меня сомнения и в этом.
Замена способа сортировки рефакторингом не является.
Вынос метода сравнения элементов при сортировке в параметр — является рефакторингом.
Почитайте Фаулера, посмотрите на Решарпер, студию, идею. Со временем набьёте руку, сможете сходу понимать, где рефакторинг, где нет.

PJ>Ну да, ты один кто пробовал тесты и понял весь дзен добавления параметра.
Нет, нас таких много. Это у вас своё, уникальное для индустрии понимание термина "рефакторинг".

PJ>Я верю в вас, генерировать очередные костыли отлично получается.
А вы как думали. Продажи растут, премии выплачиваются. Все довольны.

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

PJ>Практически любой протокол умеет поддерживать возможность добавления второй версии контракта, без ломания первой. Это настолько плохая идея, но мужики не знают. Немедленно оповестите мир о вашей находке.
Ну вот я же вам на пальцах показал, что в данном случае нет никакого способа добавить вторую версию контракта без ломания первой. Вы слишком много значения придаёте вашим контрактам, выраженным в F#.
Вам кажется, что если компилятор доволен, то и пользователи тоже.
А у меня есть богатый опыт наблюдения за тем, как люди вносили изменения в "файлы, которые никому не нужны", или убирали "атрибут, который был необязательным".
И за стоимостью последствий вот таких обоснованных решений.
И за тем, как люди месяцами откладывали принятие какого-либо решения, потому что "мы собрали ещё не все данные — давайте опросим всех партнёров и узнаем, кто какие методы использует и зачем".


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

S>>Ну конечно же это проблемы дискового кэша. Вы что думаете, вы первые в мире, кто столкнулся с такой ситуацией?
PJ>Я написал, что я так думал? Или я просил помощи в решении где это?

S>>Пока что вы ничего нового не рассказали. Ровно то же самое, чего я ожидал. Единственное — что решения, которые я себе представлял, опираются на упорядоченность записи. Если бывает так, что произведённая позже запись проходит, а произведённая раньше — нет, то придётся покумекать над решением подольше. Сходу ничего придумать не могу — все известные мне технологии восстановления построены на упорядочивании. Если диск ухитряется записать хвост журнала, но теряет его середину, то это сломает каждую из известных мне СУБД.
PJ>Да ладно, сообщение назад это же была задача для джуниора?!
Это я сходу затупил. Конечно же, за полчаса можно решить и эту задачу — хоть с версиями, хоть без них.
PJ>Два. Либо все хорошо, либо в (хотя бы в одном из них плохо) и тогда система откатывалась на дефолтное состояние. Никакой несогласованности там не было никогда.
Тогда непонятно, откуда может взяться несогласованность при введении версии конфигурации. У нас каждая из версий либо консистентна, либо нет. Берём последнюю версию, если она консистентна — всё хорошо. Если хотя бы в одном файле плохо — откатываемся на предыдущую версию. Ума не приложу, куда здесь можно приделать рефакторинг или замену целого модуля.