Posts Tagged "design"
Ignore os Detalhes de Antemão
Lendo o livro Rework de Jason Fried e David Heinemeier Hansson, a famosa dupla da 37 signals, me deparei com um tópico que tenho visto ser abordado na comunidade ágil há algum tempo e estou cada vez mais certo de que se aplica não somente a software mas a qualquer tipo de negócio: Ignore os Detalhes de Antemão.
por chrisjohnbeckett
Isso não quer dizer que os detalhes não fazem diferença. Sim, fazem. Porém, você deve ser preocupar com eles apenas pouco antes de precisar implementá-los de alguma forma. No início de seus projetos ignore-os. Simplesmente decida sobre eles depois. Preocupe-se em fazer o básico primeiro. Lembre-se, você não precisa manter suas decisões para sempre, pode mudá-las no meio no caminho. Mantenha o equilibrio entre rigidez e flexibilidade, os dois extremos são prejudiciais.
Essa mesma linha de pensamento explica porque métodos extremamente prescritivos e burocráticos geralmente não levam a bons resultados. Levantar requisitos com muita antecedência e nível exagerado de detalhes, é um exemplo de engano desse tipo, como sabemos, requisitos mudam, o cliente não sabe bem o quer desde o inicio, e o software deve ser flexível e capaz de evoluir em conformidade com as necessidades de negócio do cliente. Essa abordagem precipitada de levantamento de requisitos é chamada de BRUP (Big Requirements Up Front).
Outro grande erro é o famoso Big Design Up Front (BDUF) em que se tenta criar todo o design de um software antes de sua implementação, novamente a falta de flexibilidade em abordagens como essa geralmente levará qualquer projeto ao completo fracasso.
Em Lean Software development qualquer coisa que termine com Up Front pode ser vista como desperdício. E desperdício é algo que deve ser eliminado porque não agrega valor algum.
Você prática BRUP ou BDUF em sua organização? Tem bons resultados com abordagens assim? Qual é a sua opnião a respeito? Deixe um comentário.
Software Craftsmanship com Uncle Bob Martin
O pessoal da Software Engineering Podcast acabou de publicar a entrevista de Markus Völter com o consagrado Robert C. Martin, também conhecido como Uncle Bob Martin autor diversos livros como Clean Code e evangelista do movimento Software Craftsmanship. Recomendo que todos ouçam ao podcast (em inglês) na integra, mas gostaria de enfatizar alguns pontos importantes.
Sobre o Arquiteto de Software
Foto por Anirudh Koul
Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no “mundo que constroem para os outros”, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ”não tem que dormir na cama que faz”.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experienciar o que o time está fazendo para saber o que ele realmente precisa.
Documentação
O código é documentação mais imporante. Todos os outros documentos devem refletir o que o código faz. O código digire todos o resto e não é apenas resultado de outros documentos como sugure o waterfall.
Software Crafsmanship
O termo foi criado com a publicação do livro de Pete McBreen em 2002. Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas você deve aprender com outras pessoas ajudando-as a fazerem seu trabalho.
- Você deve sentir orgulho da forma que você trabalho.
- Sinta orgulho de poder fazer Test Driven Development.
- Sinta orgulho de ter alta cobertura de código.
- Sinta orgulho de desenvolver software de alta qualidade.
- Sinta orgulho de ter um bom design de código.
- Sinta orgulho de desenvolver software que realmente agregue valor de negócio aos clientes.
Uncle Bob sugere como práticas TDD, Integração Contínua e Programação em par, e afirma que bons times trabalham em par na maior parte do tempo, no entanto, afirma que não se deve ser religioso quanto a isso, “você não precisa trabalhar em par 100% do tempo”, diz.
Qualidade e Relacionamento com Clientes
Não basta funcionar, o software deve ser bem escrito e fácil de manter. Foque em agregar valor. Deve haver um parceira com os clientes. Você deve realmente envolver-se com as decisões tomadas e garantir que o que cliente pede realmente vai agregar valor para ele. Não faça simplesmente porque é seu trabalho se você já sabe que não vai dar certo. Comprometa-se com o resultado do seu trabalho.
Produtividade
Aprenda os Shortkeys (atalhos de teclado). Tente fazer o máximo que você puder sem usar o mouse. Um desenvolvedor de software deve estar altamente integrado com seu ambiente.
Utilize uma boa ferramenta de SCM (Source Code Control), o CVS é razoável, o SVN é melhorzinho, mas meu favorito é o Git.
Bug Tracking Systems são importantes, mas use com certo cuidado. Devem ser leves e simples de usar.
Use ferramentas para teste como jUnit (xUnit), rSpec, Cucumber, JBehave e Fit.
Linguagens dinamicas são muito produtivas e se você faz TDD o “perigo” vai embora. Você não precisa mais de um compilador para te dar uma falsa segurança.
Desenvolvimento de Carreira
A coisa mais importante para um desenvolvedor de software é noção de aprendizado contínuo. Você nunca pode parar de aprender. É como um médico.
Você deve aprender o máximo de linguagens que puder, e deve conseguir escrever código em todas essas linguagens ainda que não seja um especialista em todas elas. Não adianta. Aprenda no mínimo uma linguagem estática, uma dinâmica e uma funcional. Robert diz que todos devem aprender LISP.
Recado de Uncle Bob no Rails Conf 2009
Uncle Bob Martin na RailsConf 2009 porFabio Akita no Vimeo
Mais Informações sobre Robert C. Martin
jQuery: Poder e Simplicidade
No início deste ano conheci o jQuery e desde então não escrevo mais JavaScript sem ele. Gostaria de apresentar um pouco dessa biblioteca, e citar algumas boas razões para que você se aprofunde mais a respeito e pense em utilizá-lo.
O que é jQuery?
jQuery é uma biblioteca JavaScript rápida e concisa que simplifica percorrer documentos HTML, manipular eventos, criar animações e interações Ajax para um desenvolvimento web rápido. O jQuery foi desenvolvido para mudar a forma com que você escreve JavaScript [1].
Porque eu deveria utilizá-lo?
Simplicidade e Baixa Verbosidade
Quando bem usado o jQuery pode ajudá-lo a tornar seu web-site ou aplicação mais interativo, interessante e excitante, além disso, é simples de entender e fácil de utilizar, o que significa que a curva de aprendizado é pequena, enquanto as possibilidades são (quase) infinitas. [2].
Refactoring: Como eu perdi o medo do código velho
Este post é a tradução de um trecho do post “Dr. Strangecode, or How I Learned to Stop Worrying and Love Old Code” do Chris Boran, em ele que conta como foi descobrir a maravilha que é refatorar!
Alguns anos atrás, eu estava em minha livraria predileta quando vi o livro “Refactoring: Improving the Design of Existing Code” do Martin Fowler. Este livro mudou a minha carreira. Até então, eu tinha muito medo de mudanças. Eu enxergava o código antigo como um castelo de cartas – se não fosse extremamente cuidadoso, tudo poderia desmoronar. Sempre que meu chefe me pedia uma opinião sobre determinada área de código, minhas respostas eram mais ou menos assim:
O risco de fazer qualquer mudança, por menor que seja, é enorme – então, ou fazemos alguma gambiarra e nos arrependemos mais tarde, ou reimplementamos tudo.
Tudo bem, nós podemos conviver com a gambiarra por enquanto, e mais pra frente nós vamos arrumar um tempo pra fazer isso da forma certa.
Evidentemente, a cada release, nós eramos forçados a fazer varias decisões como essas. Quando a próxima release viesse, teriamos como prioridade corrigir código que já estaria em produção. Na prática poderíamos ter sorte e de gastar um montão de tempo reescrevendo um único e pequeno subsistema, mas introduzir pequenas gambiarras, poderiam comprometer outros sistemas. O resultado final é carinhosamente referido como uma “Grande Bola de Lama (Big Ball of Mud)”. Isso mesmo! É tão agradável como parecer ser. A vida pode ser bem miserável quando você sabe que está trabalhando todos os dias apenas alimentando a bola de lama (com + e + gambiarras). Você não gosta disso! Sua equipe não gosta disso! O seu chefe não gosta disso! Mas por algum motivo, você sente que as coisas nunca estam progredindo.
Eu pensava que o código velho precisava ser jogado fora e não re-vitalizado, mas eu queria ver se esse negócio de refectoring funcionava mesmo, então resolvi tentar. Fui bastante cuidadoso para seguir as técnicas exatamente como estavam descritas no livro. Assegurei que não estava usando a palavra refatorar quando eu queria dizer apenas re-escrever. Eu fui cuidadoso para refatorar o código toda a vez que eu queria mudar alguma coisa no código e não apenas procrastinar para mais tarde. Eu me assegurei de que os meus refactorings eram pequenos. E assim fui fazendo…
Obviamente esta forma de trabalhar também exigiu que eu fizesse testes unitários muito bons, mas eu já sabia alguma coisa sobre Test Driven Development e já tinha escrito testes unitários antes de corrigir bugs em uma tentativa de prevenir regressões. Rodar esses testes depois de cada refactroing não foi um desafio tão grande assim pra mim. Pouco a pouco eu fui descobrindo a verdade: Aplicando técnicas de refactoring, eu poderia pegar trechos de código que pensava precisar reescrever completamente e melhorá-los enquanto resolvia bugs. Eu podia matar dois coelhos numa tacada só.
