O código está sendo constantemente reescrito e, portanto, é inútil se preocupar com a qualidade das primeiras iterações do código de reescrita?

4

Na universidade um dos palestrantes insistia em um conselho que achei estranho.

Esse palestrante insistiu que seus alunos não se importam muito com decisões como a escolha da linguagem de programação, plataforma de destino ou outras opções de design que não são estritamente necessárias para criar um protótipo funcional. Quando as pessoas estavam protestando que criar algo que é conhecido por ser quebrado é uma perda de tempo e desperdício de trabalho, o palestrante argumentou que:

What programmers often do not realize is that code is being constantly rewritten. Look at most successful companies, Google for example, and products, World of Warcraft for example: They don't maintain their code, they rewrite it. I already lost count how many times the engine of WoW was rewritten and replaced by a new version. Rewriting code, even in another programming language and under changed requirements, is not hard once you have a working prototype; what is hard is making this working prototype. You can carefully choose your programming language to meet the requirements of your target platform and to achieve necessary performance; you can worry about the quality of your first iteration of code; then writing your first iteration will be much more difficult and time consuming and after you're finally done you will realize you have to rewrite your beautiful code because your code's quality is nevertheless unsatisfactory as it is impossible to determine how a code should look like without writing it first, not to mention changed requirements. Instead, focus only on making a working prototype, without caring for anything else; then, once you have it, make an informed decision how to fix the code and how to adjust it for your particular requirements and rewrite your code accordingly, this time caring for its quality; then possibly rewrite it once again before releasing it. If your product is successful enough to enter the maintenance phase you will also be periodically rewriting code whenever a need for a relatively major change arises.

Em particular, isso significa que não devemos nos importar muito com a qualidade do código do protótipo e escrevê-lo em Python se gostarmos do Python mesmo se soubermos que o Python não está disponível para nossa plataforma de destino.

(Eu tentei resumir as opiniões do palestrante acima, esperando que eu as entenda bem e que eu não as deturpe).

Este é um oposto direto das recomendações usuais para sempre colocar um cuidado extremo com a qualidade do código e também como um oposto direto de

    
por gaazkam 04.01.2018 / 13:19
fonte

8 respostas

14

In the University one of the lecturers ..

Parece um acadêmico que está sofrendo do efeito Dunning-Kruger . Mas talvez você tenha acabado de interpretar mal algumas de suas declarações.

Rewriting code, even in another programming language and under changed requirements, is not hard once you have a working prototype

Quando você somente tem um protótipo funcional, e esse protótipo não é muito grande, então reescrever o código provavelmente não é muito difícil, porque não há muito a ser reescrito . No entanto, uma vez que você tenha um software bem-sucedido desenvolvido ao longo de vários meses e anos, e uma sólida base de usuários, uma reescrita completa torna-se cada vez mais difícil. Faz diferença se você tentar reescrever 1k LOC, 20kLOC ou 400k LOC, e essa sabedoria é independente da linguagem de programação. E tenho certeza de que grandes empresas de software, como o Google ou a Microsoft, não jogam todos os códigos de seus principais produtos a bordo todo ano e reescrevem tudo do zero, o que simplesmente não seria econômico.

what is hard is making this working prototype

Fazer um primeiro protótipo é certamente mais difícil do que fazê-lo pela segunda vez quando você tiver o primeiro construído antes, e contanto que alguém não caia na armadilha do efeito do segundo sistema . Mas a parte realmente difícil vem depois disso - fazer um produto estável e de qualidade. E desde que você citou Joel Spolsky, deixe-o citá-lo também: bom software leva dez anos .

Instead, focus only on making a working prototype, without caring for anything else; then, once you have it, make an informed decision how to fix the code and how to adjust it for your particular requirements and rewrite your code accordingly, this time caring for its quality.

