C# и вывод generic-типов при создании объекта

C# умеет выводить типы при вызове generic-методов (например, Tuple.Create(5, 5)), однако при вызове конструктора типы нужно задавать явно (например, new Tuple<int, int>(5, 5))

Очевидный workaround, продемонстрированный выше, - использовать фабрику. Но это вынуждает захламлять API для обхода, по сути, недоработки компилятора.

Сегодня я решил разобраться, почему дела обстоят именно так: может быть, я зря негодую, и на текущую реализацию есть объективные причины. Оказалось, Eric Lippert (один из самых известных разработчиков C#; после Хейлсберга, конечно) уже отвечал на этот вопрос на stackoverflow. Вкратце, Эрик говорит, что нет никаких преград перед реализацией вывода типов для конструктора, более того, эта фича уже давно в ToDo-списке, но с очень низким приоритетом. Кроме того, он соглашается, что отсутствие вывода для конструкторов на фоне его наличия для методов порождает inconsistency, но при этом говорит, что цена порой оказывается важнее фичи.

Готов поспорить, что у команды C# самый высокий бюджет среди всех команд-разработчиков компиляторов. На фоне этого говорить о цене этой маленькой фичи как-то странно. Хотя тут вспоминается старый пост Эрика на тему того, что значит "реализовать фичу" согласно стандартам Microsoft. И все равно я разочарован.

Кроссфункциональная команда

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

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

В общем смысле под кроссфункциональной командой подразумевается объединение (объединение и только) в одной команде людей разных специализаций - в противовес гомогенным командам, объединяющим людей одной специальности (отдельно программисты, отдельно тестеры и т. д.)

Agile-методологии пропагандируют создание кроссфункциональных команд. И это, на мой взгляд, прекрасно (хотя и не дается даром). Однако интересно, что в agile к кроссфункциональности неназвязчиво примешивается взаимозаменямость. Здесь я позволю себе процитировать Хенрика *наше все* Книберга:

Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.

Выходит, в контексте agile кроссфункциональной должна быть не только команда в целом, но и каждый ее член (до определенной степени). Причем, как мне кажется, кроссфункциональность/взаимозаменямость членов команды вытекает не только из кроссфункциональности команды, но и из других принципов agile вроде team committment и общего codebase. Хотя, очевидно, есть некоторая грань (редкий тестер сможет выполнять работу пиарщика), которая индивидуальна для каждой команды и от которой зависит вердикт по исходному кейсу.

Интереса ради, я решил узнать мнение о рассматриваемом кейсе на programmers.stachexchange.com. Ожидаемо, мнения разделились: от

Yes, it is normal for developers to become testers if it is required to get the work done for an iteration

до

I don't think developers being testers fits the cross-functional definition. That seems more like a jack-of-all-trades type scenario where developers also test, take sales calls, go out and buy coffee to restock the office, etc, which may be typical in a startup. A cross-functional scenario seems more like a situation where, for instance, you might be a developer, and I might be in marketing, but we're working together as a team to build and market the product.

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

TransactionScope - заманчивый, но коварный

Разместил статью на Хабре: http://habrahabr.ru/blogs/net/115480/

Транзакции и многопоточный доступ к базе данных

Разместил статью на Хабре: http://habrahabr.ru/blogs/net/115156/