Um bom programador precisa ser capaz de combinar suas habilidades com o bom senso. É tudo uma questão de pragmatismo e a habilidade de escolher a melhor solução para o seu problema. Quando você se depara com um problema no desenvolvimento de software, pode usar os princípios básicos para ajudá-lo a escolher a abordagem certa.
Este texto fornece um conjunto de princípios que qualquer desenvolvedor deve conhecer e que deve ser atualizado periodicamente. Considere-os sua arma secreta de programação.
Aplicar esses princípios de maneira consistente tornará mais fácil sua transição do nível intermediário para o sênior. Você pode descobrir que alguns (provavelmente) você usa intuitivamente.
Existem muitos princípios. Vamos nos concentrar nos sete mais importantes. Usá-los ajudará você a crescer e se tornar um programador melhor.
1. YAGNI
Você não vai precisar deleEste princípio é simples e óbvio, mas nem todo mundo o segue. Se você estiver escrevendo código, certifique-se de que precisará dele. Não escreva código se você acha que será útil mais tarde.
Este princípio se aplica à refatoração. Se você estiver refatorando um método, classe ou arquivo, não tenha medo de remover métodos desnecessários. Mesmo que fossem úteis antes, agora não são mais necessários.
Pode chegar o dia em que eles serão necessários novamente - então você pode usar o repositório git para ressuscitá-los dos mortos.
2. SECO
Não se repitaEsse conceito foi articulado pela primeira vez no livro de Andy Hunt e Dave Thomas, The Pragmatic Programmer: The Journey from Apprentice to Master.
A ideia gira em torno de uma única fonte de verdade (SSOT). Afinal, o que é isso?
No projeto e na teoria de sistemas de informação, a Fonte Única da Verdade (SSOT) é a prática de estruturar modelos de informação e esquemas de dados, o que implica que todas as peças de dados são processadas (ou editadas) em apenas um lugar ... SSOTs fornecem dados confiáveis, dados relevantes e utilizáveis.
- Wikipedia
O uso do SSOT criará uma base de código mais robusta e compreensível.
A duplicação de código é uma perda de tempo e recursos. Você terá que manter a mesma lógica e testar o código em dois locais ao mesmo tempo e, se alterar o código em um local, precisará alterá-lo em outro.
Na maioria dos casos, a duplicação de código ocorre devido à ignorância do sistema. Antes de escrever qualquer coisa, seja pragmático: dê uma olhada. Talvez esta função esteja implementada em algum lugar. Talvez essa lógica de negócios exista em outro lugar. A reutilização de código é sempre uma decisão inteligente.
3. BEIJAR
Keep It Simple, StupidEste princípio foi desenvolvido pela Marinha dos Estados Unidos em 1960. Este princípio afirma que sistemas simples terão um desempenho melhor e mais confiável.
Esse princípio tem muito em comum com a reinvenção da roda, que foi feita na década de 1970. Em seguida, soou como uma metáfora de negócios e publicidade.
Com relação ao desenvolvimento de software, significa o seguinte - não crie uma solução mais complexa para o problema do que o necessário.
Às vezes, a decisão mais inteligente acaba sendo a mais simples. Escrever código simples, eficiente e eficiente é ótimo.
Um dos erros mais comuns de nosso tempo é usar novas ferramentas apenas porque brilham. Os desenvolvedores devem ser motivados a usar a tecnologia mais recente, não porque seja nova, mas porque é a certa para o trabalho.
4. Grande Design na Frente
Global Design FirstEsta abordagem para o desenvolvimento de software é muito importante e muitas vezes esquecida. Certifique-se de que tudo está bem pensado antes de prosseguir para a implementação.
… . , . , . , BDUF, , . , .
—
Muitos desenvolvedores acreditam que, se não escreverem código, não estão progredindo. Esta é a abordagem errada. Ao fazer um plano, você evita o trabalho de começar do zero continuamente.
Às vezes, outras pessoas precisam estar envolvidas nas falhas e processos de desenvolvimento da arquitetura. Quanto antes você discutir tudo isso, melhor será para todos.
Um contra-argumento muito comum é que o custo da solução de problemas costuma ser menor do que o custo do tempo de planejamento. Quanto menos erros o usuário encontrar, melhor será a experiência. Você pode não ter outra chance de lidar com esses erros.
5. SÓLIDO
Este é o princípio mais conhecido de desenvolvimento de software. Sólido é uma abreviatura de:
S) Princípio de responsabilidade única
Sua importância não pode ser subestimada. Cada objeto, classe e método deve ser responsável por apenas uma coisa. Se o seu objeto / classe / método fizer muito, você acabará com um código espaguete. Aqui está um exemplo:
const saveTodo = async () => {
try {
response = await saveTodoApi();
showSuccessPop('Success');
window.location.href = '/successPage';
} catch (error) {
showErrorPopup(`Error: ${error} `);
}
}
Este método parece inofensivo, mas na verdade faz muito:
- Salva o objeto
- Lida com notificações na IU
- Executa navegação
Outro efeito colateral desse código são os problemas de teste. Funcionalidades complicadas são difíceis de testar.
O) Princípio aberto - fechado
Os objetos do programa devem ser abertos para extensão, mas fechados para modificação. O ponto é que você não pode substituir métodos ou classes, simplesmente adicionando funções adicionais conforme necessário.
Uma boa maneira de lidar com esse problema é usando herança. JavaScript resolve esse problema com composição.
Uma regra prática simples: se você alterar uma entidade para torná-la extensível, estará quebrando esse princípio pela primeira vez.
L) Princípio de substituição de Liskov
Este princípio estabelece que objetos de classes superiores devem ser substituídos por objetos de subclasses, e o aplicativo deve funcionar conforme o esperado quando tais substituições forem feitas.
I) Princípio de segregação de interface
Este princípio foi formulado por Robert Martin quando ele estava consultando a Xerox, e é óbvio.
Objetos não devem depender de interfaces que não usam
O software deve ser dividido em partes independentes. Os efeitos colaterais devem ser minimizados para garantir a independência.
Certifique-se de não forçar os objetos a implementar métodos de que nunca precisam. Aqui está um exemplo:
interface Animal {
eat: () => void;
walk: () => void;
fly: () => void;
swim: () => void;
}
Nem todos os animais podem voar, andar ou nadar, portanto, esses métodos não devem fazer parte da interface ou devem ser opcionais.
D) Princípio de inversão de dependência
Este princípio não pode ser superenfatizado. Devemos confiar em abstrações, não em implementações concretas. Os componentes de software devem ter baixa coesão e alta consistência.
Você não precisa se preocupar em como algo funciona, mas em como funciona. Um exemplo simples é usar datas em JavaScript. Você pode escrever sua própria camada de abstração para eles. Então, se você alterar a fonte de obtenção de datas, precisará fazer alterações em um lugar, não em mil.
Às vezes, é preciso esforço para adicionar essa camada de abstração, mas compensa no final.
Dê uma olhada em date-io como exemplo , esta biblioteca tem uma camada de abstração que permite que você a use com diferentes fontes de data.
6. Evite a otimização prematura
Evite a otimização prematuraEsta prática incentiva os desenvolvedores a otimizar seu código antes que a otimização seja comprovadamente necessária. Acho que se você seguir o KISS ou o YAGNI, não cairá nesse gancho.
Faça certo, é bom antecipar que algo ruim vai acontecer. Mas antes de mergulhar nos detalhes da implementação, certifique-se de que essas otimizações sejam realmente úteis.
Um exemplo muito simples é o dimensionamento. Você não comprará 40 servidores presumindo que seu novo aplicativo se tornará muito popular. Você adicionará servidores conforme necessário.
A otimização prematura pode levar a atrasos no código e, portanto, aumentar o tempo necessário para trazer as funções para o mercado.
Muitos consideram a otimização prematura a raiz de todos os males.
7. Navalha de Occam
Brithva Okkama (às vezes Lezvie Okkama) é um princípio metodológico que afirma resumidamente: “Você não deve multiplicar coisas desnecessariamente” [1] (ou “Você não deve atrair novas entidades a menos que seja absolutamente necessário”).
- Wikipedia
O que isso significa no mundo da programação? Não crie entidades desnecessárias desnecessariamente. Seja pragmático - considere se eles são necessários, pois podem complicar sua base de código.
Conclusão
Esses princípios não são muito difíceis. Na verdade, é a simplicidade que os torna bonitos. Se você está confuso, não tente aplicá-los todos de uma vez. Apenas tente trabalhar com consciência e tente incorporar gradualmente esses princípios em seu fluxo de trabalho.
Usar princípios básicos, porém poderosos, permitirá que você se torne um programador melhor e tenha uma compreensão mais clara de por que está fazendo algo.
Se você está aplicando a maioria dos princípios intuitivamente, vale a pena pensar e entender por que está fazendo algo de determinada maneira.
Tudo de bom.
- O primeiro sistema de controle serial da Rússia para um motor bicombustível com separação funcional de controladores
- Em um carro moderno, existem mais linhas de código do que ...
- - Automotive, Aerospace, (50+)
- McKinsey: automotive
