Pergunta

Eu estou tentando configurar um repositório de código reutilizável. Eu estava pensando em ter cada módulo de código reutilizáveis ??têm um certo “Nível de Maturidade” rating. seria a classificação definida como o nível em que um código reutilizável encontra-se dentro de um determinado conjunto de requisitos. O nível de maturidade mais alto será o mais alto grau de padrão em um conjunto predefinido de requisitos.

Por exemplo:
Nível; requisitos; Descrição
Nível 0; Código é legal para uso; É o código legal para usar na indústria comercial / através de vários contratos / etc?
Nível 1; codeline base e satisfaz os requisitos nível 0; código de protótipo, ferramentas de 3, etc
Nível 2; Tem interface Função e comentários e atende nível 1 Requisitos; documentação suficiente para cada classe e função; Capaz de determinar a funcionalidade de comentários
Nível 3; Adere aos padrões de codificação e atende nível 2 requisitos; Segue padrões de codificação definidos e passa a verificação de código de teste de utilidade
Nível 4; Inclui casos de teste e atende nível 3 requisitos; Tem casos de teste suficientes para testar todas as funcionalidades do código
Nível 5; Aprovado pela comissão de reutilização e atende nível 4 Requisitos; Avaliado por especialistas de reutilização e colegas e verificou-se atende a todos os níveis de maturidade

Eu estou querendo saber se este nível de maturidade deve ser uma estrutura hierárquica, onde, a fim de passar para o próximo nível que você precisa para atender aos requisitos de todos os níveis anteriores (como mostrei acima)?

Ou se ele deve ser um subconjunto de requisitos para atender o próximo nível?

Por exemplo, temos meet X de requisitos y, podemos passar para o próximo nível (requisitos seria o mesmo como mencionado acima).

Nível 0, atende 0 de 6 requisitos
Nível 1, encontra 1 de 6 requisitos
...

O problema que vejo com a abordagem subconjunto é alguns requisitos devem ter uma ponderação mais forte, e nesta abordagem que não serão tidas em conta (a menos que eu começar a ficar específico como, atende a uma fora de b e X de y, etc). Mas então ele poderia começar a ficar complicado.

Alguém já fez isso antes, e se assim for, como é que você configurar sua biblioteca? Você tem um nível de maturidade em todos ou alguma outra estrutura? Qualquer entrada seria muito apreciada.

Foi útil?

Solução

Criação de um repositório de reutilização de código é uma tarefa difícil. A principal dificuldade não está em como você configurá-lo, mas em como você se comunica a existência de várias bibliotecas no repositório. bibliotecas de reutilização só é bom se eles são usados, e eles são usados ??somente se eles são conhecidos, e eles só são amplamente utilizados, se a qualidade do código é alta e se ele atende as necessidades dos usuários.

Eu gosto da idéia de níveis de maturidade, mas, como outros já publicados, provavelmente há um pouco de trabalho de configuração / build fazer. Eu tenho pensado de uma abordagem semelhante à constrói de uma aplicação - Eu chamei-os níveis de confiança. Na arena aplicação-build, uma compilação confiança baixa é aquele que não passou os testes de unidade; uma confiança média pode incluir testes de passagem unidade, mas não testes de integração, e assim por diante. Este era um bom mecanismo para comunicar a QA e usuários o que esperar. Um mecanismo semelhante pode ser apropriado para bibliotecas.

Os comentários de documentação são uma obrigação, e também deve ter tanto put cuidado para eles como você colocou o código. Os comentários devem comunicar o que, por que, onde, quando, como, onde, etc. O seu processo de construção deve publicar a documentação em um local bem conhecido (mais uma vez, a comunicação é fundamental).

Ao longo das linhas de comunicação, não faz mal para presente de tempos a tempos apenas o que está lá. Novamente! comunicação.

Assim, no mínimo a sua construção de cada biblioteca deve:

  • publicar a biblioteca (talvez notificar os assinantes)
  • publicar a documentação
  • executar testes de unidade
  • publicar o nível de maturidade

Quanto aos níveis de maturidade, eu defini-los com um "nome de nível" e uma descrição do que os meios de nível. Publicar os critérios para o que significa mover para cima ou para baixo um nível. Na verdade, agora que penso nisso, talvez você queira um conjunto de critérios ortogonais: um nível para o código, um nível para a documentação, uso-políticas (ou seja, deve ter uma licença para XYZ), e outros atributos. eu recomendo que você abordar isso em pequenos incrementos embora. No final do dia, fornecendo funcionalidade para usuários finais é o que importa.

