código sentimental [fechado]

Question

Eu me deparei com um artigo que discute a questão da "admiração código". Basicamente, o autor fala sobre como os desenvolvedores devem ser mais cético sobre o código que eles escrevem. Como podemos "admirar" o nosso código muito, anexar a nossa auto-a ele, tornando-nos mais vulneráveis ??aos bugs e outros percalços que podem ser deitados em frente de nós.

Como você se sente sobre esta questão? E você tem mais dicas sobre como evitar / estar mais cientes desse problema?

Answer 1

Alguns anos atrás, eu estava trabalhando com outro em um pequeno projeto "hobby", e eu percebi que nós tivemos que reavaliar as coisas. Nós tinha escrito um monte de código mas não foi tudo de bom código.

Nós realmente não quer "jogar fora" todo o trabalho que tinha colocado em Mas eu percebi uma coisa:. O que mais importava era a quantidade de trabalho que seria necessário para colocar em a partir de agora .

Nós não poderia mudar o fato de que já tinha colocado tanto trabalho para o projeto, então a única maneira de minimizar o Total quantidade de trabalho que o projeto precisa, seria a de minimizar o quantidade de trabalho que ainda não tinha feito .

Desde aquele dia, eu parei de ser ligado ao meu código. Se eu estou confiante de que jogá-lo fora e começar do meio scratch menos trabalho do que mantê-lo e adaptá-lo às minhas necessidades, então eu vou jogá-lo fora.

Answer 2

O meu professor de arte do ensino médio usado para encorajar-nos a tomar o que nós consideramos ser os nossos melhores desenhos e rasgá-las; Ele chamou isso de "limpeza da alma". Seu raciocínio era que, como artistas, que foram conduzidos para criar obras de arte, e qualquer momento que produziu algo que nós gostamos e que nos deu satisfação, nossa motivação para continuar a criar seria diminuído.

Então, eu segui seu conselho e rasgou o meu melhor material, e funcionou. Em vez de gastar meu tempo admirando meu antigo trabalho, eu criei coisas novas e continuamente ficou ainda melhor. Tentei seguir o mesmo princípio com o meu código, mas ele realmente não funciona:. Meu computador tem um reservatório de plástico resistente que é quase impossível de rasgar através

Answer 3

eu postar um fragmento do blog de Jeff Atwood, Sucking Menos Todos os Anos , e eu concordo 100%.

Muitas vezes pensei que a sucção menos cada ano é programadores como humildes melhorar. Você deve estar infeliz com código que você escreveu há um ano. Se vocês não são, isso significa que tanto a) você não aprendeu nada em um ano, B) seu código não pode ser melhorado, ou C) você Nunca revisitar código antigo. Todos esses são o beijo da morte para software desenvolvedores.

Answer 4

Temos certeza como para admirar nosso código bom, mas não é sempre fácil saber o que admirar. Complicado e código elaborado às vezes é confundido com código admirável, enquanto elegância e simplicidade deve, antes, ser o que lutar.

Duas citações vêm à mente:

"A depuração é duas vezes mais difícil como a escrita o código em primeiro lugar. Portanto, se você escrever o código como inteligentemente quanto possível, você é, por definição, não é inteligente o suficiente para depurar -lo.”

- Brian Kernighan

e

"Faça tudo o mais simples possível, mas não mais simples. "

- Albert Einstein

Answer 5

Jonathan Edwards escreveu um impressionantemente belo ensaio sobre este assunto, solicitado pelo trabalho no livro O'Reilly Beautiful Código . Aqui está o parágrafo final, mas o resto do ensaio é também vale a pena a leitura.

Outra lição que aprendi é a beleza desconfiança . Parece que a paixão com um design conduz inevitavelmente ao desgosto, como negligenciado realidades feias intrometer. O amor é cego, mas os computadores não são. Um relacionamento de longo prazo - manutenção de um sistema para ano - ensina a apreciar mais virtudes domésticos, tais como simplicidade e conventionality. A beleza é uma fantasia idealista: o que realmente importa é a qualidade da conversa interminável entre programador e código, como cada um aprende de e se adapta para o outro. A beleza não é uma base suficiente para um casamento feliz.

Outras versões desta mesma sabedoria existem em outros campos. Samuel Johnson, sobre a escrita:

Leia sobre suas composições, e onde quer que você se encontra com uma passagem que você acha que é particularmente bom, pô-lo fora.

A versão de William Faulkner deste foi muito mais sucinta: “Kill Your Darlings”

