As melhores práticas de codificação devem sempre ser usadas [fechado]

Ao codificar software, a arquitetura deve sempre ser boas práticas ou práticas práticas em relação ao aplicativo que está sendo construído?

Se estou construindo um aplicativo Web de duas páginas que pode durar 5 anos e ter 2 aprimoramentos nesses 5 anos, devo codificar injeção de dependência, padrões de design, controlador de exibição de modelo com modelos de exibição etc.

As melhores práticas de codificação devem sempre ser usadas

Sempre? Não, isso é bobagem.

As melhores práticas são diretrizes. Para a maioria das pessoas, para a maioria das situações, se implementadas com alguma delicadeza, elas produzirão os melhores resultados. Eles são onde você começa quando pensa em soluções. Mas haverá lugares onde as melhores práticas podem e devem ser ignoradas, porque existem soluções melhores.

O problema é que os humanos não podem ver o futuro. E os iniciantes (e muitos não iniciantes) pensam inevitavelmente que estão naquele cenário especial em que as regras não se aplicam a eles. Em caso de dúvida, use as melhores práticas. Anos de debate e experiência em toneladas de engenheiros mais inteligentes do que você ou eu descobrimos que eles produzem resultados consistentemente bons. Mas nenhum deles (ou quase nenhum) conhece o seu problema específico tão bem quanto você. Ocasionalmente, você encontrará casos excepcionais em que as regras podem ser alteradas.

Sim. Isso é evidente. Por que você não faria o que é melhor?

Esse não é o problema. A parte mais difícil é descobrir qual é a melhor prática, porque, para responder a isso, você precisa saber exatamente quais requisitos você tem e como o projeto provavelmente evoluirá ao longo dos anos, e isso é extremamente difícil.

No entanto, uma boa regra geral: nunca é uma prática recomendada usar os nomes de vários padrões de design e apenas juntá-los sem pensar.

Fora isso, sua pergunta realmente não pode ser respondida. Descobrir exatamente o que é "melhor prática" para uma determinada situação é o que é ser um engenheiro de software. Você precisará reduzi-lo para obter melhores respostas.

A melhor prática é a que cumpre com mais eficiência os requisitos funcionais e não funcionais do seu software para recursos, manutenção, desempenho etc. Se essa prática estiver alinhada com algum "padrão do setor", isso é incrível. Mas, se não, o pragmatismo vence.

Onde trabalho atualmente, estamos criando uma nova interface da web para nosso produto do zero. Não será RESTful de forma alguma; Ele usa o POST exclusivamente. Não é multicamada, não usa microsserviços e não usa um banco de dados NoSQL. Não possui nenhum tipo de arquitetura como o Enterprise Java.

Em outras palavras, não é nada moderno.

Mas ele incorpora uma estrutura HTML5 de ponta que inclui ligação de dados do tipo Angular, escalonamento automático para diferentes tipos de dispositivos, como dispositivos móveis e computadores, integração com a interface do usuário Kendo da Telerik para fazer todo o trabalho pesado e uma criptografia e segurança totalmente criptografadas. canal de dados.

O melhor de tudo é que será feito em 30 dias, um feito que levaria um exército de desenvolvedores Java em uma arquitetura Enterprise por ano para ser alcançado. O código é ES6 / Typecript; é um dos códigos mais limpos que eu já vi.

Não . As melhores práticas são coisas que geralmente são consideradas a melhor coisa a fazer 99% do tempo, mas isso não significa que elas sempre se apliquem a todas as situações.

Como desenvolvedor, seu trabalho é conhecer e usar essas práticas recomendadas, mas também saber quando é seguro deixá-las de lado.

Isso não deveria ser autopromoção, mas recentemente escrevi uma postagem de blog relacionada ao meu trabalho na plataforma Salesforce.com que detalhava uma dessas ocasiões . Uma das regras de ouro é "Nunca faça uma consulta dentro de um loop", mas recentemente, pela primeira vez em sete anos trabalhando na plataforma, eu tinha um motivo perfeitamente válido para não obedecer a essa regra.

