Como melhorar o treinamento dos alunos em relação à manutenção? [fechadas]

A manutenção é uma parte importante do desenvolvimento profissional de software. De fato, a manutenção é quase sempre a parte mais longa de um ciclo de vida de software, pois dura desde o lançamento do projeto até basicamente o fim dos tempos.

Além disso, os projetos em manutenção representam uma grande maioria do número total de projetos. De acordo com http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/ , a proporção de projetos em manutenção é de aproximadamente 2 / 3

Recentemente, me deparei com essa pergunta , em que o cara parece bastante surpreso ao descobrir que seu trabalho é principalmente sobre manutenção. Decidi então abrir uma discussão (em francês) no site principal da comunidade francesa de profissionais de desenvolvimento de software ( http://www.developpez.com/ ). A discussão é intitulada "Os alunos estão suficientemente treinados para a realidade do desenvolvimento profissional de software?" e é principalmente sobre manutenção . Assinalou-se que, pelo menos na França, as pessoas não estão suficientemente preparadas para enfrentar a manutenção nos dois aspectos:

• manter código existente
• tornar código sustentável

Minha pergunta aqui ecoa essa discussão e visa encontrar uma boa maneira de ensinar a manutenção.

• Como podemos ensinar a manutenção?
• Que tipo de exercício você sugeriria?
• Se você foi bem treinado em relação à manutenção, que tipo específico de curso você fez?

Depois de algum mal-entendido, acho que devo esclarecer minha pergunta. Como líder de projeto e desenvolvedor de software, frequentemente trabalho com estagiários ou estudantes recém-formados. Uma vez eu me formei recentemente. O fato é que os alunos geralmente não estão familiarizados com princípios como o SOLID que aumentam a capacidade de manutenção de um projeto. Muitas vezes, acabamos tendo dificuldades importantes para a evolução dos projetos (baixa manutenção). O que estou procurando aqui é um exemplo acadêmico concreto de ensino bem-sucedido sobre a importância da manutenção e como criar um código melhor com relação a esse ponto em particular; ou possíveis sugestões para melhorar a forma como os alunos são treinados.

Como podemos ensinar a manutenção?

Isso é uma questão de prática.

A maneira mais direta de praticá-la de uma maneira controlada em que consigo pensar é simular o projeto de manutenção típico da seguinte maneira.

Obtenha um projeto ( Projeto A ) bem-feito e introduza alguns problemas: injete alguns bugs, uma boa soneca de código duplicado e inoperante, elimine alguns recursos, testes de unidade e documentação aqui e ali, etc. Você pode até ter um dedicado nome para isso, como Projeto A - versão danificada .

Estabeleça um rastreador de problemas e preencha-o com solicitações correspondentes a danos específicos que você fez. Estabeleça regras e práticas básicas para o processo de desenvolvimento - VCS confirma, revisões de código, controle de qualidade etc. - considere tirar o que puder da lista de verificação fornecida no The Joel Test .

• 1.
  Corrija bugs, adicione testes de unidade ausentes, documentação e recursos.
• curso 2.
  Refatorar.
• 3.
  Manutenção / aprimoramento de projetos originais para uso dos alunos do próximo ano
  - Projeto A versão 2.0 e Projeto A - versão danificada 2.0 , respectivamente.
  _{Ao melhorar a versão danificada, quero dizer causar um dano educacional melhor a ela. :)}

Das práticas mencionadas acima, preste atenção especial nas revisões de código . Essa é provavelmente a maneira mais eficaz de garantir que o código seja fácil de manter, conforme indicado, por exemplo, pela resposta principal na pergunta relacionada .

Disclaimer: Acabei de obter meu diploma de CS. Eu não sou um professor.

Isso pode parecer óbvio, mas acho que a melhor maneira de ensinar manutenção de código é fazer com que os alunos realizem manutenção de código. Aqui está o que eu faria:

1. Pegue um problema moderadamente complexo e duas implementações semanticamente idênticas, mas uma é muito mais sustentável do que a outra.
2. Solicite várias alterações / adições de recursos que sejam muito mais fáceis de implementar na melhor base de código. Metade dos alunos precisa implementá-los na base de código mais sustentável, e a outra metade na base menos sustentável.
3. Por uma questão de justiça, convém repetir este exercício com os papéis invertidos.
4. Compare o número médio de alterações implementadas com sucesso entre as bases de código boas e ruins e o tempo gasto na implementação. Peça aos alunos que compartilhem suas experiências, exponham suas queixas e falem sobre o trabalho que fizeram.

A idéia é não apenas fazer com que os alunos trabalhem com o código de outra pessoa, mas também com que eles desenvolvam uma apreciação pelo código de manutenção que, esperamos, melhore suas habilidades de design.

