Preciso iniciar o design e desenvolvimento de uma nova estrutura para interagir com um ECM de código aberto. Isso inclui um modelo de dados personalizado para ajudar os desenvolvedores de sites a interagir com esse ECM, para que não precisem se preocupar com os detalhes da manipulação de nós e outros detalhes de baixo nível. Isso é apenas um monte de classes e métodos para desenvolver.

Tenho algumas dúvidas sobre como lidar com a organização e o gerenciamento desse projeto: existem algumas regras gerais a serem seguidas, dicas, práticas recomendadas ou algo a ter em mente para o desenvolvimento desse tipo de projeto?

Tenho certeza de que há alguma diferença entre o desenvolvimento de uma estrutura ou biblioteca e um aplicativo.

Primeiro, aqui estão minhas 2 regras para evitar a síndrome de desperdício de estrutura:

• A ausência de uma existente, cobrindo 80% das minhas necessidades e extensível para corresponder aos últimos 20%
• A quase certeza de que vou usá-lo novamente, em outro aplicativo

Depois de passar por eles, verifique isso:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

1) Os recursos devem ser adicionados apenas a um Framework quando extraídos do código de trabalho. Em outras palavras, antes de adicionar sua nova idéia legal à sua nova estrutura legal, verifique se ela realmente agrega valor e reduz a repetição em um aplicativo do mundo real que funciona.

2) Documentação, documentação, documentação.

3) Documentação, documentação, documentação.

Experiência dolorosa e muito esforço desperdiçado levam a este conselho: extrair ou refatorar uma estrutura do software de trabalho. Crie esse software tendo em mente que você deseja extrair uma estrutura no futuro, mas não a construa primeiro.

Eu sugeriria o livro Framework Design Guidelines . Tem alguns anos, mas os princípios permanecem verdadeiros. Ele tem vários padrões e explica o raciocínio por trás das decisões que você tomará ao construir uma estrutura.

1) Atenha-se às boas convenções desde o início, verifique se você documentou uma convenção muito específica; as melhores estruturas são as que são internamente consistentes.

2) Certifique-se de que tudo esteja altamente documentado, desde bons comentários de código até a explicação do que as funções mais importantes exigem e produzem, mesmo que pareça super simples para você, alguém pode usá-lo na 14ª hora consecutiva e eles só preciso dessa coisa naquele momento.

3) Defina um resumo do projeto para você, com o que você deseja que a estrutura atinja, metas realistas e prioridades gerais.

4) Se ele estiver disponível para uso das pessoas, verifique se você tem alguma forma de processo de suporte / rastreamento de erros em vigor. Haverá erros, isso acontece com todos nós, mas se você puder gerenciá-los desde o início, facilitará sua vida.

Em suma, abordagem semelhante à criação de qualquer aplicativo, mas os desenvolvedores são ainda mais confusos do que os usuários, e as melhores estruturas são as que podemos captar, entender e não precisamos lutar.

Não concordo muito com o que foi dito e sinto que mais não foi mencionado, então vou começar do zero.

Metodologias ágeis

Adote metodologias ágeis durante o desenvolvimento da estrutura, para que você possa se adaptar às mudanças, reagir rapidamente aos obstáculos e garantir um produto final funcional e de qualidade. Metodologias ágeis são aquelas que, de acordo com o "Manifesto Ágil", priorizam:

Indivíduos e interações em processos e ferramentas
Software de trabalho em documentação abrangente
Colaboração do cliente em negociação de contratos
Respondendo a mudanças ao seguir um plano

Está certo. Eu disse que a funcionalidade é mais importante que a documentação. Observe que o "Manifesto Ágil" menciona que as prioridades da direita ainda são importantes, menos ainda que as da esquerda.

Comunicação

Quem está criando a estrutura precisa saber:

1. Como será usado: o aplicativo de destino
2. Que problema se destina a resolver: o problema alvo
3. Quem o usará: o público-alvo

Por exemplo, se uma empresa pretender desenvolver um aplicativo final com o ASP .NET, seria tolice dizer aos programadores que "criem essa estrutura" sem informar o que foi dito acima. Se os programadores não conhecerem o aplicativo de destino, eles podem não torná-lo orientado para a Web. Se eles não soubessem o problema, poderiam criar uma estrutura para um propósito diferente. Se eles não conhecessem o público, poderiam programar a estrutura em C ++. Qualquer uma dessas circunstâncias tornaria inútil a estrutura resultante.

Estilo

Escusado será dizer que, estabelecer um estilo / formato de programação e ficar com ele.

Os E's

1. Modularidade : reutilize o código programaticamente, não literalmente.
2. Eficiência : seu código é destinado à reutilização. Qualquer prejuízo à velocidade é multiplicado.
3. Manutenção : Você deseja poder editar a estrutura para atualizar vários programas, sem precisar modificar os programas.
4. Usabilidade : os aplicativos podem realmente usar sua estrutura sem pular os bastidores?
5. Praticidade : não reinvente a roda se não for necessário. Sua estrutura pode depender de outras estruturas.
6. Redundância : captura de exceções / erros. Em toda parte. Os manuseie. Em toda parte. Nunca confie em nenhum código, exceto no escopo local, para lidar com erros, mesmo se você souber.

Tenho certeza de que há alguma diferença entre o desenvolvimento de uma estrutura ou biblioteca e um aplicativo.

Os processos de desenvolvimento são essencialmente os mesmos. As diferenças podem se resumir a questões de marketing e implantação, embora eu ache que as maiores diferenças geralmente são em termos de escopo e definição do projeto. Lembre-se de que um Aplicativo pode incluir ou usar uma estrutura ou uma biblioteca, uma estrutura pode ser uma coleção de bibliotecas.

Tenho algumas dúvidas sobre como lidar com a organização e o gerenciamento desse projeto: existem algumas regras gerais a serem seguidas, dicas, práticas recomendadas ou algo a ter em mente para o desenvolvimento desse tipo de projeto?

A organização e o gerenciamento do projeto são novamente os mesmos para qualquer projeto de desenvolvimento. Novamente, tudo se resume ao escopo. No entanto, quando se trata de escrever uma estrutura, vale a pena ter uma visão muito clara sobre o que você está tentando alcançar e colocar regras estritas de design na interface pública da estrutura para garantir consistência em termos da apresentação da API. Se você permitir que todos os desenvolvedores façam suas próprias coisas, você terminará com uma bagunça complicada e um design de API muito deselegante.

Seguirei a recomendação de Ryan Hayes de ler as Diretrizes de design de estrutura, mesmo que o livro em si seja destinado ao desenvolvimento de estruturas baseadas em .NET, porque o conselho geral é aplicável independentemente das tecnologias de implementação específicas que você pode optar por usar.

Por experiência, eu recomendaria seguir o princípio clássico do YAGNI implementando as interfaces públicas mais simplistas primeiro e depois expandindo para oferecer maior controle e profundidade posteriormente, mas tenha cuidado ao usar nomes úteis para mostrar por que métodos ou classes estão sendo expandidos. Eu nunca fui fã de adicionar "Ex" ou outros sufixos semelhantes aos nomes dos métodos ou adicionar números às definições expandidas da interface. Diferencie a funcionalidade e os nomes de interface / método devem se tornar mais claros e, com sorte, menos ofuscados e confusos.