O meu pai-de-lei funciona como um editor do filme, e ele evita cuidadosamente o conjunto onde o filme está sendo filmado. Quando ele tem que visita, ele protege seus olhos tanto quanto ele puder. Isto porque, quando ele decide se deve ou não incluir uma cena no final do filme, ele não quer ser influenciada pela quantidade de esforço que levou para filmar a cena. O que importa é o quão bem a cena funciona no filme final.

Meu ensaio, "Meu evolução como um programador" (que eu ligaria para se eu não fosse um novo usuário), é em grande parte sobre a aprendizagem de ceticismo sobre o código que eu tinha escrito: se funciona, se é útil, se é compreensível (programação par era uma chamada wake-up real aqui). É difícil!

Answer 6

Eu nunca admirar meu código. Admiro outro código povos que i "borrow" e tentar imitá-los ou melhor eles e eu acho que quanto mais eu sei, especialmente sobre a codificação do mais eu acho que eu não saiba. A única coisa de valor Wold ser para programadores de pares para admirar meu código e tomá-lo emprestado.

Answer 7

Eu acho que ele tem um bom ponto. É frustrante para trabalhar com pessoas que têm muito a isso, como ele realmente dificulta o trabalho em equipe e chegar ao melhor solução para o problema.

Como eu posso ser um pouco delirante, eu tento colocar práticas no lugar que irá manter-me fundamentada na realidade. Para código,

• testes de unidade : Estes mantêm-me mais focado no que o código é suposto fazer, em oposição a qualquer "beleza" abstrato.

• propriedade do código compartilhado : Existem dois campos aqui: dar às pessoas mais posse de seu código e orgulho esperança assume, ou dar-lhes menos e deixar que a pressão dos colegas entram em jogo. Eu acredito que dar às pessoas mais propriedade pode levar a essa admiração código. Nós praticamos a propriedade compartilhada de código, por isso estou constantemente forçados a ver alguém reescrever meu código perfeita para torná-lo melhor (em sua mente). Eu rapidamente percebi admirando-o muito era um desperdício de tempo e emocionalmente difícil.

• programação em pares :. Side-by-side trabalhar com alguém irá mantê-lo realista

• outro feedback : Estes são todos os loops de feedback, mas há outros. Não há nenhuma maneira melhor para ver se funciona mais ou menos do que assistindo alguém (tentar) usá-lo. Colocar o seu trabalho na frente de tantas pessoas quanto possível. Têm revisões de código. Leia de outras pessoas código . Execute análise estática de código ferramentas.

Answer 8

Eu estou com PurplePilot - Eu não admiro o meu próprio código, e como tal estou constantemente à procura de novo mais eficiente, (inferno, mais fácil) maneiras de fazer a mesma coisa. I como o livro Effective c #, pegou um monte de código útil de lá que eu admiro.

Eu não hesitaria em lançar código de distância e começar de novo, mas não necessariamente a partir do zero, ou seja, por escrever algum código para um cenário específico e, em seguida, jogá-lo fora, você provavelmente vai ter uma melhor compreensão do cenário. Em outras palavras, é um "problema grave", ou você encontrou uma outra maneira que não funciona a la Edison.

Ele implora uma pergunta mais ampla:? Se o código não é jogado fora, ou pelo menos revisitado, está desenvolvendo em bibliotecas que estão se tornando estagnada coisa boa

Answer 9

Não há nada de errado com a admirar o seu código ... isto é parte do processo de reforço positivo que irá motivá-lo a escrever mais e melhor código no futuro.

No entanto, extraviado ou misused admiração pode ser um problema. Se o código não é realmente bom, ou tem bugs que não foram expostos por unidade ou outro teste, ou necessidades refatoração / redesenho / substituição então este admiratoin extraviado é um problema. E usando admiração como uma desculpa para ignorar parte do processo - como revisões de código, ou não ter uma atitude cética em relação a código -. É mau uso de admiração

Como qualquer outra coisa que é bom, admiração de código pode ser perdidos ou mal utilizada - isso não significa que em si é ruim. Isso seria como dizer que "a religião é uma coisa ruim, porque provoca conflitos e guerras entre as pessoas".

Answer 10

Duas palavras:. Revisão de código

Reunir dois ou mais colegas desenvolvedores e convidá-los para revisão / criticar / comentário no seu código. 'Sarja lançar alguma luz (reconhecidamente dura) em seu código.

Answer 11

É talvez melhor ter uma perspectiva mais saudável - não somos cientistas de foguetes, e não estamos a cura do câncer. - É apenas trabalho

(Sim, é razoável para se orgulhar de um prédio inteiro que você ajudou a construir, se você é um arquiteto, mas eles realmente tem um monte de sua auto-estima embrulhado em um plano individual ou um armário no piso 3 eles projetaram por si só?).