Про що поміркувати коли розпочинаєш новий проект

Невеличкий список з пунктів, які потрібно обміркувати на самому старті проекту у той час коли створюється перший код.

Зберігайте усі бінарні залежності поряд з кодом. Зберігайте їх в вашій системі контролю версій.

Іноді цьому опираються, але якщо нема технічних проблем ( Visual Source Safe дохне при великих розмірах), то ви отримаєте декілька переваг:

- Спрощується налаштування робочого місця, адже вам не потрібно налаштовувати референси. Якщо все правильно налаштовано, то для того щоб почати роботу потрібно просто відкрити проект з системи контролю версій.

- Спрощується розробка скриптів та підтримка білд серверів, якщо всі залежності зберігати в одному місці, то додавання нової залежності, автоматично, відпрацює і на білд сервері.

- Спрощується підтримка версій. Наприклад версія 1.0 використовує EnterpriseLibrary 3.0, а 1.3 вже 3.1. Зрозуміло що якщо вам знадобиться версія 1.0, то разом з нею ви отримаєте правильні залежності.

Зберігайте бінарні релізи

Попередня частина розповідала як допомогти в ситуації коли потрібен білд попередньої версії. Але вона не може допомогти якщо вам потрібно відновити білд літера в літеру. Інакше кажучи, вам потрібна та версія, яку ви надіслали клієнту. Тут і відтворення проблем в тестовому оточенні, і порівняння швидкостей, і багато ще чого.

Зберігайте бінарні релізи разом з PDB файлами

Завжди виникають ситуації що потрібно зрозуміти чому не працює щось пару релізів потому. Дуже часто я бачу що версію просто позначають в системі контролю версій і все! А тепер уявимо що нам потрібно під’єднатися до вже працюючого додатку. Ми забираємо код з лейби(чи бранча), збираємо проект, викладаємо PDB файли, і.. облом. PDB файли з одного і того самого коду, але з різних білдів не будуть працювати (технічно там зберігається GUID білда, і теоретично його можна підмінити). От тут і допомагає репозітарій PDB файлів. Також можу рекомендувати зберігати PDB файли разом з бінарними релізами.

Не робіть папку з файлом рішення (.sln) коренем для коду (версія для сателітних файлів)

Ще не бачив проекту де був тільки код. З плином проекту додаються папки на кшталт Documents, Test Data, тощо. Завжди краще одразу зробити додаткову ланку в ієрархії папок, так щоб була можливість розширюватися горизонтально.

Не робіть папку з файлом рішення (.sln) коренем для коду (версія для підтримки гілок коду)

Навіть коли ми бачимо що проект буде плинути від версії до версії, реальність виявляється дещо іншою. У нас з’являються все більше гілок для версій, патчей, тощо. Інакше кажучи, краще одразу розташувати так щоб потім не було болячи.

Якщо нема додаткових потреб я використовую схему з головною гілкою розташованою на різних рівнях з додатковими.

- Root

--- Development (це головна гілка, тут проходить головна розробка)

--- Branches (це папка з додатковими гілками, тут проходить розробка ізольованих фітч, якихось версій)

------ Гілка для якогось фітчера

------ Гілка для іншого фітчера

------ Гілка попередньої версії

--- Releases (тут розташовані код тільки для читання, для попередніх версій)

------ Реліз 1.0.0.0

------ Реліз 1.2.0.0

Зрозуміло що є багато інших версій розташування, дещо описано в  http://www.codeplex.com/TFSGuide. Головне міркувати про це, бо в деяких системах щось змінити потім буде важко.

Не використовуйте Web проектів налаштованих на IIS.

Пам’ятайте що в майбутньому так чи інакше з’являться бранчі коду. Відновлення налаштувань IIS кожен раз коли потрібно щось зробити в іншому бранчі, може дуже швидко набриднути… Набагато легше підтримувати проекти налаштовані на вбудований в студію веб-сервер, адже не так вже і багато ситуацій коди дійсно потрібен IIS, і в таких ситуаціях зажди можна переналаштувати на IIS для окремого розробника.

Не робіть проектів які залежать від рядків під’єднання до  БД

Приклад це web.config з рядком під’єднання. Нажаль тут нема легкого рішення. Моя порада це скористатися файловими БД. Наприклад SQL Express. Для продакшена достатньо буде змінити рядок під’єднання. Нажаль є проблема, файл БД буде тільки на читання якщо не отримати Check Out.

Ще можна скористатися Visual Studio Team System 2008 Database Edition. Вона дозволяє швидко робити копію БД на кожній тачці, але з ним також є декілька проблем, якщо зацікавить зможу розповісти.

Одразу налаштуйте аналізатор коду

Іноді кажуть “Ось запустив FxCop, отримав півтори тисячі помилок”. Взагалі то це вирішується легким правилом. Написав дещицю, перевірив, виправив 10 помилок. Написав ще, і так по колу. Зрозуміло що під FxCop, може буде будь який аналізатор.

Поки що це все що спало на думку. Можливо що пізніше я щось додам.