Uma grande parte do meu código tem uma grande falha de design. Termine ou conserte agora? [fechadas]

182

Eu sou um estudante do ensino médio trabalhando em um projeto de C # com um amigo meu com o mesmo nível de habilidade que eu. Até agora, escrevemos aproximadamente 3.000 linhas de código e 250 linhas de código de teste em um intervalo de 100 commits. Devido à escola, adiei o projeto por alguns meses e recentemente consegui recuperá-lo novamente.

Quando eu o peguei de volta, entendi que o código que eu havia escrito era mal projetado, como inclusão de threads excessivos no renderizador, má prevenção de condições de corrida na interação entre o CPU emulado, GPU, e cartucho de jogos, bem como código que é simplesmente redundante e confuso.

O problema é que eu não terminei nem mesmo a funcionalidade principal do meu programa, então não posso refatorar de verdade, e me sinto desanimado por continuar perfeitamente ciente de que o design do meu código é falho. Ao mesmo tempo, não quero abandonar o projeto; uma quantidade substancial de progresso foi feito e o trabalho não deve ser desperdiçado.

Eu sinto como se eu tivesse algumas escolhas: simplesmente terminar a funcionalidade trabalhando em torno do design pobre e refatorando quando tudo estiver funcionando, parando tudo e trabalhando para desemaranhar tudo antes que o resto da funcionalidade possa ser concluída, Começando o projeto todo para que ele esteja fresco em minha mente novamente, ou simplesmente abandonando o projeto devido ao seu tamanho excessivo (essencialmente "de volta à prancheta").

Com base na experiência de outros em tais projetos, qual é o recurso para me colocar de volta no caminho certo? A partir das respostas neste site, o consenso geral é de que a reescrita é geralmente desnecessária mas uma opção disponível se o código não puder ser mantido sem custo excessivo. Eu realmente gostaria de prosseguir com este projeto, mas, do jeito que está, meu código não foi projetado o suficiente para eu continuar, e um sentimento de desânimo me impede de continuar.

    
por oldmud0 07.06.2016 / 02:12
fonte

21 resposta

264

Se eu estivesse no seu lugar, provavelmente tentaria assim:

  • primeiro, termine o projeto atual - pelo menos parcialmente - o mais rápido possível, mas em um estado de funcionamento . Provavelmente você precisa reduzir suas metas originais, pense na funcionalidade mínima que você realmente precisa ver na "versão 1.0".

  • então, e somente então pense em uma reescrita do zero (vamos chamar isso de "versão 2.0"). Talvez você possa reutilizar parte do código da V1.0. Talvez depois de dormir novamente sobre a situação você tenha tomado a decisão de refatorar a V1.0 e salvar a maior parte dela. Mas não tome essa decisão antes de não ter uma "prova de conceito V1.0" à mão.

Um programa de trabalho "1.0" é algo que você pode mostrar aos outros, mesmo quando o código é ruim (o que ninguém mais vai incomodar, exceto você). Se no meio da criação da V2.0 você perceber que está ficando sem tempo, você ainda tem a V1.0 parcialmente bem sucedida, o que será muito melhor para a sua moral. No entanto, se você não terminar V1.0 primeiro, há uma grande chance de você nunca completar V2.0, porque quando você estiver no meio, haverá um ponto em que você está insatisfeito com o design novamente, e então? Você vai abandonar a V2.0 novamente e trabalhar na V3.0? Existe um alto risco de entrar nesse círculo sem fim, nunca chegando ao fim.

Melhor considerar isso como uma oportunidade de aprender como alcançar metas intermediárias, em vez de uma oportunidade de aprender a deixar projetos em estado inacabado.

    
por 07.06.2016 / 06:18
fonte
116

Os projetos de TI concluídos, mesmo os defeituosos, são muito melhores que os inacabados.

Os inacabados também podem te ensinar muito, mas não tanto quanto os terminados.

Você pode não ver agora, mas tem uma enorme quantidade de valor trabalhando com código defeituoso.

Meu voto é para terminar e, em seguida, refatorar - se necessário. Quando você começar a trabalhar com mais projetos, verá que, surpreendentemente, a parte que "deveria ser refatorada" permanece intocada por anos, enquanto outras se prolongam.

