Welche spezifischen Praktiken könnten als "Software-Handwerkskunst" und nicht als "Software-Engineering" bezeichnet werden? [geschlossen]

Obwohl dies keine neue Idee ist, scheint das Interesse an Software-Handwerkskunst in den letzten Jahren stark zugenommen zu haben (insbesondere der häufig empfohlene vollständige Titel des Buches Clean Code lautet Clean Code: Ein Handbuch für agile Software-Handwerkskunst ).

Persönlich sehe ich Software-Handwerkskunst als gutes Software-Engineering mit einem zusätzlichen Interesse daran, sicherzustellen, dass das Endergebnis eine Freude bei der Arbeit ist (sowohl als Endbenutzer als auch als jemand, der diese Software wartet) - und dass der Fokus eher auf der Codierungsebene liegt von Dingen als die übergeordneten Prozesssachen.

Um eine Analogie zu ziehen: In den 50er und 60er Jahren wurden viele Gebäude in einem sehr modernen Stil errichtet, bei dem die Menschen, die in ihnen leben würden oder wie diese Gebäude im Laufe der Zeit altern würden, kaum berücksichtigt wurden. Viele dieser Gebäude entwickelten sich schnell zu Slums oder wurden lange vor ihrer erwarteten Lebensdauer abgerissen. Ich bin sicher, dass die meisten Entwickler mit ein paar Jahren Erfahrung ähnliche Codebasen erlebt haben werden.

Was sind die spezifischen Dinge, die ein Software-Handwerker tun könnte, die ein Software-Ingenieur (möglicherweise ein schlechter) möglicherweise nicht tut?

Ich würde sagen, der einzige Unterschied zwischen einem Profi und einem Handwerker besteht darin, sich mit ein wenig Leidenschaft zu beschäftigen . Es gibt keine spezifische, beobachtbare Praxis, die einen als Handwerker einstufen würde, sondern eine Sammlung von Eigenschaften:

• Ein Handwerker kümmert sich um die tatsächliche Qualität seiner Arbeit und nicht nur um die wahrgenommene Qualität.
• Ein Handwerker hat ein Interesse an seinem Handwerk, das über die Erledigung seiner Aufgaben hinausgeht und sich natürlich für sein Handwerk interessiert.
• Ein Handwerker kümmert sich um seinen Beruf und strebt danach, seine Fähigkeiten zu verbessern und nicht nur seine Karriere voranzutreiben .
• Ein Handwerker verbringt einige Zeit außerhalb seiner bezahlten Arbeitszeit (auch wenn es nur wenig Zeit ist) damit, etwas mit seinem Handwerk zu tun, sei es zu diskutieren, zu lernen oder sogar darüber nachzudenken.
• Ein Handwerker weiß, wie wenig er tatsächlich weiß, und ist demütig darüber.
• Ein Handwerker ist bereit, diejenigen zu unterrichten, die bereit sind zu lernen, diejenigen zu führen, die Führung suchen, und diese Dinge selbst zu suchen, wenn er sie braucht.

Ein bisschen Leidenschaft deckt all dies ab, ohne ins Schwitzen zu geraten.

Persönlich sehe ich Software-Handwerkskunst als gutes Software-Engineering mit einem zusätzlichen Interesse daran, sicherzustellen, dass das Endergebnis eine Freude bei der Arbeit ist (sowohl als Endbenutzer als auch als jemand, der diese Software wartet) - und dass der Fokus eher auf der Codierungsebene liegt von Dingen als die übergeordneten Prozesssachen.

Ein Professor von mir sagte einmal (umschrieben): "Als Softwareentwickler ist es nicht nur Ihre Aufgabe, Software zu liefern. Es ist Ihre Aufgabe, Software zu liefern, die Ihre Kunden glücklich macht."

Was sind die spezifischen Dinge, die ein Software-Handwerker tun könnte, die ein Software-Ingenieur (möglicherweise ein schlechter) möglicherweise nicht tut?

Nichts - ein Ingenieur ist ein Handwerker ... aber mehr. Engineering baut auf Handwerkskunst auf.

Als Handwerker und Ingenieur sind Sie durch eine Kombination aus Ausbildung und Erfahrung qualifizierte Einzelpersonen. Sie befolgen etablierte Verfahren. Sie sind auch pragmatisch und erkennen, was kaputt ist und besser sein muss.

Ein Ingenieur fügt jedoch noch Bedenken in den Bereichen Wirtschaft, Theorie und Wissenschaft hinzu. Es geht Ihnen darum, den größten Nutzen bei geringsten Kosten zu erzielen. Sie möchten Theorien aus Psychologie, Soziologie, Management, Mensch-Computer-Interaktionen und Informatik anwenden, um Ihre Probleme (sowohl zwischenmenschlich als auch technisch) zu lösen. Und Sie haben definitiv eine Ausbildung, um Ihre Erfahrungen zu sichern.

Die Software-Handwerksbewegung wurde als Reaktion auf die Fehler und unbefriedigenden Ergebnisse des "traditionellen" Software-Engineerings ins Leben gerufen, die (zusammen mit der Nachlässigkeit einiger Entwickler) heute zu Misstrauen von Stakeholdern und Benutzern gegenüber unserem Beruf führen.

Es hat zwei Ziele: das Vertrauen in Programmierer wiederherzustellen und dazu die Messlatte für Softwarequalität und Entwicklerfähigkeiten höher zu legen.