A manutenção é uma virtude, não uma habilidade. Existem muitos caminhos para a criação de projetos de manutenção, mas nenhuma fórmula é garantida para produzi-los.

Se você valoriza virtudes como bondade e generosidade, procura maneiras de praticar o mesmo em sua vida diária. É o mesmo com a manutenção: se você e sua organização valorizam a manutenção, você a mantém em mente enquanto cria e implementa seu projeto. Será uma razão legítima para gastar um pouco de tempo extra construindo algo, porque você sabe que a manutenção é apreciada. Por outro lado, gastar tempo extra para manter a manutenção em uma organização que não valoriza isso é desencorajado.

Se você deseja ensinar as pessoas a tornar as coisas possíveis de manter, comece deixando claro que sua organização valoriza a capacidade de manutenção. Especifique nos requisitos para seus projetos. Torne-o um dos critérios para revisões de código bem-sucedidas. Em resumo, faça da manutenção parte de sua cultura .

Em seguida, esteja disposto a dedicar alguns recursos para melhorar a capacidade de manutenção em seus projetos existentes. Identifique as partes de um projeto em que os bugs continuam aparecendo ou onde a correção de bugs ou as alterações são muito difíceis e demoram muito tempo e redesenhe ou refatore para facilitar a manutenção.

Por fim, doutrine novos desenvolvedores em sua cultura de manutenção atribuindo-os a equipes que já o praticam diariamente. Não há melhor maneira de ajudar alguém a adotar um valor do que dar-lhe muitos bons exemplos e orientações.

Eu não gosto do termo Mantido em relação ao desenvolvimento de software. A realidade é que todo software é passível de manutenção, pois pode estar sujeito a trabalhos de manutenção; portanto, o problema real é se o software é caro ou barato de manter, relativamente falando. Sei que isso soa como uma afirmação muito pedante no início de uma resposta, mas meu argumento ficará mais claro em um momento.

O problema dos diplomas de TI, que se especializam no desenvolvimento de software, é que eles realmente ensinam aos alunos apenas o mínimo que eles precisam saber sobre como escrever software. As habilidades e conhecimentos profissionais são adquiridos através do aprendizado realizado nos primeiros anos apósqualificação para o grau. É quando um graduado começa a trabalhar em projetos que realmente importam para o cliente, em um ambiente onde há grande pressão para executar, e a expectativa é criar um produto com padrão profissional. Infelizmente, muitas empresas não incentivam uma cultura em que os padrões profissionais em software são mantidos e acabam com projetos que resultam dispendiosos em desenvolver e manter como resultado. Infelizmente para os nossos graduados, eles aprendem muitos hábitos ruins nesses ambientes nos primeiros anos de suas carreiras, e pode levar muito tempo até que aprendam a superar esses hábitos ... se é que isso acontece.

Seria melhor ensinar aos alunos como escrever código limpo e como identificar os problemas no software que geralmente acabam incorrendo em dívidas técnicas . Examine os livros sobre Código Limpo , Refatoração e Desenvolvimento Lean de Software como ponto de partida e ensine os alunos a escrever testes de unidade antes do código de implementação, a fim de garantir um alto grau de cobertura. Ensine os alunos a reconhecer padrões duplicados e repetitivos em seu código e como refatorar o código para remover essa duplicação. Ajude os alunos a entender e aplicar princípios como SOLID e DRY. Mais importante, elimine essa idéia de que a capacidade de manter o código é algo que é feito com base apenas no design e na implementação do código e, em vez disso, instila um senso de habilidade e qualidade na produção de software desde o início, buscando refine o código conforme ele é implementado para minimizar o impacto da dívida técnica e, assim, manter o custo de manutenção de software no mínimo com o tempo.

Eu acho que a melhor maneira de aprender esse tipo de habilidade é fazendo revisões de código e programando pares. Durante as revisões de código, a equipe experiente pode apontar como tornar o código mais sustentável (normalmente tornando-o mais legível) e justificar por que certas opções podem criar um código mais sustentável.

A programação em pares é uma maneira ainda melhor de ensinar esse tipo de coisa, porque oferece experiência direta à equipe menos experiente em manter o código com alguém que já sabe como fazê-lo bem.

Também existem ótimos livros que você pode ler sobre como escrever códigos limpos e de manutenção. Código limpo vem à mente.

É difícil obter essa experiência na academia, pois os alunos raramente modificam grandes bases de código. A maioria dessas habilidades virá do aprendizado no trabalho, e as revisões de código e a programação em pares podem realmente facilitar esse aprendizado.

Bom código = menos manutenção e fácil de aprimorar / adicionar recursos.

Código incorreto = pesadelo de manutenção

