ApeCoder ApeCoder

Я бы не называл это рефаторингом. Это переписывание.

Вот, например, способ разбиение постепенно без полного переписывания. https://martinfowler.com/articles/extract-data-rich-service.html

Мне кажется, что товарищ DrPass говорил скорее о том, что если исходная система напоминает дремучий лес, то рефакторинг в таком случае смешивается в проклятом браке с переписыванием.

Вот эти вот все товарищи, которые учат нас рефакторингу как раз сконцентрированны на том, чтобы это было серией эквивалентных преобразований не ломающих функциональность.

Если оно смешивается, то это уже не рефакторинг (или не только рефакторинг).

пока Вы минимум сотню функций не реализуете, на Вашей системе

Не-не-не, никакого минимума, перечитайте то сообщение которое обсуждается

"с закладкой всех мыслемых и немыслемых параметризаций и точек расширения."

Так что все сразу.

"Рефа́кторинг, или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы"

Так что либо это не рефакторинг либо требования останутся соблюдены

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

Это противоречит тезису "Правильно — пересказывание написанного в таск-трекере!"
Т.е. в вашем случае impediment находится не в трекере, а в голове разработчика, из которой требуется дополнительное усилие, чтобы ее извлечь.

Описанный вами способ узнавания о препятствиях (impediments) так же ограничивает перечень препятствий только теми, которые выражаются в видимой задержке исполнения задачи в масшатбах рабочего дня (т.е. сами задачи должны быть записаны с длительностью день или меньше). Еще требует дополнительной коммуникации в том случае, если нужна помощь команды.

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

В скрам гайде не определяется как именно проводить оценки

Но достаточно популярное мнение использовать условные единицы (изначально это были "идеальные часы", насколько я помню, потом стали "стори поинты", в частности, потому, что народ не понимал, что был соблазн воспринять "идеальные часы" как реальные.)

Вот, например, мнение Сазерленда

Знание фреймворков, умение найти багу, умение найти решение проблемы на форумах

С моей точки зрения это все требует соображалки. Поиски баги — особенно.

У вас есть какие-то метрики, которые показывают, что собеседование с алгоритмами показывает уровень «соображалки» лучше, чем собеседования «за жизнь»?

А у вас есть вообще какие-о метрики по качеству найма? Если есть, поделитесь пожалуйста. По-быстрому не получается найти.

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

Кто и по какой причине предпочтет отправлять через вас если есть мессенджеры, звонки и смс?

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

Соответственно, эти требования могут быть выражены через тесты.

Я могу посмотреть в реализацию, но написать тесты так, чтобы они не зависели от реализации.

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

А с чего вы решили что юнит тестирование делается по методу черного ящика?

А не тем какие взаимодействия со внейшней средой были в прошлом?

А внутренние состояния определяются чем?

Но опять же TDD это юниты не завязанные на внутреннюю структуру. Хотя бы потому что для того чтобы знать внутреннюю структуру функций перехода код этих функций перехода уже должен быть.

Не должен — должна быть идея этого кода.

Эээ как вы определяете юнгит тесты и бранч тесты? Я нашел только определение бранч тестинга, и TDD, как мне кажется, неплохо на него ложится.

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

классов больше 200 строк вообще нет, а подавляющее большинство классов вообще на экран влазит.

Это как?

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

Вы сигнатуры всех методов крайнего разработанного вами класса помните?

Ой где же я могу посмотреть сигнатуры методов кроме как в документации?

Вторая только показывает или можно попользоваться?
Какой у меня опыт заказа, не было ли в прошлом такого, что через три года обнаруживается что я (или они) упустил что-то важное и результат не совсем тот, который я имел ввиду?

Зачем это надо мало понятно. Никто кроме Siemens MX это юзать не захотел по абсолютно понятным причинам.

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

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

Эээ. Все ваши рассуждения относятся только к ядрам или к продуктам в целом тоже?

Можно ли где-то увидеть ченджлог того, что вы называете ядром Parasolid?

А как получается что у парасолид есть новые фичи в новых версиях?

Если все что вы рассказываете верно, я представляю ченджлог так:

• Версия 1.0 — все мыслимые и немыслимые фичи
• Версия 1.1 — багфиксы
• Версия 1.2 — багфиксы
  ....
• Версия 9999.99999 — багфиксы

Тогда почему все выбирают неправильно оценивать?

Я вообще не представляю как так можно работать, если вы, конечно, не троллите.