Sw Handwerkskunst fördert technische Praktiken wie:

• FESTE Konstruktionsprinzipien
• Designmuster
• TDD (Metapher "Double Entry Accounting")
• ...

Und Team- / Organisationspraktiken:

• Paar-Programmierung
• Mentoring
• Code katas
• Dojos / Code-Retreats
• ...

Ich würde also sagen, dass der Unterschied zwischen den beiden klar ist: Software-Handwerkskunst versucht, einen großen Teil der Probleme zu lösen, die Software-Engineering in mehr als 40 Jahren hatte und die unsere Disziplin heute unzuverlässig und mit einer Geschichte von Fehlern verkrüppelt erscheinen lassen.

Unter http://manifesto.softwarecraftsmanship.org/ würde ich Folgendes ableiten.

Ein Handwerker unterscheidet sich von den traditionellen Wahrnehmungen eines "Ingenieurs", weil

• Sie konzentrieren sich auf den Wert und erfüllen nicht nur die Anforderungen.
• Sie konzentrieren sich auch im Stil ihres Codes auf Qualität und erfüllen nicht nur die Anforderungen.
• Sie beteiligen sich an der breiteren Softwareentwicklungsgemeinschaft, nicht nur an ihrem Arbeitsplatz.
• Sie verstehen nicht nur, dass der heutige Stand der Technik der Müll von morgen ist, sie sind aktiv dabei, ihn auf der einen oder anderen Ebene zu verwirklichen.
• Es ist nicht nur ein Job, es ist wer sie sind .

Onkel Bob deutete irgendwie an, dass das Programmieren eine sehr junge Disziplin ist, die noch keine stabilen Gesetze oder Regeln hat, die von den Regierungen anerkannt werden (oder war es Frederick Brooks?). Ich zitiere hier nicht wörtlich.

Sie können niemandem die Erlaubnis zum Programmieren aufgrund von Fehlverhalten widerrufen. Der Programmierung fehlen eine Reihe von Gesetzen und Regeln, die durch Gesetze, die einem "Beruf" entsprechen, gesetzlich durchgesetzt werden. Ein Arzt tötet einen Patienten aufgrund von Inkompetenz und riskiert, dass ihm sein Arzttitel oder seine Erlaubnis genommen wird.

Ein Programmierer erstellt ein fehlerhaftes Programm oder lässt ein Projekt aufgrund von Inkompetenz scheitern, und er kann die Programmierung fortsetzen.

Ich denke, das macht das Programmieren zu einem Handwerk. Ein Tontopfhersteller stellt keine zwei identischen Töpfe her. Sie haben auch noch nie von einem Tontopfhersteller gehört, der gezwungen ist, defekte Töpfe zurückzurufen. Das Programmieren ist immer noch eine sehr manuelle, persönliche Arbeit. Manchmal kann man sogar erkennen, wer einen Code geschrieben hat, gemessen am Stil.

Refactoring zu Mustern.

Erstellen Sie also etwas, das 90% der Softwareanforderungen erfüllt, und überarbeiten Sie dann das gesamte Projekt in ein klares, elegantes Design.

Normalerweise würde das Software-Engineering Sie daran hindern, da die Erfüllung von 90% der Anforderungen bedeutet, dass die Software für den Kunden einen ausreichenden Geschäftswert hat, sodass sie nicht wesentlich geändert werden sollte (mit Ausnahme von Bugfixes mit hoher Priorität).

Das Software-Engineering empfiehlt Ihnen stattdessen, die Software an dieser Stelle zu stabilisieren .

Wenn ein Projekt nicht von Anfang an mit diesem eleganten Design beginnt, wird es laut Software-Engineering als schlecht ausgeführtes Projekt angesehen (unabhängig vom Projektergebnis).

Spike-Lösung.

Ein Design, das von einer Spike-Lösung inspiriert ist, ist nach der geltenden Software-Engineering-Methodik normalerweise nicht akzeptabel.

Abwertung , aus welchem ​​Grund auch immer.

In der Softwareentwicklung darf jede Art von Abwertung nur am Ende des Lebenszyklus eines Softwaresystems erfolgen. Dies muss im Rahmen des SDLC geplant werden.

In der Praxis ist es eher üblich, dass die Mängel eines bestimmten Teils der Softwareschnittstelle einige Jahre nach Produktionsbeginn entdeckt werden und dieser bestimmte Teil mitten im Lebenszyklus veraltet sein kann, ohne den Rest der Software ungültig zu machen. Dies hätte laut Software-Engineering eine erneute Zertifizierung des gesamten Softwaresystems nach der Abwertung erforderlich gemacht.

Letztendlich ist Software-Handwerkskunst ein persönliches Streben nach guten Urteilen von Einzelpersonen, während Software-Engineering ein konservativer Wissensbestand ist. Dieses gute Urteilsvermögen bei der Entscheidungsfindung des Projekts zuzulassen, unterscheidet Software-Handwerkskunst von Software-Engineering.

Ich würde sagen, dass Unit-Tests, die 100% des Codes abdecken, gut wären. Dadurch kann das überschüssige Material entfernt werden.

Manchmal vergleiche ich Softwareentwicklung mit Skulptur. Es ist nicht das, was du hinzufügst, es ist das, was du wegnimmst.

Natürlich können Sie das zu weit gehen. Niemand wird sagen, dass ein kleiner glänzender Kiesel eine gute Skulptur ist: S.