Você deve ou não adaptar o seu estilo de codificação para atender ao domínio de negócio no qual você está trabalhando? A ideia é que domínios de negócios diferentes vão exigir coisas diferentes do seu software em termos de estilo de codificação. Por exemplo, o software escrito para o mercado de defesa deve ser robusto como uma pedra, enquanto o software escrito para um mercado que passa por constantes alterações legislativas, como a tributação, deve ser escrito para ser fácil de manuter, e na publicidade, onde os projetos e software têm uma vida útil curta, então o software deve ser escrito para ser reutilizável.
Embora eu nunca tenha visto isso aplicado a domínios de negócios antes, a ideia de priorizar características-chave no seu estilo de codificação não é nova. A vi pela primeira vez em um livro escrito por Steve Maguire, publicado pela Microsoft Press, em 1997, e chamado “Debugging the Devlopement Proces“.
Nesse livro, Steve discute a ideia de estabelecer uma ordem de classificação para as prioridades ao escrever o seu software. Ele enumera as prioridades dele e te convida a ordenar a lista de acordo com suas prioridades. A lista original dele contém o seguinte:
- Tamanho
- Velocidade
- Robustez
- Segurança
- Testabilidade
- Fácil manutenção
- Simplicidade
- Capacidade de reutilização
- Portabilidade
Agora, falando em software, 1997 foi há muito tempo, os estilos mudaram e as linguagens foram desenvolvidas. 1997 foi o ano em que os drives de CD-RW e a mídia foram introduzidas, a memória era dispendiosa, os processadores eram lentos e a linguagem escolhida era C/C++.
Permitir a passagem do tempo, esse fato que nós, programadores Java, não costumamos considerar o tamanho ou a velocidade e que o Java é portável, então a lista pode ser cortada um pouco:
- Segurança
- Testabilidade
- Tobustez
- Fácil manutenção
- Simplicidade
- Capacidade de reutilização
A próxima coisa a perguntar é se essa lista ainda é aplicável hoje, assim, falando de um item de cada vez…
Segurança
Na listagem “Segurança”, Steve estava realmente pensando em paradigmas de programação e algoritmos. Algumas técnicas são mais seguras do que outras; por exemplo, usar uma tabela look-up para retornar um valor é uma abordagem mais segura do que usar uma abordagem de orientação lógica que calcula o valor para você. Essa ideia ainda parece ser uma consideração de projeto válida.
Testabilidade e robustez
Para mim, estes dois itens pertencem um ao outro. Um código bem testado é, por definição, mais robusto. Se você estiver usando Test Driven Development (TDD), então você pode também cruzar esses itens fora da lista, pois eles ele estão enraizados em seu processo. Se você faz parte do grande grupo de programadores que não usam TDD – e existem muitos por aí que não o fazem – então esses itens devem permanecer…
Capacidade de manutenção
Eu acho que isso faz alusão ao estilo do seu código, à clareza do seu pensamento e como você pode se expressar. Em termos de estilo, eu geralmente uso o estilo descrito no Clean Code, que é um dos meus livros favoritos. O estilo do autor, Robert Com. Martin, é… limpo. Os métodos e as classes são curtos, eles obedecem a SRP e estão corretamente definidos. Esse ainda é um atributo-chave de um bom software.
Simplicidade
Você deveria tentar escrever código simples? A resposta é definitivamente “sim”, o que não significa que você deve escrever código simplista, apenas o código mais simples possível para fazer o trabalho sem quaisquer enfeites ou recursos que possam ser necessários em uma versão futura. A ideia de escrever o código mais simples possível foi levada a sério pela Comunidade Agile, de fato Shane Warden e James Shore, em seu livro “The Art of Agile Development” dedica um capítulo inteiro à ideia, o que inclui conceitos tais como “apenas uma única vez “e” você não vai precisar dele”.
Capacidade de reutilização
O código reutilizável é uma ideia muito boa e continua relevante hoje em dia, como sempre foi.
Em resumo
Eu acho que, para resumir, você tem que concordar que as coisas mudaram desde 1997, mas parece-me que as boas ideias ainda prevalecem, porém elas são expressas de formas diferentes…
Ao pegar a minha cópia empoeirada de “Debugging the Devlopement Proces” na minha estante de livros para me lembrar da lista de prioridades do autor de codificação, eu também examinei outros capítulos e seções. Ele abrange muitos tópicos sobre gerenciamento de projetos que destacam os erros que as empresas e as pessoas muitas vezes cometiam. O triste disso é que, 15 anos depois, as empresas e as pessoas ainda estão cometendo os mesmos erros…
***
Texto original de Roger Hughes, disponível em http://www.captaindebug.com/2012/03/ranking-order-for-coding-priorities.html
