Quali pratiche specifiche potrebbero essere chiamate "arte del software" anziché "ingegneria del software"? [chiuso]

11

Sebbene non sia una nuova idea , sembra esserci stato un grande aumento dell'interesse per l'arte del software negli ultimi due anni (in particolare il libro spesso raccomandato Il titolo completo di Clean Code è Clean Code: A Handbook of Agile Software Craftsrafts ).

Personalmente considero l'artigianato del software come una buona ingegneria del software con un ulteriore interesse a garantire che il risultato finale sia una gioia con cui lavorare (sia come utente finale che come qualcuno che mantiene quel software) - e anche che il suo focus è più a livello di codifica delle cose rispetto alle cose di processo di livello superiore.

Per tracciare un'analogia: c'erano molti edifici costruiti negli anni '50 e '60 in uno stile molto moderno che teneva ben in considerazione le persone che avrebbero vissuto in essi o il modo in cui quegli edifici sarebbero invecchiati nel tempo. Molti di quegli edifici si sono rapidamente sviluppati in baraccopoli o sono stati demoliti molto prima della loro durata prevista. Sono sicuro che la maggior parte degli sviluppatori con qualche anno sotto la cintura avranno sperimentato basi di codice simili.

Quali sono le cose specifiche che un artigiano del software potrebbe fare che un ingegnere del software (forse un cattivo) potrebbe non fare?

programming-practices

— FinnNk
fonte

1

L'analogia non sembra adattarsi. Sia l'artigianato del software che l'ingegneria del software hanno lo stesso obiettivo (e interesse acquisito) di migliorare l'utilità a lungo termine del software.

— rwong

3

Penso che la questione sia principalmente una questione se si considera "ingegnere" o "artigiano" il titolo più interessante, e le risposte attuali sembrano dimostrarlo. Qualunque titolo tu preferisca, ovviamente, implica che quella persona sappia cosa stanno facendo, dopo tutto.

— Ben Brocka,

Direi che la differenza tra i due è che un artigiano lavora da solo, un ingegnere lavora come parte di una squadra. A grandi linee questo sembra soddisfare le principali descrizioni dei due ruoli, non che entrambi siano diversamente qualificati, ma i loro approcci provengono da posizioni diverse.

— gbjbaanb,

Sembra proprio un titolo davvero pretenzioso da darti.

— michaelsnowden,

13

Direi che l'unica differenza tra un professionista e un artigiano è prendersi cura di un po 'di passione mescolata . Non esiste una pratica specifica e osservabile che classifichi 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 lo svolgimento del lavoro e naturalmente gravita verso la sua arte.
Un artigiano si preoccupa della sua professione, aspirando a migliorare le sue capacità e non solo a far avanzare la sua carriera .
Un artigiano trascorre un po 'di tempo al di fuori del suo orario di lavoro retribuito (anche se è una piccola quantità di tempo) facendo qualcosa con il suo mestiere, sia che si tratti di discutere, apprendere o addirittura pensarci.
Un artigiano sa quanto poco sappia effettivamente e ne è umiliato.
Un artigiano è disposto a insegnare a coloro che sono disposti a imparare, a guidare coloro che cercano guida e a cercare quelle cose lui stesso quando ne ha bisogno.

Un po 'di passione copre tutti questi senza sudare.

— Allon Guralnek
fonte

Penso che l'ultimo sia particolarmente importante

— Lovis l'

7

Personalmente considero l'artigianato del software come una buona ingegneria del software con un ulteriore interesse a garantire che il risultato finale sia una gioia con cui lavorare (sia come utente finale che come qualcuno che mantiene quel software) - e anche che il suo focus è più a livello di codifica delle cose rispetto alle cose di processo di livello superiore.

Come un mio professore ha detto una volta (parafrasato): "Come ingegnere del software, non è solo il tuo compito fornire software. È il tuo compito fornire software che rende felici i tuoi clienti".

Quali sono le cose specifiche che un artigiano del software potrebbe fare che un ingegnere del software (forse un cattivo) potrebbe non fare?

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

Come artigiano e ingegnere, sei una persona qualificata, attraverso una combinazione di educazione ed esperienza. Seguite le procedure stabilite. Sei anche pragmatico e ti rendi conto di ciò che è rotto e deve essere migliore.

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

— Thomas Owens
fonte

2

E sicuramente hai un'educazione a sostegno delle tue esperienze - felice di non aver detto "formale".

— treecoder

@greengit In molti posti, per usare il titolo di "ingegnere", devi avere un'istruzione formale. In Europa, questo significa laurearsi con una laurea in ingegneria. L'Italia aggiunge anche l'obbligo di superare un esame di certificazione. In Nord America, Texas, Florida e Canada richiedono che coloro che usano il titolo "ingegnere" (inclusi gli ingegneri del software) superino un esame di licenza.

— Thomas Owens

Anche se ciò non significa che qualcuno senza questa istruzione formale non possa praticare l'ingegneria. Non possono definirsi un ingegnere come titolo professionale.

— Thomas Owens

1

Non sono d'accordo, un ingegnere non è necessariamente un artigiano.

— Nicole,

2

@Renesis Per definizione, l'ingegneria è un mestiere. Definizione di mestiere: "un'arte, un mestiere o un'occupazione che richiedono abilità speciali, in particolare abilità manuali". L'ingegneria è un'occupazione che richiede abilità speciali, quindi è un mestiere. Tuttavia, è anche l'applicazione della teoria scientifica (tra le altre cose), che la rende più.

— Thomas Owens

2

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