A essência é que a plataforma tem limites para o número de consultas que você pode executar em um determinado contexto de execução, mas nesse caso eu tive que consultar dentro de um loop para evitar ficar sem espaço de heap e sabia que estaria bem dentro da consulta limite.

Portanto, é raro, mas há momentos em que as melhores práticas não são relevantes para um cenário; portanto, se elas não se encaixam, não as force.

Suponho que por "melhores práticas" você quer dizer uma lista de regras que alguém escreveu em um livro. Pois é claro que se você quer dizer a frase literalmente, é claro que sempre deve escrever o melhor código possível.

Preciso salientar que não existe um conjunto único e universalmente aceito de "melhores práticas"? Para qualquer regra promovida por um especialista, quase sempre é possível encontrar outro especialista com credenciais iguais que diga algo diferente.

Mas, ao ponto: resposta curta: geralmente, mas nem sempre.

Cada campo tem suas "melhores práticas" e "soluções de livros didáticos". Elas representam a experiência acumulada e a sabedoria de muitas, muitas pessoas ao longo de muitos e muitos anos, e não devem ser ignoradas. MAS! Sempre existem circunstâncias especiais, casos marginais, etc. A pessoa verdadeiramente capaz em qualquer campo sabe quando seguir as regras e quando quebrá-las.

Eu diria em geral: Comece seguindo as regras do livro. Ao seguir as regras do livro didático leva a problemas - complexidade desnecessária, desempenho ruim, o que for -, considere se quebrar essa regra dessa vez pode não ser uma idéia melhor.

Se você ignorar as regras e for onde quer que seu capricho o leve, seu código provavelmente será uma bagunça. Não importa o quão inteligente você seja, você não é o primeiro programador do mundo. Faz sentido aprender com a experiência dos outros. Em nossa vida cotidiana, é por isso que temos pais, professores e pregadores: assim, não precisamos repetir todos os erros estúpidos para descobrir que é um erro estúpido de cometer.

Mas se você seguir uma lista de regras servilmente em algum livro 100% do tempo, frequentemente se encontrará martelando uma estaca quadrada em um buraco redondo. As pessoas que escreveram o livro de regras podem não ter se deparado com um caso como o seu. E mesmo que tenham, se é raro o suficiente, eles podem ter ignorado. Uma regra que funciona 80% do tempo é uma regra excelente - desde que você entenda que funciona 80% do tempo e não 100% do tempo.

Eu escrevi um livro sobre design de banco de dados que inclui muitas regras que eu aconselho os designers de banco de dados a seguir. (Abster-me-ei de dar o título para não parecer descaradamente insolente na autopromoção.) Certamente, incentivo qualquer pessoa que queira criar um banco de dados a ler um livro como o meu e aprender tudo o que puder com ele. . Mas é claro que há momentos em que você deve violar as regras que listo.

Certa vez, escrevi um documento sobre padrões de programação para uma equipe de desenvolvedores que liderava na época. E a última regra foi mais ou menos assim: "Se você tem um bom motivo para violar uma das regras acima, vá em frente, MAS você deve incluir um comentário em seu código explicando por que você quebrou a regra. Se você não pode vir por um bom motivo, siga a regra. Se escrever o comentário é mais problemático do que seguir a regra, siga a regra. " Tivemos apenas algumas vezes que alguém achou que infringir uma regra vale a pena ter que explicar o porquê.

Pelas práticas recomendadas , suponho que você queira dizer "regras informais que a comunidade de desenvolvimento de software aprendeu ao longo do tempo, o que pode ajudar a melhorar a qualidade do software" e não algum tipo de melhor maneira literal de executar uma tarefa específica.

Sim, até que você tenha um motivo para não fazê-lo. Deve ser uma boa razão para você ter considerado seriamente e aplicado as circunstâncias e limitações da tarefa em questão. Isso significa que você entende completamente a prática e é capaz de aplicá-la. Não vamos entrar nessa noção de que, se você não entende, não deve ser o melhor tipo de pensamento. Veja a definição.

