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

2. Microsoft®
TechDays 2005
Aprender, Partilhar, Experimentar
ARC03
As Falácias e os Desenganos no
Desenvolvimento 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

3. Patrocinadores

4. Falácia
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.

5. 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

6. Processo Desenvolvimento
Processo 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.

7. Processo define-se mais tarde
Definir 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

8. 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,…)

9. “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...)

10. 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

11. “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

12. Segurança
A 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

13. “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.

14. Desempenho
Nã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.

15. “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.

16. Desempenho
Largura 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  )

17. “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.

18. Desempenho
Custo 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

19. 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

20. Manutenção
Topologia é 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.

21. Topologia é imutável
Utilizar 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.

22. Manutenção
O 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.

23. Sistema é monolítico
Definir 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.

24. Manutenção
O 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.

25. O sistema está terminado
Construir 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.

26. Manutenção
Existe 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?

27. Existe um só administrador
Tornar 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.

28. Manutenção
Só 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

29. 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

30. Interoperabilidade
O 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

31. O ambiente é homogéneo
Desenvolver 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

32. 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

33. Perguntas e Respostas?

34. Recursos
The Eight Fallacies of Distributed Computing
http://today.java.net/jag/Fallacies.html
Blog Ted Neward
http://blogs.tedneward.com
Fallacies of Enterprise Computing
http://blogs.tedneward.com/content/binary/FallaciesOfEnterpriseComp
Web Services Interoperability Organization
http://www.ws-i.org/

35. Pergunte Aos Especialistas
Obtenha as Respostas às suas Questões
Estarei na área Pergunte Aos Especialistas,
no Pavilhão 5 :
Quinta 10 Novembro 12:30 – 13:00

36. 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

37. 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

38. 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

39. Microsoft®
TechDays 2005
Aprender, Partilhar, Experimentar
Não se Esqueça de Preencher o
Questionário de Avaliação!
ARC03
As Falácias e os Desenganos no
Desenvolvimento de Software

40. 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.

41. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.