N\u00e3o importa como voc\u00ea olhe, em termos gerais, os desenvolvedores de software de aplicativos de neg\u00f3cios t\u00eam uma m\u00e1 reputa\u00e7\u00e3o. Os sistemas s\u00e3o quase inevitavelmente entregues com atraso ou at\u00e9 mesmo n\u00e3o s\u00e3o entregues. O usu\u00e1rio m\u00e9dio de uma empresa m\u00e9dia passa literalmente horas todas as semanas reclamando dos sistemas de computador que \u00e9 for\u00e7ado a suportar. \u201cPor que isso foi feito?\u201d, \u201cO que diabos isso significa?\u201d s\u00e3o algumas das coisas que ou\u00e7o diariamente. <\/p>\n\n\n\n\n\n\n\n
\n\t\tPassei anos escrevendo sistemas de neg\u00f3cios, na maioria dos casos os usu\u00e1rios eram positivos sobre o que estavam obtendo e usando. Sistemas escritos de acordo com uma especifica\u00e7\u00e3o inicial, testados at\u00e9 o fim e depois adaptados como e quando necess\u00e1rio, a um custo acordado, se necess\u00e1rio. Suporte cont\u00ednuo ao cliente e receita sustentada para a empresa de software foi uma combina\u00e7\u00e3o vencedora. A especifica\u00e7\u00e3o inicial baseada em uma an\u00e1lise detalhada de requisitos seria sempre uma vis\u00e3o geral funcional e n\u00e3o conteria nenhuma especifica\u00e7\u00e3o de c\u00f3digo. Acho que usei pseudoc\u00f3digo uma vez (quando estava escrevendo jogos). \u201c\u00c9 isso que precisamos fazer\u201d, geralmente era bom o suficiente para mim. Fora isso, foram alguns modelos de interface de usu\u00e1rio e muito design de banco de dados e pronto. A fase de testes e ajustes do ciclo de vida de desenvolvimento foi muito importante. Os sistemas geralmente foram entregues no prazo e funcionaram.\n\t\t<\/p>\n\n\n\n
\n\t\tHoje em dia (nunca pensei que diria isso), tudo relacionado a sistemas \u00e9 uma quest\u00e3o de planejamento, mais planejamento e depois reutiliza\u00e7\u00e3o. O que me parece t\u00e3o estranho \u00e9 que grande parte desse planejamento n\u00e3o visa atender a um requisito funcional, mas sim detalhar como e por que escreveremos o que escrevemos quando o escrevemos. Espero que isso fa\u00e7a sentido? Por que escrever algo em 10 linhas que voc\u00ea poderia fazer em 1000, na hip\u00f3tese de \u201cpoder\u201d precisar reutiliz\u00e1-lo 2 anos depois? A n\u00edvel pessoal, nunca escrevi nada que n\u00e3o pudesse reescrever melhor dois anos depois. Estou sempre aprendendo e melhorando, quando olho para o c\u00f3digo com 12 meses de idade, muitas vezes me encolho. Olhando an\u00fancios de emprego \u00e9 f\u00e1cil perder-se nas metodologias e compet\u00eancias que s\u00e3o solicitadas. Ser\u00e1 humanamente poss\u00edvel que uma pessoa saiba tanto que muitas vezes me pergunto? Outra quest\u00e3o \u00e9: eles alguma vez produzem um produto? Com todo esse planejamento e preocupa\u00e7\u00e3o com a reutiliza\u00e7\u00e3o de c\u00f3digo, alguma coisa \u00e9 feita? Conhe\u00e7o uma empresa que contratou desenvolvedores acad\u00eamicos que estavam t\u00e3o ocupados concentrando-se no design que a empresa faliu antes que qualquer produto estivesse quase pronto, s\u00e9rio! Quantos atrasos podemos esperar que as pessoas tolerem, a fase de testes nunca foi um problema l\u00e1! Por que a empresa que nos paga por um produto deveria pagar pelo c\u00f3digo que ser\u00e1 usado repetidamente em projetos posteriores, e n\u00e3o por eles?\n\t\t<\/p>\n\n\n\n
\n\t\tN\u00e3o me interpretem mal, n\u00e3o estou dizendo que o planejamento seja ruim, \u00e9 uma parte essencial do desenvolvimento de sistemas, mas n\u00e3o \u00e9 a \u00fanica. Talvez eu seja da velha escola, mas a parte que gosto \u00e9 escrever o sistema e faz\u00ea-lo funcionar. Ok, eu sei que os sistemas est\u00e3o ficando cada vez maiores e mais complexos. Grandes equipes de desenvolvedores s\u00e3o a norma. \u00c9 que eu acho que por mais que voc\u00ea planeje, visualize e fa\u00e7a um brainstorming algo sempre vai faltar. Estamos nos esfor\u00e7ando para alcan\u00e7ar sistemas imposs\u00edveis e perfeitos, mas, nos piores casos, n\u00e3o estamos entregando nenhum sistema. N\u00e3o acredite em mim? Veja a Microsoft. Imagine as horas de trabalho gastas no planejamento de qualquer uma de suas aplica\u00e7\u00f5es? Com que frequ\u00eancia um novo bug ou vulnerabilidade \u00e9 descoberto? Por que eles n\u00e3o foram discutidos na fase de design? Nunca passou pela cabe\u00e7a da equipe de desenvolvimento que a \u201cvulnerabilidade X\u201d pudesse ocorrer. Simplificando, com qualquer coisa al\u00e9m do mais b\u00e1sico dos sistemas, \u00e9 quase imposs\u00edvel planejar todas as eventualidades, n\u00e3o importa qu\u00e3o l\u00f3gico voc\u00ea seja. Por que eles n\u00e3o s\u00e3o encontrados durante os testes? A solu\u00e7\u00e3o aqui \u00e9 o desenvolvimento da velha escola, menos tempo planejando (conversando), mais tempo escrevendo e testando? Menos tempo se preocupando em reutilizar o c\u00f3digo e mais tempo fornecendo ao cliente um produto funcional? A Microsoft seria melhor ou pior se gastasse menos tempo planejando e mais tempo testando? Em defesa da Microsoft, eles s\u00e3o muito bons em patches, suponho que eles poderiam ser vistos como n\u00f3s como testadores. Talvez se eles passassem mais tempo fazendo testes adequados, n\u00e3o precisar\u00edamos test\u00e1-los?\n\t\t<\/p>\n\n\n\n
\n\t\tO pior exemplo de planejamento excessivo que ainda n\u00e3o encontrei \u00e9 um sistema financeiro que uso diariamente. A implementa\u00e7\u00e3o deste sistema custou milh\u00f5es de d\u00f3lares, anos de planejamento e sabe-se l\u00e1 quantos consultores. Foi escrito por um dos maiores players da ind\u00fastria de software, adaptado por uma consultoria especializada em software. O resultado final disso \u00e9 um sistema que \u00e9 praticamente inutiliz\u00e1vel e n\u00e3o est\u00e1 muito longe de ser substitu\u00eddo por um produto de prateleira. \u00c9 t\u00e3o ruim no n\u00edvel mais baixo que mesmo um clique errado do mouse travar\u00e1 o aplicativo. N\u00e3o posso acreditar que este sistema tenha sido testado antes de ser entregue. A entrega demorou muito para ser entregue, devido ao \u201cciclo de planejamento\u201d mais longo do que o esperado. O que faz n\u00e3o \u00e9 assim t\u00e3o complexo, apenas foi obviamente planeado ao ponto de a implementa\u00e7\u00e3o ter sido pensada \u00e0s pressas. Todo esse planejamento nem sequer resultou em um sistema que atendesse aos requisitos funcionais b\u00e1sicos de seus usu\u00e1rios, mas, heh, tenho certeza de que eles reutilizar\u00e3o esse c\u00f3digo em algum momento no futuro.\n\t\t<\/p>\n\n\n\n
\n\t\tDe qualquer forma, acabei de come\u00e7ar um diploma para me ajudar a entender por que \u00e9 t\u00e3o importante usar diversas estrat\u00e9gias de planejamento diferentes. Por que escrever em 1 dia o que eu poderia passar um m\u00eas fazendo \u201ccorretamente\u201d? Eu sei que vou ler isso daqui a alguns anos e me pergunto o que estava pensando; ou isso ou direi para mim mesmo \u201cnossa, foi quando eu realmente terminei o que estava escrevendo\u201d. S\u00e9rio, tenho certeza que no final perceberei onde estou errando, enquanto isso continuarei escrevendo aplicativos usando meu estilo RAD (ainda bem que ele tem um nome!) que embora n\u00e3o seja do gosto de todos, funciona muito bem para mim. \n\t\t
<\/p>\n\n\n\n