Os métodos de desenvolvimento devem esmagar o individualismo de um desenvolvedor?

Estou no meu semestre final da faculdade e estou fazendo um curso de engenharia de software. Na aula, aprendemos sobre vários métodos de desenvolvimento de software. O que focamos e usamos para desenvolver nosso projeto foi o método em cascata.

Sinto que o instrutor pode ter implementado errado. Em nossos diagramas de classe, tivemos que listar TODAS as propriedades e métodos, incluindo os privados. Eu li alguns livros, ou seja, Código Limpo, que dizem manter as funções o mais curtas e focadas possível. Parece tedioso listar todas as pequenas funções em nossos diagramas se elas não ajudarem outros desenvolvedores (são particulares, ninguém mais as usará). Além disso, talvez eu não pense em todas as pequenas funções ao projetar o programa, elas podem surgir quando refatoradas.

O instrutor nos disse errado ao pedir que listássemos todas as funções? E esses métodos de design reprimem o individualismo do desenvolvedor para escrever o código de como ele pode melhor entendê-lo?

Você perguntou ao instrutor por que você tinha que listar todos os métodos?

É possível que, como com grande parte do que é solicitado em um ambiente de sala de aula, a intenção não fosse tornar os diagramas de turma mais úteis para os desenvolvedores, mas ajudar você e seus colegas a pensar em como você projetaria suas aulas. Quando os alunos estão aprendendo a decompor problemas maiores em problemas menores, provavelmente é útil que eles pensem sobre quais métodos particulares eles provavelmente precisariam. E provavelmente é útil para o instrutor ter uma idéia melhor de quais métodos os alunos estão pensando em implementar, a fim de intervir mais cedo no processo, se o projeto de alguém for mal pensado. A documentação em um ambiente de sala de aula geralmente é muito mais envolvida do que a documentação em um ambiente do mundo real porque o instrutor

Obviamente, também é possível que o instrutor acredite que esse nível de documentação seja útil em um projeto real. Se for esse o caso, o instrutor provavelmente está desatualizado ou veio de um nicho específico em que esse nível de planejamento e documentação é apropriado. Se você está construindo o sistema de navegação para o ônibus espacial ou projetando dispositivos médicos, por exemplo, geralmente é muito mais apropriado investir pesadamente no design antecipado, em vez de refatorar o código durante o desenvolvimento. Se você está desenvolvendo um site de rede social, por outro lado, uma abordagem mais ágil é mais apropriada.

Não, o instrutor está certo ao pedir para listar todas as propriedades e métodos antecipadamente, se você estiver usando o método em cascata. A Wikipedia observa uma crítica à cachoeira:

Muitos argumentam que o modelo em cascata é uma péssima idéia na prática - acreditando ser impossível para qualquer projeto não trivial concluir perfeitamente uma fase do ciclo de vida de um produto de software antes de passar para as próximas fases e aprender com elas. Por exemplo, os clientes podem não saber exatamente quais requisitos eles precisam antes de revisar um protótipo em funcionamento e comentar sobre ele. Eles podem alterar seus requisitos constantemente. Designers e programadores podem ter pouco controle sobre isso. Se os clientes alterarem seus requisitos após a finalização do design, ele deverá ser modificado para acomodar os novos requisitos. Isso significa efetivamente invalidar uma boa quantidade de horas de trabalho, o que significa aumento de custo, especialmente se uma grande quantidade de recursos do projeto já foi investida no Big Design Up Front.

Esses métodos de desenho não esmagam o implementador do individualismo do desenho, pois ainda há partes para interpretar e maneiras de dar toques únicos à estrutura, por exemplo, uma figura com um esqueleto e adicionar músculos e outros tecidos para criar um animal imaginando quanto liberdade você teve que projetar esse animal?

Você encontrou uma falha na cachoeira sim, mas tudo tem seus pontos fortes e fracos.

Na aula, aprendemos sobre vários métodos de desenvolvimento de software. O que focamos e usamos para desenvolver nosso projeto foi o método em cascata.

Você provavelmente aprendeu o modelo clássico da Cachoeira, que a pessoa atribuída ao apresentá-lo ao mundo do desenvolvimento de software declarou desde o início que era inadequado para o desenvolvimento de sistemas de software em larga escala. Você provavelmente estaria interessado em ler o artigo de Winston Royce intitulado Gerenciando o desenvolvimento de grandes sistemas de software para aprender mais sobre os problemas com o que muitas pessoas consideram o modelo Waterfall.

No entanto, o modelo Waterfall é bom para ensinar o ciclo de vida de desenvolvimento de software à medida que você avança e pode gastar tempo aprendendo e executando engenharia de requisitos, design arquitetônico, design detalhado, implementação, teste e manutenção em fases muito claras e distintas.

Em nossos diagramas de classe, tivemos que listar TODAS as propriedades e métodos, incluindo os privados. Eu li alguns livros, ou seja, Código Limpo, que dizem manter as funções o mais curtas e focadas possível. Parece tedioso listar todas as pequenas funções em nossos diagramas se elas não ajudarem outros desenvolvedores (são particulares, ninguém mais as usará). Além disso, talvez eu não pense em todas as pequenas funções ao projetar o programa, elas podem surgir quando refatoradas.

Todos esses são pontos muito válidos.

Listar todas as propriedades e métodos durante a fase de design, mesmo ao usar o Waterfall, provavelmente é um exagero. Você definitivamente deve listar tudo o que é público, juntamente com as propriedades essenciais. Na realidade, tudo o resto é um detalhe de implementação que você pode obter através da engenharia reversa de sua implementação em diagramas.