Il suo obiettivo è duplice: ripristinare la fiducia nei programmatori e, a tal fine, elevare l'asticella della qualità del software e delle competenze degli sviluppatori.

L'artigianato Sw promuove pratiche tecniche come:

Principi di progettazione SOLID
Modelli di progettazione
TDD (metafora della "contabilità doppia voce")
...

E pratiche team / organizzative:

Coppia di programmazione
mentoring
Code katas
Ritiri Dojos / codice
...

Quindi direi che la differenza tra i 2 è chiara: l'arte del software cerca di affrontare 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.

— guillaume31
fonte

1

Non sono d'accordo - la ragione per cui l'ingegneria del software ha fallito è perché non aveva ingegneri, solo artigiani che fingevano di essere ingegneri. La NASA non ha inviato veicoli spaziali sulla luna usando artigiani!

— gbjbaanb,

@gbjbaanb Penso che sia piuttosto il contrario: avevamo ingegneri, ed è per questo che hanno cercato di afferrare un modello di ingegneria tradizionale e la mentalità di altre industrie sul software, ma non ha funzionato.

— guillaume31,

I veicoli spaziali non sono fatti di cose immateriali che possono essere rimodellate, riprogettate e ridistribuite più volte. Le leggi a cui obbediscono differiscono ampiamente da quelle dei programmi software.

— guillaume31,

Lo space shuttle ha booster ridistribuibili, almeno, e senza dubbio ha riutilizzato bit (o almeno conoscenza) di razzi precedenti. E i veicoli spaziali hanno un sacco di software. Non credo che inizino da zero con ogni nuovo satellite o sonda e difficilmente applicano gli aggiornamenti una volta distribuiti. L'ingegneria del software può e ovviamente funziona, ma solo se ci si avvicina con la mentalità di un ingegnere, non un artigiano.

— gbjbaanb,

Si prega di definire la "mentalità dell'ingegnere", nel contesto del software.

— guillaume31,

1

Andando da http://manifesto.softwarecraftsmanship.org/ trarrei il seguente.

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

Si concentrano sul valore, non solo per soddisfare i requisiti.
Si concentrano sulla qualità anche nello stile del loro codice, non solo per soddisfare i requisiti.
Partecipano alla più ampia comunità di sviluppo software, non solo al posto di lavoro.
Non solo comprendono che lo stato dell'arte di oggi è la spazzatura di domani, ma sono attivi nel realizzarlo a un livello o all'altro.
Non è solo un lavoro, è quello che sono .

— MIA
fonte

4

Onestamente, tutti quei punti elenco descrivono un buon ingegnere. Soprattutto 1, 2 e 4.

— Thomas Owens

@ThomasOwens E che dire del cattivo ingegnere? È anche un artigiano? O artigiano buono contro cattivo?

— Euforico

@Euforico Non penso che tu possa essere un buon ingegnere senza essere un buon artigiano. È come una messa in scena. Devi ottenere un "buon artigiano" prima di ottenere un "buon ingegnere". Tuttavia, puoi essere un buon artigiano e non essere un buon ingegnere.

— Thomas Owens

1

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

Non è possibile revocare a nessuno il permesso di programmare a causa di negligenza. La programmazione è priva di un corpus di leggi e regole rispetto a quelle legalmente applicate dalla legislazione che conforma una "professione". Un medico uccide un paziente a causa di incompetenza e rischia che il titolo del suo medico o il permesso gli vengano tolti.

Un programmatore fa un programma difettoso o fa fallire un progetto a causa dell'incompetenza ed è libero di continuare la programmazione.

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

— Tulains Córdova
fonte

0

Refactoring ai modelli.

Ossia, crea qualcosa che soddisfi il 90% dei requisiti software, quindi trasforma 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 che non dovrebbe essere modificato in modo significativo (tranne correzioni di bug ad alta priorità).

L'ingegneria del software ti consiglierebbe invece di stabilizzare il software a questo punto.

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

Spike Solution.

Un design ispirato a una soluzione a spike normalmente non è accettabile secondo la metodologia di ingegneria del software prevalente.

Deprecazione , per qualsiasi motivo.

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

In pratica, è piuttosto comune che le carenze di una parte specifica dell'interfaccia software vengano scoperte a pochi anni dalla produzione e che quella parte specifica possa essere deprecata nel mezzo del ciclo di vita, senza invalidare il resto del software. Ciò avrebbe richiesto una ricertificazione dell'intero sistema software dopo il deprezzamento, secondo l'ingegneria del software.

Alla fine, l'arte del software è uno sforzo personale per il buon senso degli individui, mentre l'ingegneria del software è un corpo conservatore di conoscenza. Lasciare quel buon senso nel processo decisionale del progetto è ciò che separa l'artigianato del software dall'ingegneria del software.

— rwong
fonte

-1

Direi che avere test unitari che coprono il 100% del codice sarebbe positivo. In quanto ciò consente di eliminare le cose in eccesso.

A volte confronto lo sviluppo del software con la scultura. Non è ciò che aggiungi, è ciò che porti via.

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

— Antony Scott
fonte

3

Di quanto stiamo parlando qui? :-)

— Chris,

1

Il più delle volte sono d'accordo con questo, ma non sono sicuro che valga sempre la pena il rigoroso 100%, ad esempio getter / setter in cui non hanno logica. Anche il codice generato viene generalmente lasciato senza test unitari (sebbene i test di integrazione possano essere appropriati)

— FinnNk

@FinnNk - sono d'accordo. Ho usato dotCover di recente e questo dice che un getter / setter è coperto se viene utilizzato in un altro test. Quindi, non intendevo davvero un metodo di prova per ogni getter e setter

— Antony Scott,