Você nem sempre fará o que é melhor. Quando o chefe diz para você: "Envie esse pedaço de lixo ou você está demitido!" Você o enviará e provavelmente procurará outro emprego, mas ainda o enviará. Às vezes, você se vê fazendo algo que é bom o suficiente. Claro, você não quer criar um hábito disso, mas às vezes precisa fazer os vagões rolarem e não pode se preocupar com os cavalos que são cegos.

Algumas coisas são importantes, outras não.

Você deve adaptar sua escolha de idioma e estilo ao problema em questão.

Por exemplo, uma "Melhor Prática" para o tratamento de exceções pode ser sempre capturar exceções e registrá-las, mas ao criar um teste de unidade, a melhor prática é geralmente deixá-los jogar fora, para que a estrutura de teste de unidade possa relatá-las corretamente.

Por outro lado, considere a regra "SECA". Buscar o código que não se repete é sempre bom, não apenas pelas razões óbvias, mas também porque quanto mais você codifica dessa maneira, melhor se torna um codificador - é uma ótima maneira de flexibilizar suas habilidades de codificação / pensamento em vez de suas habilidades de digitar e copiar / colar, e a longo prazo, geralmente você se sentirá melhor revisitando seu código (mesmo quando você esperava que fosse um código descartável) se seguisse algumas regras sensatas.

Em resumo, seja flexível, mas não codifique apenas o lixo ilegível, porque você acha que é um código descartável.

Vou tentar ver de uma perspectiva diferente.

As estruturas modernas de hoje tornam muito fácil a configuração de um projeto básico com mvc, injeção de dependência, arquitetura em camadas, etc. Eu diria que comece com uma base gerada e use as ferramentas fornecidas, até encontrar algo que exija uma solução artesanal. Em seguida, você pode cortar os cantos dessas práticas recomendadas.

Não é mais difícil usar algo como o Spring Boot para aplicativo da web de 2 páginas e depois rolar seus próprios servlets, consultas jdbc e outras coisas.

Na minha experiência, há apenas uma prática recomendada que considero obrigatória:

Mantenha as coisas simples, estúpidas (KISS)

Em outras palavras: Quaisquer que sejam as ferramentas, APIs, arquiteturas etc. que você escolher - se você simplificar, é mais fácil trabalhar no futuro, ter menos bugs, ser rápido, ter memória eficiente e tudo o mais que desejar.

Todas essas outras coisas sobre as quais as pessoas falam: princípios, padrões, práticas etc. - considero um palete de ferramentas que posso escolher, selecionando aquelas que melhor se adaptam ao projeto em que estou trabalhando. Todos eles fornecem técnicas e idéias para resolver problemas. O truque é descobrir se você tem esses problemas em primeiro lugar.

As melhores "Práticas recomendadas" sempre contêm uma seção que você deve usar sua inteligência e experiência para identificar quando os itens do manual são inadequados. Eles também podem conter uma seção sobre revisar, aprovar e documentar essas exceções e torná-las parte das "melhores práticas".

Ao codificar software, a arquitetura deve sempre ser boas práticas ou práticas práticas em relação ao aplicativo que está sendo construído?

Em teoria, sim.

No mundo real, [ainda] sim, desde que você possa se dar ao luxo de fazê-lo.

O que, é claro, significa "Não".

As pressões de tempo e dinheiro sempre tentarão empurrá-lo para o caminho de uma solução "rápida e suja", porque fornece um valor "melhor" ao cliente. Como isso é implementado não interessa ao cliente ou a seus contadores. Se você pode fazer um trabalho [ruim] em dois dias ou perfeitamente em três meses, o que você acha que eles vão pedir?

A diferença entre as duas melhores práticas e o que você precisa "se safar" - é chamada de "Dívida técnica"; é perfeitamente aceitável, desde que você planeje "retribuir", ou seja, voltar e melhorar as coisas mais tarde. Novamente, não é algo para o qual você sempre (sempre?) Obtenha o orçamento.

Uma tática é lançar uma versão beta inicial com a correção "rápida", mas garantir que as melhorias arquitetônicas necessárias sejam priorizadas antes da versão "completa". Novamente, não é algo que você sempre (sempre?) Faz.