Use seu próprio juízo na aplicação dessas práticas e conselhos.
O segredo para construir grandes aplicações é nunca construir aplicações grandes. Quebre suas aplicações em pequenas peças. Então, monte essas peças de maneira testável, como pequenos módulos em uma grande aplicação.
– Justin Meyer, autor de JavaScript MVC
Quando eu ouço "Um código que apenas chute pro gol, rode e funcione" eu penso em todos os aplicativos que eu não uso mais porque eles foram gradualmente perdendo a capacidade de iteração.
– Avdi Grimm
Não escreva código (só escreva código novo quando tudo mais que existe estiver falhando) é a mais importante lição que todo desenvolvedor deveria aprender. A quantidade de duplicidade, de código mal feito por aí, atualmente é enorme. Em muitos caso, os desenvolvedores não se incomodam em olhar ao redor [para usar o que é bom]. Eles apenas querem escrever código.
"Eu odeio código, e eu quero o menos possível em nosso projeto" – Jack Diederich
O velho ditado "não reinvente a roda" não se aplica quando a roda vem acoplada a um motor de locomotiva.
É importante lembrar que quando você inicial algo a partir do zero não há absolutamente nenhuma razão para acreditar que você fará um trabalho melhor do que fez pela primeira vez. Em primeiro lugar, você provavelmente ainda tem a mesma equipe de programação que trabalhou na versão inicial, então na verdade vocês não tem necessariamente "mais experiência". Você só vai fazer a maioria dos antigos erros novamente, e introduzir alguns novos problemas que não estavam na versão original.
– Joel Spolsky
A assinatura que diz "isso deveria ser uma classe" existe quando a classe tem dois métodos, e um deles é o constructor. Se a qualquer hora você ver esses sinais, você provavelmente deveria ter escrito apenas uma função.
– Jack Diederich
O problema: é muito fácil perder de vista o que os usuários se importam com mais frequência, isto é, a performance e a usabilidade da aplicação e das funcionalidades que eles já usam cotidianamente.
– Tim Anderson
Inventar suas próprias rodas dá a você um profundo saber e entendimento sobre como as rodas funcionam e o que as faz boas.
- Simples é melhor do que complexo.
- Complexo é melhor que complicado.
- Plano é melhor que aninhado.
- Legibilidade conta.
- Se a implementação é dificil de explicar, é uma ideia ruim.
- Se a implementação é fácil de explicar, pode ser uma boa ideia.
– The Zen of Python
Pequena lista extraída da Palestra "Pare de Escrever Classes" por Jack Diederich
Se você está mudando mais de 25% de uma classe ou método, considere simplesmente rescrevê-lo. Você irá escrever o código mais claramente.
- O código é uma porcaria
- "Nós estamos melhores agora"
- Nós escolhemos a plataforma/linguagem errada
- Sempre demora mais do que você imagina
- Os mercados mudam
- Clientes já existentes ficam frustrados
- Refatoração pode limpar o código
- Você não controla a reescrita, ela controla você
A chave é reconhecer desde o início que você não tem idéia de como isso irá crescer. Quando você aceita que você não sabe tudo, você começa a projetar o sistema defensivamente ... Você deveria gastar a maior parte do seu tempo pensando sobre interfaces em vez de implementações.
– Nicholas Zakas, autor de "Alta performance em websites Javascripts"
Cada programador sabe que deve escrever testes para o seu código. Poucos fazem. A resposta universal para "Por que não?" é "Eu não tenho tempo." Isto rapidamente cria um ciclo vicioso: quanto mais mais pressão você sente, menos testes que você escreve. Com os poucos testes que você escreve, menos produtivo você fica e menos estável o seu código se torna. E quanto menos produtivo e preciso você for, maior a pressão que você sente. Programadores ficam esgotados com esses ciclos.
Quebrar esse ciclo vicioso requer uma influencia externa. É possível encontrar a influência externa que precisávamos em um simples framework de testes que nos ajuda fazendo pequenos testes que fazem uma grande diferença.
[Sem testes unitários] Você não está refatorando, você está apenas mexendo na merda. — Hamlet D'Arcy
- Nova palavra chave em um construtor ou em um campo declarado
- Método estático chama algo em um construtor ou em uma declaração de campo
- Qualquer coisa além de um campo declarado em um construtor
- Objeto não totalmente inicializado após a conclusão do construtor (observer a inicialização dos métodos)
- Controle de fluxo (condicional ou looping) em um construtor
- Código fazendo a construção de um objeto gráfico dentro de um construtor ao invés de usar um método Factory
- Adição ou uso de um bloco de inicialização
- Objects are passed in but never used directly (only used to get access to other objects)
- Law of Demeter violation: method call chain walks an object graph with more than one dot (.)
- Suspicious names: context, environment, principal, container, or manager
- Adding or using singletons
- Adding or using static fields or static methods
- Adding or using static initialization blocks
- Adding or using registries
- Adding or using service locators
- Summing up what the class does includes the word “and”
- Class would be challenging for new team members to read and quickly “get it”
- Class has fields that are only used in some methods
- Class has static methods that only operate on parameters
Even if you aren't testing your code, you should write testable code. IoC enables testable code. Inject test-friendly dependencies or mocks at test time, to isolate the unit-under-test.
"Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. ... A little debt speeds development so long as it is paid back promptly with a rewrite ... Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation ...” (Emphasis mine)
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
It is much cheaper to do it correctly the first time than to redo it later on. The sooner a problem is identified and fixed, the cheaper it is to do so.
"The general who wins a battle makes many calculations in his temple before the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to win or lose."
For this to work, everyone involved has to listen, everyone has to be open, everyone has to be responsive. Or we could keep flailing away with the fucked up attitude that “it has to be this way” because the sacred project plan says it’s this way. Because that really is a lot of fun, isn’t it?
... a team of mediocre, inexperienced coders who work together and write for the benefit of the team has the capability to become a great team, and they can take that learning approach to create other great teams. It all comes down to whether the team sees its work as simply writing code... or writing with the goal of both code and learning" (Emphasis mine)
– Reginald Braithwaite
When the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information.
Software can only partially be designed in advance. ... requirements suffer from observation, that the act of building software causes the requirements to change. ...technical factors cannot be perfectly understood, that only the act of trying to build something with specific components will reveal all of the gotchas and who-knews associated with a chosen technology strategy. ...software design is an iterative process, starting with a best guess that is continually refined with experience. the normal case for software projects is that tasks are rarely completed exactly as estimated, but that as a project progresses, the aggregate variance from estimates falls.
Nobody likes to look stupid. If you’re a professional and someone puts you on the spot to answer “how long will this take?” it’s only human to want to provide an answer. Whether you call it professional pride or ego, it’s a powerful driver. Good IT workers really don’t like saying “I don’t know.” If they say it, they probably mean it. So stop pushing for a definitive answer when one doesn’t exist.It’s perfectly reasonable to want some sort of plan up front. I’m actually one of those funny types who believe up front planning is a necessity. So long as everyone understands an estimate is just that: an estimate. You learn as you go along and discover more detail. So you revise the estimate accordingly.
– Joe Armstrong, author Erlang
##Your architecture should resemble your domain
So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: health care system, or accounting system, or inventory management system? Or do they scream: rails, or spring/hibernate, or asp?
Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.
– Uncle Bob Martin, "Screaming Architecture"
- Do not add new functionality unless you know of some real application that will require it.
- It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
- The only thing worse than generalizing from one example is generalizing from no examples at all.
- If a problem is not completely understood, it is probably best to provide no solution at all.
- If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also Worse is better.)
- Isolate complexity as much as possible.
- Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface" - Doug McIlroy, quoted in A Quarter Century of Unix [Salus]. Addison-Wesley. 1994. ISBN 0-201-54777-5.
- Rule of Modularity: Write simple parts connected by clean interfaces.
- Rule of Clarity: Clarity is better than cleverness.
- Rule of Composition: Design programs to be connected to other programs.
- Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
- Rule of Simplicity: Design for simplicity; add complexity only where you must.
- Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
- Rule of Transparency: Design for visibility to make inspection and debugging easier.
- Rule of Robustness: Robustness is the child of transparency and simplicity.
- Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
- Rule of Least Surprise: In interface design, always do the least surprising thing.
- Rule of Silence: When a program has nothing surprising to say, it should say nothing.
- Rule of Repair: When you must fail, fail noisily and as soon as possible.
- Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
- Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
- Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
- Rule of Diversity: Distrust all claims for “one true way”.
- Rule of Extensibility: Design for the future, because it will be here sooner than you think.
– Eric S. Raymond, "A Arte da programação UNIX"
