Approved Final Committee Draft for C++

Approved Final Committee Draft (FCD) for C++0x - Ура, товарищи!!! 
Теперь ожидаются только багфиксы и редакторские правки (займёт около года). Так что у нас будет стандарт C++0xB.

P.S.
А CodeBubbles показывают как будет выглядеть IDE в будущем. 

Working Effectively with Legacy Code - впечатления от книги

Наконец-то прочитал Working Effectively with Legacy Code - дождался таки её выхода на русском и прочитал. Общее впечатление от книги - "must read" для тех, кто работает с maintanence.

"Красной нитю через всё произведение проходит" идея о необходимости покрытия кода юнит-тестами. С этой идеей я целиком и полностью согласен, т.к. не так давно приняли LC систему, у которой нет каких-либо тестов (только ручные по сценариям) и с знанием только по общей логике работы программы у предыдущего разработчика - проблема классическая для LC системы - время проверки правильности изменений может занимать до 3-х рабочих дней просто из-за того, что все проверки проходятся вручную.

Что ещё приятно в этой книге, так это то, что автор не навязывает какой-то подход (чем часто грешат метологи аджайла - "юнит тесты ВСЕГДА перед кодом" - блин, это же гибкие методологии разработки! ну как так можно?), он просто показывает как эффективно работать с унаследованным кодом.

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

1. описываются способы внесения изменений, которые позволяют снизить риск внесения ошибки практически до 0, в случае если нельзя прикрепить тесты к системе из-за каких-то ограничений (архитектурных, например).
2. какие тесты лучше иметь перед внесением своих изменений и как их лучше подсунуть в систему
3. какие изменения понадобятся в архитектуре системы для добавления тестов в такой-то области и к чему они приведут
4. плюсы и минусы различных способов реализации заглушечных функций и объектов для тестов.

Ну а то, что Майкл Физерс является автором CppUnit, является приятной фенечкой этой книги ;)

Слабым минусом этой книги является её перевод. Хотя разница по времени между выпуском английского оригинала и русским переводом составила почти 5 лет, качество перевода не блестящее - иногда (но не часто) приходилось делать обратный перевод на английский, чтобы понять мысль автора (использовались немного не очевидные термины), раза два или три лезть в английский оригинал за замыслом автора, и несколько раз были переведены имена переменных в тексте. Но в целом перевод хороший - по крайней мере таких ляпов как в переводе программиста-прагматика, я не нашёл.

Я бы посоветовал её читать тем кто работает с унаследованными системами где-то через полгода после прочтения Рефакторинга Фаулера и Паттернов Банды Четырёх, по следующим причинам:

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

Я читал её значительно позже чем советую - об этом сейчас сожалею. Прочитал бы вовремя - сэкономили бы командой кучу времени/нервов на изобретение велосипедов и избежали бы части просчётов в разработке.

Очень бы советовал прочитать "Refactoring to Patterns" by Joshua kirievski на том же этапе, что и Working Effectively with Legacy Code - они прекрасно дополняют друг друга и освещают работу с уже работающими системами с разных точек : Working Effectively with Legacy Code - это больше тактика внесения изменений(изменения в коде), а "Refactoring to Patterns" - это больше стратегия низкого уровня внесения изменений в системы (изменения в дизайне на уровне классов).

ЗЫ
а стратегия высокого уровня внесения изменений в системы - это уже просто перепроектирование системы :p