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

Idsa, GoF, PoEAA - по паттернам

PashaPash, по паттернам мое внимание привлекла вот эта книжка. Правда, не знаю, как ее позиционировать: как замену или как дополнение классики жанра.

по паттернам - только Банда четырех. Самое доступное издание - 2001 года. Есть и в 2003 и в 2005, и в 2008, но я на них смотрел. Крове пары орфографический ошибок больше там ничего не изменилось.
 НУ и на винграде есть источник 
http://forum.vingrad.ru/faq/topic-41784.html#st_0_view_0

Idsa, позиционировать как yet another вольный пересказ GoF. читай оригинальную GoF, потом Фаулера - PoEAA, потом можно еще Нильсона пролистать - Applying Domain-Driven Design and Patterns With Examples in C# and .Net.

А GoF (в оригинале) переиздавался? То издание, которое нашел на Амазоне, 94-го года.

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

Окей, по паттернам ToRead-list сформирован:
1. GoV
2. PoEAA
3. Applying Domain-Driven Design and Patterns With Examples in C# and .Net
4. C# 3.0 Design Patterns

PashaPash, если не секрет, сам какие из этих трудов изучил? 

Кстати, помнится, на Винграде проскакивала ссылка с реализацией паттернов под C# с подробными комментариями (причем распространяется это чудо мысли платно)...

Перейдем ко второй части вопроса, к юнит-тестированию 

Idsa, читал 1, Александреску, 2, пролистал 3. 

А что за книга?

Idsa, http://www.rsdn.ru/res/book/cpp/alex.xml. 

Idsa, видимо речь о, пожалуй, самой известной его книге Modern C++ Design...

PashaPash, +1.

Подозрительная тишина по поводу второй части вопроса 

