Давно, очень давно собирался написать что-то на эту тему, но всё никак не формировалось. Не формируется и сейчас, поэтому просто мысли.

Я уже давно пришёл к выводу, что многие люди неправильно понимают, что такое “просто”. Это касается не только программирования, а часто и вообще любых жизненных ситуаций, но я всё же немного с этим уклоном…

Очень часто, к сожалению, люди путают “просто” и “сложно”. То есть, когда они что-то делают “просто”, то получается в результате “сложно”.
Почему так получается? Да просто потому, что это самое “просто” изначально определено неверно в их головах.

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

Правильное понятие о простоте, я думаю, должно складываться именно из результата.
Вот я прихожу, смотрю на код – а его так просто поддерживать и изменять, что ну никаких проблем с этим не возникает. Всё разложено по полочкам, разобрано по смыслам, не допускает двойных толкований. Легко читать, легко понять, что имеется в виду.
Вот это – просто. Я и коллеге скажу: “да там всё просто написано, сразу всё понятно”.
И это вовсе не означает, что человек, который писал этот код, не прилагал усилий. Это в 99% случаев означает совершенно обратное, кстати.

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

И, мне кажется, если мы будем смотреть на слово “просто” с точки зрения не процесса, а результата, то многое станет дейтвительно проще и осмысленнее.

Поэтому.. Пожалуйста, когда в следующий кто-то предложит, или сами решите сделать что-то просто, вы уж не поленитесь

Читая Мишины отзывы и ссылки, думал тут про тестеров.
Там кто-то говорит про "плохих" и "хороших" программистов и тестеров, кто-то объясняет, что программисты делают "тяп-ляп" потому, что "типа тестер всё равно проверит", а тестеры типа относятся к программерам как к "багоделам".

Это показалось мне странным, я думал-думал и пришёл к такому вот выводу: что-то тут не так :)

Потому, что лично я, как программист, пишу код не для тестеров. И не с расчётом на тестирование. И для меня никаким критерием не является то, нашли тестеры баг, или не нашли, и если нашли, то сколько. Я об этом не думаю, когда пишу код. Я не думаю о тестировании, когда пишу код. Я не думаю о тестерах, понимаете?
Да, имеет значение, есть баги в коде или нет. Но я не думаю о тестерах как о некой страховке! Предполагая, что в коде может быть баг, я подсознательно предполагаю (и прямо вижу, так сказать), как этот баг находит кастомер, не тестер.
Я делаю задачу, и для меня, когда я сдаю эту задачу, эта задача закончена. То есть, с моей точки зрения задача выполнена полностью. Я сделал, я написал юнит-тесты на всё, что хотел и что имело смысл проверить, я проверил, как оно работает...
Такой мысли, что "если чё - тестеры найдут" просто не возникает.

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

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

Когда программист начинает думать про тестеров как о страховке, когда он начинает думать "сейчас я зачекиню, они проверят, и, если чё - я пофиксю", то он начинает думать о незаконченной задаче как о законченной, то появляется сама возможность, там, в голове, сдать полузаконченную задачу.
Когда программист думает о тестерах как о неком фильтре, который за него разберётся что он сделал “так”, а что “не так” и выдаст назад результат в виде “вот тут ещё доделай и вот тут подкрути”, начинается такая фигня, и потом эта фигня вырастает в “ну чё он придирается”.

Тестер для программиста никогда не должен быть некой сущностью, которая проверяет домашнее задание непоседливого школьника, указывая на недостатки и недоработки. А школьник этот вертится на стуле и стремится поскорее “ответреться”. А если тут ещё ПиЭм неправильный, который типа контроллирует и типа требует результата – то и вообще атас (это я всё о том же).

Так кто же такие тестеры получаются?
Тестеры “располагаются” уровнем выше, так сказать. Они располагаются на уровне продукта. Они не являются фильтром ляпов программиста, они отвечают за конечное качество продукта. За то, чтобы фичи, которые идут в релиз, работали так, как им допустимо работать. Поэтому, насколько я вижу тестеров, у них точно так же нет мыслей о том, что кто-то там наделал багов. Они просто не размышляют в категориях конкретных программистов, они мыслят на уровне “эту фичу я пропускаю к релизу, а вот эта не вполне соответствует спецификации + для релиза необходимо иметь вон ту штуку готовой”.

Такой подход + отсутствие персонального владения кодом (я не помню, писал про таковое, или посчитал очевидным, но это – Изначальное Зло, если оно есть в команде – срочно искоренять, а тех, кто это устроил – линчевать) ведут к естественному и правильному взаимодействию тестеров и программистов, которое выражается… в отсутствие персонального взаимодействия

То есть, я не имею в виду, что тестеры с программистами не общаются, вовсе нет. Общаются, и ещё как! Но это общение вида: я делаю фичу, или чиню баг, у меня есть вопрос, я пошёл к тестеру и попросил объяснить, как это должно работать, или как это воспроизвести, или что-то ещё.
Но это не взаимодействие типа “я напишу, а я проверь там” и “я проверил, ты там доделай”.

Поэтому есть команда программистов и команда тестеров. Которые просто выполняют разные задачи, на разных уровнях, а вовсе не “фехтуют” друг с другом.
И описанных проблем не возникает.

Интересный и даже полезный инструмент для неудомимых TFS-миграторов: http://tfsintegration.codeplex.com/
Целая "платформа", позволяющая перекачивать и даже синхронизировать по-разному и Source Code и Workitems между TFS-серверами Поддерживаются 2008 и 2010, причём можно и 2008-2010 делать.
На сегодняшний день это единственный способ перенести проект из одной Collection в другую, который я знаю.
Или вообще добавить существующий проект в существующую коллекцию.

Завтра работаю, финальная миграция с TFS 2008 в одном домене на TFS 2010 в другом домене. В последнем случае у меня будет ещё 4 физических сервера для build agents, думаю, что build controller будет жить на одном из них, чтобы не грузить саму TFS-машину.

На сегодняшний день (не мною) было отсмотрено и оттестировано достаточное количество process templates, включая MS SCRUM v1.0, MS Agile, MS CMMI/MFC, ScrumForTeamSystem v3.0

"Победил" последний - ScrumForTeamSystem v3.0, который, хотя поначалу и кажется "перенавороченым", но вот потыкавшись там, понимаешь – ба, тут того нет, тут – этого… Причём вещи-то полезные.

Словом, Царина (человек, которому с этим всем работать) смотрит видео с PDC (мы с ней, кстати, были на той сессии ) и прочих конференций, посвящённых SCRUM, а я завтра “нажму кнопку”.

Надеюсь успеть быстро.

Карма в действии. В Акателе я TFS мигрировал два раза, тут тоже…