Como manter uma qualidade ruim codebase?

Question

Para ser capaz de manter o código que eu escrevo, eu o nome de variáveis bem, o documento do meu código, tenha certeza de que nada é repetido, que são abstrações de trabalho, de modo a que os hacks não são necessários..e o comentário com moderação, pois os comentários, muitas vezes me interromper a leitura do código.

Mas muitas outras antigo que eu tenho visto são mais como um turbilhão.Os nomes de variáveis são foobar, o material está ficando calculado, mesmo se nunca necessária, muitos hacks e patches são aplicados, abstrações falhar, implantação de scripts falhar...O código é uma incompreensível e quase inutilizável sopa.

Então!Estou curioso.Como é que você faz para manter a baixa qualidade codebase?

Answer 1

Disciplina

Answer 2

refactoring constante; quando você abre um arquivo de código e você vê algo estranho, você pode investir alguns minutos, a fim de melhorar o design do código existente.

Ter um conjunto de unidades-testes podem ajudá-lo com ele, que lhe dá a confiança de se o código que você está mudando ainda funciona ou quebra por causa de sua mudança.

É um pouco como a história de ter uma janela quebrada em uma casa. Quando você vê uma janela quebrada, você deve corrigi-lo. Se você não corrigi-lo, as coisas vão começar a deteriorar a partir daí, e que irá resultar em uma confusão unmaintenable.

A maioria dos meus projetos também são colocados onder ContinuousIntegration; ao lado de construir e executar UnitTests, uma análise de código estático (FxCop) é realizada também. De vez em quando, eu tenho um olhar para os resultados, e tentar corrigir algumas violações que estão sendo relatados.

Answer 3

Geralmente o que você descreve é ??a tendência natural de qualquer base de código para aumento de entropia. Isso acontece em todos os projetos pela virtude de ele ser desenvolvido e mantido. Para combater este aumento constante Gostaria de sugerir o seguinte:

1. Alguém na equipe com autoridade suficiente tem de cuidar. Esta é a parte mais importante. Se ninguém se importa, não será feito. Este ponto parece óbvio, mas não é.

2. Estabelecer padrões e melhores práticas. A maioria das línguas têm um livro escrito por alguém sobre as melhores práticas. Por exemplo, em PERL há uma muito boa Perl Best Practices livro de Damain Conway. A menos que você fizer isso, cada pessoa da equipe tem sua própria maneira de escrever código, variáveis ??nome, comentário e assim por diante.

3. revisões de código. Você vai precisar de uma lista de verificação para revisões de código. Não é o suficiente para que sua mudança funciona, tem que estar de acordo com a lista de melhores práticas também. Montamos uma duas revisões de código níveis, primeiro nível são pares revisões de código e segundo nível é um gerente de lançamento que se preocupa com a qualidade do código.

4. Projeto Comentários. Quando bug ou melhoria é preenchido no sistema de acompanhamento de bugs, é importante para que se revisado por um conselho de controle de mudanças, que decide sobre a programação do trabalho e também sobre quem precisa de rever a concepção do trabalho. Isto é onde você manter as abstrações de código e certifique-se a mudança que respeitar a projetar documentos e metas para o projeto. O arquiteto da equipe ou designer de chumbo software deve ser parte do CCB.

5. Checkin gatilhos de qualidade de código. Algumas das melhores práticas podem ser diretamente aplicadas pelo código. Escrever pequenos scripts que verificam seu código para coisas como formatação, uso de guias / espaços e tal. Isso ajudará você a pensar sobre a qualidade do código de uma maneira diferente.

Alguns lendo para uma referência.

Answer 4

As revisões pelos pares rapidamente estabelecer uma norma de qualidade código que é difícil de quantificar em um pedaço de papel. Os testes de unidade permitirá que você alterar o código com pouco medo. Disciplina, muita dela.

Answer 5

A questão relacionada:? Como as pessoas fugir com escrever código de má qualidade

Aqui está a resposta.

Uma boa estratégia para pessoas incompetentes em nossa indústria é o seguinte:

1. Desenvolver a capacidade de parecer impressionante, especialmente para as pessoas não-técnicas e semi-técnicos. Ser capaz de soar bastante plausível para o pessoal técnico, o suficiente para mantê-los fora de equilíbrio.

2. Faça uma bagunça completa do código que você tocar.

3. Agora, esta é a parte crucial: sair e encontrar um emprego melhor em outro lugar antes de você são encontrados fora. O melhor momento dependerá das circunstâncias particulares.

Answer 6

Eu gostaria de apresentá-lo a um termo que eu ouvi há alguns anos - Dívida Técnica . Aqui está um (1) Wikipedia entrada e outra de Martin Fowler de (2) web site .

Essencialmente, eu não acho que as pessoas começam com o objetivo de software de construção ruim. O que normalmente acontece é que os prazos são comprimidos, os requisitos são modificados ou substituídos meados de desenvolvimento e qualquer número de outras realidades comerciais morder no centro do desenvolvimento da qualidade e design.

De Fowler:

"fazer as coisas da maneira rápida e suja define-nos com uma dívida técnica, que é semelhante a uma dívida financeira. Como uma dívida financeira, a técnica dívida incorre juros, que vir na forma de um esforço extra que temos de fazer no futuro desenvolvimento por causa da rápida e projeto sujo escolha. "

De Wikipedia:

"Atividades que podem ser adiadas incluir testes de documentação, escrita, atendendo aos comentários TODO e combater compilador e de código estático avisos de análise. Outros casos de dívida técnica incluem o conhecimento de que não é compartilhado em torno da organização e código que é muito confusa para ser modificada facilmente ".

O que eu vi (e dirigiu várias equipes de desenvolvimento para fazer) é refatorar e limpar a base de código cedo em iterações de desenvolvimento, geralmente no início antes de novo trabalho é desenvolvido.

As revisões pelos pares, testes unitários e testadores de software profissional de toda a ajuda para pagar alguns dos que a dívida técnica, bem como uma boa previsão (e boa reutilização de código).

Se você tiver o orçamento, testes automatizados pode ser um bom investimento, enquanto você estiver disposto a pagar a manutenção (tempo, esforço).

Há uma abundância de ferramentas de qualidade em torno de hoje, como FxCop (e outros como ele), no entanto você tem que escolher com cuidado que se aproxima de você está indo para entreter.

Esforço na manutenção da qualidade no design e na base de código tem de ser explicada, então pense com cuidado sobre a maneira mais eficaz e útil para sua equipe de desenvolvimento / produto / empresa / clientes etc.

[(1) http://en.wikipedia.org/wiki/Technical_debt ]
[(2) http://martinfowler.com/bliki/TechnicalDebt.html ]

Answer 7

Este é apenas o caso quando tem de escrever o código e outros as pessoas a ler
1.A esquerda maus hábitos
2. Use significativa procedimento, função, nome da variável
3. Utilizar a documentação sobre como ele (procedimento/função/cálculo/etc) funciona e o que resultou que, não fazer qualquer comentário desnecessários
4.Tente dê estilo à sua codificação para que as pessoas possam conhece-lo (como o uso de GNU código de estilo)
ou
Use o código beautifier para que
5. Acho que para trabalhar como equipe (mesmo se você estivesse sozinho) e não é só você que vai ler o seu código (mesmo se foi)
6. Refatorar código deve ser tão bom assim
7. Consultar com seus companheiros de equipe sobre o código que você estava escrita, eles podem lê-lo?
8. Aprender comunidade OpenSource, como eles funcionam e o compartilhamento de códigos e patches
9.Se você puder, use SVN ou CVS para a manutenção do seu código

e lembre-se de BEIJO princípio (Keep Eut Simplementação, Stupid)

e é claro Simples, Leve, Médio E Bonito

se invertida (outras pessoas, escrever, ler) eu não sei o que disse :D (talvez dar o que as pessoas acima de conselhos LOL)

Answer 8

Documentação, de controlo de origem, unitários-testes, e ser um bom programador.

Answer 9

Um conjunto abrangente de testes de unidade que permite mudanças e refatoração sem se preocupar com quebrar o código existente.

Eu recomendo pegar uma cópia de Michael Pena de "trabalhar efetivamente com Legacy Code".

Answer 10

fridgemagnet dizer: "Os programadores maçantes têm bases de código imaculado"

Answer 11

Você só pode sair com a manutenção de uma base de código mal quando você é um muito pequena (menos de 10-20 pessoa ou então em um único projeto) equipe de desenvolvimento. Se o seu projeto cresce e sua equipe cresce, ou suas práticas irá escalar para cima ou você irá falhar.

A mudança que você está perguntando é essencialmente a transição de cortar a programação e, finalmente, Engenharia de Software.

Com Engenharia de Software você reconhecer que nem todos na equipe é perfeito. Você rever o código, você garante que os outros testes, você cruzar-verifique o outro.

Você começa a ver a necessidade de um arquiteto que podem digerir os desejos dos clientes e traduzi-los em um documento de design. Isso pode facilmente comer um mês de tempo antes que alguém sequer é adicionado ao projeto (mas ao longo do tempo de desenvolvimento pode economizar meses ou mesmo anos!). Ele garante que tudo faz sentido e se encaixam razoavelmente bem.

Você tem documentos de projeto, geralmente UML base para que diferentes partes da equipe pode entender pontos de integração. Você reconhece que tudo o que foi feito, você pode precisar de re-fazer sem as pessoas que fizeram isso, então você documentá-lo.

O seu processo de qualidade fica muito mais rigorosa e eles começam a impor regras como você só check-in alterações que os erros de endereços específicos durante o teste.

Os testes, refatoração, etc. são, obviamente, fundamental e são por pares e equipe de revisão imposta-re.

Não estou dizendo que este tipo de material é sempre necessário, obviamente, não é, mas na sua pergunta, você discutir bases de código intrincada, e essas boas práticas são muitas vezes a solução para esse problema.

Normalmente, estas boas práticas são implementadas depois que um projeto gigante que falhar completamente, porque a base de código é uma porcaria tão ruim. Em seguida, eles fogo qualquer um que não pode evitar a culpa, contratar alguns gestores que espero que tenham alguma experiência com projetos maiores e (se não ficar sem dinheiro) reiniciar do zero.

Pelo menos essa é a minha experiência. YMMV

Answer 12

Você prática só precisa, boas ferramentas e capacidade e vontade de quebrar maus hábitos e aprender.

Answer 13

Codificação é muito parecido com caligrafia. Todo mundo tem seu próprio estilo distinto. Um dos maiores desafios que enfrentei, mantendo o código legado, está tentando descobrir o que está acontecendo. Geralmente se trata de falta de consistência na base de código.