Basicamente, precisamos transmitir aos alunos que "sempre que houver um código de baixa qualidade em um projeto, um novo desenvolvedor que ingressará na empresa porque o autor original do código sofrerá e como o software será impactado" . "

Portanto, uma das melhores maneiras de ensinar o aluno sobre manutenção de software é mostrar o exemplo de código bom e código ruim e pedir que eles adicionem um recurso e depois ensiná-los que escrever um bom código não é apenas para satisfação pessoal, mas para criar É fácil para as pessoas que manterão o código.

Exercício:

1) Tenha um código incorreto pré-escrito (por exemplo, código duplicado), um método que diz "para calcular o pagamento da hipoteca" é escrito em 9 locais em um projeto.

Peça ao aluno para aprimorar o recurso para "adicionar sobretaxa de 1,2% a todos os pagamentos de hipoteca".

Agora, o aluno verá a dor de localizar e corrigir o código nos 9 locais. Há muitas chances de ele não conseguir localizar todos os 9 locais em que o "pagamento da hipoteca" é calculado.

2) Agora mostre o código Good que possui esse método que calcula o pagamento da hipoteca em um único local . demonstre ao aluno como é fácil aprimorar um código bem escrito e explique como ele aprimora a manutenção do código / projeto.

BTW, adorei sua abordagem de expor os alunos à manutenção do software.

@mattmattj: Como existem muitas respostas e o link que eu postei também tem algumas dicas, adicionarei algo que, esperançosamente, não é uma repetição das respostas já postadas.

Primeiro, DEVE definir "manutenibilidade" - não há uma única definição aceita por todos - semelhante à da arquitetura de software. Portanto, escolha uma que você julgue ser a mais importante, abrangente e declare em 3-4 linhas no máximo. Depois, você pode falar sobre algumas métricas como - tempo para lembrar / entender seu próprio código (ou de outra pessoa), número de WTFs por minuto / hora etc. Mantenha-o leve (bem-humorado) - que os tornará mais receptivos ao que você tem para dizer depois disso.

Alguns exercícios (pode parecer um pouco sobreposto com algumas das respostas, perdoe isso)

Divida a turma em duas - dê a uma seção uma tarefa simples de codificação que precisa ser feita em um ou dois dias. Máx. Prazo final. Eles precisam executar o trabalho sob todas as circunstâncias - diretrizes - "código de funcionamento", conforme entenderem. Para o outro grupo de alunos, a mesma tarefa, mas com uma lista de convenções (nomeação) e algumas diretrizes sobre design e como os pontos serão deduzidos se não forem seguidos. Isso NÃO é trapaça, mesmo que pareça;) Agora peça que eles troquem os códigos, ou seja, o grupo 1 agora trabalha com o que o grupo 2 fez e vice-versa. Agora sugira uma modificação para a atribuição de codificação original e peça que eles façam isso no mesmo período de tempo. Reconvoque e pergunte a eles como foi fácil / difícil e abra a palavra para discussões / opiniões. O ponto definitivamente chegará em casa - grandes chances de 50% da classe ficarem felizes e acharem fácil e 50% acharem difícil. Você também pode pedir que eles trabalhem por conta própria após 3 semanas e ver se eles podem fazê-lo em 1 dia;)

(Uma boa ideia é escrever o mesmo pedaço de código de maneira complicada e dar à classe para modificação juntamente com as suas próprias)

Aqui é onde você estabelece as bases da manutenção - todas as linhas de código modificadas / atualizadas custam dinheiro à empresa. Quanto mais fácil é ler e lembrar o código, melhor / mais rápida a modificação que ajudaria a diminuir o tempo de colocação no mercado. Muito importante no espaço tecnológico rápido de hoje. A manutenção é a chave para a evolução eficiente dos sistemas.

É importante entender a diferença entre desenvolvimento greenfield e brownfield - nem todo projeto ou sistema seria criado a partir do zero (é bastante difícil encontrar ou fazer parte de projetos "do zero"). Explicando que o campo é "inerentemente" marrom e você deve dedicar algum tempo para moldá-lo à medida que avança com a eventual descontinuação quando ficar "fora de controle" (possível apenas quando a deriva é excessiva e 'inatingível'). Quanto mais cedo eles aceitarem isso, melhor. Isso é difícil, pois a programação é inerentemente criativa, mas o aprimoramento do código de outra pessoa não é percebido como tal - altere-o. Criatividade, existe a capacidade de entender o código e, em seguida, aplicar a "sua" criatividade para aprimorá-lo - se melhor mantida, você poderá aprimorá-lo de maneira mais criativa no futuro.

Sinta-se à vontade para consultar a analogia do espaguete no link acima ... espero que isso ajude a atingir alguns pontos. As outras respostas ajudam a preencher as lacunas e devem ajudá-lo com o ensino! Boa sorte!