Idsa, по второй части - выучить паттерн IoC/DI (http://martinfowler.com/articles/injection.html) , понять разницу между Unit-тестированием и TDD. Может быть еще прочитать "Экстремальное программирование. Разработка через тестирование" Бека - http://www.rsdn.ru/res/book/prog/beck.xml. 

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

Это сообщение отредактировал(а) Bogdan1024 - 24.6.2009, 15:37

Bogdan1024, на английском она вполне на уровне - там предисловие от Фаулера, ему понравилось.
http://www.informit.com/content/images/032...n_Forewords.pdf
Кстати, вот глава про POCO и репозитории:
http://www.informit.com/content/images/032...ilsson_ch06.pdf

А русские переводы почти всегда ужасны - посмотри что они с CLR via C# сделали. "Особое внимание уделено обобщениям".

Кому-нибудь удавалось найти PoEAA в PDF, а не в chm?

Забыл добавить. Я ищу PoEAA в оригинале.

Вопрос снимается.
Спасибо Partizan'у 

Решил сразу собрать подборку книг. Не нашел в pdf:
1. Test-driven development: by example (Kent Beck)
2. Applying Domain-Driven Design and Patterns With Examples in C# and .Net (Jimmy Nilsson)
Буду благодарен за помощь в этом направлении.

Это сообщение отредактировал(а) Idsa - 6.7.2009, 12:11

Idsa, меня, когда-то, очень сильно впечатлила моя первая книга по TDD: "Test-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov". Рекомендую. 

С паттернами намного сложнее, тут нужно много практики, одной теории мало. Лучше бы найти знающего человека и его немножко помучить (пол годика  )

Спасибо  Буду иметь ее в виду.


Уж кого помучить я найду 

Вопрос снят 


Почитал я отзывы об этой книге на Амазоне... много недовольных (особенно на второй странице комментов). Я призадумался 

Добавлено через 1 минуту и 16 секунд
Вот, кстати, конкурент для книги "Test-Driven Development in Microsoft .NET": http://www.amazon.com/Pragmatic-Unit-Testi...pd_bxgy_b_img_b

Прочитал. Все как я и ожидал: книга -- хороший старт, но некоторые моменты не освящены... "Если вы хотите реально узнать о TDD читайте Бекка"

Idsa, эта книга -- отличный старт. Она очень легко читается. Я ее прочитал за 4 часа (пока летел в самолете и в аэропорту ждал). Все очень доступно. Что же еще нужно для старта?
Бекка не читал, но уверен, что там будет много теории... осилить которую будет не просто. Здесь же чистая практика.


Книгу не читал, но судя по серии (Pragmatic Programmers // две книги у меня сейчас лежат на столе: прочитаны/перепрочитаны) она будет стоящаяя... Но, скорее всего, это будет фундаментальный труд структурированный небольшими разделами. ИМХО, must read, но после хорошей вводной книги например "Test-Driven Development in Microsoft .NET"

Добавлено через 4 минуты и 19 секунд
Да, после знакомства с TDD рекомендую "Рефакторинг" Фаулера. 

ivashkanet, тогда, пожалуй, буду читать в следующем порядке:
1. Test-driven development: by example
2. Test-Driven Development in Microsoft .NET
3. Pragmatic Unit Testing in C# with NUnit

Idsa, и еще раз: я бы не советовал начинать с Бекка.

Скачл книгу, просмотрел.
Первая глава -- подробный (даже слишком) пример как же работать по ТДД (минус:  java + старая версия jUnit с не очень удачным синтакцисом)
Вторая -- как сделать свой собственный фреймворк для тестирования??? + Питон (оно тебе надо?)
Третья -- паттерны TDD (наверное неплохо, только зачем тебе это с самого начала?)

ivashkanet, уговорил  Меняю первый и второй пункты местами:
1. Test-Driven Development in Microsoft .NET
2. Test-driven development: by example
3. Pragmatic Unit Testing in C# with NUnit 

Это сообщение отредактировал(а) Idsa - 9.7.2009, 13:32

Idsa, продолжаю уговаривать...
Выкинь Бекка нафик   Чел безусловно грамотный, один из основателей TDD, за что ему огромное спасибо, но читать мы будем других  


Берем "Test-Driven Development in Microsoft .NET" для того чтобы понять "а что это?"
Для более глубокого изучения берем XUnit Test Patterns -- фундаментальный труд писанный всем инетом, очень неплохо
Дальше берем Физерса Working Effectively with Legacy Code -- супер книга, о том как сделать нетестируемый код тестируемым

PashaPash будет ругаться 


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

Не буду, я вообще Бека не читал (только тссс!), и не фанат TDD. Мне как-то обычные Unit-тесты больше по душе.

Физерса я сам лично читал на английском, в восторге! Купил бумагу (на русском) -- теперь настольная книга.
XUnit Test Patterns -- прочитал около сотни страниц, катострофически закончилось время, книга безусловно стоящая, плохо что большая   


Не за что.

Добавлено через 26 секунд

  

Вы не смешивайте TDD и UnitTests - это принципиально разные вещи, только инструменты одинаковые.

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

Добавлено через 5 минут и 17 секунд

Нет, не так: познакомившись с TDD... знаком с юнит тестированием  

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

Юнит-тестирование (Test-before-development) - это когда перед написанием какого-то конкретного куска пишется тест для него.

Разница в результате - При TDD получаются автоматические regression-тесты для приложения. При Unit-тестировании получаются отдельные тесты для каждого юнита, и для каждого уровня - свой набор тестов для UI, набор для BL, набор для DA.

Юнит-тестирование - однозначно гуд. TDD, лично для меня - пока под вопросом - для девелоперов слишком большой соблазн остановится на "как угодно" и не рефакторить 

Это я как бы к тому, что знакомство с TDD не дает навыка написания unit-тестов.

Это сообщение отредактировал(а) PashaPash - 9.7.2009, 19:19

PashaPash, не хочу холиварить но ты ошибаешься. 
Юнит тестирования -- это когда пишутся тесты для юнита (в изоляции от других частей). Все! Юнит тест написанный задним числом не перестает быть юнит тестом.


Первый раз о такой практике слышу   
Т.е. TTD -- пишем интеграционные тесты на все юзкейсы, а потом заставляем их пройти? Жесть. Паш, ты извини, но, ИМХО, ты не совсем в курсе что такое TDD:
 
Но это русский вариант, у нас, обычно, в вики пишут что в голову взбредет (сама фраза "модульные тесты для программы или её фрагмента" это нечто   ).

В английской википедии в определении нигде нет "Юнит Теста", есть только "тест перед кодом":

И я с этим согласен, тест перед кодом -- ключевой аспект TDD. В определение ничего дополнительно добавлять не нужно. Даже Red-Green-Refactor -- ключевую фичу TDD не обязательно затрагивать. Но если посмотреть на примеры Бекка (или другой книги по TDD) окажется, что эти тесты -- юнит тесты. Так как в TDD требуют двигаться маленькими шажками: один цикл (R-G-R) занимет, в теории, не более 5 мин.  В случае интеграционных тестов это невозможно.
Когда говорят о TDD в 90% случаях имеют ввиду именно Юнит тесты. Да и вообще, очень тяжело не программисту написать тесты ДО кода. А тесты программиста -- именно юнит тесты (интеграционными и проч, занимаются QA).
Лично я TDD-чу именно юнит тестами.


Возможно ты говоришь про ATDD (если честно, первый раз такое услышал):

Оказывается тоже есть такая практика, но она не столь широко распространена. Я услышал о ней впервые, хотя в "Test-Driven Development in Microsoft .NET" рассказывается про FIT приемочное тестирование (тогда я не придал значение тому почему FIT рассматривается в книге по TDD).

СУВ, ivashkanet

Ес-но тесты пишутся по одному, и т.д  Я хотел показать что TDD-тесты не тестируют отдельные юниты (классы, методы), а проверяют тесткейсы. Один тесткейс вполне может покрывать 20-30% кода приложения - слишком много для "теста одного юнита". 


Зато в английской википедии есть определение Unit testing, где про "перед кодом" в определении ничего не сказано. Зато там есть "tests that individual units of source code" и "A unit is the smallest testable part of an application."


Немного не согласен с этим утверждением - и с выводами из него. TDD - это процесс разработки. Из 6 пунктов. Если ты оставишь "основной аспект" и выбросишь остальные - то получишь обычный Tests Before Development. 

Есть неплохая статья на эту тему: http://stephenwalther.com/blog/archive/200...unit-tests.aspx, ну и та же рядом: http://stephenwalther.com/blog/archive/200...evelopment.aspx

З.Ы. Впрочем, whom how. IMHO - просто писать тесты до кода - намного лучше, чем вообще их не писать. И не обязательно хуже TDD.


Это сообщение отредактировал(а) PashaPash - 10.7.2009, 13:27

Не мог ты подкрепить свое мнение ссылками на источники?


Who is Stephen Walther??? Очередной толкователь создателей TDD? Они оказывается имели ввиду не то что написали, а вот это и вот это... А пацаны-то не знают 


Из 5-ти (если судить по книге Бекка). Что есть "обычный Tests Before Development". Что это вообще за термин? Кто его ввел? Кто о нем знает? Почему Гугл не знает?


Так вот, из "пяти пунктов TDD" убрать можно только Рефакторинг и стадия Red (запускаем тест до написания кода и убеждаемся что он валится). Все остальные (добавить тест, добавить код для прохода теста, запустить тесты) естественны для TBD (Test-before-development). 
Идем далее. Стадия Red естественна для TBD. Так как если только что написанный тест прходит, то этот тест ничего нового не тестит. Нафик он нужен.

Получается, что TDD отличается от TBD только стадией рефакторинга (ну и принципом "пишем минимальный код который проходит тест", но он опирается на стадию рефакторинга).


P.S. PashaPash, ты мне лучше скажи, неужели в TBD обязательно должны быть юнит тесты. С тем же успехом я могу сказать, что к TBD относятся и приемочные, и интеграционные тесты.


Не понял что ты этим доказываешь. Что такое Юнит тест я знаю. Он никак не завязан на TDD. Наоборот TDD завязан на на тесты (чаще всего на Юнит тесты). 
Это ты почему-то решил, что Юнит тест == TBD:

Дык, википедия же

А как же repeat? 

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


Потому что в моем определении есть слово "конкретного куска", он же модуль, он же юнит.

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

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

Я бы заменил на "чаще всего не unit-тесты". Что является юнитом в типичном TDD тесте для приложения? Пример - 3-layer web-приложение, пишем тест для тесткейса "при нажатии на кнопку create user, в базе (репозитирии) создается новый user, пользователя редиректит туда-то". Что здесь юнит? метод в UI-логике? Класс в BL?

Сам хотел предложить   Очень неблагодарное это дело... все равно каждый останется при своем   

P.S. 
В TDD главное, что "тесты уравляют разработкой".

Добавлено через 1 минуту и 27 секунд

ИМХО, лучше вынести. Пусть останется для потомков Ж))