Лучшие инструменты, доступные для реализации Joel Test в .Net

Question

Мне нужна помощь в настройке среды разработки для проектов на основе .Net.

В настоящее время я работаю в организации с «единственным» разработчиком (мной). Мы разрабатываем и поддерживаем программное обеспечение на месте. В настоящее время мы используем Visual Studio и загрузку файлов вручную - каждое время для тестирования / производства (с внесением изменений в исходный код каждый раз!). Я читал о преимуществах «теста Джоэла» и был впечатлен его преимуществами - при правильном выполнении.

Мой вопрос

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

2) Для каждого из шагов - какие из лучших инструментов доступны? Например - Q.1: Вы используете контроль версий? - Я хочу знать, какой инструмент хорош / лучше всего подходит для реализации (1) в моем сценарии. и так далее для других очков.

Другая информация:

Я ищу решения, которые используются в промышленности в настоящее время, и я ищу как коммерческие, так и бесплатные решения - при условии, что они стабильны и имеют хорошую базу использования.

Текущая настройка такова

IIS-Production, SQL Server-Production

IIS-test SQL Server-Test

developer machine - with Visual Studio Installed

Любая помощь очень ценится - я ищу стандартное и хорошее решение, чтобы будущим разработчикам было легко работать там. Спасибо !!

Answer 1

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

Для единоличного разработчика я бы порекомендовал следующее.

1. Система управления источником обязательна.В противном случае вы бы быстро оказались в беспорядке, вроде «Я думаю, эта ошибка была введена две недели назад, когда я добавил туда функцию ...».
   Subversion - хороший выбор для начала.Git и Perforce также являются хорошими кандидатами (последний стоит денег, хотя они предлагают бесплатную лицензию для 2 пользователей).Я не рекомендовал бы инструменты Microsoft здесь.

2. База данных задач (ошибок / функций) также необходима, потому что вы хотите знать, куда вы идете, и отслеживать прогресс.Если задействованы только один или два человека, полноценная система отслеживания проблем не требуется.Хорошо иметь его, но для большинства практических целей можно использовать таблицу Excel.
   Вы можете попробовать Jira (прямо сейчас, они предлагают бесплатные лицензии для организаций с <10 ​​разработчиками) или Trac. </p>

3. Написание спецификации перед кодированием.Это может быть не очевидно, но спецификации полезны.Это заставляет вас продумывать многие детали вашей будущей реализации задолго до того, как вы действительно ее внедрите, и, таким образом, избавляет вас от необходимости тратить много времени на неправильное направление.Кроме того, хорошая спецификация будет полезна для вашего клиента, вашего преемника в проекте и т. Д.

4. Согласованная процедура развертывания.Не загружайте код из вашей конфигурации разработки в производство.Очень легко забыть о каких-то важных изменениях, которые вы только что внесли, или о некотором отладочном коде, который вы добавили, или о некоторых незафиксированных файлах и так далее.Установите правило, что каждое изменение сначала переходит к управлению исходным кодом, затем оно перестраивается из исходного кода и проверяется, после чего оно развертывается в рабочей среде.
   Если ваш проект небольшой, использование сервера сборки может быть излишним, поэтомуподойдет простой пакетный файл, или скрипт Powershell, или скрипт Nant.В любом случае, убедитесь, что между процессом сборки вашей конфигурации dev и автоматической сборкой есть как можно меньше различий (чтобы избежать синдрома «он работает на моей машине»).
   Хорошими серверами сборки являются CruiseControl.Net(FOSS) и TeamCity (бесплатно для небольших проектов).

