Microsoft®TechDays 2005       Aprender, Partilhar, ExperimentarARC03As Falácias e os Desenganos noDesenvolvimento de Softw...
Patrocinadores
FaláciaTodo e qualquer programador, aquando da  construção de uma aplicação poderá ter  partido das premissas aqui apresen...
Agenda Falácias com implicações a nível de     Processo Desenvolvimento     Integridade     Fiabilidade/Robustez     Segur...
Processo DesenvolvimentoProcesso define-se mais tarde “Por agora faz-se assim, e depois automatiza- se”. “Isto é só tempor...
Processo define-se mais tardeDefinir boas prácticas à cabeça Definição de convenções de código e alguns templates pré-defi...
Integridade e Fiabilidade”A rede é fiável”  O Hardware falha      Routers “crasham”, fios são cortados, falha a      energ...
“A Rede é fíavel”Não assumir fiabilidade Assumir que durante uma comunicação remota, a rede poderá falhar a qualquer altur...
Fiabilidade/Robustez“Alteraçõezinhas” última hora “É só mais esta funcionalidadezinha sem impacto”    Associada a esta fun...
“Alteraçõezinhas última hora”Evitar a tentação de funcionalidadesnão planeadas “É dificil não cair na tentação, mas a carn...
SegurançaA Rede é Segura “Programadores são competentes”     Nem sempre ... Quantos é que sabem sobre segurança de     red...
“A Rede é Segura”Assumir a insegurança Qualquer aplicação que comunique, tem no mínimo dois clientes: A que nós escrevemos...
DesempenhoNão existe latênciaOs dados demoram tempo a viajar pelas camadas de rede e pelo hardware    E isto acontece muit...
“Não existe latência”Medir os tempos de rede Seja frugal com a quantidade de dados que transmite pela rede; quanto maior a...
DesempenhoLargura de banda infinita Uma linha T1 (1.544 Mbps) fica saturada rápidamente quando lhe metemos em cima VOIP, s...
“Largura de banda infinita”Não envie mais do que precisa Seja frugal com a quantidade de dados que transmite pela rede; te...
DesempenhoCusto de transporte é zero Os ponteiros não viajam bem É dispendido muito tempo a transformar a representação in...
Custo de transporte é zeroPerceber e quantificar o seu custo Medir o custo total de enviar os dados pela rede, medindo o c...
ManutençãoTopologia é imutável Mudanças de topologia, acontecem sem qualquer planeamento:    Falhas de hardware, falhas de...
Topologia é imutávelUtilizar níveis de indirecção  A infra-estrutura de rede, disponibiliza  frequentemente níveis de indi...
ManutençãoO sistema é monolítico “Sim, isso é simples. Só temos que desenvolver e instalar mais um bocado de código…”     ...
Sistema é monolíticoDefinir as fronteiras  Desenhar o sistema, a tornar explicito quais as partes  que são interdependente...
ManutençãoO sistema está terminado A única altura em que o sistema está “terminado”, é quando o servidor é desligado, toda...
O sistema está terminadoConstruir sistemas que durem Conceber sistemas com pontos de extensibilidade que permitam a evoluç...
ManutençãoExiste um só administrador “…e ele nunca nos abandonará, nunca adoecerá, nunca terá férias, ou será atropelado p...
Existe um só administradorTornar o sistema facilmente gerível Em qualquer altura, qualquer administrador de sistema relati...
ManutençãoSó mais um IF “Então para fazermos isto não é só mais um IF? Isto não custa nada certo?”    “Esparguetada” difíc...
Só mais um IF“Não cair na tentação da martelada” Pode parecer a solução mais rápida, mas a médio prazo poder-se-á tornar n...
InteroperabilidadeO ambiente é homogéneo Em qualquer empresa existem sempre vários ambientes    Ambientes legados    Mac d...
O ambiente é homogéneoDesenvolver sistemas agnósticos àplataforma Na concepção do sistema, nunca assumir que do outro lado...
Mas.....Em jeito de conclusão A parte complicada, é perceber quais as falácias que se aplicam ao seu caso em particular Nã...
Perguntas e Respostas?
RecursosThe Eight Fallacies of Distributed Computinghttp://today.java.net/jag/Fallacies.htmlBlog Ted Newardhttp://blogs.te...
Pergunte Aos EspecialistasObtenha as Respostas às suas QuestõesEstarei na área Pergunte Aos Especialistas,no Pavilhão 5 :Q...
Participe Noutras Sessões  ARC01 -Padrões para Arquitecturas Orientadas a Serviços (SOA)  WEB04 - Hacked!!! Como são ataca...
Recursos Úteis  MSDN Portugal   http://www.microsoft.com/portugal/msdn   Noticias   Comunidades   Centro de Arquitectura  ...
Recursos Úteis  Recursos para Comunidades Microsoft  http://www.microsoft.com/portugal/technet/comunidades  Subscrições Te...
Microsoft®TechDays 2005         Aprender, Partilhar, ExperimentarNão se Esqueça de Preencher oQuestionário de Avaliação!AR...
Passatempo  Bónus Extra no TechDays 2005!!                     Habilite-se a ganhar uma Xbox          360 e               ...
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.         MICROSOFT...
As Falácias e os Desenganos no Desenvolvimento de Software (TechDays 2005)
Upcoming SlideShare
Loading in …5
×