É claro que "time-to-market" geralmente é muito mais importante do que a qualidade do código ao trazer uma nova ideia para um mercado concorrente, isso é verdade. Protótipos são importantes para fins de demonstração, marketing, prova de conceitos. Substituir o primeiro protótipo por uma versão totalmente reescrita pode ser a abordagem mais sensata. Não reescrevê-lo quando a qualidade do código foi sacrificada para obter a coisa durante a prototipagem pode ser uma grande falha - mas muitas vezes os desenvolvedores têm que convencer seus superiores sobre isso, caso contrário eles são forçados a construir um sistema inteiro naquele protótipo, sem chance de mudar para uma arquitetura diferente.

If your product is succesfull enough to enter the maintenance phase you will also be periodically rewriting code whenever a need for a relatively major change arises.

Em primeiro lugar, você irá constantemente refatorar o código de tal produto. Você também pode reescrever algumas partes dele de tempos em tempos, se evoluí-las em pequenos passos não parecer mais possível ou acessível. Mas você certamente quer evitar jogar a coisa toda na lata de lixo e começar tudo de novo. Tentar isso levará ao tipo de desastre mencionado em Joel Spolsky's ensaio que você já mencionou.

This lecturer insisted that his pupils do not care too much about decisions like the choice of the programming language, target platform, or other design choices that are not strictly necessary to make a working prototype.

Essa recomendação é boa, pelo menos para esse público. Não se esqueça em uma universidade, os alunos normalmente não iniciam um desenvolvimento de longo prazo para algum produto comercial, eles começam com projetos de aprendizado, e 99,9% deles serão jogados fora, independentemente da qualidade do código. / p>

Então, TLDR; a maior parte do que seu palestrante disse é aceitável quando aplicado a protótipos pequenos , em seu ambiente acadêmico, mas você não deve interpretar isso como uma recomendação ou uma desculpa para sacrificar a qualidade do código em sistemas de software maiores e comerciais. / p>

Uma nota final sobre

... write it in Python if we like Python even if we know that Python is unavailable for our target platform.

Com que frequência você encontra uma situação em que um protótipo precisa ser criado em uma plataforma tão diferente da plataforma de destino que o Python não está disponível no segundo, mas faz sentido usar o Python no primeiro? Não que tais situações não ocorram, mas isso me parece muito artificial.

    
por 04.01.2018 / 13:58
fonte
8

Isso é algo que eu seria muito cauteloso em uma empresa privada. Eu pessoalmente encontrei um número de vezes que um protótipo 'rápido e sujo' foi colocado em prática e esse 'protótipo' foi posteriormente vendido como um software completamente funcional.

Muitas vezes, nessas circunstâncias, há muito pouco tempo disponível para reescrever desde o início, para que seu protótipo receba polimento e seja enviado, aumentando a lucratividade da empresa.

Em resumo, embora a prototipagem possa, por sua natureza, ser um pouco difícil, você deve sempre ficar de olho no que o produto final pode ser.

Eu observaria que codificar ativamente seu protótipo em um idioma que não está disponível na plataforma na qual ele será enviado pareceria uma maneira de contornar esse problema, no entanto, não é provável que você fique muito popular com a gestão ...

    
por 04.01.2018 / 14:20
fonte
3

O que eu acho é que, quando apresentada com dois extremos, a resposta geralmente está em algum lugar no meio. Outra ótima leitura seria A Catedral e o Bazar , que na superfície pareceriam ecoar a história do seu professor. afirmações. Eu acho que a intenção por trás do que seu professor estava falando é:

Stop worrying about how to start and get something written.

Paralisia por análise é um problema muito real no qual os alunos se enquadram. É porque eles têm muita teoria e não prática suficiente no mundo real. Adquira alguma prática do mundo real para descobrir se o que você acha que deveria funcionar realmente funciona.

Se ele parasse por aí, não acho que teria havido alguma confusão.

Há algumas declarações que precisam de esclarecimentos:

  • O software do mundo real é reescrito regularmente, mas não é tão regular quanto os comentários do seu professor parecem indicar
  • Os projetos dos alunos não pretendem ser obras de arte, eles são abandonados - escritos para uma tarefa e nunca mais foram tocados
  • Se acontecer de você ter uma boa ideia de um projeto da escola que você acha que pode transformar em um produto real, provavelmente é melhor escrevê-lo com isso em mente