Do ponto de vista do emprego, na maioria dos casos, você terá mais reconhecimento por um projeto finalizado.

    
por 07.06.2016 / 04:26
fonte
55

Eu ficaria feliz em começar o projeto.

Você é um estudante e ainda está aprendendo. Isso coloca você em uma posição muito diferente da questão a qual você ligou.

  • Você não tem responsabilidade profissional pelo seu código; se você deletasse todo o projeto agora e fosse embora, não sofreria nenhuma repercussão. Esta é uma enorme vantagem para um desenvolvedor. Na pergunta que você vinculou, esses desenvolvedores estão tentando manter o software pelo qual as pessoas estão pagando, e até pequenos bugs podem causar grandes problemas com os clientes, o que torna perigoso escrever do zero. Você não tem esse problema.

  • Como projeto pessoal, esta é a oportunidade perfeita para experimentar coisas novas e aprender com seus erros. É ótimo que você reconheça que seu código antigo tem problemas, porque isso significa que você aprendeu a fazer melhor. A experiência por meio de tentativa e erro pode ser inestimável para programadores iniciantes.

  • Seu projeto é relativamente pequeno e você basicamente não tem testes. Poderia ser tão curto algumas noites para escrever 3000 linhas a partir do zero, especialmente desde que você já tem idéias sobre o que fazer melhor da próxima vez.

  • Trabalhar em uma base de código quebrada será um dreno muito maior em sua moral do que uma reescrita faria.

Como um aparte, esta pode ser uma grande chance de tentar escrever um programa mais modular com testes unitários. Isso facilita muito a compreensão do código se você voltar a ele depois de um longo intervalo e ajuda a evitar erros que você pode introduzir acidentalmente devido ao esquecimento.

Por fim, aqui é uma opinião sobre a sabedoria de, às vezes, darmos passos para trás e darmos um passo adiante.

    
por 07.06.2016 / 02:52
fonte
32

Você provavelmente ainda está no aprendizado rápido do seu desenvolvimento. Há uma boa chance de que, daqui a alguns meses, você descubra que seu novo e incrível design está terrivelmente quebrado de uma forma que nem sabia quando começou.

Faça as coisas acontecerem - esta é a coisa mais importante que você precisa aprender. Acredite, eu conheço muitas pessoas (não apenas programadores) que estão presas no ciclo "continue começando do zero desde que eu aprendi muito antes de começar este projeto". O problema é que ele nunca acaba - até que você pare de aprender coisas novas, o que não é um bom lugar para se estar:)

Também é importante ser capaz de terminar qualquer coisa. Começar de novo é excitante, legal, divertido ... mas se você só aprender isso, nunca conseguirá terminar nada. Novamente, essa não é uma habilidade muito útil e, na verdade, não é tão boa quanto fazer algo útil (ou divertido). A vida é curta, o tempo é limitado, e você não pode simplesmente continuar praticando sem resultados tangíveis - você ficará muito bravo com isso. Se você não consegue começar a trabalhar porque simplesmente não consegue decidir qual abordagem tomar, você já está na zona de perigo.

Sempre haverá impulsos para começar de novo. Mesmo em um ambiente de aprendizado, essas são provavelmente uma má ideia. Isso não significa que você precisa carregar cada protótipo para um aplicativo pronto para produção, longe disso. Mas você precisa pelo menos chegar a uma fase de protótipo em funcionamento - isso provavelmente ajudará sua moral, e é uma característica muito útil para um desenvolvedor de qualquer tipo. Faça as coisas acontecerem . E a parte divertida é que você verá rapidamente que há um milhão de coisas mais divertidas ou úteis que você pode fazer com seu protótipo em vez de "reescrevê-lo do zero" - e, em muitos casos, até refatorá-lo. Tudo o que você faz tem um custo - no mínimo, você poderia ter feito outra coisa enquanto isso.

    
por 07.06.2016 / 11:46
fonte
24