Você tem que comunicar também uma mentalidade de, naturalmente, empurrando pedaços reutilizáveis ??no repositório. Os desenvolvedores têm que ter incentivo para fazer isso normalmente. estática de código verificando ferramentas que olhar para a duplicação e avaliações pelos pares só ir tão longe. Alguém tem que realmente fazer o trabalho de mover o código para o repositório.

Finalmente, eu recomendo que você use o máximo de apoio ferramenta possível na instalação, configuração, manutenção e comunicação do repositório. Caso contrário, como qualquer artefato não-código, você vai enfrentar uma certa quantidade de entropia que reduz o valor que o artefato não-código torna-se datado.

Outras dicas

Eu acho que você vai ter dificuldade para assegurar que toda a equipe de desenvolvimento segue essas diretrizes com precisão suficiente. Especialmente quando as linhas de orientação podem ser interpretados de um modo ou outro. Além disso, irá ser uma grande dor, se alguém melhora a uma peça de código através da adição de testes e de repente, tem de se mover para um projecto diferente. Mais provável que não, esse código vai ficar no projeto foi originalmente colocado em, e ao longo do tempo os níveis de maturidade se tornará sem sentido.

Uma abordagem que eu vi muito bem a trabalhar em uma grande empresa é o seguinte:

  • Todas as bibliotecas de terceiros estão empenhados em um diretório especial e sempre incluem um número de versão.
  • As nossas próprias bibliotecas comuns são divididos com base nos referências que eles têm para outras coisas. Por exemplo. se as referências de código de utilitário da biblioteca Infragistics então este pedaço de código utilitário vai para uma biblioteca InfragisticsUtils.
  • As nossas próprias bibliotecas comuns que formam "unidades" claramente identificáveis ??entrar em bibliotecas separadas. Por exemplo, uma biblioteca de código que lida com valores mobiliários de preços é um projeto separado.
  • Todo o código reutilizável que não satisfaz qualquer um dos acima entra em um pega-tudo projecto Utilities.
  • As nossas próprias bibliotecas são compilados e liberado para um local compartilhado onde os projetos pode referenciá-los. Cabe a equipe de desenvolvimento dos projetos de decidir se quer fazer referência a um binário compilado ou apenas incluem o projeto de utilidade para a sua solução.

Obviamente, a qualidade do código que você encontra no catch-all biblioteca Utilities podem variar significativamente. Para aliviar este nós simplesmente garantiu que duas pessoas de diferentes equipes de desenvolvimento revisou todos os checkins para Utilities. Este ervas daninhas fora um monte de coisas que não tem lugar lá!

Eu acho que um grande repositório de código que incluem uma ferramenta CM e uma ferramenta Wiki. A ferramenta CM deve ser estruturado usando a ideia de nível (como proposto), uma vez que as estruturas do código de qualidade. O wiki deve agir como um "anúncio" do que o software pode fazer e como ele pode ajudá-lo. Este wiki também poderia manter informações como, quais os projectos que estão usando o código, a classificação de como utilizável que é, e exemplos de como usá-lo. Se alguém está preocupado com a equipe de desenvolvimento seguindo as diretrizes de nível, deve ser salientado como auto policiamento obras e dar o exemplo de como ele funciona bem com wikis.

Agora, a estruturação da ferramenta CM é importante. Ele é projetado para transmitir a qualidade do código, para que você saiba o que você entrar quando você usá-lo. Por exemplo, se você escrever uma classe simples com apenas quaisquer comentários e ele realmente não defender a padrões de codificação (talvez um protótipo), então ele iria ser celebrado \ sw_repository \ level0 \ ExamplePrototype.

Talvez alguém, em seguida, leva esse pedaço de código e comentários adicionados e leva-lo até padrões. Em seguida, essa pessoa iria colocá-lo em \ sw_repository \ level1 \ ExamplePrototype.

Em seguida, essa mesma pessoa, um pouco mais tarde, cria testes de unidade para o ExamplePrototype. Este seria, então ir para level2 e assim por diante.

