Quali pratiche specifiche potrebbero essere chiamate "artigianato del software" piuttosto che "ingegneria del software"? [chiuso]

Direi che l'unica differenza tra un professionista e un artigiano è prendersi cura di un po 'di passione mescolata in . Non esiste una pratica specifica osservabile che classificherebbe uno come artigiano, ma piuttosto una raccolta di qualità:

• Un artigiano si preoccupa della qualità effettiva del suo lavoro, e non solo della qualità percepita.
• Un artigiano ha un interesse per la sua arte che va oltre il lavoro svolto e, naturalmente, gravita attorno al suo mestiere.
• Un artigiano si preoccupa della sua professione, aspira a migliorare le sue abilità e non solo ad anticipare la sua carriera .
• Un artigiano trascorre un po 'di tempo fuori dal suo orario di lavoro retribuito (anche se è una piccola quantità di tempo) facendo qualcosa con il suo mestiere, sia che discuta, apprenda o addirittura ci pensi.
• Un artigiano sa quanto poco sappia e ne viene umiliato
• Un artigiano è disposto ad insegnare a coloro che sono disposti a imparare, a guidare coloro che cercano una guida e a cercare quelle cose quando ne ha bisogno.

Un po 'di passione copre tutti questi aspetti senza sudare.

Personally I see software craftsmanship as good software engineering with an added interest in ensuring that the end result is a joy to work with (both as an end user and as someone maintaining that software) - and also that its focus is more at the coding level of things than the higher level process things.

Come professore di mine ha detto una volta (parafrasato): "Come un ingegnere del software, non è solo il tuo lavoro per fornire il software È il vostro lavoro per fornire un software che rende felici i vostri clienti.".

What are the specific things that a software craftsman might do that a software engineer (possibly a bad one) might not?

Niente - un ingegnere è un artigiano ... ma di più. L'ingegneria si basa sull'artigianato.

In qualità di artigiano e ingegnere, sei una persona competente, attraverso una combinazione di educazione ed esperienza. Segui le procedure stabilite. Sei anche pragmatico e realizza ciò che è rotto e ha bisogno di essere migliore.

Tuttavia, un ingegnere aggiunge preoccupazioni di economia, teoria e scienza. Sei preoccupato di ottenere il massimo beneficio per il minor costo. Vuoi applicare le teorie della psicologia, della sociologia, della gestione, delle interazioni uomo-computer e dell'informatica per risolvere i tuoi problemi (sia interpersonali che tecnici). E hai sicuramente un'educazione per sostenere le tue esperienze.

Il movimento del software artigianale è stato avviato in risposta ai fallimenti e ai risultati insoddisfacenti dell'ingegneria del software "tradizionale" che (insieme alla negligenza di alcuni sviluppatori) oggi portano a sfiducia nei confronti delle parti interessate e degli utenti verso la nostra professione.

Il suo obiettivo è duplice: ripristinare la fiducia nei programmatori e, al fine di farlo, innalzare la barra della qualità del software e delle capacità di sviluppo.

La lavorazione artigianale promuove pratiche tecniche come:

• Principi di progettazione SOLID
• Modelli di design
• TDD (metafora "double entry accounting")
• ...

E pratiche di gruppo / organizzative:

• Accoppia programmazione
• Mentoring
• Code katas
• Dojos / code retreats
• ...

Quindi direi che la differenza tra i 2 è chiara: l'artigianato del software cerca di risolvere gran parte dei problemi che l'ingegneria del software ha avuto in oltre 40 anni di esistenza che oggi rendono la nostra disciplina inaffidabile e paralizzata da una storia di fallimenti .

Seguendo il link ricaverei quanto segue.

Un artigiano è diverso dalle percezioni tradizionali di un "ingegnere" perché

• Si focalizzano sul valore, non solo sui requisiti di riunione.
• Si focalizzano sulla qualità anche nello stile del loro codice, non solo sui requisiti di riunione.
• Partecipano alla più ampia comunità di sviluppo software, non solo al loro posto di lavoro.
• Non capiscono solo che lo stato dell'arte di oggi è spazzatura di domani, sono attivi nel portarlo a un livello o un altro.
• Non è solo un lavoro, è chi sono sono .

Lo zio Bob in qualche modo ha suggerito che la programmazione è una disciplina molto giovane che non ha ancora un corpo stabile di leggi o regole riconosciute dai governi (o era Frederick Brooks?). Non sto facendo una citazione verbatin qui.

Non puoi revocare a nessuno il permesso di programmare a causa di negligenza. La programmazione è priva di un corpus di leggi e regole che sono legalmente applicate da una legislazione che conforma una "professione". Un medico uccide un paziente a causa di incompetenza e rischia che il titolo del medico o il permesso venga sottratto a lui.

Un programmatore esegue un buggy o fa fallire un progetto a causa dell'incompetenza ed è libero di continuare a programmare.

Penso che sia praticamente ciò che rende la programmazione un mestiere. Un produttore di vasi di terracotta non produce due vasi identici. Né hai mai sentito parlare di un produttore di vasi di terracotta costretto a ricordare pentole difettose. La programmazione è ancora un tipo di lavoro molto manuale, personale. A volte puoi persino dire a chi ha scritto un pezzo di codice a giudicare dal suo stile.

Refactoring To Patterns.

Cioè, costruisci qualcosa che soddisfi il 90% dei requisiti software, quindi rifatta l'intero progetto in un design pulito ed elegante.

Normalmente, l'ingegneria del software ti impedirebbe di farlo, perché soddisfare il 90% dei requisiti significa che il software ha un valore commerciale sufficiente per il cliente da non poter essere modificato in alcun modo significativo (eccetto bugfix ad alta priorità).

L'ingegneria del software dovrebbe invece consigliare di stabilizzare il software a questo punto.

Inoltre, se un progetto non parte da quel design elegante fin dall'inizio, sarebbe considerato un progetto eseguito male (indipendentemente dal risultato del progetto), secondo l'ingegneria del software.

Soluzione spike

Normalmente, un design ispirato a una soluzione spike non è accettabile secondo la metodologia di ingegneria del software prevalente.

Deprecation , per qualsiasi motivo.

Nell'ingegneria del software, qualsiasi tipo di deprecazione può accadere solo alla fine del ciclo di vita di un sistema software. Questo deve essere pianificato come parte dello SDLC.

In pratica, è piuttosto comune che i difetti di una parte specifica dell'interfaccia del software vengano scoperti da alcuni anni nella produzione e che la parte specifica possa essere deprecata nel bel mezzo del ciclo di vita, senza invalidare il resto del Software. Ciò avrebbe richiesto una nuova certificazione dell'intero sistema software dopo la deprecazione, secondo l'ingegneria del software.

Alla fine, l'artigianalità del software è un tentativo personale di giudizi positivi da parte di individui, mentre l'ingegneria del software è un corpo di conoscenze conservatore. Permettere che il buon senso nel processo decisionale del progetto sia ciò che separa l'artigianato del software dall'ingegneria del software.

Direi che test di unità che coprono il 100% del codice sarebbero buoni. In quanto ciò consente di rimuovere le cose in eccesso.

A volte paragono lo sviluppo del software alla scultura. Non è quello che aggiungi, è ciò che togli.

Ovviamente puoi prenderlo troppo lontano. Nessuno dirà che un piccolo ciottolo lucido è una buona scultura: S