Eu sigo a ideologia "Fazer funcionar, fazer direito, tornar isso rápido" no desenvolvimento de software.

  1. Faça funcionar : escreva a funcionalidade principal, para que o projeto seja utilizável. Faça o que for preciso para que tudo funcione, mesmo que isso signifique código feio.
  2. Faça certo : corrija os erros e refatore o código para facilitar a leitura, o entendimento e a manutenção.
  3. Faça isso rápido : otimize o programa, visando um bom equilíbrio entre velocidade, uso de recursos e capacidade de manutenção.

Neste momento, você ainda não concluiu a etapa 1. Faça com que ela funcione primeiro e, em seguida, você pode se preocupar com o quanto seu código é feio. Na verdade, criar um produto funcional é uma das coisas mais difíceis para os novos desenvolvedores, porque eles ficam tão envolvidos na tentativa de tornar seu código perfeito na primeira vez, e assim ficam presos no Optimization Hell e nunca chegam a terminar implementando todos os recursos. Você tem que aprender como deixar de lado todas as preocupações sobre refatoração e otimização para que você possa se concentrar apenas em fazer o software funcionar. Uma vez que você tenha mais experiência, naturalmente fará mais coisas certas na primeira vez, portanto, é necessária menos refatoração.

Tenha em mente: a otimização prematura é a raiz de todo o mal (veja esta excelente questão Programmers.SE para uma boa discussão). Se você gasta muito tempo pensando em como melhorar seu código, fica paralisado na paralisia da análise . Isso mata o projeto. É melhor apenas concluir o projeto antes de começar a otimizá-lo.

Para citar um grande palestrante motivacional: faça isso .

Como sempre, há um xkcd relevante:

    
por 07.06.2016 / 07:30
fonte
22

Reescreva-o. Código não funcional tem pouco valor e três mil linhas não tem muito código. Não demorará quase o tempo necessário para escrever o código que você tem atualmente, e será muito melhor. Eu já joguei fora quinhentas ou mil linhas de código pobre, e muitas vezes a reescrita é um quinto do tempo.

A maioria das noções de "não reescrever" está relacionada a grandes sistemas que fazem coisas importantes e passam por constantes mudanças para atender aos requisitos em evolução. Reescritos de sistemas complexos em uso raramente são bem-sucedidos.

Sua situação é o oposto completo. Você tem um pequeno aplicativo sem usuários e os únicos requisitos são aqueles que você escolhe implementar. Então vá em frente e reescreva-o.

    
por 07.06.2016 / 08:39
fonte
19