Definir os níveis deve levar algum pensamento. Eles realmente deve ser um pouco sequencial e mesmo se, por exemplo, você tinha escrito testes de unidade para o código do protótipo mas não satisfez os comentários e padrão de codificação em seguida, ele é colocado em level0 de qualquer maneira. No entanto, seria fácil ir para level2 se esses comentários e padrões foram satisfeito.

Para minha biblioteca, eu só colocar no código que eu escrevi que pode ser usado em várias aplicações. Se o código é específico para uma aplicação particular, então ele não vai para a biblioteca. À medida que mais aplicativos usá-lo, os insetos se funcionou assim que eu nunca esperava que fosse livre de erros imediatamente. Erros será constantemente encontrados e corrigidos como seus amadurece biblioteca e está estressado com diferentes aplicativos. Ele nunca será livre de erros, mas ao longo do tempo vai se aproximar de confiabilidade. Além disso, quando eu percebo que API para algumas coisas é errada, eu não me preocupo com isso e refatorar o API o mais rápido possível.

Aqui é a minha biblioteca em C ++
http://code.google.com/p/kgui/

Durante anos a Microsoft tem sido um grande defensor para o que é conhecido como fábricas de software , uma grande parte do que é dedicado a resolver os problemas da reutilização.

Quais são os problemas de reutilização? Primeiro de tudo, é difícil. É muito difícil para chegar a uma biblioteca e API que servirá para além das necessidades imediatas do projeto na mão. Como você prever o futuro? Além disso, o problema de um repositório centralizado que serve como uma base de conhecimento e uma vibrante comunidade de prática é muito desafiador. Como você faz algo que é muito flexível e fácil de usar? Muitos tentaram e falharam. Ambos fábricas de software e noreferrer linhas de produtos de software tentar resolver estes problemas.

Boa sorte!

Kit mencionado o problema mais importante: a reutilização . o resto da ideia é bom, mas não é mais do que um detalhe.

Quer dizer, eu mesmo tenho problemas para manter a minha própria biblioteca de reutilização. Às vezes eu faço uma implementação que é específico projeto de muito, ou eu faço o n-th protótipo de uma idéia, e nenhum dos que nunca se mete em minha biblioteca.

Se você realmente ter sucesso em ter uma biblioteca de reutilização de código, que é utilizado e mantido por muitos desenvolvedores, de forma disciplinada, que isso é vitória. você precisa de um sistema de controle de versão e um bug tracker, sendo este último utilizado por ambos os proprietários e usuários do projeto. você precisa de comunicação e meios de contribuição. ter um punhado de desenvolvedores que usam um projeto melhora drasticamente a sua qualidade. implementação fica melhor. documentação é criado. API e design recurso está em um nível muito mais elevado. um comitê é uma coisa agradável, mas não pode decidir, como é bom dado código é, sem realmente usá-lo. ele pode decidir se o código atende aos padrões específicos, mas o cumprimento das normas não é suficiente para boas bibliotecas.

que você precisa para fazer o seu melhor para ter certeza, você não tem toneladas de trechos de código que flutuam ao redor, tudo o que pode mais ou menos fazer alguma coisa. ok, qualquer decisão de projeto tem prós e contras, mas eu acho que, não faz mais sentido começar com um projecto para uma dada tarefa, e ramo que, se for realmente necessário, mas manter a comunicação viva entre as equipes de projeto, e considerar (parcialmente) a fusão de volta.

Não se preocupe muito com categorizar a qualidade de diferentes projectos. se um projeto é ruim, então os usuários / desenvolvedores vai empurrá-lo para um nível melhor. a maioria das pessoas são bastante inteligente para ver, quando uma biblioteca é bom, e quando não é. você realmente precisa para colocar a sua energia nesses efeitos simbióticas, em vez de tentar participantes carga com regras rígidas.

apenas meus 2 centavos ...;)

Olhe Will Tracz de "Confessions of a Salesman programa usado", e coisas pela reutilização rabino da HP, Martin Griss.

Eu acho que você está pensando demais em um não problema.

Como você configurar minha biblioteca? fácil, se você usar o mesmo (ou quase o mesmo) Método em dois ou mais projetos, movê-lo para a biblioteca.

É considerado boa abordagem para ter sua própria biblioteca, mas milhares de linhas é uma ruína!

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top