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 (tiago.pascoal@agilior.pt)(tiago.pascoal@agilior.pt)

Bruno Câmara Bruno Câmara (bruno.camara@agilior.pt)(bruno.camara@agilior.pt)

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.