• Compartilhar
  • ?
  • Perfis ▼
  • Comunidades ▼
  • Aplicativos ▼

Blogs

  • Meus Blogs
  • Blogs Públicos
  • Minhas Atualizações

Essa comunidade pode ter membros de fora da organização. iMasters

  • Efetue login para participar
fd26864d-cb41-49cf-b719-d89c6b072893 Blog

▼ Marcações

▼ Entradas Semelhantes

How to Identify Clas...

Blog: Application I...
MicheleCalcavecchia 270000HCF1
Atualizado
0 pessoas curtiram istoCurtir 0
Sem ComentáriosComentários 0

How to ensure that a...

Blog: CSE-Sterling ...
Paul Barrie 270003JP87
Atualizado
0 pessoas curtiram istoCurtir 0
Sem ComentáriosComentários 0

z/TPF rules engine d...

Blog: TPF Blog
Chris Filachek 270007S5UM
Atualizado
0 pessoas curtiram istoCurtir 0
Sem ComentáriosComentários 0

Updates to z/TPF sup...

Blog: TPF Blog
lemie 060000M2N6
Atualizado
3 pessoas curtiram istoCurtir 3
Sem ComentáriosComentários 0

IBM ITSM Netcool Ope...

Blog: Network and S...
Murali-Pa 270002P65C
Atualizado
3 pessoas curtiram istoCurtir 3
Sem ComentáriosComentários 0

▼ Archive

  • janeiro de 2014
  • agosto de 2013
  • julho de 2013
  • maio de 2013
  • abril de 2013
  • março de 2013
  • fevereiro de 2013
  • janeiro de 2013
  • dezembro de 2012
  • novembro de 2012
  • outubro de 2012
  • setembro de 2012
  • agosto de 2012
  • julho de 2012
  • junho de 2012
  • maio de 2012
  • abril de 2012
  • março de 2012
  • fevereiro de 2012
  • janeiro de 2012
  • dezembro de 2011
  • novembro de 2011
  • outubro de 2011
  • setembro de 2011
  • agosto de 2011
  • julho de 2011
  • junho de 2011
  • maio de 2011
  • abril de 2011
  • março de 2011
  • fevereiro de 2011
  • janeiro de 2011
  • dezembro de 2010
  • novembro de 2010
  • outubro de 2010
  • setembro de 2010
  • agosto de 2010
  • julho de 2010
  • abril de 2010

▼ Autores do Blog

iMasters

Visualizar Todas as Entradas
Clicar no botão faz uma atualização completa da página. O usuário pode acessar a região "Lista de Entrada" para visualizar o novo conteúdo.) Lista de Entrada

A ordem de classificação para as prioridades de codificação

iMasters 27000343BF | | Marcações:  desenvolvimento java ‎ | 3.998 Visualizações

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

  • Incluir um Comentário Incluir um Comentário
  • Editar
  • Mais Ações v
  • Colocar esta Entrada em Quarentena
Notificar Outras Pessoas
notification_ex

Enviar Notificação por Email

Colocar esta entrada em quarentena

deleteEntry
duplicateEntry

Marcar como Duplicata

  • Entrada Anterior
  • Principal
  • Próxima Entrada
Feed para Entradas de Blog | Feed para Comentários de Blog | Feed para Comentários desta Entrada