Что я должен предложить для организации многократной библиотеки кодов?

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

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

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

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

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

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

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

EDIT: (Ответы на вопросы)

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

6 ответов

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

  • Программирование на основе компонентов на основе Evangelize (хорошее чтение Программирование компонентов .NET - Jubal Lowy). Проповедуйте принцип кодирования DRY (Do not Repeat Yourself).

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

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

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

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

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

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

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


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


Еще один момент, так как у нас есть "общий код" в моем магазине.

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

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

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

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

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

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

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

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

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

  • Нам лучше писать процессы, чем следовать им: единственным процессом, связанным с этим, является процесс упаковки, и он может быть довольно автоматизирован

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


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


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

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

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


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

licensed under cc by-sa 3.0 with attribution.