Блог

TFS проблемы при коммите

Работая с TFS я уже несколько раз замечал, что он не любит, когда мерджат или коммитят файлы, при этом локальная копия файла далеко не свежая. Особенно это заметно при больших файлах. У меня на работе в репозитории есть один достаточно большой файл, и если изменить его локально и попытаться коммитить, а на сервере уже есть измененная версия, то TFS автоматически будет мерджить удаленную версию с локальной. Коммит остановится и TFS в таких случаях даёт шанс осмотреться и одуматься, но иногда народ не проверяет результат мерджа, а просто нажимает кнопку commit снова. 

Я несколько раз видел, как TFS во время автоматического мерджа вытворял совершенно непонятные и не объяснимые вещи. Но как только я перед коммитом начал забирать последние изменения, то проблемы исчезли. Забираем последнее, в этот момент так же происходит мердж, но почему-то он проходит отлично и я ни разу не видел мусора в результате. Авто мердж при нажатии коммита уже не раз выдавал мне мусор. 

Умение писать в блокноте - ретроград

Сейчас читаю журнал Хакер и наткнулся на комментарий компании Mirantis по поводу программистов, которые предпочитают писать в блокноте. 

Если кандидат на полном серьезе рассказывает, что ему «удобнее в блокноте», а IDE — это не для тру-программеров, это плохой симптом. Такой ретроград может стать обузой для развивающейся компании и потянет всю команду за собой назад. Часто люди не понимают, что им платят по часам работы, а использование дополнительных инструментов позволило бы существенно повысить их продуктивность и заодно снизить количество ошибок. В конечном итоге и человеку разгрузка, и компании плюс. 

Вот я не понял, каким образом программист, который будет писать код в блокноте, будет обузой и тянуть команду назад? Работая в Klick Health я писал код в notepad++ и у меня даже не стоял Visual Studio, но я писал быстрее и больше любого другого программиста в моей команде. Если не считать автокомплитера, то в VS больше ничего особого и нет, что позволяет писать код быстрее меня в блокноте. 

Visual Studio против Visual Studio Code

Сегодня установил себе на Mac полноценный Visual Studio от Microsoft, запустил, посмотрел, и в голове возник вопрос - и нафига теперь Visual Studio Code? 

Visual Studio Code может быть полезен только тем, кто любит простые редакторы для работы с кодом, а не полноценные  IDE. В принципе, меня можно отнести к таким людям, я пишу код и там и там одновременно под Windows, а под Маком пока ничего не делал такого. 

Я вообще пока установил Visual Studio на Мак больше ради интереса. В ближайшее время ничего такого не планирую на нем делать. Хотя все возможно. 

.NET Core проекты - не нужно явно добавлять файлы

Я не понимаю, зачем изначально в Visual Studio решили явно добавлять файлы в проект. Это делает файл csproj неоправданно большим и добавляет лишние конфликты при объединении разных веток кода (merge). 

Я люблю создавать файлы прямо в Total Commander, просто создаю .cs файл и сразу же пишу в нем код. Ах да, если кто пропустил, я часто пишу код в Notepad++. Я люблю и использую VS, но также часто пишу и в приплюснутом блокноте. 

Сейчас узнал, что в .NET Core больше не нужно будет добавлять файлы явно в проект. Я ни одного проекта под Web на Core не писал, все еще присматриваюсь к нему, но пока все нравится. VS сам должен подхватывать все изменения в файловой системе и добавлять файлы. Какая прелесть. 

Нагрузочное тестирование

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

Сегодня прочитал мнение, что нагрузочное тестирование нужно гнать на CI сервере. Если честно, то мне сложно это представить. CI сервер должен взять изменения, откомпилировать и запустить тесты. На больших проектах тесты могут выполняться достаточно долго, у меня они гнались два часа. Если после этого еще и гнать нагрузочное тестирование, то это отнимет слишком уж много времени. 

Ну не знаю, на мой взгляд юнит тесты на много важнее. Нагрузочное тестирование может занимать часы, ведь нужно подержать каждую страницу хотя бы минут 10 под нагрузкой. Две минуты могут ничего не дать, и вы не увидите результат. Такие ошибки, как не закрытое соединение с базой данных, не закрытое соединение с сервисом, отсутствующий индекс могут серьезно проявится только минут через 10 – 15 нагрузки, а могут даже через пол часа.

Все говорят пишите тесты, а ты пишешь тесты?

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

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

Использование автомаперов

Интересный спор у нас произошел на работе. Один из программистов начал проталкивать AutoMapper, это фигня, которая автоматически может копировать данные из одного объекта в другой, даже если их классы разные. Маппинг происходит автоматически, если имена полей совпадают, но можно и конфигурировать, если имена не совпадают. 

Преимущество использования автомаперов - не нужно писать код типа:

dst.Field1 = src.Field1

dst.Field2 = src.Field2

dst.Field3 = src.Field3

Тесты затормозили сайт

Я дома перешёл на Visual Studio 2015, хотя он немного более требователен к ресурсам. До этого я не использовал тесты MS, а тут вдруг решил перейти на них для своего последнего проекта. В общем создал проект для тестов, набросал кучу полезных вещей и заодно пока писал тесты нашёл несколько ошибок в своём коде. 

Вчера нужно было делать демо через gotomeeting, а у меня компьютер начал нереально тормозить, сайт не грузиться и даже sp_who2 в SQL Server не хочет выполнятся. Я перезапустил SQL Server и вроде бы помогло, сайт загрузил страницу. Но при попытке перейти куда-то дальше, все снова повисло. 

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

Почему должен быть только один Assert?

Недавно смотрел видео, в котором специалист из MS рассказывал про юнит тесты, кажется я его смотрел на Channel 9. Так там затронули тему того, что рекомендуется, чтобы у каждого теста был только один Assert. Один тест - одна проверка. 

В видео специалист MS сказал, что он не совсем согласен с требованием, ограничивать тесты только одной проверкой, и считает, что их должно быть немного, но необходимо достаточное количество. 

Лично я не против большого количества проверок Assert и не понимаю, зачем их ограничивать. Вот сейчас я пишу тесты для системы, которая будет давать какие-то перки за определенные действия - клиент называет это Promotion Engine. Там клиент конфигурирует различные промоушены, потом загружаются данные, и движок на основе данных проверяет, должен ли я дать призы тем, кто хорошо играет в игры или нет. 

Зоопарк технологий

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

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

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

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Обратная связь

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

Пишите мне