BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

O Manifesto do Pronto

| por Shane Hastie Seguir 11 Seguidores , traduzido por Felipe Torres Seguir 0 Seguidores em 23 mar 2010. Tempo estimado de leitura: 3 minutos |

Para melhorar a experiência das pessoas que acessam o InfoQ Brasil, nós criamos uma série de funcionalidades que te permitem ficar pode dentro das últimas tendências e das novidades de seu interesse, sem que você seja incomodado por coisas irrelevantes. Receba e-mails periódicos e notificações sobre seus tópicos favoritos!

Alixx Skevington postou um Manifesto do Pronto como o começo de uma discussão, falando sobre os compromissos que os membros do time tem  sobre os outros em relação à qualidade do seu trabalho e claramente expressando suas obrigações para entregar valor de negócio através do código.

Sua lista dos critérios de Pronto contém:

  • Eu terei certeza de que meu código é usável. Meu código é para uso e interação com outras pessoas, e tudo que eu escrevo deve fazer disso uma experiência prazerosa, e reduzir a carga de trabalho ao invés de aumentá-la.
  • Eu escreverei código que esteja de acordo com o estilo adotado pelo time. Outras pessoas, além de mim, deverão ser capazes de manter e alterar meu código. Então eu devo ser flexível para projetar e utilizar qualquer tecnologia para criar minha solução. Optando pelo padrão, eu escrevo código que permite que outros mantenham-no.
  • Eu concordo em manter meus métodos em um tamanho razoável. Métodos muito grandes tornam dificeis a navegação e debug. Sempre que possível eu manterei meus métodos num tamanho razoável para diminuir essa complexidade.
  • Eu comentarei todo código. Sempre que eu criar um código novo ou alterar algum já existente, eu farei comentários curtos e sucintos para explicar o que eu fiz. Então assim que outros virem esse código depois de mim entenderão o que eu fiz e qual o seu objetivo.
  • Eu concordo em testar unitariamente meu código. Eu concordo em fazer esses testes reutilizáveis e não frágeis. Eu farei o teste explicar o que se está testando e qual o motivo. Então além dos outros poderem rodar meus testes quando meu código for refatorado ou corrigido, poderão também ver o que o meu código tenta fazer.
  • Eu concordo em manter os testes unitários para o código. Quando eu alterar ou adicionar novas features ao código, terei certeza de que todos os testes passam e que haverá novos, para toda feature.
  • Eu concordo em tentar manter a cobertura do meu código em, ao menos, 80%. Verificando a cobertura do meu código, estarei certo de que tudo o que eu escrevi tem valor. Que náo haverá surpresas no meu código que poderiam causar problemas futuramente.
  • Eu concordo em verificar que meu código se integra corretamente. Quando eu terminar de escrever meu código, trabalharei com os outros desenvolvedores para ter certeza de que meu código funciona bem com todas as outras partes e que desempenha corretamente a função desejada.

O post gerou um número de comentários no LinkedIn com sugestões para outros itens serem adicionados à lista, como:

Eu adicionaria um "eu rodarei novamente os testes unitários antes do check-in". O motivo pelo qual eu sugeri isso é aparentemente independentemente do código de um lugar poder quebrar testes e/ou código em outro lugar. Isso aconteceu várias vezes no meu último trabalho. (David Kramer)
Re: de fato eu alteraria para "eu escreverei testes unitários antes de escrever o código", porque eu sou um grande entusiasta do TDD. Outra coisa a dizer sobre testes: eles são código de produção, trate-os como tal. (Scott Ames)

Scott Mcphee discorda do item sobre comentário de código:

sobre o comentário de código, eu não posso dizer que discordo mais. Comentários frequentemente mentem, ou apenas mostram coisas óbvias (ex: /* atribui y a x */ x=y), e sempre adiciona bagagem extra que será mantida na linha com o código atual. Um código bem escrito e bem projetado não precisa de "comentários sucintos para explicar o que foi feito" - é óbvio, ao se ler o código, o que ele faz; e o os commits e controle de versão apenas iluminam o "porquê" algo foi feito. Documentação da API é algo diferente, mas isso geralmente é dirigido aos usuários dos métodos públicos, não aos leitores de código, e faz parte dos artefatos lançados.

Jay Packlick adicionou um ponto considerado o mais crucial:

A definição mais importante de feito está implícita, mas merece uma atenção explícita e eu a colocarei no topo da lista: * "Todos os critérios de aceitação definem 'feito' para uma função são expressos em testes e passar."

E você leitor, quais mudanças você faria nessa lista?

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT