Создание библиотеки активов кода

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

The common attributes of solutions I have seen work at mutiple corporations are a multi pronged approach.

1. Buy in at some level from the management. Usually it's a CTO/CIO that the idea resonates with and they claim it's a good thing and don't give any money to fund it but they won't sand in your way if they are aware that someone is going to champion the idea before they start soliciting code and consolidating it somewhere.
2. Some list of projects and the collateral available in english. Seen this on wikis, on sharepoint lists, in text files within a source repository. All of them share the common attribute of some sort of front end search server that allows full text over the description of a solution.
3. Some common share or repository for the binaries and / or code. Oftentimes a large org has different authentication/authorization methods for many different environments and it might not be practical (or possible logistically) to share a single soure repository - don't get hung up on that aspect - just try to get it to the point that there is a well known share/directory/repository that works for your org.
4. Always make sure there is someone listed as a contact - no one ever takes code and runs it in production without at lest talking to the previous owner of it - and if you don't have a person they can start asking questions of right away then they might just go ahead and hit file->new.

Неудачные атрибуты я видел?

1. N submissions per engineer per time period = lots of crap starts making it's way in
2. No method of rating / feedback. If there is no means to favorite/rate/give some indicator that allows the cream to rise to the top you don't go back to search it often because you weren't able to benefit from everyone else's slogging through the code that wasn't really very good.
3. Lack of feedback/email link that contacts the author with questions directly into their email.
4. lack of ability to categorize organically. Every time there is some super rigid hierarchy or category list that was predetermined everything ends up in "other". If you use tags or similar you can avoid it.
5. Requirement of some design document to accompany it that is of a rigid format the code isn't accepted - no one can ever agree on the "centralized" format of a design doc and no one ever submits when this is required.

Просто мои мысли.