Se dermos a você meia história para continuá-la, como você faria isso? Como você continuaria e adicionaria seu enredo lá?

Em primeiro lugar, você precisa entender a história completa, você irá pesquisar por todos os personagens, seu papel em diferentes capítulos ou parte da história, quais personagens você precisa levar até o final ou qual deles tem o papel apenas por alguns capítulos, você também precisa entender como diferentes partes da história estão conectadas para contar a você o que exatamente está acontecendo na história.

Programar é como contar uma história para um colega programador, onde variáveis ​​são personagens em sua história, algumas desempenham seu papel até o final e outras terminam no meio, diferentes funções contam diferentes partes de sua história e conectam todas as classes ou funções em um pedido específico pode apenas completar a história. Para continuar a escrever a história, você quer tudo em uma ordem específica para que possa entender a história facilmente e continuar adicionando suas falas de onde foi deixada.
Não importa o quão bom codificador você seja, em programação, seu trabalho não é apenas escrever código que funcione e fornecer a saída desejada, mas também escrever um código que seja sustentável, extensível e fácil de entender para que mais tarde quem dá continuidade ou mantém seu projeto possa entendê-lo e não precise passar por uma história de terror que lhe dá um pesadelo.

Sempre codifique como se o cara que acaba mantendo seu código fosse um psicopata violento que sabe onde você mora.
-Martin Golding

Aprender alguns princípios de programação e usá-los em seu código o torna um desenvolvedor melhor. Ele melhora a qualidade do código e, posteriormente, adicionar outras funcionalidades ou fazer alterações nele se torna mais fácil para todos. Vamos discutir alguns princípios básicos de programação e os benefícios de usá-los.

7 princípios de programação comuns

1. KISS: Ninguém na programação adora depurar, manter ou fazer alterações em códigos complexos. “ Keep It Simple, Stupid (KISS) “ afirma que a maioria dos sistemas funcionam melhor se forem mantidos simples em vez de torná-los complexos, portanto, quando você está escrevendo o código, sua solução não deve ser complicada, o que exige muito tempo e esforço para ser entendido. Se o seu código for simples, outros desenvolvedores não terão nenhum problema em entender a lógica do código e podem facilmente prosseguir com o seu código. Portanto, sempre tente simplificar seu código usando abordagens diferentes, como dividir um problema complexo em partes menores ou retirar algum código desnecessário que você escreveu.

O objetivo da engenharia de software é reduzir a complexidade, não criá-la.
-Pamela Zave

2. DRY: A duplicação de dados, lógica ou função no código não apenas torna seu código extenso, mas também perde muito tempo quando se trata de manter, depurar ou modificar o código. Se você precisar fazer uma pequena alteração em seu código, precisará fazê-lo em vários lugares. O objetivo principal do “Don't Repeat Yourself (DRY)” é reduzir a repetição de código. Ele afirma que um trecho de código deve ser implementado em apenas um lugar no código-fonte. O oposto do princípio DRY é WET (“escreva tudo duas vezes” ou “desperdice o tempo de todo mundo”) que quebra o princípio DRY se você estiver escrevendo a mesma lógica em vários lugares. Você pode criar uma função comum ou abstrair seu código para evitar a repetição em seu código.

3. YAGNI: Seu software ou programa pode se tornar maior e complexo se você estiver escrevendo algum código de que possa precisar no futuro, mas não no momento. “Você não vai precisar disso (YAGNI)”O princípio afirma que “não implemente algo até que seja necessário” porque na maioria dos casos você não usará aquele trecho de código no futuro. A maioria dos programadores, enquanto implementa o software, pensa na possibilidade futura e adiciona algum código ou lógica para alguns outros recursos que eles não precisam no momento. Eles adicionam todas as classes e funcionalidades desnecessárias que talvez nunca usem no futuro. Fazer isso é completamente errado e você acabará escrevendo um código inchado e seu projeto se tornará complicado e difícil de manter. Recomendamos a todos os programadores para evitar este erro para economizar muito tempo e esforço.

4. SOLID: O princípio SOLID representa cinco princípios que são Responsabilidade única, Aberto-fechado, Substituição de Liskov, Segregação de interface e Inversão de dependência. Esses princípios são fornecidos por Robert C. Martin e você pode verificar esses Princípios SÓLIDOS em detalhes.

5. Separação de preocupações (SoC): Separação de preocupações O princípio particiona uma aplicação complicada em diferentes seções ou domínios. Cada seção ou domínio aborda uma preocupação separada ou tem um trabalho específico. Cada seção é independente uma da outra e é por isso que cada seção pode ser abordada de forma independente também se torna mais fácil manter, atualizar e reutilizar o código.
Por exemplo, a lógica de negócios (o conteúdo da página da web) em um aplicativo é uma preocupação diferente e a interface do usuário é uma preocupação diferente em um programa de aplicativo da web. Um dos bons exemplos de SoC é o padrão MVC onde os dados ("modelo"), a lógica ("controlador") e o que o usuário final vê ("visualização") são divididos em três seções diferentes e cada parte é tratada de forma independente . Salvar dados em um banco de dados não tem nada a ver com renderizar os dados na web.

6. Evite Otimização Prematura: Otimização realmente ajuda a acelerar o programa ou algoritmo, mas de acordo com este princípio, você não precisa otimizar seu algoritmo em um estágio inicial de desenvolvimento. Se você fizer uma otimização prematura, não será capaz de saber onde estarão os gargalos de um programa e a manutenção se tornará mais difícil para você. Se você otimizar seu código no início e se o requisito mudar, então seus esforços serão perdidos e seu código irá para o lixo. Portanto, é melhor otimizar o algoritmo no momento certo para obter o benefício certo dele.

A otimização prematura é a raiz de todos os males da programação.
–Donald Knuth

7. Lei de Demeter: Este princípio foi introduzido pela primeira vez por Ian Holland em 1987 na Northeastern University. É também conhecido como o princípio do mínimo conhecimento . Este princípio divide a responsabilidade entre classes ou unidades diferentes e pode ser resumido em três pontos.

• Cada unidade deve ter apenas um conhecimento limitado sobre outras unidades: apenas unidades “intimamente” relacionadas com a unidade atual.
• Cada unidade deve conversar apenas com seus amigos; não fale com estranhos.
• Fale apenas com seus amigos imediatos.

A Lei de Demeter ajuda a manter classes independentes e torna seu código menos acoplado, o que é muito importante no desenvolvimento de software para tornar sua aplicação flexível, estável, fácil de manter e compreensível.