Здравствуйте, Maxim S. Shatskih

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

Продумывание и копи-пейст ... Лучший комментарий это "правило трех ударов" Кеннета Бека. Человеко-часы не тратятся на ненужную работу, а появляются только когда появляется потребность. TDD позволяет получить более правильный дизайн автоматически, однако надо понять суть подхода и его философию. Без этого это слепая трата человеко-часов. Опять же рефакторинг без тестов, как уже говорили просто НОНСЕНС. "писать с минимумом багов" как раз отлично ложиться в тему.

"Наследование, полиморфизм" и связанные с ними осторожности тоже из области слепого. Есть разумный подход, пяток принципов OOП, метрики оценки дизайна. Не нужно относится осторожно, нужно поощрять знания по этой теме. Тот, кто не понимает ООП никогда хорошего кода не напишет. И если это проект а не поделка, проигрыш будет больше времени, потраченного на изучения хорошего ООП дизайна.

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

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

Да в каком-то смысле само видение тоже ограничение. Искусство состоит в том, чтобы знать многие возможные методы и применять их только в крайнем случае.

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

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

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

N>Продумывание и копи-пейст ... Лучший комментарий это "правило трех ударов" Кеннета Бека. Человеко-часы не тратятся на ненужную работу, а появляются только когда появляется потребность. TDD позволяет получить более правильный дизайн автоматически

Это как? обвешали что-то криво спроектированное юнит-тестами — и оно от этого стало прямо спроектированное?

N>"Наследование, полиморфизм" и связанные с ними осторожности тоже из области слепого. Есть разумный подход, пяток принципов OOП, метрики оценки дизайна.

Я знаю ООП _на практике серьезной работы_ с 93 года (на уровне хохотушек для личного самоудовлетворения где-то с начала 92 с ТурбоПаскалем и ТурбоВижном). Тогда и приучили.

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

С тех пор я могу говорить только о _коренных недостатках_ ООП, в т.ч. нерешаемой как правило проблеме хрупкого базового класса.

N>"Лучше спагети, чем затягивание сроков" ... зависит от проекта. Если проект должен жить дальше контрольный срок сдачи проекта, то это провальный вариант.

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

N>"Осторожнее с джуниорами" — тоже бред. Вменяемого молодого можно быстрее научить работать правильно.

Хыыы... джуниор может вдруг и невменяемым оказаться.

N>Понянчился с ними 3-4 месяца и окупил все вложения.

Повезло товарищу.

N>Если нужно просто быстро и качественно сделать какую-то работу — отдайте ее на сторону профессионалам — это всегда дешевле.

А недостатки такого подхода надо перечислять?

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

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

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

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

Нужно, конечно, только это называется не "качество", а чем-то вроде "цена внесения изменений", или maintainability. В целом, этот показатель замерить сложнее, но он в целом кореллирует с относительной продолжительностью фазы проектирования к кодированию+отладке. То есть, в среднем — чем больше внимания уделялось проектированию, тем выше maintainability. Вторая закономерность в метриках состоит в том, что удлиннение фазы проектирования в среднем приводит к пропорциональному сокращению фаз кодирование+отладка, то есть в среднем проектирование+кодирование+отладка имеет тенденцию быть константой независимо от относительной продолжительности фаз, и в сумме показывает неплохие корелляции с объемом кода в строках (за вычетом комментариев и пустых) и функциональностью.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

G>>Кроме того, формула не учитывает влияние такого важного фактора, как применение интеллектуальной собственности сторонних производителей

MSS>Мне это пришло в голову при написании исходного поста, но я понял, что у меня крайне малый опыт такого использования, и потому мне почти нечего сказать на эту тему.

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

А при грамотном применении это может экономить трудозатраты, и сокращать сроки. Но увеличивать бюджет проекта. Короче, будем считать не ограничивая общности, что интеллектуальную собственность мы уже выбрали до старта проекта. Так, на самом деле, правильно.

G>>Можно. См правило "квадрат риск-приоритет", которое вполне указывает конкретно, продумывание чего можно посылать.

MSS>Низкий приоритет и высокий риск?

Это вообще кандидат на исключение из плана даже если сроки не поджимают. Потом жертвуем просто низким приоритетом, независимо от риска.

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

G>А при грамотном применении это может экономить трудозатраты,

Естественно, для того готовые компоненты и существуют.

G>Но увеличивать бюджет проекта.

Уменьшать.

Как правило цена этой IP ниже, чем цена разработки аналога "дома".

Причины воздержаться от сторонней IP могут быть а) выверты с ее лицензированием, налагающие обязательства б) то, что я перечислил в предыдущем сообщении.