Reiniciar do zero geralmente é uma má jogada em projetos da vida real, principalmente porque projetos da vida real acumulam correções de bugs que um desenvolvedor recém-chegado não está ciente (por exemplo, veja Coisas que você nunca deve fazer , do blog Joel on Software .

No entanto, os projetos escolares não herdam tal história e geralmente começam codificando e projetando ao mesmo tempo com conhecimento parcial de computação e falta de experiência. Eu consideraria sua primeira versão como um protótipo, usado como uma prova de conceito que falhou, e eu ficaria feliz em jogá-la fora (veja Quais são as diferenças entre protótipos descartáveis e evolutivos? para uma discussão sobre prototipagem descartável versus prototipagem evolutiva.)

O design certo amadureceu na sua cabeça e não deve levar muito tempo para escrevê-lo em código.

    
por 07.06.2016 / 09:38
fonte
12

Eu respeitosamente discordo de sugestões que reescrevem é uma má ideia.

No domínio do ciclo de vida do software, é geralmente aceito que o tempo e o esforço necessários para corrigir um erro aumentam em uma ordem de magnitude em cada camada do ciclo de vida. Ou seja, se levar 1 hora para corrigir um erro no nível de requisitos, levará 10 horas em design, 100 horas em teste de codificação e 1000 horas como correção de bug. Esses números podem soar ultrajantes, mas são aceitos pela indústria como sendo aproximadamente corretos. Obviamente, menos em um projeto menor, mas a ideia geral permanece. Se o seu projeto tem uma falha básica de projeto, é mais apropriado chamar isso de uma experiência de aprendizado e voltar atrás, rever seus requisitos iniciais e reformular.

Eu também encorajaria a considerar um modelo de Desenvolvimento Orientado a Testes usando testes unitários estruturados. Eles são uma dor e inicialmente parecem uma perda de tempo, mas sua capacidade de descobrir erros, especialmente ao se integrar com o código de outra pessoa, não pode ser superestimada.

    
por 07.06.2016 / 16:34
fonte
10

Você me perdeu nesta frase:

The problem is that I have not finished even the main functionality of my program, so I cannot truly refactor, and I feel discouraged to go on perfectly aware that my code's design is flawed.

Eu acredito no princípio (declarado em Systemantics ) que

  • A complex system that works is invariably found to have evolved from a simple system that works.
  • A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

Então, escrever um sistema complexo inclui

  • Escrevendo um sistema simples
  • Certificando-se de que funciona

... ou seja, os seguintes passos:

  1. Escreva um pouco de código
  2. Teste para ter certeza de que funciona
  3. Escreva um pouco mais de código
  4. Teste novamente
  5. Etc.

Observe que a etapa 3 pode envolver:

  1. Escreva um pouco mais de código
    1. Refatorar código existente para prepará-lo para nova adição
    2. Teste a refatoração para garantir que ainda funcione
    3. Adicione a nova funcionalidade

Além disso, o Passo 2 "Testar para ter certeza de que funciona" pode envolver alguma reescrita, se isso não acontecer.

Se eu estivesse construindo uma base de código podre, eu não estaria inclinado a adicionar outras funcionalidades. Então, eu estaria inclinado a agendar algo como "simplificar a implementação de threading existente" como o próximo trabalho a ser implementado. Supondo que você tenha testado à medida que avança, você deve ser capaz de tratar isso como um exercício de refatoração. Os critérios de sucesso / saída para esta fase de trabalho seriam:

  • O código-fonte é mais simples
  • E não foram introduzidos novos bugs
  • (e alguns bugs antigos eliminados)

Incidentalmente, "testá-lo para ter certeza de que funciona" não significa necessariamente "testes unitários" - quando a estrutura da equipe é simples, você pode testar um sistema (simples) usando (simples) testes de sistema (em vez disso, testes de unidade) .

    
por 07.06.2016 / 17:11
fonte
7

Um dos problemas que você está enfrentando quando se depara com um problema como este, é que você está emocionalmente ligado ao código que você escreveu até agora de alguma forma ou de outra.

Um colega me disse que estava escrevendo um programa na universidade enquanto recebia lições de um professor famoso (creio que foi Dijkstra). Ele pediu ao professor que olhasse para o código em que ele estava trabalhando há mais de um mês. O professor perguntou se ele tinha feito um backup, ele respondeu não. O professor então apagou todo o seu código e pediu que ele escrevesse novamente.

Ele estava chateado, mas 3 dias depois ele terminou o programa, com código mais limpo e menos bugs e menos linhas de código.

Tente fazer uma estimativa honesta sobre qual é a melhor opção no tempo disponível para o projeto.

As 3 opções são

  • Excluir (completamente, sem olhar para trás)
  • Continue trabalhando no design antigo
  • Refaça o código enquanto você vai.

Sou programador profissional há mais de 10 anos e, na minha linha de trabalho, concluí que a última opção é a maioria das vezes a escolhida, mas nem sempre é a melhor opção. / p>     

por 07.06.2016 / 15:26
fonte
6

Parece que suas habilidades cresceram substancialmente nesse período de tempo. Talvez trabalhar nesse projeto tenha contribuído para isso. Projetá-lo novamente como uma experiência de aprendizado intencional seria frutífero.

Lembre-se de que isso não é algo que você precisa entregar como um programa de trabalho para um cliente. Foi escrito especificamente para a prática. Então, a menos que você queira praticar problemas de entrega e entrega defeituosa, acho que atualmente você está em uma fase de desenvolvimento em que trabalhar seus "músculos de projeto" seria proveitoso.

Ao fazer isso, concentre-se no processo de design e planejamento e reflita sobre suas coisas existentes e reflita sobre o que você entende melhor.

    
por 07.06.2016 / 09:51
fonte
6

Refatorar. Refatorar. Refatorar! REFADORADOR !!!!

Honestamente, não importa o quão experiente você seja, esse é um problema comum. Você escreveu código, aprendeu alguma coisa e deseja usar o novo conhecimento no código antigo. Você quer medir o código antigo contra o novo conhecimento.

Isso simplesmente não funcionará. Se você fizer isso, seu aplicativo / jogo nunca será concluído. Em vez disso, tente alocar seu tempo no projeto para que algumas de suas "tarefas" refatenham o código incorreto. Digamos, por exemplo, que você tivesse um método horrível de salvar o jogo. Continue trabalhando no jogo em si, mas encontre algum tempo para refatorar (substituir) aquele método horrível. Tente manter os refatores pequenos, e isso não deve ser um problema.

Quando você chega a uma parte importante do aplicativo que precisa de um refatorador, então você está fazendo errado, seriamente. Quebre essa refatoração em partes menores. Tente passar sete horas escrevendo código e refatorando uma hora.

Quando você terminar o projeto e clicar em congelamento de recurso, poderá gastar uma refatoração em massa. Por enquanto, faça o jogo, mas ainda tente refatorar alguns. Isso é o melhor que você pode fazer.

Sempre haverá algo para refatorar.

    
por 08.06.2016 / 18:59
fonte
4

Eu diria que isso depende um pouco do tipo de código que você tem agora e de onde exatamente estão os problemas. Ou seja, se as suas fundações são boas (design de classe adequado na maioria das partes, boa dissociação / coesão, etc., apenas algumas escolhas ruins como as que você mencionou), então descubra 1.0 e então refatorar como não há amanhã.

Por outro lado, se é realmente apenas um monte de arquivos de texto feios, de alguma forma, passando pelo compilador, sem estrutura discernível, etc. (em outras palavras, uma prova de conceito de aprendizado no trabalho protótipo), então eu prefiro apagá-lo e começar de novo.

Na sua próxima versão, faça uma abordagem ágil: defina um cronograma de repetição fixo, como duas semanas ou o que for mais adequado à sua programação. No início de cada pedaço (vamos chamá-lo de sprint), estabeleça metas que sejam alcançáveis nas duas semanas. Vá em frente e faça-os, tente o seu melhor para fazê-lo funcionar. Defina suas metas para que, após cada 2 semanas, você tenha algo que possa ser mostrado a um amigo, e não apenas algum trabalho interno abstrato. Google "scrum" e "smart goal". Isso tudo é muito fácil de fazer, se você está sozinho, apenas um pedaço de papel com alguns pontos de anotação rapidamente anotados.

Se você puder fazer isso, começar tudo de novo é bom. Se você sabe bem no fundo que depois de começar de novo, você provavelmente vai acabar onde você está agora, de qualquer maneira, então continue com seu código e faça-o funcionar.

    
por 07.06.2016 / 17:59
fonte
3

Você tem que se colocar no lugar dos empregadores.

Para a maioria dos recrutadores, você seria o mais valioso se fosse assim: - Conclua com 100% de testes no novo código que você escreve. - Adicione testes para o código antigo (mal desenhado). - Refatá-lo para alcançar o que você queria como um design.

Faça tudo isso com um bom processo de versionamento, ramificações e tags.

Reescrever é frequentemente uma ideia sexy, mas é frequentemente uma ideia que os recém-chegados têm que é perigosa na vida real. Mostrando que você está mais disposto a melhorar a qualidade do trabalho que já fez, e que começar do zero é um bom sinal de que você é uma pessoa séria.

Você pode, obviamente, reescrevê-lo, mas torná-lo outro projeto então.

    
por 08.06.2016 / 07:21
fonte
3

Só para adicionar um pouco da minha experiência anterior no mix. Eu tenho trabalhado em um projeto paralelo há mais de um ano, sempre que recebo alguns minutos extras. Este projeto passou de um simples testbed para uma classe estática para um projeto slim alinhado a objetos que é agora.

Ao longo de todas essas alterações, mantive a mesma funcionalidade do código, excluindo correções de bugs e benefícios de desempenho (precisa ser o mais rápido possível). A mesma base de código, embora refatorada, permaneceu a mesma e, como tal, eu a melhorei massivamente sem precisar reescrever o código do zero e perder tempo.

Isso significou que consegui melhorar o código em um ritmo mais rápido do que eu teria sido capaz antes. Também significava que, enquanto eu estava indo, era mais fácil dizer o que precisava ser removido, ou seja, classes desnecessárias, e o que poderia ficar mais fácil do que reescrever com a velha idéia ainda em mente.

Portanto, meu conselho seria refatorar seu código e seguir adiante, fazendo melhorias, conforme necessário. Embora lembre se você decidir reescrever a partir do zero, você deve pegar as boas idéias do projeto antigo e examiná-las de perto para ver onde elas estão defeituosas. Ou seja não basta copiar o código antigo para o novo projeto.

    
por 08.06.2016 / 12:38
fonte
3

A resposta depende de algo que eu gosto de chamar de "teto da complexidade". À medida que você adiciona mais e mais a uma base de código, há uma tendência de tornar-se cada vez mais complexa e cada vez menos organizada. Em algum momento, você atingirá um "teto de complexidade", no qual o progresso para frente se torna muito difícil. Em vez de tentar seguir em frente com a força bruta, é melhor fazer backup, reorganizar / reescrever e depois seguir em frente.

Então, é a sua base de código tão ruim que você está se aproximando de um teto de complexidade? Se você perceber que é, leve algum tempo para limpar e simplificar antes de prosseguir. Se a maneira mais fácil de limpar é reescrever algumas partes, tudo bem.

    
por 10.06.2016 / 19:13
fonte
2

Nem? Ambos?

Continue em frente, passe algum tempo revisando o design existente e algum tempo adicionando novas funcionalidades.

Se você tiver interações vigorosas, pode ser um bom lugar para começar ("threads excessivos no renderizador" soa como uma ineficiência, em vez de algo que causaria problemas de correção). Veja se você pode descobrir uma maneira geral de fugir das corridas (e possivelmente deadlocks), ou pelo menos várias maneiras específicas de fazê-lo.

Eu não sei até que ponto coisas como deadlock e race detectors estão disponíveis para C #, mas se elas existirem, elas podem ser úteis para identificar quais problemas existem e verificar se suas correções estão funcionando.

Acho que, em geral, estou mais motivado para corrigir problemas com código que fazem algo útil, em vez de jogá-lo fora e começar, novamente, do zero. Há casos em que o desenvolvimento de campo queimado (em analogia ao greenfield e brownfield ...) é mais satisfatório, mas geralmente é para coisas em que a abordagem existente é tão diferente de onde deveria ser que não está mais errado. / p>     

por 07.06.2016 / 10:42
fonte
2

Se o seu código é modular, então você deve ser capaz de terminar o resto do código em torno dos componentes gravados incorretamente e, em seguida, reescrever os componentes gravados incorretamente sem afetar o resto do código.

Nesse caso, cabe a você quando você reescreve os componentes mal escritos. Se os componentes gravados incorretamente forem escritos de forma tão ruim que o código finalizado não funcionará com eles como estão, você precisará reescrevê-los antes de concluir o restante do código.

    
por 11.06.2016 / 12:29
fonte
2

A primeira pergunta que você deve se fazer é "quão ruim é a falha?"

O que exatamente você fez de errado?

Se algo estiver tão ruim que você perderá muitas horas tentando trabalhar com o problema, expondo dados confidenciais (senhas / cartões de crédito) ou causar uma vulnerabilidade ruim, talvez seja necessário editá-los, mas a maioria deles vez que você pode pegar o que tem, terminar e corrigir o problema mais tarde.

Os programadores adoram melhorar seus aplicativos, querendo que eles sejam "os melhores possíveis", mas essa não é a abordagem correta.

SE você liberar seu aplicativo o mais rápido possível, mesmo que não seja 100%, bugs e tudo, você terá FEEDBACK de outros, enquanto tiver tempo para corrigir os bugs e outras coisas para a versão 1.1. Outras pessoas poderão ajudá-lo a tornar o aplicativo muito melhor e você poderá ter perda de tempo fazendo algo que as pessoas possam não gostar.

Então, no seu caso, divulgue-o, obtenha feedback e você poderá estruturar a versão 2.0 com todas as alterações e corrigir a falha que você tem.

Outra coisa a lembrar é que estamos constantemente melhorando. Há um ditado que diz que se você pode olhar para o seu código de um ano atrás e ver que está ruim, isso significa que você ainda está melhorando, e isso é ótimo.

    
por 16.06.2016 / 01:06
fonte
1

Depende de como seu código está bagunçado.

  • Se você fez erros n00b reais que tornam seu código excessivamente complexo ou detalhado, então eu recomendo reescrever essas partes.

  • Se você acha que tem sérios erros que você terá que corrigir de qualquer maneira, então escreva alguns testes de unidade que podem verificar se você corrigiu o bug (... já que você ainda não pode iniciar o programa ). É melhor corrigir os bugs cedo, e é definitivamente melhor corrigir bugs enquanto você ainda se lembra do que o código faz.

  • Se você não gosta do que os métodos são chamados, ou a que classe eles pertencem, ou pequenas coisas como essa, então apenas use o IDE. (Lembre-se, este é o C #, não algum javascript, python, perl, php, etc.) Quando você está trabalhando em código que usa o componente afetado, e você tem uma imagem clara do que esse componente deve fazer, em seguida refatore-o se o seu IDE o tornar indolor.

Caso contrário, trabalhe e aprimore suas habilidades no próximo projeto.

    
por 15.06.2016 / 21:47
fonte
1

Como outros sugeriram, como este é um projeto pessoal, não (ainda) um projeto profissional, eu consideraria seriamente uma reescrita.

No entanto, você pode aproveitar o método científico aqui, realizando um experimento. Primeiro, conceba uma hipótese. O meu seria "provavelmente é hora de uma reescrita". A fim de economizar tempo, reduzir o custo da falha e limitar um viés a priori, antes de fazer qualquer outra programação, decida um período de tempo ("caixa de tempo"). Eu sugeriria talvez 4 horas de relógio de parede. Decida também uma metodologia para avaliar a hipótese. Como as apostas são baixas, eu sugeriria como metodologia, simplesmente pergunte a si mesmo: "Estou feliz por ter feito isso?" Agora comece o experimento. Após a sua caixa de tempo escolhida, qual é a avaliação da hipótese? por exemplo. Do meu exemplo, você está feliz que você começou a reescrever agora que você passou 4 horas fazendo isso? Então é provavelmente a escolha certa.

Você pode pedir todos os conselhos do mundo, mas não há nada como testar uma hipótese empiricamente.

Alguns motivos para considerar a possibilidade de selecionar uma reescrita como sua experiência:

  • Na minha experiência, geralmente é mais divertido. Uma grande razão pela qual as reescritas geralmente não são selecionadas em situações profissionais é que a diversão está longe de ser o único critério. Mas você ainda é relativamente novo na codificação, por isso a diversão é provavelmente um critério muito importante, e também um indicador de outros fatores que podem ser intangíveis para você neste estágio inicial (a diversão sugere que você aprenderá mais, etc.). li>
  • Sua experiência e provavelmente um incômodo senso de consciência parecem estar lhe dizendo que uma reescrita vale a pena ser considerada. Ouça essa voz, se houver uma. Mesmo que você não siga seu conselho, pelo menos ouça. No futuro, haverá mais vozes externas e você precisará praticar ouvindo seu próprio bom senso.
  • Eu suspeito que com uma reescrita, você tem mais probabilidade de modularizar mais seu código. Quando você cria módulos, você tem componentes mais reutilizáveis e confiáveis que você pode aproveitar para outros projetos. Você pode até achar que, no final, o que parecia ser um mero módulo do seu projeto principal acaba sendo o código mais interessante e valioso que você escreve.

Terminar algo é uma boa ideia, mas não no vácuo. Se você começar uma reescrita, poderá optar por terminar algo concluindo um sub-módulo específico. Você pode definir isso como um primeiro objetivo, após o experimento acima. O acabamento não precisa significar terminar seu projeto inicial ainda. Depois de concluir um módulo, conclua outro, etc., até terminar de reescrever todo o escopo do projeto original, se desejar.

    
por 12.02.2018 / 15:49
fonte