Embed Size (px)
Citation preview
ARC03ARC03As Falácias e os Desenganos As Falácias e os Desenganos no Desenvolvimento de no Desenvolvimento de SoftwareSoftware(Partes desta apresentação baseadas numa sessão do Ted (Partes desta apresentação baseadas numa sessão do Ted Neward)Neward)
ARC03ARC03As Falácias e os Desenganos As Falácias e os Desenganos no Desenvolvimento de no Desenvolvimento de SoftwareSoftware(Partes desta apresentação baseadas numa sessão do Ted (Partes desta apresentação baseadas numa sessão do Ted Neward)Neward)
Tiago Pascoal Tiago Pascoal ([email protected])([email protected])
Bruno Câmara Bruno Câmara ([email protected])([email protected])
AgiliorAgilior
MicrosoftMicrosoft®®
TechDays 2005TechDays 2005Aprender, Partilhar, ExperimentarAprender, Partilhar, Experimentar
PatrocinadoresPatrocinadores
Todo 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.
Falácia
Falácias com implicações a nível deProcesso Desenvolvimento
Integridade
Fiabilidade/Robustez
Segurança
Desempenho
Manutenção (nível desenvolvimento e operação)
Interoperabilidade
Agenda
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.
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
Integridade e Fiabilidade”A rede é fiável”
O Hardware falhaRouters “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,…)
“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...)
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
“Alteraçõezinhas última hora”Evitar a tentação de funcionalidades nã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
SegurançaA Rede é Segura
“Programadores são competentes”Nem sempre ... Quantos é que sabem sobre segurança de redes?
Os dados remotos são confiáveisA origem dos pacotes TCP/IP pode ser forjada
Principal preocupação do IPv6
Sistemas remotos são confiáveisMesmo sendo confiáveis agora, qual a garantia que algures no futuro não serão comprometidos?
Nunca correrá fora da firewallPortáteis e PDA’s a viajar fora da rede
Redes wireless sem conhecimento departamento de redes
“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.
DesempenhoNão existe latência
Os 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.
“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.
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 )
“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.
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
Custo de transporte é zero Perceber 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
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.
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.
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.
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.
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.
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.
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?
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.
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
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
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
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
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
Perguntas e Respostas?Perguntas e Respostas?
Recursos
The Eight Fallacies of The Eight Fallacies of Distributed ComputingDistributed Computinghttp://today.java.net/jag/Fallacies.html
Blog Ted NewardBlog Ted Newardhttp://blogs.tedneward.com
Fallacies of Enterprise ComputingFallacies of Enterprise Computinghttp://blogs.tedneward.com/content/binary/FallaciesOfEnterpriseComputing.ppt
Web Services Interoperability OrganizationWeb Services Interoperability Organizationhttp://www.ws-i.org/
Pergunte Aos EspecialistasObtenha as Respostas às suas Questões
Estarei na área Pergunte Aos Especialistas,
no Pavilhão 5 :
Quinta 10 Novembro 12:30 – 13:00
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
Recursos Úteis
MSDN Portugalhttp://www.microsoft.com/portugal/msdn
Noticias
Comunidades
Centro de Arquitectura
MSDN Flash
Subscrições MSDNhttp://msdn.microsoft.com/subscriptions
Recursos Úteis
Recursos para Comunidades Microsofthttp://www.microsoft.com/portugal/technet/comunidades
Subscrições TechNethttp://www.microsoft.com/portugal/technet/subscricoes
Certificaçõeshttp://www.microsoft.com/portugal/technet/certificacoes
IT’s Showtime Webcastshttp://www.microsoft.com/portugal/technet/itshowtime
MicrosoftMicrosoft®®
TechDays 2005TechDays 2005Aprender, Partilhar, ExperimentarAprender, Partilhar, Experimentar
Não se Esqueça de Preencher Não se Esqueça de Preencher o Questionário de Avaliação!o Questionário de Avaliação!
ARC03ARC03As Falácias e os Desenganos As Falácias e os Desenganos no Desenvolvimento de no Desenvolvimento de SoftwareSoftware
Não se Esqueça de Preencher Não se Esqueça de Preencher o Questionário de Avaliação!o Questionário de Avaliação!
ARC03ARC03As Falácias e os Desenganos As Falácias e os Desenganos no Desenvolvimento de no Desenvolvimento de SoftwareSoftware
PassatempoPassatempo
Habilite-se a ganhar uma Habilite-se a ganhar uma Xbox 360Xbox 360 e e
um um i-mate JAM 128i-mate JAM 128 por dia! por dia!
Complete o questionário de avaliação e devolva-o no final do dia à saída no balcão da recepção.Complete o questionário de avaliação e devolva-o no final do dia à saída no balcão da recepção.
Bónus Extra no TechDays 2005!!Bónus Extra no TechDays 2005!!
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