G>Потом — жертвуем средним приоритетом, с наиболее высокими рисками. И так далее. На самом деле — в реальной жизни разумный человек кроме рисков при принятии таких решений принимет во внимание еще и прогноз трудозатрат. Что также — достаточно очевидно. Если трудозатраты на фичи примерно одного порядка — можно на них и забить, но это совсем не так обычно.

Простите. То есть — высокие трудозатраты приводят к исключению _из роадмапа_? вот это вряд ли верно.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Это как? обвешали что-то криво спроектированное юнит-тестами — и оно от этого стало прямо спроектированное?

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

N>>"Наследование, полиморфизм" и связанные с ними осторожности тоже из области слепого. Есть разумный подход, пяток принципов OOП, метрики оценки дизайна.

MSS>Я знаю ООП _на практике серьезной работы_ с 93 года (на уровне хохотушек для личного самоудовлетворения где-то с начала 92 с ТурбоПаскалем и ТурбоВижном). Тогда и приучили.

MSS>И проблемы хрупкого базового класса (название тогда не знал даже мой тогдашний шеф, а он почти гений) там стоили немалого гимора всей команде, вплоть до начальственной матерной брани. Причем заметно, что гимор возникал от ООП-шного перфекционизма, желания следовать принципам ООП не на пять, а на шесть.

MSS>С тех пор я могу говорить только о _коренных недостатках_ ООП, в т.ч. нерешаемой как правило проблеме хрупкого базового класса.

Давай пример поконкретнее — интересно. Да и что такое хрупкий класс? С большим количеством обязанностей?

N>>"Лучше спагети, чем затягивание сроков" ... зависит от проекта. Если проект должен жить дальше контрольный срок сдачи проекта, то это провальный вариант.

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

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

N>>"Осторожнее с джуниорами" — тоже бред. Вменяемого молодого можно быстрее научить работать правильно.
MSS>Хыыы... джуниор может вдруг и невменяемым оказаться.

Да это интересно — но и избавляться от таких джуниоров легче — не болит и не несет серьезных последствий. Но то что если пара звезд уже есть, но лучше брать молодых. И в общем основным критерием для подбора штатного сотрудника должна быть именно вменяемость, а не технические навыки. Лидер, проджект, аналитик, архитектор — да нужны звезды. Разработчик в комманду — нет — звезды не нужны — нужны просто вменяемые люди. Ну и выкинуть по контексту аналитика и архитектора, если они не нужны.

MSS>>Это как? обвешали что-то криво спроектированное юнит-тестами — и оно от этого стало прямо спроектированное?

N>Да нет еще круче — не тратится времени на проектирование — делается сразу как можно проще и дизайн эволюционирует только тогда, когда это действительно необходимо. Все точки расширения сразу все равно не угадать. Тесты обеспечивают работоспособность решения. Когда начинается второе повторение (копи-пейст) кода — берем на заметку, когда третье — делаем рефакторинг, улучшающий наш дизайн. Потом это же относится и к проектированию — не проектировать больше чем надо... Нужно сразу оговорится, что если все аспекты приложения известны заранее, то можно потратится на дизайн и сразу. Вот ты говорил о проектировании далеко вперед, но это тоже ругают как "коллапс проектирования". 1 принцип — вам это не понадобится.

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

Пара примеров из личной практики.

