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

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

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

A>>Кто вам сказал, что правильность заключается в использовании UML? Это часом не введении к мануале по розе написано?

H>Правильные должны были быть в кавычках. Не вижу причин чем использование UML может навредить, но в данном случае все было доведено до маразма — все описывалось настолько мелко, что быстро рассихронизировалось с действительностью. Вместо описывания интерфейсов UML использовали для описания внутреннего "дерьма".
Например в DDD/TDD роль uml сведена к минимуму. Фактически он вообще не нужен в классическом понимании.

A>>Утверждая, что юнит тесты туфта эквивалентно утверждению "я не умею ими пользоваться и не хочу учиться". Я вот после того как начал их применять вообще перестал понимать как это я без них умудрялся разрабатывать раньше, дело не в правильности, а в технической поддержке рефакторинга. Без них после любого рефакторинга надо скрестить пальцы и думать где же свалится.

H>Когда unit тесты — это главный вид тестирования (а многие верят что это так), то это становится профанацией. Тестирование должно быть сбалансированным. Авторегрессии не было, а юниты без регресиии — это профанация.

Юниттесты не могут быть главным методом или неглавныим методом. Юниттесты и функциональное тестирование являются разными вещами, это как складывать метры с километрами. Юниттесты проверяют соответсвие кусков кода ожидаемому поведению, функуциональность приложения не затрагивается. Функциональное тестирование, т.е. тестирование в своём классическом понимании, проверяет функционирование приложения, т.е. корректность работы всех возможных (точнее документированных) сценариев использования ПО.

H>Кто будет создавать окружение для модуля? Что, модуль сам себя тестировать будет? Среда тестирования — это обвязка вокруг модуля которая эмулирует для него внешний мир, эмулирует интерфейсы других модулей и выдает отчет.
Это прям новое свово в технологии юнит тестирования. Бесплатный совет — посмотрите опенсурс проекты с применением этой технологии, посмотрите как пишут юниттесты, для чего они предназначены и как применяются. Суть теста в том, что вы проверяете маленький, очень маленький

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

Rhino.Mock рулит , но это самом собой разумеется и к тулзам я не отнёс.

A> Это прям новое свово в технологии юнит тестирования. Бесплатный совет — посмотрите опенсурс проекты с применением этой технологии, посмотрите как пишут юниттесты, для чего они предназначены и как применяются. Суть теста в том, что вы проверяете маленький, очень маленький


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

Во вторых, где написано что модули должны быть маленькими? Пример в студию.

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

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

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

A>> Это прям новое свово в технологии юнит тестирования. Бесплатный совет — посмотрите опенсурс проекты с применением этой технологии, посмотрите как пишут юниттесты, для чего они предназначены и как применяются. Суть теста в том, что вы проверяете маленький, очень маленький


H>Вы когда в контору приходите со сложившейся практикой, Вам что дают возможность сделать как Вы хотите?

H>Во вторых, где написано что модули должны быть маленькими? Пример в студию.
какие нафик модули, по моему разговор идёт в разных измерениях? тестируют обычно один два три метода. Если у вас методы огромные пересматривайте дизайн.

H>Человек, который занает как все должно быть "правильно" вызывает у меня очень большие сомнения.
Тоакого человека нет и о нём никто не говорит, есть общепринятые нормы разработки софта.

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

H>>Во вторых, где написано что модули должны быть маленькими? Пример в студию.
A>какие нафик модули, по моему разговор идёт в разных измерениях? тестируют обычно один два три метода. Если у вас методы огромные пересматривайте дизайн.

Unit-test — тест модуля (юнита), под модулем может пониматься все что угодно — модуль из одного файла, модуль из сотни файлов, модуль который занимает 1/10 файла. Понятие модуля четко не определено.

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

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

A>Повторяю, что юнит тест не проверяет работу функционала, он проверяет работу куска кода. При граммотном проектировании с ориентацией на тестируемость принципиальных проблем не возникнет. Если у вас один компонент использует 100 других и в одном методе обрабатывает сообщения от сотни связанных с ним компонентов, стоит серьёзно задуматься о качестве и поддерживаемости кода имхо .

Вы реальный мир видели? Или Вы в институте студентов учите?

A>Очень всё правильно сказано, серьёзно правильно. Кроме одного — всё это не оправдывает рассказанный процесс разработки и коллег автора.