No entanto, no mundo real, você terá que manter o software que outras pessoas escreveram. O fato de não ser feito da maneira que você faria não significa que seja ruim ou precise ser reescrito. Quando uma empresa está disposta a reescrever um software, é devido a um motivo principal:

The cost of rewriting the software to enable the current needs is less than shoehorning the feature in to the software.

A maioria dos desenvolvedores que conheço são muito conscientes sobre como escrever o software da maneira mais estruturada e projetada possível, dentro das restrições de programação e qualificação que possuem. Eles tendem a trabalhar de forma iterativa, construindo novos recursos em um pouco de cada vez. Se a programação permitir, eles preferem limpar com a refatoração à medida que avançam. Infelizmente, o cronograma e a pressão da gerência para fornecer força alguns para cortar alguns cantos com soluções "boas o suficiente". Se não tivéssemos o cronograma, os ciclos de lançamento poderiam ser muito longos para serem competitivos.

Você descobrirá que:

  • Se você fizer isso cedo o suficiente, a maioria da fealdade no software pode ser corrigida com pequenas refatorações
  • Se você se concentrar em trabalhar o suficiente para atender às suas necessidades, limpe à medida que for

Lembre-se apenas de que o software de trabalho feio supera o software que não funciona muito bem e que funciona todo o tempo.

    
por 04.01.2018 / 19:18
fonte
2

Acho que você pode ter entendido mal a afirmação do seu palestrante de que "o código está sendo constantemente reescrito".

Se um bug for descoberto no código de produção, você não descartará a coisa toda e iniciará novamente. Você encontra o bug, conserta, testa, implanta. E isso é muito difícil de fazer se o código for uma bagunça ilegível.

Dito isso, é importante diferenciar entre o código do protótipo e o código de produção. Se você está apenas explorando um conceito, não há problema em que o código do protótipo seja áspero nas bordas. No entanto, no ponto em que você decide que vale a pena transformar o conceito em um produto completo, então sim, você deve reescrevê-lo com vistas à estabilidade e manutenção.

    
por 04.01.2018 / 13:56
fonte
1

Embora as opiniões do palestrante pareçam loucas, elas fazem sentido no contexto.

O ponto importante é que o seu "produto" pode não ser todo o seu negócio. Pode ser apenas um serviço que seja pequeno o suficiente para que reescrever seja uma boa ideia, em vez de criar um hack de hacker. Este é o caso tanto no Google quanto no WoW. Eles não são enormes monólitos, mas compostos de muitos pequenos serviços interconectados, onde cada um pode ser reescrito de forma independente. É por isso que os microsserviços estão se popularizando atualmente. Ter cada microsserviço construído usando uma linguagem diferente ou em pilha diferente não é apenas possível, mas até mesmo recomendado. O problema aqui é que a experiência de muitas pessoas com software é com enormes monólitos. Nesse caso, a ideia de reescrever é tão louca quanto parece. Então, para fazer esse tipo de mentalidade "reescreva quando necessário", todo o produto deve ser dividido em partes pequenas e fracamente acopladas. O que não é tão comum em nossa indústria.

Outra coisa que vem à mente é que a qualidade não significa apenas a qualidade do código. A qualidade do software é um conceito amplo, que engloba códigos, testes, documentação, etc. E o teste é a parte importante aqui. Se o seu código tiver um conjunto sólido de testes automatizados, reescrevê-lo será trivial. Mas, novamente, isso não é algo que vem de graça. Bons testes são caros e difíceis de criar. Mas uma vez que você os tenha, o código se torna tão flexível quanto o putty. Torna-se muito fácil refatorar ou mesmo reescrever completamente partes de sua aplicação sem se preocupar em quebrar nada. Acredito que tanto o Google quanto o WoW têm grandes conjuntos de testes automatizados.

Resumindo: A idéia de que o código pode ser drasticamente alterado ou mesmo reescrito é válida e até mesmo incentivada, quando você se certifica de que todo o seu produto é dividido em pequenas unidades fracamente acopladas e é feito um grande esforço para criar e manter testes automatizados. para essas unidades.