— Тестировали UI, был делфи-проект с наследованием UI (смеяться бесполезно и начальство двигало TestComplete для этих целей. При добавлении нового или изменении старого интерфейса, тест нужно было модифицирвать. А на DUnit, благодаря внутреннему дизайну, который позволил такое решение, это решилось в пол-часа процедурой, которая создавала каждый интерфейс пробегаясь по коллекции зарегистрированных интерфейсов.

— Стал на неизвестную тропу Native XML DB с XML:DB-Api, немного повошкался сделал пару тестовых классов — доволен шо той слон — потратив около часа на тесты развеял все сомнения по всем интересовавшим вопросам.

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

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

G>Ну, идея выписать формулу — интересная. Тока, думается мне, формула чутка другая. Ну-ка, попробуем вывести.
G>Очевидно, в предположении идеальной балансировки задач по ресурсам, которое будет почти верным в случае, если у нас ограничены ресурсы, а проект длинный:
G>Трудозатраты = Сроки * человекоресурсы.
G>Также, очевидно, что
G>Трудозатраты ~ качество * функциональность.
G>Бюджет ~ Трудозатраты
G>Итого,

G>Бюджет ~ Сроки * Человекоресурсы ~ Качество * Функциональность.
G>Вот, собственно. Каждый показатель из пяти может быть ограничен. Собственно, у тебя ошибка — Сроки должны в знаменателе стоять.

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

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


Широко известна аксиома проектного менеджмента о тройственном ограничении по параметрам Functional, Duration, Resources. Правило железного треугольника, говорит, что изменение одного из трех параметров обязательно приведет к изменению как минимум еще одного.

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

Functional = K * Duration * Resources

Кстати, совершенно понятно, что данная формула применима не только для проектов по созданию ПО. Она подходит для описания зависимостей основных параметров ЛЮБОГО проекта в классическом понимании слова "проект". Можно обобщить формулировку, и вместо термина "Functional" использовать более общий термин "Value", демонстрируя эту обобщенность:

Value = K * Duration * Resources (аксиома тройственного ограничения)

Теперь, в левой части просто некий планируемый объем. В проекте по созданию ПО он может измеряться в строках кода, килобайтах, функциональных поинтах, количестве use-case'ов, освоенных долларах, освоенных часах, етк. При строительстве дома — в этажах, при рытье траншеи — в метрах. Просто некий объем работы.

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

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

Work = Duration * Resources

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

Value = K * Work
K = Value / Work

Вот теперь смысл коэффициента K становится абсолютно осязаемым. Отношение созданной ценности к фактическим трудозатратам, проинвестированным в ее создание, есть ничто иное как производственная эффективность. Т.е. этот коэффициент демонстрирует насколько эффективно затраченные человеко-часы преобразуются в освоенный объем. Далее, для ясности, так и будем называть этот коэффициент: коэффициент производственной эффективности (Production Performance Index — PP):

Value = PP * Work
PP = Value / Work

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

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

Упрощая, положим, что на PP влияет только качество. Понятно, что производственная эффективность обратнопропорциональна требуемому уровню качества — чем строже ограничения по плотности деффектов, тем медленнее движется прогресс проекта:

PP = 1 / Quality

Тогда, подставляя значение коэффициента, в формулу тройственного ограничения, имеем:

Value = Resources * Duration / Quality

Resources = Value * Quality / Duration

Duration = Value * Quality / Resources

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

Аналогичным образом, выражая PP через другие экономико-социо-инженерно-психологические факторы, можно отслеживать их влияние на проект.

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

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

N>Да нет еще круче — не тратится времени на проектирование

Уже смешно.

N>- делается сразу как можно проще и дизайн эволюционирует только тогда,

Еще смешнее. Изменения _дизайна_ — это не просто тупой рефакторинг из серии "выделить метод". Это крайне дорогостоящий реинжиниринг.

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

N>Все точки расширения сразу все равно не угадать.

Ключевое слово — roadmap. Можно не угадать, а просто выяснить многие из них на раннем этапе.

N>пейст) кода — берем на заметку, когда третье — делаем рефакторинг, улучшающий наш дизайн.

Вот чем реже возникает нужда в таком — тем лучше.

N>Потом это же относится и к проектированию — не проектировать больше чем надо...

...авось кривая вывезет.

N>ругают как "коллапс проектирования". 1 принцип — вам это не понадобится.

Понадобится. Просто не сейчас.

N>Есть разумный подход, пяток принципов OOП

На них что, молиться теперь?

N>Давай пример поконкретнее — интересно. Да и что такое хрупкий класс? С большим количеством обязанностей?

Да нет, всего-то картина, когда разработчики наследников полагаются на внутренние детали о работе базы. Исходник базы-то вот он. Соблазн крайне велик.

N>>>"Лучше спагети, чем затягивание сроков" ... зависит от проекта. Если проект должен жить дальше контрольный срок сдачи проекта, то это провальный вариант.

Еще раз повторяю — спагетти живет зачастую годами. Не самое худшее. Хрупкий базовый класс намного хуже.

Макароны — они локальны. Зачастую 1-2 экрана кода. А вот хрупкий базовый класс сразу делает хрупким все дерево наследования.

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

Это не повод сразу делать хрупкий код.

N>если будет более двух обращений к такому коду — его просто эффективнее будет переписать.

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

N>Да это интересно — но и избавляться от таких джуниоров легче — не болит и не несет серьезных последствий.

Время только потеряно, деньги потеряны.

N>звезды не нужны — нужны просто вменяемые люди. Ну и выкинуть по контексту аналитика и архитектора, если они не нужны.

То есть — если есть кому делать аналитику и архитектуру.

N>Хочу добавить, что дизайн появляется именно благодаря тестам.

Ага, а бензин на бензоколонках появляется благодаря соблюдению ПДД

N>Т.к. использование кода начинается до его написания. И соотвественно изменить дизайн чего-то чего еще нет — ничего не стоит.

Всего-навсего все тесты в помойку выкинуть и новые написать, а так действительно ничего.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Это опечатка.
MSS>Объем внимания у всех ограничен, и опечатки бывают.
AJD>>IMO, большинство багов у опытного девелопера — это ошибки в бизнес логике, но никак не ошибки в синтаксесе.
MSS>Это опечатки. Их количество почти одинаково у всех и всегда, а бизнес-логику можно и продумать.