На мой взгляд, в коллективе из 10 программистов расказанный процесс разработки вполне допустим (учитывая, что они, видимо, не вдесятером одну программу пишут, а ведут параллельно несколько проектов, скажем, по 4-5 человек в каждом). Чтобы 4-5 программистам договориться друг с другом, UML не обязателен. Вот если бы было 100 программистов, да еще с постоянной текучкой, и новым приходилось дописывать код, начатый уволившимися — тогда да, с таким процессом далеко не продвинешься. А для нескольких программистов внедрение "правильного" процесса разработки может, наоборот, замедлить разработку на порядок.

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

H>Это теория. На практике бывают модули, которые весьма сильно связаны с другими. Что тогда?

A>>Повторяю, что юнит тест не проверяет работу функционала, он проверяет работу куска кода. При граммотном проектировании с ориентацией на тестируемость принципиальных проблем не возникнет. Если у вас один компонент использует 100 других и в одном методе обрабатывает сообщения от сотни связанных с ним компонентов, стоит серьёзно задуматься о качестве и поддерживаемости кода имхо .

H>Вы реальный мир видели? Или Вы в институте студентов учите?

Вот прямо сейчас рефакторю событийно-ориентированный движок
Максимально изолирую код по отдельным и почти не связанным интернальным классам на базе интерфейсов, потом для каждого такого классика пишу юниттест, потом уже пишу для взаимодействия нескольких (2-3 сразу) таких классов и т.п.
В начале описал контракт при помощи Rhino, на одних заглушках. Параллельно завершению отдельных классов заменяю ими заглушки (но в новой версии теста контракта).
А Вы говорите "сложный объект"... Сложный — значит, невозможно тестировать. Невозможно тестировать — значит, он непредсказуем и рефакторить его низзя.
Так что при всем желании с Aviator`ом в данном не поспоришь

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

На самом деле, 99.99999% таких решений вида "мы не используем STL/boost/что_там_еще" принимаются именно потому, что "страшно", "мы не справимся", "у наших разработчиков нет квалификации", "в своём коде мы в случае чего можем исправить ошибки, а в xxx — нет", и другие причины, которые я бы назвал отмазками.
Да — именно так. Из-за нехватки квалификации и нежелания эту самую квалификацию поднимать. Закостенелость и замшелость. Это та причина, по которой немолодые конторы имеют крайне заторможенный процесс развития и реакцию.

Здравствуйте, Handie, Вы писали:
H>Вы реальный мир видели? Или Вы в институте студентов учите?
Студентов не учил никогда. За код, не поддающийся тестированию отрывал бы руки сразу . А вот как раз от ваших понятий модулей веет какой-то древней теорией. Если у вас компоненты завязаны в один большой клубок то не завидую Вам, это действительно проблематично рефакторить тестировать и отлаживать. И проблема тут не в сложности или громоздкости задачи, а в слишком большой количестве обязанностей на каждом компоненте. Вы думаете у вас сверх сложная система, а все остальные сидят софт для ведения семейного бюджета пишут?

SD>На самом деле, 99.99999% таких решений вида "мы не используем STL/boost/что_там_еще" принимаются именно потому, что "страшно", "мы не справимся", "у наших разработчиков нет квалификации", "в своём коде мы в случае чего можем исправить ошибки, а в xxx — нет", и другие причины, которые я бы назвал отмазками.

Почему я не использую boost...
Сейчас мой проект в SVN занимает менее 1MB total
Если добавить boost, то он будет занимать ~150MB total
При этом exe вырастет тоже нехило.

BOOST — это монстр, части которого написаны отлично, а части — отвратительней некуда.
Некоторые части boost меня вводят в глубокий ступор:

cout << format("%s at %s with %s\n") % x % y % z;

или

printf("%s at %s with %s\n", x, y, z);

Первый из них — кошерный, новомодный, typesafe, второй — древний и без проверки типов. Теперь скажите честно, какой код читабельней?

SD>Да — именно так. Из-за нехватки квалификации и нежелания эту самую квалификацию поднимать. Закостенелость и замшелость. Это та причина, по которой немолодые конторы имеют крайне заторможенный процесс развития и реакцию.

Немолодые конторы доказали жизнеспособность своей бизнес-модели, в то время как молодые, при всех boost'ах и прочих монстрах как правило нет.

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

H>Почему я не использую boost...
H>Сейчас мой проект в SVN занимает менее 1MB total
H>Если добавить boost, то он будет занимать ~150MB total

А нельзя залить туда только релевантные части boost'а?

H>При этом exe вырастет тоже нехило.

С чего бы?

H>cout << format("%s at %s with %s\n") % x % y % z;

H>или

H>printf("%s at %s with %s\n", x, y, z);

H>Первый из них — кошерный, новомодный, typesafe, второй — древний и без проверки типов. Теперь скажите честно, какой код читабельней?

Одинаково?

П>На мой взгляд, в коллективе из 10 программистов расказанный процесс разработки вполне допустим (учитывая, что они, видимо, не вдесятером одну программу пишут, а ведут параллельно несколько проектов, скажем, по 4-5 человек в каждом). Чтобы 4-5 программистам договориться друг с другом, UML не обязателен. Вот если бы было 100 программистов, да еще с постоянной текучкой, и новым приходилось дописывать код, начатый уволившимися — тогда да, с таким процессом далеко не продвинешься. А для нескольких программистов внедрение "правильного" процесса разработки может, наоборот, замедлить разработку на порядок.

Очень правильная мысль! Процесс должен быть адекватен задаче и команде, а то в команде где 5 человек — UML, юнит тестирование, все как "у взрослых" — а в реале разбазаривание времени на "туфту"

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

H>Почему я не использую boost...
я тоже не использую

H>Сейчас мой проект в SVN занимает менее 1MB total
метр исходников — вполне нормальный размер проекта, чтоб юзать там вполне себе "большие" либы...

H>Если добавить boost, то он будет занимать ~150MB total
H>При этом exe вырастет тоже нехило.
уже сказали что надо отрезать ненужные куски

H>Некоторые части boost меня вводят в глубокий ступор:
H>cout << format("%s at %s with %s\n") % x % y % z;
H>или
H>printf("%s at %s with %s\n", x, y, z);
H>Первый из них — кошерный, новомодный, typesafe, второй — древний и без проверки типов. Теперь скажите честно, какой код читабельней?

Да одинаково, только первый слегка питоном попахивает

H>Немолодые конторы доказали жизнеспособность своей бизнес-модели, в то время как молодые, при всех boost'ах и прочих монстрах как правило нет.
согласен, вообще изначально все похоже на "пустите я все перепишу пи..то!" — я такое видел во *всех* конторах и проектах где работал

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

H>Очень правильная мысль! Процесс должен быть адекватен задаче и команде, а то в команде где 5 человек — UML, юнит тестирование, все как "у взрослых" — а в реале разбазаривание времени на "туфту"

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

A> Когда старая команда разбежится новая без проблем напишет перепишет проект, так как разбираться со старым барахлом возможности нет.

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

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

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

H>Это теория. На практике бывают модули, которые весьма сильно связаны с другими. Что тогда?

Как что? Переписывать нафиг. Зависимости оформлять интерфейсами. А в юнит-тестах интерфейсы эмулировать mock-ами.

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

SD>>На самом деле, 99.99999% таких решений вида "мы не используем STL/boost/что_там_еще" принимаются именно потому, что "страшно", "мы не справимся", "у наших разработчиков нет квалификации", "в своём коде мы в случае чего можем исправить ошибки, а в xxx — нет", и другие причины, которые я бы назвал отмазками.

H>Почему я не использую boost...
Да причём тут буст? Кто в этой ветке активно агитировал за буст? Правильно, никто, это был пример не более чем, а что вы за него так уцепились мне совершенно непонятно. Я даже полностью согласен, что привлечение буста должно быть очень серьёзно обоснованно. А отказ от stl по причине его незнания — верх маразма. Нетистируемость кода — недопустимо, преписать всё с нуля, если не выходит открыть проекты и читать исходники до посинения пока не придет осознание как писать юнит тесты, как уменьшать связность, как обращать зависимости, как делать моки.

H>Сейчас мой проект в SVN занимает менее 1MB total
Да, это очень большой проект, в таких проектах никогда не рефакторят .

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

A>> Когда старая команда разбежится новая без проблем напишет перепишет проект, так как разбираться со старым барахлом возможности нет.

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

П>Можно, например, давать гарантию на какой-то определенный срок. Скажем, в течении полугода заказчик может предъявлять претензии по найденным багам, они будут исправляться. Во-первых, за полгода вся команда не разбежится. Во-вторых, за полгода программисты не успеют все начисто забыть, и исправят баги без подробной программисткой документации и UML-диаграмм.

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

H>>Это теория. На практике бывают модули, которые весьма сильно связаны с другими. Что тогда?

SA>Как что? Переписывать нафиг. Зависимости оформлять интерфейсами. А в юнит-тестах интерфейсы эмулировать mock-ами.

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

1) Переписать все очень дорого
2) Переписать все очень долго
3) С высокой вероятностью получится то-же самое дерьмо что было в начале

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

H>Очень часто "переписчики" страдают тем, что не могут разобраться в чужом коде, либо считают это ниже своего достоинства.

С другой стороны, бывает и полное переписывание своего кода, который зашел в тупик. Тут-то нельзя сказать, что переписчик не разбирается в коде. Но часто такое переписывание себя оправдывает.