As Falácias e os Desenganos no Desenvolvimento de Software (TechDays 2005)

449 views
392 views

Published on

As Falácias e os Desenganos no Desenvolvimento de Software (TechDays 2005)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
449
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Example: Session Code: PPT300 (see your session code) Session Name: Building a Good Presentation With PowerPoint (see your session name) Speaker Name: Mike Presenter Title: Office Product Manager Company: Microsoft Corporation DURING BREAK AND BEFORE YOUR SESSION, LEAVE THIS SLIDE ON SCREEN TO INFORM ATTENDEES
  • "Essentially everyone, when they first build an enterprise application, makes the following 10 assumptions. All turn out to be false in the long run and all cause big trouble and painful learning experiences."
  • "Essentially everyone, when they first build an enterprise application, makes the following 10 assumptions. All turn out to be false in the long run and all cause big trouble and painful learning experiences."
  • This slide can be used if Q&A will exist in the session
  • This a sample of Session’s Resources . It can be technology or product related.
  • Use this slide to share with the audience when you are present at Ask-the-Experts area.
  • Review communities to include local communities
  • Links for ITPRO Community
  • Example: Session Code: PPT300 (see your session code) Session Name: Building a Good Presentation With PowerPoint (see your session name) Don’t forget: Remind attendees to fill eval forms.
  • As Falácias e os Desenganos no Desenvolvimento de Software (TechDays 2005)

    1. 1. Microsoft®TechDays 2005 Aprender, Partilhar, ExperimentarARC03As Falácias e os Desenganos noDesenvolvimento de Software(Partes desta apresentação baseadas numa sessão do Ted Neward)Tiago Pascoal (tiago.pascoal@agilior.pt)Bruno Câmara (bruno.camara@agilior.pt)Agilior
    2. 2. Patrocinadores
    3. 3. FaláciaTodo e qualquer programador, aquando da construção de uma aplicação poderá ter partido das premissas aqui apresentadas.No médio prazo estas verificam-se como não sendo verdadeiras, e causam problemas. Revelam-se experiências didácticas mas dolorosas.
    4. 4. Agenda Falácias com implicações a nível de Processo Desenvolvimento Integridade Fiabilidade/Robustez Segurança Desempenho Manutenção (nível desenvolvimento e operação) Interoperabilidade
    5. 5. Processo DesenvolvimentoProcesso define-se mais tarde “Por agora faz-se assim, e depois automatiza- se”. “Isto é só temporário, depois vê-se”. Regras de codificação, não existentes Os processos de build são habitualmente manuais, sendo os seus automatismos relegados para mais tarde; e quando se vai pensar, ou já não há tempo ou é tarde demais. Gestão de configurações insuficiente.
    6. 6. Processo define-se mais tardeDefinir boas prácticas à cabeça Definição de convenções de código e alguns templates pré-definidos Processo de build automatizado desde o dia zero de desenvolvimento Build sem intervenção humana e repetível Definição de regras claras de gestão de configurações Políticas de Check-In, nomenclatura de versões, regras de estruturação da árvore de desenvolvimento Padronização dos ambientes de desenvolvimento
    7. 7. Integridade e Fiabilidade”A rede é fiável” O Hardware falha Routers “crasham”, fios são cortados, falha a energia (a culpa é da cegonha), .... Desligam-se servidores inadvertidamente,... O Software falha Excepções inesperadas, crashes, … Sistemas são crackados “As leis da física falham” Por vezes os sinais não viajam como são supostos (interferência, ruído,…)
    8. 8. “A Rede é fíavel”Não assumir fiabilidade Assumir que durante uma comunicação remota, a rede poderá falhar a qualquer altura Programação defensiva: timeouts, re- tentativas Mecanismos de compensação (humana se for caso disso). Backups (quando tudo o resto falha...)
    9. 9. Fiabilidade/Robustez“Alteraçõezinhas” última hora “É só mais esta funcionalidadezinha sem impacto” Associada a esta funcionalidade não foi feita qualquer análise de impacto, podendo afectar a fiabilidade da aplicação Tipicamente não existem testes (acto de fé, é tão simples que….) Potencial inconsistência com as restantes funcionalidades
    10. 10. “Alteraçõezinhas última hora”Evitar a tentação de funcionalidadesnão planeadas “É dificil não cair na tentação, mas a carne tem que ser forte” Funcionalidades novas só com testes efectuados Análise de risco e/ou de impacto
    11. 11. SegurançaA Rede é Segura “Programadores são competentes” Nem sempre ... Quantos é que sabem sobre segurança de redes? Os dados remotos são confiáveis A origem dos pacotes TCP/IP pode ser forjada Principal preocupação do IPv6 Sistemas remotos são confiáveis Mesmo sendo confiáveis agora, qual a garantia que algures no futuro não serão comprometidos? Nunca correrá fora da firewall Portáteis e PDA’s a viajar fora da rede Redes wireless sem conhecimento departamento de redes
    12. 12. “A Rede é Segura”Assumir a insegurança Qualquer aplicação que comunique, tem no mínimo dois clientes: A que nós escrevemos e o telnet (o melhor amigo dos crackers) Se assumirmos que qualquer byte de rede passa por um processo de verificação antes de ser usado, é um bom começo. Quem discute a dimensão de uma chave criptográfica com outro programador, está apenas a discutir a espessura da porta blindada da tenda Se confia na firewall para garantir a sua segurança espero que não trabalhe para nenhuma empresa à qual eu confio os meus dados.
    13. 13. DesempenhoNão existe latênciaOs dados demoram tempo a viajar pelas camadas de rede e pelo hardware E isto acontece muitas vezes (uma por intermediário) Mesmo as redes rápidas, são ordens de grandeza mais lentas que o BUS lento de um PC.
    14. 14. “Não existe latência”Medir os tempos de rede Seja frugal com a quantidade de dados que transmite pela rede; quanto maior a dimensão dos dados, mais tempo demora a ser transmitido. O TCP/IP tenta garantir a entrega dos pacotes, cuja dificuldade aumenta com uma maior quantidade de pacotes.
    15. 15. DesempenhoLargura de banda infinita Uma linha T1 (1.544 Mbps) fica saturada rápidamente quando lhe metemos em cima VOIP, streaming video, downloads de música,etc,etc Assim que se metem Web Services à mistura, é de esperar que as necessidades dupliquem ou tripliquem Colocar mais cablagem para aumentar capacidade, é o jogo do tapa e destapa na rua mais próxima (mais uma vez…) Programadores desenvolvem localmente ou em redes pouco congestionadas. Um ambiente de produção com estas características, tem uma probablidade igual à de eu ganhar o Euromilhões (e nem sequer jogo  )
    16. 16. “Largura de banda infinita”Não envie mais do que precisa Seja frugal com a quantidade de dados que transmite pela rede; tentar enviar apenas aquilo que não pode ser colocado em cache Ironicamente, este argumento vai contra a corrente inicial das aplicações baseadas em browsers visto que grande parte da informação enviada é apresentação. Daqui o recente ressurgimento dos “smart clients” e de aplicações AJAX Testar a aplicação (e não apenas na véspera de passagem a produção) num ambiente muito próximo do de produção.
    17. 17. DesempenhoCusto de transporte é zero Os ponteiros não viajam bem É dispendido muito tempo a transformar a representação interna dos dados em algo que possa ser transmitido. Este processo é denominado por marshaling e tem custos associados. Quer o Java quer o .Net remoting usam serialização para fazer o marshaling Os Web Services tem que fazer o marshal/unmarshal de XML
    18. 18. Custo de transporte é zeroPerceber e quantificar o seu custo Medir o custo total de enviar os dados pela rede, medindo o custo total do marshaling. Recriar o processo de marshaling/unmarshaling (serializando/deserializando todos os dados) “Observar” dados na rede (tracer) Medir com um profiler o peso da execução
    19. 19. ManutençãoTopologia é imutável Mudanças de topologia, acontecem sem qualquer planeamento: Falhas de hardware, falhas de software, desastres (naturais ou causados),etc. O código pode correr num portátil ou PDA que anda “por aí” A rede pode ser wireless, onde os nós estão em mutação constante. Ou pior uma combinação de rede wireless e cablada.
    20. 20. Topologia é imutávelUtilizar níveis de indirecção A infra-estrutura de rede, disponibiliza frequentemente níveis de indirecção de forma a abstrair a topologia física da topologia lógica: DNS,NAT,etc,etc Alguns modelos de programação disponibilizam modelos (JNDI) Considerar técnicas Peer to Peer (WS-Discovery, UDP/IP, Multicast,…) para manter registo e reagir a alterações topológicas em runtime.
    21. 21. ManutençãoO sistema é monolítico “Sim, isso é simples. Só temos que desenvolver e instalar mais um bocado de código…” Mesmo que se controle todos os intervenientes hoje…. …o amanhã trás sempre alterações a nível do controle das peças “Parti a tua aplicação? O que queres dizer com isso? Nunca sequer ouvi falar dessa aplicação!” Poderão existir sistemas, a interligar-se com o nosso (o que não era suposto) sem sequer o sabermos. As bases de dados são sistemas orgânicos que ganham vida própria. Muitas vezes a “propriedade” da BD perde-se assim que é colocada em produção.
    22. 22. Sistema é monolíticoDefinir as fronteiras Desenhar o sistema, a tornar explicito quais as partes que são interdependentes e que necessitam de ser alterados atomicamente (tightly coupled); manter as fronteiras externas (rede) o mais possível fora destes átomos (loosely coupled) Se as dependências do componente se mantiverem apenas do nosso lado, são muito mais fáceis de controlar. Interrogar-se: “Como é que reagimos se o schema e código evoluírem independentemente?”. Preferir definir contratos por oposição a tipos partilhados.
    23. 23. ManutençãoO sistema está terminado A única altura em que o sistema está “terminado”, é quando o servidor é desligado, todas as cópias do código fonte são apagadas, e todos as pessoas envolvidas no projecto são “terminadas” de uma forma final. De qualquer outra maneira o sistema renascerá de novo noutro projecto “precisamos de algo que o projecto ABC tinha, bastando apenas …” Mesmo que deixemos a empresa, o código que escrevemos ganha vida própria.
    24. 24. O sistema está terminadoConstruir sistemas que durem Conceber sistemas com pontos de extensibilidade que permitam a evolução da plataforma sem ter que alterar significativamente o código base Manter o desenho simples e baseado em interfaces ou protocolos.
    25. 25. ManutençãoExiste um só administrador “…e ele nunca nos abandonará, nunca adoecerá, nunca terá férias, ou será atropelado por um autocarro” Acreditem ou não, mesmo os administradores que vivem e respiram os sistemas, gostam de estar longe do computador de vez em quando “Mas nós controlamos ambas as pontas” Por agora, talvez, mas o que é que acontece se a tua aplicação tiver um grande sucesso? Ou se a tua empresa compra um concorrente? Ou for comprada? Ou faz uma parceria?
    26. 26. Existe um só administradorTornar o sistema facilmente gerível Em qualquer altura, qualquer administrador de sistema relativamente competente deve ser capaz de usar ferramentas e serviços para instalar, monitorizar, e diagnosticar o sistema Usar as capacidades de gestão do SO e ferramentas standard de monitorização Desenvolver funcionalidades de gestão e administração não contempladas inicialmente (ex: adicionar/remover utilizadores, auditing, etc.) em vez de obrigar o admin a actualizar directamente na BD.
    27. 27. ManutençãoSó mais um IF “Então para fazermos isto não é só mais um IF? Isto não custa nada certo?” “Esparguetada” difícil de manter Aumento da complexidade
    28. 28. Só mais um IF“Não cair na tentação da martelada” Pode parecer a solução mais rápida, mas a médio prazo poder-se-á tornar num conhecimento perdido (“mas porque é que este IF está aqui?”) Refactorização de código
    29. 29. InteroperabilidadeO ambiente é homogéneo Em qualquer empresa existem sempre vários ambientes Ambientes legados Mac do departamento gráfico Aplicação Java da empresa que foi comprada Existe sempre um amanhã E as inevitáveis aquisições, fusões, parcerias, etc. Podes correr, mas não te podes esconder
    30. 30. O ambiente é homogéneoDesenvolver sistemas agnósticos àplataforma Na concepção do sistema, nunca assumir que do outro lado estará uma plataforma “X” Utilizar standards nas fronteiras do sistema Quando tivermos que interoperar, fazê-lo remotamente e nas fronteiras do sistema
    31. 31. Mas.....Em jeito de conclusão A parte complicada, é perceber quais as falácias que se aplicam ao seu caso em particular Não existem dogmas O que foi aqui dito deve ser lido com um espírito crítico Pesar bem os pratos da balança, e fazer uma análise custo-beneficio
    32. 32. Perguntas e Respostas?
    33. 33. RecursosThe Eight Fallacies of Distributed Computinghttp://today.java.net/jag/Fallacies.htmlBlog Ted Newardhttp://blogs.tedneward.comFallacies of Enterprise Computinghttp://blogs.tedneward.com/content/binary/FallaciesOfEnterpriseCompWeb Services Interoperability Organizationhttp://www.ws-i.org/
    34. 34. Pergunte Aos EspecialistasObtenha as Respostas às suas QuestõesEstarei na área Pergunte Aos Especialistas,no Pavilhão 5 :Quinta 10 Novembro 12:30 – 13:00
    35. 35. Participe Noutras Sessões ARC01 -Padrões para Arquitecturas Orientadas a Serviços (SOA) WEB04 - Hacked!!! Como são atacadas as aplicações Web, e como devemos usar a .NET Framework para as proteger ARC04 - Domain Specific Language (DSL) Tools para Desenvolvimento Model-Driven no Microsoft Visual Studio 2005
    36. 36. Recursos Úteis MSDN Portugal http://www.microsoft.com/portugal/msdn Noticias Comunidades Centro de Arquitectura MSDN Flash Subscrições MSDN http://msdn.microsoft.com/subscriptions
    37. 37. Recursos Úteis Recursos para Comunidades Microsoft http://www.microsoft.com/portugal/technet/comunidades Subscrições TechNet http://www.microsoft.com/portugal/technet/subscricoes Certificações http://www.microsoft.com/portugal/technet/certificacoes IT’s Showtime Webcasts http://www.microsoft.com/portugal/technet/itshowtime
    38. 38. Microsoft®TechDays 2005 Aprender, Partilhar, ExperimentarNão se Esqueça de Preencher oQuestionário de Avaliação!ARC03As Falácias e os Desenganos noDesenvolvimento de Software
    39. 39. Passatempo Bónus Extra no TechDays 2005!! Habilite-se a ganhar uma Xbox 360 e um i-mate JAM 128 por dia!Complete o questionário de avaliação e devolva-o no final do dia à saída no balcão da recepção.
    40. 40. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

    ×