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% de minhas necessidades e extensíveis para corresponder aos últimos 20%
• O próximo certeza de que irei usá-lo novamente, em outro aplicativo

Depois de passar naqueles, verifique:

• 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

Comentários

• Eu acrescentaria que se você puder ‘ encontrar uma estrutura que atenda à sua regra 80/20, ou você está trabalhando em um domínio extremamente único OU você não ‘ não entende seu domínio bem o suficiente.

1) Os recursos só devem ser adicionados a um Framework quando eles são extraídos do código de trabalho. Em outras palavras, antes de adicionar sua nova ideia legal ao seu novo framework legal, certifique-se de que ela realmente agrega valor e reduz a repetição em um aplicativo funcional do mundo real.

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

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

Experiência dolorosa e muito esforço desperdiçado levar a este conselho: extrair ou refatorar uma estrutura de software funcional. Crie esse software tendo em mente que você acha que vai querer extrair uma estrutura no futuro, mas não crie a estrutura primeiro.

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

1) Atenha-se às boas convenções desde o início, certifique-se de documentar uma convenção muito específica, os melhores frameworks são aqueles que são internamente consistentes.

2) Certifique-se de que tudo está altamente documentado, desde bom comentários de código por todo o caminho para explicar o que as funções mais importantes exigem e produzem, mesmo que pareça muito simples para você, você pode ter alguém para usá-lo na 14ª hora consecutiva e essa pessoa apenas precisa de uma coisa certo então.

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

4) Se ele vai estar disponível para as pessoas usarem, certifique-se de ter algum tipo de processo de suporte / acompanhamento de bugs em vigor. Haverá bugs, isso acontece com todos nós, mas se você puder gerenciá-los desde o início, tornará sua vida mais fácil.

De modo geral, abordagem semelhante para construir qualquer aplicativo, mas os desenvolvedores são ainda mais exigentes do que os usuários, e os melhores frameworks são aqueles que podemos aprender, entender e não precisamos lutar.

Discordo de muito do que foi dito e sinto que mais não foi mencionado, então começarei do zero.

Metodologias Ágeis

Adote metodologias ágeis durante o desenvolvimento de seu framework 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 sobre processos e ferramentas
Software de trabalho sobre documentação abrangente
Colaboração do cliente sobre negociação de contrato
Resposta à mudança sobre seguindo um plano

Correto. Eu disse que a funcionalidade é mais importante do que a documentação. Observe que o “Manifesto Ágil” menciona que as prioridades do lado direito ainda são importantes, mas menos importantes do que aqueles à esquerda.

Comunicação

Quem está fazendo o framework precisa saber:

1. Como será usado: o aplicativo de destino
2. O problema que pretende resolver: o problema de destino
3. Quem o usará: o público-alvo

Por exemplo, se uma empresa pretendia desenvolver um aplicativo final com ASP .NET, seria tolice dizer a seus programadores “fazer esta estrutura” sem dizer o que foi dito acima. Se os programadores não conhecessem o aplicativo de destino, eles poderiam não torná-lo orientado para a Web. Se eles não conhecessem o problema, eles poderiam fazer uma estrutura para um propósito diferente. Se eles não conhecessem o público, eles poderiam programar a estrutura em C ++. Qualquer uma dessas circunstâncias tornaria a estrutura resultante inútil.

Estilo

Nem é preciso dizer, estabeleça um estilo de programação / format e fique com ele.

The E “s

1. Modularidade : Reutilize o código programaticamente, não literalmente.
2. Eficiência : Seu código deve ser reutilizado . Quaisquer prejuízos à velocidade são multiplicados.
3. Capacidade de manutenção : você deseja poder editar a estrutura para atualizar vários programas, sem ter que modificá-los.
4. Usabilidade : os aplicativos podem realmente usar sua estrutura sem pular obstáculos?
5. Praticidade : Não reinvente a roda se você não tiver para fazer isso. Sua estrutura pode depender de outras estruturas.
6. Redundância : captura 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 que confia.

Comentários

• Bem-vindo para P.SE! Eu ‘ Não concordo com o nº 6 em capturar exceções em sua estrutura. Eu ‘ sou um grande crente que o framework deve ser um pirralho absoluto e lançar exceções e deixar isso para o programador usar o framework para capturá-los ou (melhor ainda) reorientar seu código para para evitar a exceção – encorajando a conformidade com a convenção.

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 biblioteca, uma estrutura pode ser uma coleção de bibliotecas.

Tenho algumas dúvidas sobre como lidar com a organização e gerenciamento desse projeto: Existem algumas regras gerais para llow, dicas, práticas recomendadas ou algo para se ter em mente ao desenvolver este tipo de projeto?

A organização e o gerenciamento de projetos são novamente os mesmos para qualquer projeto de desenvolvimento . Mais uma vez, 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 de design estritas na interface pública da estrutura para garantir a consistência em termos de APIs apresentação. Se você permitir que cada desenvolvedor faça suas próprias coisas, você vai acabar com uma bagunça complicada e um design de API muito deselegante.

Vou seguir Ryan Hayes “ recomendação para ler as Diretrizes de design da estrutura embora o livro em si seja voltado para o desenvolvimento de frameworks baseados em .NET, porque o conselho geral é aplicável independentemente das tecnologias de implementação específicas que você pode escolher para usar.

Por experiência, eu aconselharia manter o princípio YAGNI clássico, implementando primeiro as interfaces públicas mais simplistas e, em seguida, expandindo para oferecer maior controle e profundidade posteriormente, mas tome 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 a nomes de métodos, ou adicionar números a definições de interface expandidas. Diferencie na funcionalidade, e seus nomes de interface / método devem se tornar mais claros e, espero, menos ofuscados e confusos.