5. Автоматизированное тестирование.Ручное тестирование, если оно выполнено должным образом, обходится дорого с точки зрения потраченных человеко-часов.Ручное тестирование, выполняемое разработчиком и / или заказчиком, обычно не выполняется должным образом и поэтому не очень полезно.Автоматизированное тестирование тоже непросто, но в долгосрочной перспективе оно может избавить вас от головной боли.Модульное тестирование - это минимум, который вам необходим для небольшого проекта, системное тестирование сложнее, поэтому, вероятно, будет проведено несколько автоматических (или даже ручных) проверок работоспособности до и после развертывания.MSTest или NUnit - хорошие фреймворки для юнит-тестирования.

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

Лучшие инструменты, которые можно купить за деньги, дороги и(при условии, что вы не собираетесь использовать пиратское программное обеспечение) может быть недоступно для небольшой компании.Довольно часто вы можете получить почти то же самое бесплатно.
Если вы выбираете между различными версиями Visual Studio, обратите внимание на функциональность модульного тестирования - сам MSTest и поддержку покрытия кода.Другие различия, между прочим, практически незначительны (хотя вы можете использовать бесплатные NUnit и NCover).
Если вы можете себе это позволить, Resharper - очень выгодное вложение, imho.

Answer 2

Очевидно, что любой ответ на эти вопросы будет субъективным и будет отражать опыт, предвзятость и т. Д. Ответчика. С учетом сказанного, вот мой не очень короткий ответ:

1) Это не слишком много для реализации. Возможно, вам не нужно набирать 12, но вам определенно следует использовать контроль источника как минимум.

2) Лучшие инструменты доступны? Это все равно что спросить меня: "Какая машина лучше?" Эти вещи не только субъективны, но и лучшие инструменты различаются в зависимости от ситуации.

(1) Во всяком случае, мне нравится выступление в качестве системы управления источниками, и мне это очень нравится. Я также люблю Mercurial (HG) и GIT. Я на самом деле не использовал Team Server, но если вы все являетесь Microsoft, это тоже не плохой выбор. (Я сказал мог).

(2) Можете ли вы сделать сборку за один шаг? Вы должны быть в состоянии сделать сборку за один шаг. msbuild вместе с некоторыми питонами, летучими мышами, nant или чем-то, что должно помочь вам. Лучший инструмент - тот, который ты знаешь лучше всего. Мой выбор будет зависеть от того, насколько вы хотите этого. Мне нравится питон.

(3) Вы делаете ежедневные сборки? Делаете ли вы ежедневные заезды, действительно вопрос? Почему бы не построить каждую регистрацию? Насколько велика система, о которой мы говорим, и сколько времени занимает шаг (2)?

(4) У вас есть база данных ошибок? Я надеюсь, что вы отслеживаете ошибки не в блокноте. Мне нравится Джира, среди других.

(5) Исправляете ли вы ошибки перед написанием нового кода? Ты должен сделать это. Я делаю.

(6) У вас есть актуальное расписание? Это кажется логичным, чтобы иметь. Вы можете использовать Microsoft Schedule или любой из 100 других инструментов.

(7) У вас есть спецификация? Если вы строите что-то большее, чем несколько дней работы, вероятно, стоит записать, что вы строите в первую очередь. Эти вещи довольно очевидны, не так ли? Попробуйте Visio.

(8) Имеют ли программист (ы) тихие условия работы? Я предпочитаю музыку во время работы, но если требуется тишина, она должна быть доступна.

(9) Используете ли вы лучшие инструменты, которые можно купить за деньги? Я считаю, что многие из лучших инструментов бесплатны, но ymmv, и, очевидно, работа под рукой диктует лучший инструмент.

(10) У вас есть тестеры? Если вы этого не сделаете сейчас, я надеюсь, что вы.

(11) Пишут ли новые кандидаты код во время собеседования? Это похоже на хорошую практику.

(12) Проводите ли вы тестирование удобства использования в коридоре? Я полагаю, что это зависит от продукта, который вы делаете, но, вероятно, это не повредит.

Лишь немногим из этих тестов Джоэла действительно нужны инструменты, и, надеюсь, я дал вам мои предвзятые и субъективные ответы на этот вопрос.