Что я должен предложить для организации библиотеки многократно используемого кода? - PullRequest
4 голосов
/ 25 декабря 2008

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

Я разговаривал со своим менеджером перед рождественскими каникулами, и он упомянул это, хотя ему не нравится термин «вскрытие» (я понятия не имею, что не так с этим термином, какие-либо деловые люди или менеджеры там) знаете?), он действительно хотел провести совещание где-то в середине января, где вся контрактная группа проверит год и попытается выяснить, что пошло правильно, что пошло не так, и какие инициативы мы можем предпринять, чтобы попытаться улучшить прибыльность.

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

Что я должен предложить в качестве работоспособного репозитория с общим исходным кодом для команды, состоящей как минимум из 10-12 разработчиков на полную ставку, плюс где-то от 5-50 (очень) разработчиков с частичной занятостью, которые временно предоставлены контрактной группе для специализированной работы?

Для ответа потребовалась некоторая культурная информация для любого шанса на разумный ответ, поэтому я приведу ее здесь вместе с некоторыми своими мыслями по теме:

  1. Разработчики не будут вынуждены использовать этот репозиторий. Барьер для вход должен быть как можно ниже, чтобы поощрять участие, или это будет быть проигнорированным. К сожалению, это означает что-нибудь, что требует дополнительный программный клиент будет установить и запустить, скорее всего, не удастся. Развертывание ClickOnce примерно как близко, как мы можем получить, и это ужасно сомнительно.
  2. Мы не склонны к риску, магазин Microsoft. Возможно, я смогу продавать решения с открытым исходным кодом, но на них будут смотреть с подозрением. Все разработчики имеют VSS, корпоративный директор заявил, что VSTS не жизнеспособен в будущем. Если установка не слишком сложна, а лицензия либеральна, я все же могу попытаться подключить VSTS-сервер в лабораторию.
  3. Некоторые мои коллеги-разработчики заботятся о написании качественного, надежного программного обеспечения, некоторые нет. Я бы хотел защитить любой общий код, написанный теми, кто заботится о тех, кто этого не делает. Обычные практики управления конфигурациями (например, проверка кода во время его работы) полностью игнорируются, по крайней мере, пятой частью моих коллег по контрактной команде.
  4. Мы лучше пишем процессы, чем следуем им. Мне в значительной степени потребуется письменный процесс, чтобы продать его моему менеджеру. Я считаю, что он должен быть легким, гибким и обеспечиваться инструментами, чтобы иметь дистанционное отношение, потому что мой менеджер - единственный человек, который когда-либо его читает.
  5. Не принимайте передовой опыт. Я бы очень хотел включить такие вещи, как обязательные проверки кода, чтобы обеспечить использование инструментов статического анализа (FxCop, StyleCop) в общем коде. Однако это поднимает планку, поскольку в настоящее время такие практики не выполняются согласованным образом.

Я буду рад предоставить любую дополнительную запрашиваемую информацию. :)

РЕДАКТИРОВАТЬ: (отвечает на вопросы)

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

Ответы [ 6 ]

4 голосов
/ 26 декабря 2008

По звукам у вас есть возможность во время «вскрытия» представить некоторые решения. Я хотел бы создать презентацию с изложением ваших идей и представить их на этой встрече. Перед этим я бы порекомендовал вам установить некоторые решения и продемонстрировать их во время презентации. Некоторые вещи сделать -

  1. Евангелизируйте программирование на основе компонентов (хорошее чтение - Программирование .NET Components - Jubal Lowy ). Пропагандировать принцип кодирования СУХОЙ (не повторяйся)

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

  3. Облегчите людям использование ваших библиотек кода, предоставляя шаблоны проектов для общих сценариев с уже встроенными библиотеками кода. Таким образом, ваши коллеги получат согласованный шаблон для работы. Вы можете использовать для этого возможности шаблонов проектов VS.NET - перейдите по следующим ссылкам Система проектов VSX (VS.Net 2008) , Код Проектная статья о создании шаблонов проектов

  4. Используйте инструмент автоматизации сборки, такой как MSBuild (который входит в комплект VS2005 и выше), чтобы скопировать только компоненты, необходимые для конкретного проекта. Сделайте эту часть вашей сборки в IDE (в VS.NET 2005 и более поздних версиях есть отличные способы настройки задач перед компиляцией и посткомпиляцией с использованием MSBuild)

  5. Я знаю, что есть сопротивление для решений с открытым исходным кодом, но я все равно рекомендую установить и использовать систему непрерывной автоматизации, такую ​​как CruiseControl.NET , чтобы вы могли использовать ее для компиляции и тестирования своих проектов. на регулярной основе из центрального репозитория, где поддерживается многократно используемая библиотека кода. Таким образом, любые изменения в библиотеке кода можно быстро проверить, чтобы убедиться, что она ничего не нарушает. Это также помогает выявить проблемы с версиями в различных проектах.

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

Надеюсь, это поможет вам и удачи в вашей евангелизации :-)

Я наткнулся на этот набор фреймворков, недавно названный Chuck Norris Frameworks - они доступны на NuGet по http://nuget.org/packages/chucknorris. Вы обязательно должны проверить их, так как у них есть несколько хороших шаблонов для ваших проектов ASP.NET. Также обязательно оформить заказ Nuget .

1 голос
/ 25 декабря 2008

организовывать по темам, требовать юнит-тестов (на уровне возможностей) для регистрации / принятия в библиотеку; добавить вики, чтобы объяснить что / почему и для поиска

0 голосов
/ 25 декабря 2008

Прежде всего для организации кода ознакомьтесь с Руководством по проектированию Microsoft Framework по номеру http://msdn.microsoft.com/en-us/library/ms229042.aspx, а затем создайте центральный элемент управления исходным кодом Location для новой платформы, которую вы собираетесь создать. Настройте некоторые пространства имен по умолчанию, сборки для более чистого разделения и убедитесь, что каждый получает ежедневную сборку.

0 голосов
/ 25 декабря 2008

Просто дополнительный пункт, так как у нас в магазине есть «общий код».

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

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

Процесс сборки может очень хорошо управляться Maven или любым другим (ant / nant) инструментом, который вам нужен.

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

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


Таким образом:

  1. Разработчики не будут вынуждены использовать этот репозиторий. Барьер для входа должен быть настолько низким, насколько это возможно, чтобы поощрять участие, или он будет игнорироваться : это просто скрипт, который нужно выполнить, чтобы получить «модуль доставки» со всем, что ему нужно (можно использовать репозиторий maven). за это тоже)

  2. Мы не склонны к риску, магазин Microsoft : вы можете использовать любой репозиторий по вашему желанию

  3. Некоторые мои коллеги-разработчики заботятся о написании качественного, надежного программного обеспечения, некоторые - нет : это никак не связано с качеством кода, написанного в этих модулях пакетов

  4. Мы лучше пишем процессы, чем следуем им : единственный процесс, связанный с этим, - это процесс упаковки, и он может быть довольно автоматизирован

  5. Не принимайте лучшие практики : вы не обязаны применять какой-либо статический анализ кода перед упаковкой исполняемых и исходных файлов.

0 голосов
/ 25 декабря 2008

Maven решил повторно использовать код в сообществе Java - вы должны проверить его.

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

Maven действительно мог бы использоваться для непосредственного управления сборками .NET (мы используем его с нашими модулями кода Flex .swf и .swc), просто .NET пришлось бы покончить с использованием инструмента Java и, вероятно, написать Плагин Maven для диска msbuild.

0 голосов
/ 25 декабря 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...