Claro, esta é apenas a minha interpretação colorida pela minha experiência. Eu posso estar errado e o palestrante é realmente louco e suas idéias insustentáveis.

    
por 04.01.2018 / 15:18
fonte
0

Ele provavelmente exagerou um pouco, mas há alguma verdade nisso.

  • "análise-paralisia": há tantas opções possíveis e maneiras de desenvolver algo que parece muito longo para o melhor ajuste da tecnologia pode se tornar contraproducente em algum momento. Talvez se você tivesse escolhido o primeiro "ok", você já teria terminado a tarefa no momento em que levaria para avaliar todas as tecnologias possíveis.

  • "roadblocks inesperados". Você não pode prever tudo. E se você investiu muuuuito tempo na construção de uma "solução" ideal para descobrir mais tarde que alguns detalhes causam problemas reais, o esforço é desperdiçado ou se consome muito tempo. Fazer o protótipo inicial é uma maneira muito boa de explorar o que está à sua frente, incluindo as armadilhas.

  • "retornos antecipados". Um protótipo é muito útil, seja como prova de conceito. Talvez você tenha que reescrever tudo (e melhor) na próxima vez, mas você ganhou informações valiosas, feedback, maneiras de melhorá-lo ... e talvez o seu projeto não estivesse à tona senão porque a solução "certa" teria sido muito demorado.

  • "tecnologias antigas". Especialmente para projetos maiores, no momento em que você termina, é provável que muitas ferramentas, tecnologias, APIs e bibliotecas tenham progredido a ponto de sua solução atual parecer obsoleta. Eu já trabalhei em uma empresa que transicionava grandes bases de código de assembler para C, C ++ e agora provavelmente C # e em uma década, também mudaria. Da mesma forma, as GUIs do JAVA são portadas para os técnicos da Web, os web techs são portados para o celular nativo e assim por diante, e assim por diante.

... então, bem, sim, é uma questão de encontrar o equilíbrio certo entre planejar e fazer.

    
por 04.01.2018 / 19:39
fonte
0

Quando você está criando um protótipo de uma peça pequena de um grande projeto, os comentários do seu palestrante estão certos.

Por exemplo, quando trabalhei em uma empresa de sequenciamento genético da próxima geração, muitos dos algoritmos foram desenvolvidos em python devido à familiaridade com os cientistas de dados e à velocidade do desenvolvimento. Muitas vezes, era preciso muito trabalho de hacking e experimentação para obter as estruturas de E / S e de dados corretas e para atender aos requisitos de velocidade e espaço de processamento dos enormes conjuntos de dados. Às vezes usamos R ou MatLab. Há muitas outras opções aqui.

Depois que o protótipo estava funcionando, a interface inicial para ele era via linha de comando. Lentamente, ao longo do tempo, a maioria foi convertida para o nosso aplicativo "real", escrito em Java, que foi visto (note que eu não estou tomando uma posição sobre isso!) Como mais robusto e sustentável, e certamente estava mais familiarizado com o software engenheiros.

    
por 04.01.2018 / 22:55
fonte
0

O código não é constantemente reescrito, então tudo já está baseado em uma suposição errada.

Às vezes você tem código usado uma vez e nunca mais. Qualidade não importa se você pode verificar se o resultado está correto. A maioria dos códigos não é assim.

Às vezes as pessoas escrevem protótipos com a intenção de jogar fora o protótipo e escrever o código real mais tarde. E então você faz o gerenciamento decidir que o protótipo de lixo é bom o suficiente e que a má qualidade vai assombrá-lo para sempre. Em teoria, isso não deveria acontecer. Na prática, há uma diferença entre teoria e prática.

A menos que você tenha 100% de certeza de que a baixa qualidade não afetará VOCÊ, mas sim o problema de outra pessoa, certifique-se de que tudo o que você fizer tenha qualidade satisfatória desde o início. É mais barato assim.

    
por 05.01.2018 / 09:11
fonte