Quais práticas específicas poderiam ser chamadas de “artesanato em software” em vez de “engenharia de software”? [fechadas]

Embora não seja uma idéia nova , parece ter havido um grande aumento no interesse pelo artesanato de software nos últimos dois anos (principalmente o título completo do livro Clean Code, frequentemente recomendado, é Clean Code: A Handbook of Agile Software Craftsmanship ).

Pessoalmente, vejo o artesanato em software como uma boa engenharia de software, com um interesse adicional em garantir que o resultado final seja um prazer para trabalhar (tanto como usuário final quanto como alguém que mantém esse software) - e também que seu foco está mais no nível de codificação das coisas do que o nível superior processa as coisas.

Para fazer uma analogia - havia muitos edifícios construídos nos anos 50 e 60 em um estilo muito moderno, que levava muito pouco em conta as pessoas que morariam neles ou como esses edifícios envelheciam ao longo do tempo. Muitos desses edifícios rapidamente se transformaram em favelas ou foram demolidos muito antes da expectativa de vida útil. Tenho certeza que a maioria dos desenvolvedores com alguns anos de experiência terá experimentado bases de código semelhantes.

Quais são as coisas específicas que um especialista em software pode fazer que um engenheiro de software (possivelmente ruim) não pode?

Eu diria que a única diferença entre um profissional e um artesão é se importar com um pouco de paixão misturada . Não existe uma prática observável específica que classifique alguém como artesão, mas sim uma coleção de qualidades:

• Um artesão se preocupa com a qualidade real de seu trabalho, e não apenas com a qualidade percebida.
• Um artesão tem interesse em seu ofício que vai além da realização do trabalho e naturalmente se aproxima de seu ofício.
• Um artesão se preocupa com sua profissão, aspirando a melhorar suas habilidades e não apenas avançar em sua carreira .
• Um artesão passa uma quantidade de tempo fora do horário de trabalho remunerado (mesmo que seja uma pequena quantidade de tempo) fazendo algo com sua arte, seja discutindo, aprendendo ou até pensando nisso.
• Um artesão sabe quão pouco ele realmente sabe, e é humilhado por isso.
• Um artesão está disposto a ensinar aqueles que estão dispostos a aprender, guiar aqueles que buscam orientação e buscar essas coisas quando precisar delas.

Um pouco de paixão cobre tudo isso sem suar a camisa.

Pessoalmente, vejo o artesanato em software como uma boa engenharia de software, com um interesse adicional em garantir que o resultado final seja um prazer para trabalhar (tanto como usuário final quanto como alguém que mantém esse software) - e também que seu foco está mais no nível de codificação das coisas do que o nível superior processa as coisas.

Como disse um professor meu (parafraseado): "Como engenheiro de software, não é apenas seu trabalho entregar software. É seu trabalho entregar software que faça seus clientes felizes."

Quais são as coisas específicas que um especialista em software pode fazer que um engenheiro de software (possivelmente ruim) não pode?

Nada - um engenheiro é um artesão ... mas mais. A engenharia se baseia no artesanato.

Como artesão e engenheiro, você é uma pessoa qualificada, através de uma combinação de educação e experiência. Você segue os procedimentos estabelecidos. Você também é pragmático e percebe o que está quebrado e precisa ser melhor.

No entanto, um engenheiro acrescenta preocupações de economia, teoria e ciência além disso. Você está preocupado em obter o maior benefício pelo menor custo. Você deseja aplicar teorias da psicologia, sociologia, gerenciamento, interações homem-computador e ciência da computação para resolver seus problemas (interpessoais e técnicos). E você definitivamente tem uma educação para fazer backup de suas experiências.

O movimento de criação de software foi iniciado em reação às falhas e aos resultados insatisfatórios da engenharia de software "tradicional" que (junto com o descuido de alguns desenvolvedores) hoje leva à desconfiança das partes interessadas e dos usuários em relação à nossa profissão.

Seu objetivo é duplo: restaurar a confiança nos programadores e, para isso, elevar a fasquia da qualidade do software e das habilidades do desenvolvedor.

O artesanato Sw promove práticas técnicas como:

• Princípios de design do SOLID
• Padrões de design
• TDD (metáfora "contabilidade de dupla entrada")
• ...

E práticas de equipe / organização:

• Programação em pares
• Mentoria
• Code katas
• Dojos / retiros de código
• ...

Então, eu diria que a diferença entre os dois é clara: o artesanato em software tenta resolver uma grande parte dos problemas que a engenharia de software tem em mais de 40 anos de existência, que hoje fazem com que nossa disciplina pareça não confiável e comprometida com um histórico de falhas.

Indo em http://manifesto.softwarecraftsmanship.org/ Eu derivaria o seguinte.

Um artesão é diferente das percepções tradicionais de um "engenheiro" porque

• Eles se concentram no valor, não apenas no atendimento aos requisitos.
• Eles se concentram na qualidade, mesmo no estilo de seu código, não apenas no atendimento aos requisitos.
• Eles participam da comunidade mais ampla de desenvolvimento de software, não apenas no local de trabalho.
• Eles não entendem apenas que o estado da arte de hoje é o lixo de amanhã, eles são ativos em realizá-lo em um nível ou outro.
• Não é apenas um trabalho, é quem eles são .

De alguma forma, o tio Bob deu a entender que a programação é uma disciplina muito jovem que ainda não possui um corpo estável de leis ou regras reconhecidas pelos governos (ou era Frederick Brooks?). Não estou fazendo uma citação verbatin aqui.

Você não pode revogar ninguém a permissão para programar devido a más práticas. A programação carece de um corpo de leis e regras que sejam legalmente aplicadas pela legislação que conforma uma "profissão". Um médico mata um paciente devido à incompetência e corre o risco de obter seu título ou permissão médica.

Um programador cria um programa de buggy ou falha no projeto devido à incompetência e fica livre para continuar programando.

Eu acho que é isso que torna a programação um ofício. Um fabricante de panelas de barro não faz dois potes idênticos. Você também nunca ouviu falar de um fabricante de panelas de barro forçado a se lembrar de panelas com defeito. A programação ainda é um tipo de trabalho muito manual e pessoal. Às vezes, você pode até dizer quem escreveu um pedaço de código, julgando pelo estilo dele.

Refatoração para padrões.

Ou seja, crie algo que atenda a 90% dos requisitos de software e refatorar todo o projeto em um design limpo e elegante.

Normalmente, a engenharia de software impediria que você fizesse isso, pois satisfazer 90% dos requisitos significa que o software possui valor comercial suficiente para o cliente e não deve ser modificado de maneira significativa (exceto correções de alta prioridade).

A engenharia de software recomendaria que você estabilizasse o software neste momento.

Além disso, se um projeto não começar com esse design elegante desde o início, ele seria considerado um projeto mal executado (independentemente do resultado do projeto), de acordo com a engenharia de software.

Solução Spike.

Um design inspirado em uma solução de pico normalmente não é aceitável de acordo com a metodologia de engenharia de software vigente.

Deprecação , por qualquer motivo.

Na engenharia de software, qualquer tipo de descontinuação é permitida apenas no final do ciclo de vida de um sistema de software. Isso deve ser planejado como parte do SDLC.

Na prática, é bastante comum que as deficiências de uma parte específica da interface do software sejam descobertas alguns anos após a produção, e essa parte específica possa ser preterida no meio do ciclo de vida, sem invalidar o restante do software. Isso exigiria uma recertificação de todo o sistema de software após a reprovação, de acordo com a engenharia de software.

No final, o artesanato em software é uma luta pessoal por bons julgamentos de indivíduos, enquanto a engenharia de software é um corpo conservador de conhecimento. Permitir esse bom julgamento na tomada de decisão do projeto é o que separa o artesanato de software da engenharia de software.

Eu diria que ter testes de unidade cobrindo 100% do código seria bom. Isso permite que o excesso de material seja retirado.

Às vezes, comparo o desenvolvimento de software à escultura. Não é o que você adiciona, é o que você tira.

Obviamente, você pode levar isso longe demais. Ninguém vai dizer que uma pedrinha brilhante é uma boa escultura: S