Условно, вы должны выпускать сразу продукт в котором есть все-все-все фичи никак не получая обратной связи с рынком/пользователями. Либо у вас какая-то специфическая ниша, либо вы чего-то не замечаете, либо вы тролите.

А результат планирования кому-то нужен? Что происходит если план не соответсвует факту? Кто-то страдает от этого?

с закладкой всех мыслемых и немыслемых параметризаций и точек расширения.

Всех нужных и не нужных?

Т.е. все занимаются самообманом в отношении планирования.

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

Конечно. Я согласен.

Се́кта (сред.-в. лат. secta — школа, учение, от лат. sequor — следую) — понятие (термин), которое используется для обозначения религиозной, политической, философской или иной группы, иногда отделившейся от основного направления и противостоящей ему, или указания на организованную традицию, имеющую своего основателя и особое учение[1][2]

Я могу найти нечто общее между сектой и agile. Как и практически между сектой и любым другим направлением мысли.

Да и другие люди тоже бывают "java guru", "C# pundit" и прочее. Религия — достаточно частая метафора.

А как вы планируете? По идее "метод вчерашней погоды" должен колебания привести к среднему.

Если я не знаю значения слова, я обычно смотрю его в словаре.

Вот, например, в википедии

Практически все источники допускают нерелигиозное трактование понятия «ритуал» и, таким образом, полное отождествление его с понятием «обряд»[1][4][2][3]. Тем не менее, например, Ю. В. Чернявская проводит чёткую границу между ритуалом и обрядом, определяя их как равнозначные формы преемственности культуры и дополняя их третьей формой — обычаем. При этом обряд определяется как «десакрализованный ритуал»[7].

Или очередь не должна быть под контролем только этого сотрудника. Оценка отдельно — приоритет отдельно. См. разные agile процедуры планирования и разделения ответственности

Делать нужно как в нормальной науке

Делайте. Или приведите пример того, кто делает (в именно в дизайне).

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

А вы в мастер именно пушите или делаете пулл реквест?

Можете привести ссылочку? У меня сложилось впечатление, что в случае если некачественность не вкусовая (не понравился фильм), а объективная (разбитый DVD или там что-то не то с отображением) то права потребителя защищаются.

Вот, например, за отсутствие субтитров:

https://en.wikipedia.org/wiki/Criticism_of_Netflix#Accessibility

On March 11, 2011, Don Cullen filed a national class action lawsuit[53] against Netflix alleging that the service failed to closed caption its streaming video library and had misled deaf and hard of hearing customers. In June 2011, the National Association of the Deaf represented by the Disability Rights Education and Defense Fund (DREDF) filed a lawsuit against Netflix under the Americans with Disabilities Act.[54] On November 11, 2011, the court denied Netflix a motion to dismiss the case.[55]

In October 2012, the parties agreed to a settlement, under which Netflix agreed to pay $755,000 in legal fees, caption its entire library by 2014, and have captions available for all new content within 7 days by 2016.[56] In April 2015, the Ninth Circuit Court of Appeals issued an unpublished decision ruling that the ADA did not apply to Netflix in this case, as it is "not connected to any actual, physical place" and thus not a "place of public accommodation" that applies to the Act.[57]

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

А вы на 100% уверены, что недополученная прибыль копираста не является следствием нарушения какого-то договора (например, публичного ) копираста?

контенту он не нужен

Что такое "нужен контенту"? DRM нужен правообладателям. Контент же не живой?
Какое-то подмножество правообладателей считает DRM полезным и применяет его и успешно. Какое-то подмножество пользователей считает этот контент достаточно привлекательным, чтобы терпеть неудобства.

Если условный нетфликс выбирает DRM, а каждому Васе известно что без DRM всем только лучше, может быть две ситуации:

• Netflix не смотря на все свои A/B тесты и прочее не может дойти до истины, которая известна каждому Васе.

  
  

• Возможно, менеджеры Нетфлкс разбираются в своем бизнесе лучше чем Вася и им зачем-то DRM нужен и приносит пользу.

  
  

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

Интересно, кстати, не было ли экспериментов каких-то по отмене DRM нетфликсом и что из этого вышло.

А потом взяла и прогорела.

Все мы умрем.
Ну посмотрим, зарулит этих всех копирастов какой-то первый из них, кто откажется от DRM или нет.

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

А почему это проще, чем

сваять на чём-то вроде Delphi приложение с веб-контролом.