O conselho do Clean Code (nunca o li - só estou seguindo o que você postou) parece ser justo e aplicável mesmo ao usar a metodologia Waterfall. Você pode projetar suas classes e métodos com respeito ao Princípio de responsabilidade única , separação de preocupações e outros princípios do SOLID . O Waterfall não diz como projetar, exatamente quando você precisa fazê-lo. Dito isto, é mais difícil desde o início, à medida que você aprende e pensa em maneiras melhores de fazê-lo durante a implementação.

Eu acho que isso indica o fato de que precisa haver uma iteração entre design e implementação muito claramente - um problema que o Waterfall tradicional não explica.

Parece tedioso listar todas as pequenas funções em nossos diagramas se elas não ajudarem outros desenvolvedores (são particulares, ninguém mais as usará).

Se você acha isso tedioso, espere até obter uma programação de trabalho real. Considere, por um momento, que o software pode não ser uma carreira viável para você.

Além disso, talvez eu não pense em todas as pequenas funções ao projetar o programa, elas podem surgir quando refatoradas.

Então?

o instrutor nos disse errado pedindo que listássemos todas as funções?

Não. É um requisito comum.

E esses métodos de design reprimem o implementador do individualismo de design (o desenvolvedor) para escrever o código de como eles podem melhor entendê-lo?

Sim. O esmagamento da alma dos indivíduos é uma parte importante do desenvolvimento de software. Toda a individualidade será derrotada de todos os programadores em todos os momentos, de todas as maneiras possíveis. Diz que em algum lugar das "Regras de Programação de Deus" transmitidas de alguma montanha a algum profeta.

Não. Você está apenas recusando o tédio. Supere isso e volte ao trabalho.

Programação é a arte de trabalhar dentro de restrições. A CPU fornece um conjunto de instruções limitado; E / S é restrita pelo design do hardware; As APIs do sistema operacional são criadas para incentivar certos comportamentos e restringir outros; linguagens de alto nível geralmente são projetadas para promover um conjunto de idiomas em detrimento de outros ...

E metodologias também são criadas para restringir.

Seu desafio, em todos os aspectos do processo de desenvolvimento, é realizar sua visão dentro dessas restrições. Você vai bater a cabeça contra cada parede erguida por hardware, linguagem, API e metodologia? Ou você encontrará uma maneira de harmonizar o que deseja alcançar com o que é permitido e incentivado?

Você realmente acha que seu instrutor deseja ler inúmeras páginas de minúcia? Depois teste essa teoria: divida um programa e documente cada átomo. Quando a mesa dele está caída sob o peso, suspeito que você descobrirá que o verdadeiro desejo dele é um pouco diferente do que você espera.

Ou preparar a documentação como você vê o ajuste. Deixe claro, compreensível, faça com que seja lido como um romance de Dashiell Hammett. E então sente-se e converse com ele, mostre a ele o que você fez, convença-o de seu mérito.

Eu acho que o instrutor é brilhante por fazer você fazer esse projeto e, assim, ensinando-lhe os prós e contras (principalmente) do desenvolvimento do Waterfall.

Uma regra simples para avaliar a complexidade da análise de projeto é "O desenvolvedor ou a empresa em que trabalha pode ser responsabilizado por algo dramático o suficiente (geralmente incluindo morte ou grande quantidade de dinheiro perdido) acontecendo com o software criado?".

Eu tive a mesma experiência que você em alguns dos meus cursos. Pessoas com formação na indústria militar nos ensinariam análise. E isso seria uma análise completa e exaustiva, planejando todo o andamento do projeto, mesmo nos mínimos detalhes. Você não pode pagar muitas iterações com esse tipo de projeto (também a explosão de bombas pode ser boa, a explosão de orçamento não é); portanto, não há lugar para criatividade aqui; é preciso seguir o plano.

Por outro lado, se você leu um pouco, certamente leu sobre metodologias ágeis. Geralmente, há menos documentação e mais espaço para o desenvolvedor usar sua criatividade enquanto desenvolve uma solução para o problema que encontra.

Em conclusão, quanto mais experiência você obtiver, melhor e o que o seu instrutor está mostrando a você se aplica a alguma parte do setor. Esteja ciente de que certamente existem tantas maneiras de gerenciar e projetar um projeto quanto de codificá-las. E você encontrará defensores e críticos para todos eles. Teste-os enquanto estiver estudando e escolha o que mais lhe agrada.

Algumas aulas de engenharia de software, como a que eu tive, são ministradas em um estilo estranho, onde 'falha é sucesso', sucesso é uma oportunidade desperdiçada de aprender com a falha e mais é menos e menos é mais. Se esse é um deles, basta seguir as tarefas e apreciar a estranheza.

Eu acho que seu instrutor está fora de contato. O software comercial raramente é projetado ou documentado nessa extensão. É muito caro e a documentação resultante não pode ser mantida sem ainda mais despesas. Essas práticas da IMO são um legado dos dias em que a codificação era frequentemente feita em linguagem assembly. Você gastaria mais tempo tentando práticas mais ágeis: desenvolvimento orientado a testes, programação de pares, refatoração contínua.

O instrutor "lhe disse errado"?

Acho que sim.

Atribuir trabalho chato a trabalhadores de propriedade intelectual é um desperdício. Na escola, o trabalho chato tem pouco ou nenhum valor pedagógico, exceto, talvez, para atrair os alunos para o trabalho chato. Tais exercícios têm consequências negativas, tanto para os estudantes quanto para a indústria. Os alunos são prejudicados porque seu tempo é perdido. A indústria está prejudicada, porque alguns estudantes podem concluir que esse tédio é necessário e útil. Não é nenhum. Em trinta anos em software, o único trabalho que consigo pensar que era ao mesmo tempo chato e útil era trocar fitas de backup. Havia robôs que podiam fazer isso, mas eram proibitivamente caros.