Большинство опечаток находится компилятором. Опечатки типа испозование ++i вместо i++ в большинстве случаев абсолютно не принципиальные и не ломают логику софта. А вот "бизнес-логику можно и продумать" — не так-то просто.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>GlebZ тут предлагал вообще такое — перед имплементацией фичи каким-то девелопером надо ее обсудить в коллективе.
+1
Только коллектив это не значит что вся компания обсуждает.

MSS>Потрясающе. У других девелоперов есть другие задания, а они от них отвлекутся. Глянем на Микрософт — у них есть такое? нет, у них есть понятие code ownership.
Густо-часто кодом владеет команда, а не определенный человек. В MS это по другому?

N>>Хочу добавить, что дизайн появляется именно благодаря тестам.
MSS>Ага, а бензин на бензоколонках появляется благодаря соблюдению ПДД
N>>Т.к. использование кода начинается до его написания. И соотвественно изменить дизайн чего-то чего еще нет — ничего не стоит.
MSS>Всего-навсего все тесты в помойку выкинуть и новые написать, а так действительно ничего.

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

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

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

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

G>>Ну, идея выписать формулу — интересная. Тока, думается мне, формула чутка другая. Ну-ка, попробуем вывести.
G>>Очевидно, в предположении идеальной балансировки задач по ресурсам, которое будет почти верным в случае, если у нас ограничены ресурсы, а проект длинный:
G>>Трудозатраты = Сроки * человекоресурсы.
G>>Также, очевидно, что
G>>Трудозатраты ~ качество * функциональность.
G>>Бюджет ~ Трудозатраты
G>>Итого,

G>>Бюджет ~ Сроки * Человекоресурсы ~ Качество * Функциональность.
G>>Вот, собственно. Каждый показатель из пяти может быть ограничен. Собственно, у тебя ошибка — Сроки должны в знаменателе стоять.

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

S>Когда-то тоже задумывался над обобщением формулы тройственного ограничения, и пришел к следующей, модели.

По сути то же самое (что хорошо — значит все правильно, раз одинаковый результат получен независимо), но рассуждение — совершенно великолепно. И более общо. Буду ссылаться.

Здравствуйте, Maxim S. Shatskih, Вы писали:


MSS>Макароны — они локальны. Зачастую 1-2 экрана кода.
Это не макароны и тем более не спагетти — ет вермишель

А вот строчек от 500 — ет уже спагетти в которые смотреть страшно

MSS>>GlebZ тут предлагал вообще такое — перед имплементацией фичи каким-то девелопером надо ее обсудить в коллективе.
AJD>+1
AJD>Только коллектив это не значит что вся компания обсуждает.

Дурацкие растраты времени.

MSS>>Потрясающе. У других девелоперов есть другие задания, а они от них отвлекутся. Глянем на Микрософт — у них есть такое? нет, у них есть понятие code ownership.
AJD>Густо-часто кодом владеет команда, а не определенный человек. В MS это по другому?

По-другому. Каждым куском кода владеет персонально один девелопер. Это владение переменно со временем с периодом порядка 1-2 лет, как я слышал.

AJD>Большинство опечаток находится компилятором. Опечатки типа испозование ++i вместо i++ в большинстве случаев абсолютно не принципиальные и не ломают логику софта.

Совершенно неверно. Запросто может возникнуть ошибка, да еще трудновоспроизводимая и тяжелая в поиске.

N>Ну где-то так. Причем особенно интересно именно в погоне за фичерами. Глубокое опережающее проектирование в заранее неизвестной задаче это плохо.

Этап первый. Делаем задачу известной. Это аналитика требований. Если ее толком нет — то будет плохо, и никакое TDD не поможет.

А в известной (хотя бы примерно) задаче уже и глубоко проектировать можно. Кстати, подход "ядро — плагины" имени Гапертона, к которому независимо приходили многие разные команды — это благо. Очень хорошие архитектуры. Если правильно сделать интерфейс втыкания плагинов, конечно. В Windows Shell правильно, во FreeBSD VFS (а неправильно — в Linux VFS, но Линус вообще убогий архитектор).

N>Особенно когда сидит и думает один или два человека.

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

N> И как раз тут в помощь TDD — ты не знаешь проектирования, а пытаешься сразу создать код, который использует еще не созданную архитектуру.

...как первокурсник на коленке. Посмешище.

N>Т.е. TDD это прежде всего не тесты — просто такой подход к проектированию через практику использования.

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

N>Именно в архитектуре и должен TDD себя хорошо проявлять, т.к. тестов не много и вместе с тем они охватывают систему целиком.

...о аллах...

Как это "немного" тестов могут "охватывать систему целиком"?

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

Юнит-тесты — штука кое-где полезная и незаменимая. Но TDD...