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

Это то же самое, что знание языков.

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

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

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

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

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

на эту тему

Вот так 'Вера Ивановна открыла для себя ТайДД'.

Я начал реализовывать некий численный метод.

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

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

Я незадолго прочел кой-что о TDD, и хотел применить на практике.

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

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

Создал по одному тесту для известных свойств функции из мат. справочника.
Сразу оказалось, что не все свойства напрямую представимы в виде тестов типа: f(X) = Y
Более ценными оказались несколько теорем и их следствий, который рассматривались в том же мат. справочнике, и которые как раз выдавали эти самые связки f(X) = Y.
Всего их было около 12-и.

Естественно, я так же создал по одному тестовому методу для каждого известного проблемного случая. Каждый из этих методов имел вид типа:
Assert.AreEqual(y, f(x));

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

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

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

...

Не могу вам передать, сколько раз я видел, что горят 3 из 20 лампочек, 18 из 20, 1 из 20 в разных комбинаторных сочетаниях, пока я переделывал код всего-навсего одного метода, чтобы добиться правильной его работы. Теперь представьте, сколько у меня было шансов решить, что наконец-то все заработало, и можно дальше не париться, тогда как метод работал только для некоторых параметров, но не для других.

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

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

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

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

Моей смерти ждать не пришлось, ибо стало ясно, что хотя метод работает теперь блестяще правильно, он все еще далеко не оптимален по времени и по памяти. И вот тут я понял, что усилия были в правильную сторону. Началось самое test-driven, до этого это была просто попытка привести к этой парадигме.

Теперь у меня была свобода воротить в коде метода все, что хочется, я точно знал, что ничего не сломаю, потому что "волшебные пузырьки" тут же все покажут красным светом.
От алгоритма и камня на камне не осталось: я все переписал заново, убрав рекурсию, и много кой чего еще. Два служебных метода тоже были полностью переписаны. Я еще никогда так легко и уверенно не переписывал ничего. Тут до меня стало доходить, в чем сила TDD. Сам код не так уж и ценен. Гораздо ценнее усилия по проверке, что этот алгорити работает. И эти усилия аккумулируются в необходимом и достаточном колличестве в виде отдельных тестовых методов, и поэтому больше не будет никакого: "главное ничего здесь не трогать, слава богу - работает", потому что код, покрытый тестами, легко поставить с ног на голову и обратно, если понадобится, и быть уверенным, что ничего не сломается.

VxS_trdm

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

Здраааавствуйте!.. Когда это С и С++ стали языками низкого уровня? Я что опять в своей жизни что-то проспал?

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

VxS_,

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