Práticas de Programação em .NET

2.010 visualizações

Publicada em

Nesta sessão o Ricardo vai nos mostrar algumas das principais práticas utilizadas no desenvolvimento profissional de software na plataforma Microsoft .NET. Serão abordados temas como convenções e padrões de codificação em equipa e validação do código, diferentes formas estruturar uma solução, uma solução vs múltiplas soluções e quando faz sentido, princípios diversos como DRY, SOLID, KISS, YAGNI com demonstrações práticas, testes unitários, e mais...

Publicada em: Tecnologia
1 comentário
0 gostaram
Estatísticas
Notas
  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.010
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
34
Comentários
1
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Namingconventions é um dos elementos mais importantes de previsibilidade e de descoberta em uma aplicaçãoO uso difundido e a compreensão destas convenções deve eliminar muitas das perguntas mais básicas e comuns dos utilizadores
  • HorizontalAlignment tem umalegibilidade superior a AlignmentHorizontalCanScrollHorizontally é muitomaislegivel e claroqueScrollableX (referencia “obscura” aoeixo X)
  • UsarOnButtonClick em vez de OnBtnClickGetLength é melhorqueGetInt
  • Validar as convençõesusadasporomissão no stylecop, ver se nãobatem com os slidesanterioresVer se ainda se consegueconfigurar novas regras de validação no StyleCop
  • Five valuation principles of object-oriented developmentManage dependencies between classes and reduce unnecessary complexityFacilitates testingPrinciples, not lawsRequire students
  • Umaclassedevefazerapenasumacoisa, e deve faze-la bem
  • É aplicavel a pacotes, assemblies, etcÉ a base paratodososoutrosprincipios
  • Devemosusarpolimorfismo e herançaparapoder extender a classe e modificar o comportamentonaderivada, nuncaalterando o codigoda original
  • O principio maisimportante de todosOs requisitosestãosempreemconstantemudança, masprecisamos de desenvolvercodigoestavel a mesmaCom OO,conseguimoscriarabstrações com desenhosolido, mascomportamentoflexivelA grandequestão e quandodevemosaplicareste principio
  • Nãodevehaverpreocupação entre usar a classe base ou a derivada
  • Violaçãodeste principio indicaquedevemosprecisar de fazeralgumrefactornanossahierarquia de classesIsto é um principio, nãouma lei
  • Criar interfaces pequenas e consistentesSe temosumaclasseabstractaou interface,entãoosimplementadoresnãodevem ser forçados a implementarpartesquenãolhesinteressam
  • Classes nãodevemdevpender de outras classes, elesdevemdepender de abstrações (interfaces)Prevent: Rigid (change affects too many parts of the system) Fragile (every change breaks something unexpected) Immobile (impossible to reuse)
  • Validar as convençõesusadasporomissão no stylecop, ver se nãobatem com os slidesanterioresVer se ainda se consegueconfigurar novas regras de validação no StyleCop
  • Práticas de Programação em .NET

    1. 1. http://netponto.org<br />15ª Reunião Presencial - 23/10/2010<br />Práticas de programação em .NETRicardo Alves<br />
    2. 2. Ricardo Alves<br />Licenciado do Instituto Superior de Engenharia de Lisboa (ISEL)<br />4 anos de experiência profissional<br />C#, WCF, ASP.NET, SQL, VS LightSwitch, Agilemethodologies<br />
    3. 3. Agenda<br />NamingConventions<br />CodingPractices<br />UnitTestsPractices<br />
    4. 4. NamingConventions<br />Código tem de reflectir a sua intenção<br />Código claro e objectivo<br />Meio caminho andado para documentação <br />
    5. 5. Naming Conventions<br />NamingConventions da .Net Framework<br />http://msdn.microsoft.com/en-us/library/ms229045.aspx<br />Escolher nomes facilmente legíveis e claros<br />Dar preferência a legibilidade sobre brevidade<br />Não usar underscore, hífenes, ou qualquer caracter não alfanumérico<br />Não usar abreviações como identificadores<br />
    6. 6. Naming Conventions<br />NamingConventions da .Net Framework<br />http://msdn.microsoft.com/en-us/library/ms229045.aspx<br />Só usar acrónimos que sejam bem conhecidos<br />Regra do Bing<br />Fazer uma pesquisa no Bing pelo acrónimo, se o acrónimo aparecer nos primeiros resultados então podemos usar<br />Regra não se aplica a acrónimos do negócio<br />Usar nomes comuns, como value ou item, em casos onde o identificador e o seu tipo não têm qualquer valor semântico<br />Usado em parâmetros ou variáveis de iteração<br />Não usar “Hungariannotation”<br />
    7. 7. Naming Conventions<br />NamingConventions da .Net Framework<br />http://msdn.microsoft.com/en-us/library/ms229045.aspx<br />Pascal Case<br />A primeira letra é maiúscula e as restantes primeiras letras de cada palavra são maiúsculas<br />ObjectContext, BackColor<br />Camel Case<br />A primeira letra é minúscula e as restantes primeiras letras de cada palavra são maiúsculas<br />numberOfDays, isValid<br />Uppercase<br />Todas as letras são maiúsculas<br />PI, ID<br />
    8. 8. Naming Conventions<br />Namespaces<br />Pascal Case, não usar underscores<br />Acrónimos de 3 ou mais letras devem usar Pascal Case<br />Seguir padrão:<br /><Nome da Empresa/Developer>.<Tecnologia><br />AppliedIS.TimeCard.BusinessRules<br />IrritatedVowel.Controllers<br />PeteBrown.DotNetTraining.InheritanceDemo<br />PeteBrown.DotNetTraining.Xml<br />
    9. 9. Naming Conventions<br />Classes e estruturas<br />Pascal Case, não usar underscores<br />Não usar nomes começados por “I” a não ser que a próxima letra seja minúscula, para não confundir com interfaces<br />Acrónimos de 3 ou mais letras devem usar Pascal Case<br />Não devem usar o mesmo nome que o Namespace a que pertencem<br />Widget<br />InstanceManager<br />XmlDocument<br />MainForm<br />DocumentForm<br />HeaderControl<br />
    10. 10. Naming Conventions<br />Interfaces<br />Usar as mesmas convenções que para as classes, mas o nome deve começar com um “I” e a próxima letra deve ser maiúscula<br />IWidget<br />IComponent<br />
    11. 11. Demo #1: Validar NamingConventions através do FxCop<br />demonstração <br />
    12. 12. CodingPractices<br />Princípios S.O.L.I.D.<br />
    13. 13. CodingPractices<br />SOLID<br />Single ResponsibilityPrinciple<br />Open/ClosedPrinciple<br />LiskovSubstitutionPrinciple<br />Interface SegregationPrinciple<br />DependencyInversionPrinciple<br />
    14. 14. CodingPractices<br />Single ResponsibilityPrinciple<br />
    15. 15. CodingPractices<br />Single ResponsibilityPrinciple<br />Uma classe não deve ter mais que uma razão para ser alterada<br />
    16. 16. Demo #2: Single ResponsabilityPrinciple<br />demonstração <br />
    17. 17. CodingPractices<br />Open/ClosedPrinciple<br />
    18. 18. CodingPractices<br />Open/ClosedPrinciple<br />Deve ser possível alterar o comportamento duma classe sem a modificar<br />
    19. 19. Demo #3: Open/ClosedPrinciple<br />demonstração <br />
    20. 20. CodingPractices<br />LiskovSubstitutionPrinciple<br />
    21. 21. CodingPractices<br />LiskovSubstitutionPrinciple<br />Classes derivadas devem ser substituíveis pelas suas classes base<br />
    22. 22. Demo #4: LiskovSubstitutionPrinciple<br />demonstração <br />
    23. 23. CodingPractices<br />Interface SegregationPrinciple<br />
    24. 24. CodingPractices<br />Interface SegregationPrinciple<br />Classes não devem ser forçadas a implementar interfaces que não usam<br />
    25. 25. Demo #5: Interface SegregationPrinciple<br />demonstração <br />
    26. 26. CodingPractices<br />DependencyInversionPrinciple<br />
    27. 27. CodingPractices<br />DependencyInversionPrinciple<br />Módulos não devem depender de outros Módulos, devem depender de abstracções<br />Abstracções não devem depender dos detalhes, os detalhes é que devem depender das abstracções<br />
    28. 28. Demo #6: DependencyInversionPrinciple<br />demonstração <br />
    29. 29. CodingPractices<br />YAGNI<br />Youain’tgonnaneedit<br />DRY<br />Don’trepeatyourself<br />KISS<br />Keepitsimple, stupid!<br />
    30. 30. Unit Tests Practices<br />Ser o mais simples possível<br />Ser independentes entre si<br />Devem testar uma unidade de código de cada vez<br />Usar Mocks para simular componentes externos<br />Não testar configurações<br />Não devem fazer asserções desnecessárias<br />
    31. 31. Unit Tests Practices<br />Devem ter nomes claros e concisos<br />Testar comportamentos e não métodos<br />Testar apenas classes e métodos com visibilidade publica<br />Criar testes para reproduzir bugs encontrados<br />Assegurar que as excepções que são lançadas têm testes associados<br />
    32. 32. Demo #6: UnitTestsPractices<br />demonstração <br />
    33. 33. Dúvidas?<br />
    34. 34. Referências<br />ThePrinciplesof OOD<br />http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod<br />Design Guidelines for Developing Class Libraries<br />http://msdn.microsoft.com/en-us/library/ms229042.aspx<br />Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries <br />http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613<br />
    35. 35. Patrocinadores desta reunião<br />
    36. 36. Obrigado!<br />Ricardo Alves<br />ricardoloboalves@gmail.com<br />http://pt.linkedin.com/in/rmalves/<br />http://twitter.com/rmalves<br />

    ×