Onkel Bob ist wieder extrem und zeigt eine Person, die unser asymptotisches Ziel ist und die niemand erreichen kann.

Die Übermenschin (auch bekannt als The Clean Coder) ist immer für ihre Handlungen verantwortlich, kann selbst in den härtesten Zeiten und zu den härtesten Managern und Kunden Nein sagen, schläft mindestens 7 Stunden pro Tag und verbringt 20 Stunden pro Woche für ihren persönlichen Fachmann Entwicklung, programmiert regelmäßig Kata, macht TDD 100% der Zeit, schreibt keine Features, es sei denn, es gibt Abnahmetests, benötigt die Zone nicht, kümmert sich ebenso um die Geschäftsziele für die technische Qualität, schreibt Prüfungen, wenn sie dies verursacht Probleme, Refaktoren gnadenlos.

An einigen Stellen vermischte Onkel Bob die Abstraktionsebenen und implizierte Implementierungsdetails (TDD), wenn das höhere Ziel, Arbeitscode zu haben, im Vordergrund stehen sollte. Außerdem waren einige der Geschichten nicht die besten Beispiele. 70er waren verschiedene Zeiten :-)

Im Allgemeinen hat es mir sehr gut gefallen. Ich habe ein paar Dinge gelernt, aber ich hatte in irgendeiner Form schon einmal am meisten gehört. Es ist jedoch eine gute Empfehlung für Freunde.

Es gibt eine Menge ähnlicher Bücher auf dem Markt. Das bemerkenswerteste ist "Pragmatic Programmer" von Andy Hunt und Dave Thomas. Beide Bücher behandeln ziemlich ähnliche Themen - von Designaspekten bis zu bestimmten Praktiken. Der Hauptunterschied zwischen ihnen besteht darin, dass der "pragmatische Programmierer" ein breiteres Themenspektrum und viel mehr Tiefe abdeckt.

Ich sehe einige Probleme mit "The Clean Coder":

1. Tonnenweise nutzlose Geschichten aus dem Privatleben der Autoren.
In den meisten Fällen sind sie für das Thema der Kapitel nicht so relevant und fast immer einfach zu lang

2. Buchen Sie über den perfekten "Codierer" und Dump-Manager
In mehreren Kapiteln finden Sie ähnliche Diskussionen zwischen Manager und Entwickler, bei denen der Manager versucht, eine Frist durchzusetzen, die auf jeden Fall vom alleinigen Entwickler erreicht werden sollte. In vielen Fällen geht der Autor davon aus, dass „Codierer“ geduldig und weise sein sollte, über verschiedene Planungspraktiken Bescheid wissen und das Geschäft vorantreiben sollte.

3. Fehlende Codierungspraktiken
Der Titel des Buches geht davon aus, dass reguläre Entwickler die Zielgruppe des Buches sind. Dieses Buch enthält jedoch nur ein Kapitel zum Thema Codierung (Kapitel 4). In diesem Kapitel werden jedoch keine Codierungspraktiken oder codierungsbezogenen Themen behandelt. NICHTS!

4. Tonnenweise Wiederholung
Das Buch enthält mindestens 3 Stellen mit fast identischen Absätzen über FitNess. Einige Geschichten werden mehr als einmal wiederholt. Ich weiß, dass DRY ein sehr hartes Prinzip ist, aber die Wiederholung einiger irrelevanter Dinge klingt nicht professionell.

5. Arroganz und fehlende Argumente
In einigen Fällen gibt es keine Argumente, die die Gedanken einiger Autoren belegen. Zum Beispiel behauptet der Autor, dass jeder eine 100% ige Codeabdeckung anstreben, ständig TDD und Paarprogrammierung verwenden sollte. Ich schätze eine angemessene Codeabdeckung, gutes Design und automatisierte Tests und glaube, dass Paarprogrammierung nützlich ist. Eine 100% ige Codeabdeckung ist jedoch schädlich, TDD als Praxis ist subjektiv (Artefakte dieser Praxis sind es nicht, aber niemand sollte erzwingen, wie diese Artefakte erzeugt werden), und Paarprogrammierung ist nur unter bestimmten Umständen nützlich.

Dieses Buch ist relativ klein und wenn Sie fast nutzlose Erzählungen ausschließen, erhalten Sie sehr kleine Themen, über die Sie nachdenken müssen. Es gibt viele Bücher mit viel besserer Qualität (wie „Pragmatic Programmer“), die Sie wirklich ermutigen und den Geist Ihres „Programmierers“ viel besser öffnen.

Eine gründlichere Überprüfung auf Russisch: http://sergeyteplyakov.blogspot.com/2...

Ich neige dazu, jedes Jahr mindestens eines dieser Bücher zu lesen, in denen es darum geht, ein professionellerer Programmierer zu sein. Historisch haben sie mich nicht beeindruckt. Dieser war die seltene Ausnahme - er sprach mich aus irgendeinem Grund wirklich an.

Nichts in diesem Buch ist wirklich neu oder einzigartig. Aber Martin hat viele wirklich gute Punkte angesprochen und einige Dinge, über die ich in der Vergangenheit nie wirklich nachgedacht hatte, haben plötzlich für mich geklickt.

Ich denke, es läuft wirklich auf die Präsentation hinaus - Martin präsentierte (größtenteils) "das gleiche alte Zeug" wie die meisten Bücher auf diesem Gebiet, aber er präsentierte es für mich auf die richtige Weise. Dies ist möglicherweise nicht für alle der richtige Weg, und das ist in Ordnung, aber dies ist eine schnelle Lektüre, und ich möchte jeden Softwareentwickler ermutigen, es zumindest einmal auszuprobieren.

Meistens ist dieses Buch ziemlich gut. Es ist eine Reihe von Anekdoten aus der Lebenszeit des Autors in der Softwareindustrie. Sie erinnern an Dinge, die Sie vielleicht täglich sehen, aber sie werden mit einer Erklärung versehen, wie die richtige Reaktion auf jede Situation aussehen würde. Dies macht das Buch tatsächlich lesbarer als das vorherige in der Reihe, was viel technischer war. Es macht es auch schwieriger, sich auf das eigene Leben zu beziehen. Es geht nicht mehr nur darum, eine Checkliste mit Code-Stilpunkten herunterzulaufen. Ich denke, insgesamt hat der Leser ein Gespür für den „richtigen“ Umgang mit Geschäftsinteraktionen, aber ich befürchte, dass er sehr schnell vergessen wird, wenn er ihn nicht noch einmal liest und sich Notizen macht.

Es ist interessant, dass viele der Beispiele Missverständnisse aufweisen, die von jemandem verursacht werden, der eine mehrdeutige Sprache verwendet, um eine Konfrontation zu vermeiden. ZB besteht der Chef darauf, dass der Programmierer das Projekt innerhalb einer Woche abschließt, selbst nachdem ihm mitgeteilt wurde, dass dies unmöglich ist, und der Programmierer sagt, er werde "versuchen, das zu tun". Der Chef hört, was er hören will und geht weg. Der Autor betrachtet dies moralisch als das gleiche wie Lügen. Ich denke, in England wird dieser Sprachgebrauch zur Vermeidung von Konflikten tatsächlich als Tugend angesehen, daher bezweifle ich, dass wir damit aufhören können, aber vielleicht hat er Recht und wir sollten direkter sein.

Natürlich bin ich nicht davon überzeugt, dass Projektschätzungen wirklich das sind, was in allen Beispielen von Programmierern, die an ihren Waffen gegen Bosse festhalten, hätte verwendet werden sollen, denn ich denke, die Chefs müssen wissen, dass Schätzungen häufig um den Faktor zehn und höher sind Es ist also nicht ganz lächerlich zu erwarten, dass der Programmierer seine Schätzung verkürzt.

Es gibt ein Problem, das überall auftritt: die nebulöse Definition von "professionell". Der Leser wird ständig daran erinnert, dass er als Profi autonom sein und keine Angst haben sollte, Nein zu seinem Chef zu sagen, wenn er mehr weiß als der Chef oder wenn er gebeten wird, etwas „Unprofessionelles“ zu tun. Es werden Vergleiche mit Ärzten und Anwälten angestellt. Das Problem ist, dass diese Fachkräfte selbstständig sind. Sie werden von Kunden angeheuert, arbeiten aber nicht für Chefs. Es ist zwar möglich, dass ein Programmierer auf die gleiche Weise selbstständiger Berater ist, dies ist jedoch nicht die Norm, und alle im Buch aufgeführten Beispiele sind Programmierer, die Mitarbeiter sind. Es gibt Beispiele für die Entwicklung von Software für Kunden, aber die Programmierer hier sind immer noch Mitarbeiter einer Beratungsfirma und nicht direkt von den Kunden beauftragt.

Die Verwirrung ist am schlimmsten im ersten Kapitel, das fast dazu geführt hätte, das Buch aufzugeben. Der Autor scheint die Propaganda der amerikanischen Kapitalisten, die es rechtfertigt, ihre Angestellten wie Scheiße zu behandeln, vollständig akzeptiert zu haben. Er sagt uns, dass wir die Pflicht haben, 60 Stunden pro Woche zu arbeiten - weil wir „Profis“ sind und es uns daher schulden -, aber dass wir als Profis auch für unser eigenes Wohlergehen verantwortlich sind und daher kein Recht darauf haben Erwarten Sie von unserem Arbeitgeber jegliche Vorteile. Grundsätzlich erwartet er, dass die Lohnsklaven mit der gleichen Leidenschaft arbeiten wie die Eigentümer des Unternehmens. Ein hervorragendes Beispiel für die Binsenweisheit "Der Sozialismus hat in Amerika nie Wurzeln geschlagen, weil sich die Armen nicht als ausgebeutetes Proletariat, sondern als vorübergehend verlegene Millionäre verstehen."

Kritik: The Clean Coder - und warum ich es nicht mag

Robert C. Martin als Autor ist wahrscheinlich am bekanntesten für „Clean Code“.
Das wird heutzutage als ein Muss für neue Kollegen angesehen.

Sein Buch „The Clean Coder: Ein Verhaltenskodex für professionelle Programmierer“ aus dem Jahr 2011 befasst sich mit einer anderen Perspektive der heutigen Codierung und versucht zu lehren, „was es bedeutet, sich als echter Software-Handwerker zu verhalten“. In meinen eigenen Worten: die sozialen Aspekte der täglichen Arbeit eines Programmierers.

Was ich an dem Buch mag

Die realen Geschichten von Martin, die bis in die 70er Jahre zurückreichen, geben einen Einblick, wie es war, damals Programmierer zu sein - und wie viel mehr manuelle Arbeit damit verbunden war. Darüber hinaus ist er offen darüber, wie er versagt hat und warum.
Ich mag die allgemeine Idee der Kapitel „Nein sagen“ und „Ja sagen“. Das ist etwas Wichtiges zu lernen. Die Beispiele sind jedoch sehr künstlich und schwer zu verallgemeinern ...

Warum ich das Buch nicht mag

Grundsätzlich habe ich 3 Hauptbeschwerdepunkte zu diesem Buch. Bitte beachten Sie, dass dies meine subjektive Meinung ist und an meine alltäglichen Situationen und Erfahrungen als Product Owner gebunden ist.

1. Ich denke, der Autor sieht Agile als einen Prozess zur Verbesserung von Entwicklung und Entwicklern, nicht als einen Weg, Unternehmen in einen menschenzentrierteren und erfolgreicheren Ort zu verwandeln. Insbesondere geht das Buch nicht einmal in Richtung Scrum-Mechanismen, um typische Situationen zwischen Stakeholdern und Entwicklungsteams zu bewältigen.

2. Die Beispiele für Gespräche zwischen „Management“ und „Programmierern“ sind so extrem, dass ich das Projekt lieber ändern würde, als eine Technik zu empfehlen, um mit solchen unrealistischen Erwartungen umzugehen.

3. Das Buch lehrt keine Reflexionstechniken, wie man Feedback gibt, wie man mit Konflikten umgeht, wie man kommuniziert, nicht einmal ein bisschen Psychologie. Für mich ist dies ein Hauptaspekt, den jeder Entwickler untersuchen sollte. Persönlich habe ich am meisten davon profitiert, als ich davon erfahren habe.
Zusammenfassung

Um ehrlich zu sein, denke ich, dass der gesamte Lernpunkt dieses Buches auf 2 Blog-Posts von vielleicht 10 Seiten mit vielen Links zu Leuten reduziert werden könnte, die die Details viel besser erklärt haben als Martin. Und 2 Aussagen zu beachten.
Für einen Anfänger könnte dieses Buch geeignet sein. Das Gespräch mit Ihren Kollegen funktioniert meiner Meinung nach viel besser.

Blog Post 1
Dies sind die 10 Dinge, über die Sie als professioneller Softwareentwickler nachdenken und lesen sollten

Blog Post 2
Warum ich in meinem Leben als professioneller Softwareentwickler versagt habe und was ich daraus gelernt habe

Erklärung 1
Sagen Sie NEIN, wenn Sie vielleicht sagen möchten

Erklärung 2
Normalerweise ist ein JA mit einer Reihe von Bedingungen verbunden. Machen Sie sie transparent.

Chapeau Robert Martin !!

Tolle. Hat mich angeklickt. Es ist wirklich fantastisch, wenn Sie sagen: "Ja, genau. Das ist es, wonach ich gesucht habe." mit jeder einzelnen Zeile, die Sie lesen.

Ich betrachte dieses Buch als Ergänzung oder das andere Gesicht des Clean Code-Buches. Sauberer Code kümmert sich um die technische Seite und dieser um die persönliche. Sie müssen beide lesen!

Der Teil, den ich am meisten schätzte, ist Üben und Schätzen. Die Schätzung ist in der Tat keine leichte Aufgabe. Ich habe viele schwierige Situationen erlebt, in denen die Schätzung der Flaschenhals war.

Auch testgetriebene Entwicklungs- und Teststrategien sind für mich der Treibstoff, um mit diesem Trend zu arbeiten, und ich habe große Erwartungen daran.

Ich kann dieses Buch jedem Entwickler empfehlen, der professionell sein möchte - und wer nicht? !! -.

In der Populärkultur werden Computerprogrammierer, die manchmal mit Sysadmins verwechselt werden, oft als Punks im Teenageralter beschrieben, die im Dunkeln sitzen und nur durch das Leuchten ihres Monitors beleuchtet werden Tastatur.

Was bedeutet es, ein professioneller Programmierer zu sein? Trägt es Anzug und Krawatte zur Arbeit? Verfügt es über Zertifizierungen oder Diplome, die die Wände Ihres Büros schmücken? Arbeitet es hart, manchmal Überstunden und Wochenenden, nur um Ihr Engagement zu zeigen?

Für Onkel Bob bedeutet dies nicht, dass ein professioneller Programmierer. Die Dinge, die häufig mit Professionalität verwechselt werden, wie beispielsweise eine Kleiderordnung, sind letztendlich nicht wichtig. Es ist jedoch wichtig, dass Entwickler professionell gegenüber dem Code und untereinander handeln.

"Clean Coder" ist eine Sammlung von Anekdoten und Geschichten über die 42-jährige Programmierkarriere von Robert Martin und teilt seine reiche Erfahrung mit, was es bedeutet, ein professioneller Programmierer zu sein. Es ist wichtig zu wissen, wann man selbst zu den hartnäckigsten Managern Nein sagt und Ja sagt, indem man sich einer Aufgabe verpflichtet und hinter seinem Engagement steht. Es geht darum, den bestmöglichen Code zu schreiben, indem auch in Zeiten des Drucks keines der Prinzipien guter Codierungspraktiken geopfert wird. Es geht darum, um Hilfe zu bitten und anderen zu helfen, anstatt sich mit aufgesetzten Kopfhörern zu hacken.

Wenn Sie Ihren gewählten Beruf schätzen, sollten Sie dieses Buch unbedingt lesen, insbesondere wenn Sie in einem weniger idealen Unternehmensumfeld arbeiten. Es liegt an Ihnen, Änderungen an Ihrem Arbeitsplatz voranzutreiben, wenn die Einstellungen es Ihnen nicht ermöglichen, professionell zu handeln . Wenn Ihr Unternehmen keine Quellcodeverwaltung verwendet, richten Sie diese selbst ein und bringen Sie Ihrem Team die Verwendung bei. Wenn Sie keine Komponententests schreiben oder darauf warten, dass die Qualitätssicherung auf Fehler überprüft, lernen Sie, wie Sie Ihren Code testen, damit Sie sicher sein können, dass er funktioniert. Halten Sie Ihre Fähigkeiten scharf und Ihre Werkzeuge schärfer. Das bedeutet es, ein professioneller Programmierer zu sein!

Ich genieße es wirklich. Ich mag den Stil, in dem das Buch geschrieben ist, und ich denke, dass die Mehrheit, wenn nicht alle Leute auf diesem Gebiet es lesen sollten, um einige Einblicke in ein bisschen Geschichte, Erfahrung und was zu tun ist, um ein Profi zu werden. :) :)

Robert C. Martin (1952-) programmiert seit 1970 professionell, hat sich jedoch als außergewöhnlicher Softwareentwickler und Berater profiliert, als er in den 1980er Jahren mit der Entwicklung objektorientierter Software begann und später zu den Unterzeichnern des Agilen Manifests gehörte (2001) ) destillierte einen Teil seiner Konstruktionserfahrung in die fünf bekannten SOLID-Prinzipien (2003) und entwickelte das Framework für Abnahmetests mit FitNesse. Er ist auch ein gefragter und energischer Hauptredner. Dieses Buch stellt Robert C. Martins persönliche Reflexion darüber dar, was es bedeutet, ein professioneller Softwareentwickler zu sein. Aufgrund seiner umfassenden Erfahrung auf diesem Gebiet und seiner Artikulierbarkeit sollte jeder objektorientierte agile Softwareentwickler oder Student, der sein Geld wert ist, auf seine Aufmerksamkeit achten Wörter.

Für Martin ist Softwareprofi ein Bündel aus Einstellung, Verhalten, Arbeitsethik und -gewohnheiten, Mentoring und lebenslangem, kontinuierlichem Lernen. Es geht darum, vierzig Stunden pro Woche für Ihren Arbeitgeber zu arbeiten und weitere zwanzig Stunden pro Woche darauf zu verwenden, mit dem von Ihnen gewählten Bereich Schritt zu halten. Es geht darum zu wissen, wann Sie Ja sagen müssen und, was noch wichtiger ist, wann (und wie) Sie Nein zu Ihrem Arbeitgeber sagen müssen und Ihre Kunden. Es geht darum, ehrliche Einschätzungen der Bemühungen vorzunehmen, die volle Verantwortung für Ihre Arbeit zu übernehmen, verbindliche Verpflichtungen einzugehen, hervorragende Handwerkskunst, Teamarbeit und Zusammenarbeit sowie eine klare Kommunikation mit Ihren Teamkollegen, Ihren Kollegen, Ihrem Arbeitgeber und Ihren Kunden. Es geht um diszipliniertes Zeitmanagement, unablässiges Üben, Beherrschung der richtigen Werkzeuge und eine Pause, wenn es nötig ist.

Natürlich können Sie nicht mit allem einverstanden sein, was Martin sagt; In einer seltenen Einschränkung warnt er den Leser, dass das, was er präsentiert, für ihn funktioniert. Zum Beispiel stimme ich seiner umfassenden und unbekümmerten Entlassung von MDA (Model Driven Architecture) und UML nicht zu. Ich schlage vor, dass Sie einige seiner Vorschläge - Paarprogrammierung, testgetriebene Entwicklung (TDD), Programmierung von Katas, Timeboxing, Planung von Poker mit Pert-basierten Schätzungen - offen machen; Die Erfahrung wird aufschlussreich sein, selbst wenn Sie feststellen, dass die von ihm empfohlenen Techniken für Sie nicht funktionieren. Martin ist eher ein Evangelist für agile objektorientierte Entwicklungstechniken als ein objektiver Bewerter, aber ich habe nicht festgestellt, dass dies das Buch beeinträchtigt - aber das mag daran liegen, dass ich dem Hauptschwerpunkt seiner Empfehlungen zustimme ;-)

Persönlich fand ich die letzten gekennzeichneten Kapitel und den Anhang zu den von ihm bevorzugten Werkzeugen interessant, aber etwas zu kurz; Zum Beispiel seine Beschreibung des verteilten Versionskontrollsystems Git wird den Lesern das Gefühl geben, etwas ausgelassen zu sein.

Wenn Sie "Onkel Bob" Martins überlebensgroße Persönlichkeit nicht in Aktion gesehen haben, schauen Sie sich ein paar YouTube-Videos seiner Keynote-Reden an - er ist ein hervorragender Schausteller der Sorte Feuer und Schwefel. Seien Sie gewarnt, dass einige Leser Martins Erklärungen möglicherweise zu oberflächlich finden, sein kraftvoller Stil zu egoistisch und gerecht und daher unangenehm.

Ein zusätzliches Plus für mich als nahen Zeitgenossen von Martin war die Reise in die Vergangenheit, als ich seine Anekdoten über die für jüngere Leser wahrscheinlich alte Computergeschichte erzählte: Schreibmaschinen- und Teletyp-Wagenrückläufe und Zeilenvorschübe, Lochkarten, Minicomputer und Krawatten als obligatorische Geschäftsanforderungen für Programmierer, um nur einige zu nennen.

In diesem Buch gibt es viele fundierte Ratschläge, aber denken Sie wie immer daran, Ihre kritischen Fähigkeiten zu trainieren. Das intellektuelle Auseinandersetzen mit Martin ist meiner Meinung nach eine hervorragende Möglichkeit, den Charakter zu entwickeln, den Sie benötigen, um professionell erfolgreich zu sein ...

Nun, dieses Buch ist ein Muss für alle Entwickler, die Profis und nicht nur Techniker sein wollen.
Es ist kein technisches Buch, es ist einfach zu lesen und erklärt die Themen anhand von Beispielen aus der Praxis. Ich mochte das Kapitel, in dem Schätzungen von verschiedenen Seiten definiert werden ("Unternehmen betrachten Schätzungen gerne als Verpflichtungen. Entwickler betrachten Schätzungen gerne als Vermutungen"). Mir hat auch das Kapitel gefallen, in dem es darum geht, mit Druck umzugehen und wie sich eine Person in solchen Fällen auf ihre Disziplinen verlassen sollte. Onkel Bob betont die Bedeutung von Zusammenarbeit, Paarprogrammierung und Mentoring in anderen großartigen Kapiteln, und ich kann nicht mehr zustimmen.

Ja, "The Clean Coder" ist eine Fortsetzung von Onkel Bobs "Clean Code". Dies ist ein großartiges Buch und zeigt, was es wirklich bedeutet, ein professioneller Entwickler zu sein, wenn es von einer angesehenen Quelle geliefert wird.

Das Buch ist sehr gut lesbar und enthält Ratschläge, gemischt mit Geschichten aus der Vergangenheit und dem Dialog des Autors. Ich mag die Verwendung von Dialogen, um Kommunikationsprobleme wie "erledigt" oder übermäßiges Festschreiben anzuzeigen. Sogar das Vorwort war eine Geschichte.

Ich denke, es gab zu viele Wiederholungen der Geschichten in den Kapiteln. Fast so, als wären die Kapitel in eigenständiger Form geschrieben worden. Ich hatte das Gefühl, ein paar Mal über denselben Arbeitgeber (von Grund auf neu eingeführt) zu lesen. Es war interessant, etwas über die Lochkartenwelt mit Lektionen zu hören und wie sich die Dinge verändert haben. Gleiches gilt für FitNesse. Ich verstehe, dass es Unit-Tests hat.

Der Rat ist ausgezeichnet. Meine drei Favoriten (die für Computerliteratur ziemlich einzigartig waren):
1) Unterschied zwischen Leistung und Praxis
2) TDD in Angriff gegen Verteidigung
3) Manna auf Zeitmanagement konzentrieren

Der einzige Rat, gegen den ich mich entschieden fühlte, ist, im "Fluss" zu sein, was eine schlechte Sache ist. Solange Sie das Problem außerhalb des Flusses definieren, sehe ich kein Problem darin, sich vorübergehend vom Gesamtbild zu isolieren.

---
Offenlegung: Ich habe vom Verlag eine Kopie dieses Buches erhalten, als Gegenleistung für das Schreiben dieser Rezension im Auftrag von CodeRanch.

Der saubere Codierer

Ein weiteres Buch von Robert C. Martin! Ich habe darauf gewartet. Ich erinnere mich, als ich bekam
Der Clean Code, eines meiner Lieblingsbücher. Ich habe viel daraus gelernt
und es liegt auf meinem Schreibtisch, seit ich es gekauft habe.

Ich denke, The Clean Coder wird ähnlich sein. Leider habe ich gemischte Gefühle.
Erstens ist es kein technisches Buch. Sie werden keinen technischen Wert daraus ziehen.
Es geht um Soft Skills und darum, wie man in einer Codierungsumgebung verrückt bleibt.
Ja, manchmal kann es rau sein;)

Zweitens denke ich, dass dieses Buch nicht jedermanns Sache ist. Weniger erfahrene Entwickler wie Junioren
oder sogar Stammgäste, werden nicht viel Wert daraus ziehen. Es beschreibt Situationen wie
NEIN zum Kunden sagen oder wie man Aufgaben richtig einschätzt und wie man stark bleibt und seine Einschätzungen und Best Practices nicht unter dem Druck ändert, den jeder versucht, auf Sie auszuüben. Wenn Sie anfangen oder nicht viel Erfahrung haben, sind diese Probleme für Sie nicht so wichtig. Ich erinnere mich, dass sie nicht für mich sind :) Ich habe mich auf technische Probleme konzentriert und meine Aufgaben erledigt. Ich habe nicht, obwohl ich nein zum Kunden sagen kann, ich hatte nicht viel Erfahrung und Selbstvertrauen, und das ist normal.

Wenn Sie erfahrener sind (z. B. Senior oder Teamleiter), bietet Ihnen dieses Buch mehr Wert.
In diesem Buch werden Sie viele Situationen erkennen, die Sie in der Vergangenheit hatten und nicht wussten, wie Sie damit umgehen sollen. Dieses Buch gibt Ihnen die Bestätigung, dass Sie Ihre Best Practices befolgen und sich nicht unter Druck beugen sollten. Sie sind erfahren, Sie haben technische Fähigkeiten, um gute Entscheidungen zu treffen, und Sie sollten sie nicht ändern, weil Ihnen das jemand sagt - ohne gute Argumente.

Kann ich dieses Buch bewerten?
Nun, ich muss zwei Schätzungen abgeben. Für Entwickler mit weniger Erfahrung Position werde ich es 2/5 geben. Entschuldigung Robert :(
Auf der anderen Seite, wenn Sie erfahrener sind und nach einem Buch suchen, das Ihnen beim Umgang hilft
Mit nicht technischen Fähigkeiten ist dieses Buch für Sie. Ich bin gerade in dieser Position und für mich ist es 3.8 / 5.

Hatte dieses Buch zusammen mit Clean Code als Kombipack auf dem Kindle gekauft. Ich habe dieses Buch mehr genossen, da es wirklich ein kurzes Buch ist.

Hier bringt Onkel Bob Ihnen nichts im Zusammenhang mit dem Code bei, aber er erklärt oder hämmert die Tatsache, was es bedeutet, ein professioneller Entwickler zu sein.

Einige der Kapitel mögen

1. Wann soll ich Ja sagen?
2. Wann soll ich nein sagen?

Diese Kapitel aus dem ganzen Buch haben mir sehr gut gefallen.

Der Rest des Buches fehlt mir etwas, weil ich nicht glaube, dass es nur die Verantwortung des Entwicklers ist, alles im Team zu erledigen, denn wenn das so ist, warum haben wir dann verschiedene Disziplinen in der Softwareentwicklung wie

1. Testen
2. Devops

Auch wenn ich Entwickler mit Ärzten vergleiche, stimme ich dem nicht ganz zu, da beide unterschiedliche Berufe sind und ihre eigenen Herausforderungen haben.

Manchmal ist es einem Entwickler auch nicht möglich, Mitarbeiter im Management davon zu überzeugen, warum wir Unit-Tests benötigen. Onkel Bob, du musst überzeugen, sonst machst du deinen Job nicht. Ich stimme solchen hartnäckigen Annahmen nicht zu.

Insgesamt ist das Buch in Ordnung zu lesen, aber viele Inhalte im Buch sind veraltet.

Professionalität in der Softwareentwicklung definieren

Dies ist ein Programmierbuch, aber nicht über Algorithmen, Datenstrukturen oder Muster. Es ist eine genaue Definition von Professionalität im Softwarebereich, eine Reihe von Praktiken und Einstellungen, die einen professionellen Programmierer von dem größeren Pool von "Menschen, die codieren" trennen. In der typischen Art von Onkel Bob ist es eigensinnig, entschlossen und gut, sauber. Es kodifiziert viele der Lektionen und Intuitionen, die erfahrene Programmierer durch ihre Karriere gewonnen haben, und argumentiert für sie mit einer klaren, idealistischen Sprache, die bei der Entwicklung der Standards Ihres eigenen Teams leicht zu kommunizieren ist. Die Softwareentwicklung war oft die Domäne von Primadonnen, Zauberern, Superhelden und Cowboys. Aber es ist jetzt ein ausgereiftes Gebiet, und dieses Buch ist eine schöne Beschreibung dessen, wie erwachsene Programmierung aussieht.

Die Verhaltensweisen, die Martin beschreibt, sind ehrgeizig. Asymptotisch. Aber das Bild, das er malt, ist ein nützliches und würdiges Ziel, das er als einzelner Fachmann und als technische Abteilung anstreben kann, um seine Kultur zu formen.

Ich bin mit dem Vorschlag nicht einverstanden, dass der Arbeitgeber absolut keine Verantwortung für die berufliche Entwicklung seines Mitarbeiters trägt und dass Sie als Programmierer mindestens 20 Stunden pro Woche zu Hause verbringen müssen, um sich beruflich weiterzuentwickeln. Ein Arbeitgeber, der nicht in seine Mitarbeiter investiert, ist unglaublich kurzsichtig und (im Allgemeinen) nicht jemand, für den Sie arbeiten möchten. Wenn er über persönliche Entwicklung sprach, könnte ich zustimmen, aber nicht über die berufliche Entwicklung, dass ich meinen Job machen muss und dass mein Arbeitgeber mich braucht, um weiterhin ein wertvoller Mitarbeiter zu sein.

Zum Beispiel verbringe ich persönlich mehr als 20 Stunden pro Woche damit, für persönliche Interessen wie Philosophie, Soziologie, Feminismus, Religionswissenschaft, Minderheitenstudien, Psychologie usw. zu lesen (oder zur Universität zu gehen). Betrachte ich diese berufliche Entwicklung? Glaube ich, sie machen mich zu einem besseren Mitarbeiter und möglicherweise zu einem besseren Programmierer? Ja, absolut und ohne Vorbehalt.

Ich frage mich auch, ob 20 Stunden wirklich so realistisch sind wie behauptet. Junior-Programmierer in kleinen Unternehmen können im Verhältnis zu dem, was sie tatsächlich tun, unglaublich schlecht bezahlt werden (ich musste 2 Jobs niederhalten und arbeitete 60 Stunden pro Woche für einen Teil meiner Karriere). Ist es auch für Alleinerziehende mit Kindern realistisch, bei denen Sie so viele andere Verpflichtungen haben (Kochen, Putzen, Termine, Vereine / Sport usw.)? Wäre das nicht selbst für eine Familie mit doppeltem Einkommen eine Herausforderung? Ich muss mich fragen. Dies scheint mir ein Rezept für Burnout zu sein.

Ein weiteres gutes Buch von Onkel Bob. Im Grunde geht es darum, ein Profi zu sein. Er spricht über seine Karriere, seine Fehler, Best Practices, Zeitmanagement, Schätzungen und Arbeiten unter Druck. Der Clean Coder ist nicht nur für Entwickler gedacht, sondern ein Selbsthilfebuch für alle, die sein Fachgebiet in der heutigen Welt beherrschen möchten, in der Unternehmen von Zusammenarbeit und Technologien angetrieben werden.

Erinnerte mich daran, was es bedeutet, ein professioneller Entwickler zu sein, gab aber auch praktische Tipps zum Verwalten von Projekten, zum Codieren von Ansätzen usw.

Ein bisschen zu viel Flaum, aber ein großartiges Buch über Professionalität in der Softwareindustrie

Sehr empfehlenswert für alle Programmierer (insbesondere für diejenigen, die sich "professionell" nennen möchten).

- 60 Stunden pro Woche zu arbeiten ist eine praktische Idee.
- Es braucht Zeit, um ein gutes Team aufzubauen, also brechen Sie das Team nicht. Füttere Projekte an das Team.

Tolles Buch, leicht zu lesen, tolle Geschichten. Gibt eine Zusammenfassung des Programmierlebens und macht Ihnen klar, dass die meisten Probleme, mit denen Sie sich täglich beschäftigen, häufiger auftreten als Sie!

Dieses Buch gibt einige wichtige Perspektiven darüber, wie sich professionelle Programmierer verhalten müssen und welche Werte sie einhalten müssen. Er legt großen Wert auf testgetriebene Entwicklung. Es ist eine schnelle Lektüre mit einigen interessanten Punkten zum Mitnehmen.

Wichtige Informationen

Buchbesprechung - der saubere Codierer
Uncle Bob
Robert C. Martin

Professionell zu sein bedeutet, Verantwortung zu übernehmen

Erstens: keinen Schaden anrichten (an Funktion oder Struktur)

Fehler in Ihrem Code beeinträchtigen die Funktion. Geben Sie qa erst dann Code, wenn Sie ihn bereits getestet haben.

Sie sollten eine 100% ige Testabdeckung anstreben. Wenn eine Funktion schwer zu testen ist, sollte sie neu geschrieben werden, um das Testen zu vereinfachen. TDD

Tests automatisieren. Wenn es einfacher ist, machst du es tatsächlich.

Gnadenloses Refactoring oder die Pfadfinderregel: Verlasse jedes Modul besser als du es gefunden hast. Suchen Sie bei jeder Überprüfung nach Verbesserungen. Wenn diese schwieriger zu implementieren sind als erwartet, kann dies ein Designproblem widerspiegeln.

Profis lernen und entwickeln sich kontinuierlich (auch in ihrer Freizeit). Die Regel 40 + 20 ist, 20 Stunden pro Woche damit zu verbringen, Ihre Fähigkeiten für Ihre Karriere zu entwickeln.

Arbeit ist Leistung. Ein Profi muss üben. Machen Sie Code-Kata, lernen Sie neue Sprachen, probieren Sie neue Dinge aus, arbeiten Sie zusammen, koppeln Sie und holen Sie sich einen Mentor.

Kennen Sie Ihre Domain und Ihre Kunden: Erfahren Sie etwas über das, wofür Sie schreiben (Buchhaltung, Reisen). Stellen Sie sicher, dass das, was Sie tun, nicht nur den Spezifikationen entspricht, sondern auch für diese Branche nützlich ist.

Demütig sein. Sie könnten die nächste Person sein, die einen Fehler macht.

Kapitel 2 - sag nein

Profis sagen der Macht die Wahrheit und sagen Nein zu ihren Managern.

Kompromisse können kontrovers sein, wenn die Ziele nicht perfekt aufeinander abgestimmt sind: Der Manager benötigt ein Produkt, das für die Demo bereit ist, und der Ingenieur muss den richtigen Weg finden. Wenn der Manager darum bittet, Schritte zu beschleunigen und zu überspringen, sagt der Fachmann Nein und arbeitet an einem Kompromiss (Verzögerung, Modell, einmalig, gefolgt von einer zusätzlichen Auszeit für den Programmierer usw.).

Nein zu sagen ist am wichtigsten, wenn viel auf dem Spiel steht.

Kapitel 3 - Ja sagen

Verpflichtung ist: Sag es, mein es ernst, tu es.

Fachleute müssen nicht zu jeder Anfrage Ja sagen. Wenn sie ja sagen, sollten sie diese Verpflichtung einhalten und nicht die Qualität der Arbeit oder des Lebens opfern.

Kapitel 4 - Codierung

Meisterschaft kommt von Vertrauen und Irrtum.

1. Ihr Code sollte funktionieren. 2. Ihr Code sollte das Problem des Kunden lösen (wie es wirklich ist, nicht unbedingt wie beschrieben). 3. Ihr Code sollte in das System passen, ohne die Steifigkeit, Fragilität oder Opazität zu erhöhen. 4. Ihr Code sollte für andere Ingenieure lesbar sein.

Stellen Sie sicher, dass Ihr Schlaf, Ihr Lebensstil und Ihre Gesundheit aufeinander abgestimmt sind, damit Sie gute Arbeitszeiten haben.

Professionelle Entwickler teilen ihre persönliche Zeit so ein, dass ihre Arbeitszeit so produktiv wie möglich ist. Bringen Sie Ihr Privatleben und Ihren Kopf in Ordnung, denn abgelenkter Code ist schlechter Code.

Das Betreten der "Zone" ist nützlich zum Üben, aber die Produktionsarbeit ist in der Zone oft kurzsichtig oder begrenzt, sodass der geschriebene Code wahrscheinlich später zurückgegeben und behoben werden muss.

Die Debugging-Zeit ist genauso teuer wie die Codierungszeit.

Stimmen Sie nicht zu, Überstunden oder lange Arbeitszeiten zu leisten, insbesondere nicht länger als zwei Wochen und ohne Backup-Plan, wenn der zusätzliche Aufwand das Projekt nicht abschließt.

Definieren Sie erledigt und lassen Sie diese Definition nicht verrutschen. Sie werden später nicht mehr zurückkehren, um es zuzuknöpfen.

Holen Sie sich Hilfe und geben Sie anderen Programmierern Hilfe.

TDD
1. Sie schreiben keinen Produktionscode, bis Sie einen fehlgeschlagenen Komponententest geschrieben haben.
2. Sie schreiben nicht mehr von einem Komponententest, als ausreicht, um fehlzuschlagen.
3. Sie schreiben nicht mehr Produktionscode, als zum Bestehen des fehlgeschlagenen Komponententests erforderlich ist.

Vorteile: Sicherheit, Fehlerinjektionsrate, Mut (Änderungen vorzunehmen), Dokumentation, Design.

Praxis:

Codieren von Kata, um Sie darin zu schulen, bereit zu sein, Produktionscode effizient bei der Arbeit zu machen.

Wasa: Paar Kata. Schreiben Sie einen Komponententest, dann schreibt Ihr Partner den Produktionscode, um ihn zu bestehen, und den nächsten fehlgeschlagenen Komponententest. Hin und her gehen.

Randori: Round Robin Gruppe Wasa.

Üben Sie in Ihrer Freizeit und tragen Sie zu Open Source-Projekten bei. Lernen Sie neue Frameworks, Sprachen und Paradigmen.

7 - Abnahmeprüfung

Vermeiden Sie:
Vorzeitige Präzision
Das Unsicherheitsprinzip der Kunden
Schätzungsangst
Späte Mehrdeutigkeit

Fertig ist abgeschlossen. Besteht alle Tests. QS genehmigt. Stakeholder getestet und genehmigt. Kein Fachmann erlaubt, dass Code nur teilweise festgeschrieben wird.

Im Idealfall würden Geschäftsanalysten die "Happy Path" -Tests schreiben, da diese einen Prozesswert liefern.
Im Idealfall würde die Qualitätssicherung die Tests "Unglücklicher Pfad" schreiben, da sie sich mit dem befassen, was mit einem Produkt schief gehen kann.

Wenn ein Entwickler der Meinung ist, dass ein Test wie geschrieben falsch ist, sollte er mit dem Verfasser über Vorschläge sprechen, um ihn richtig zu machen. Seien Sie direkt für das, was für das Projekt am besten ist. Das Schreiben von Code, um nur einen Test zu bestehen, ist passiv aggressiv und nicht professionell.

Abnahmetests sind keine Unit-Tests.
Unit-Tests werden von Programmierern für Programmierer geschrieben.
Abnahmetests werden vom Unternehmen für das Unternehmen geschrieben.

Einheits- und Abnahmetests sind in erster Linie eine Dokumentation des Designs, der Struktur und des Verhaltens. Dass sie überprüfen, was sie angeben, ist ein sekundärer Effekt.

Das Prinzip der Einzelverantwortung besagt, dass Sie die Dinge, die sich aus verschiedenen Gründen ändern, trennen und diejenigen, die sich aus demselben Grund ändern, zusammenfassen sollten.

Schreiben Sie Geschäftsregel-Tests mit derselben API, die die GUI verwendet. Halten Sie die Präsentation von der Logik getrennt.

CI - Lassen Sie Ihren Quell-Build und Ihre Tests beim Einchecken von Code automatisch ausführen. Teilen Sie die Ergebnisse mit.

Einheit, Komponente, Integration (Leistung und Durchsatz), System und schließlich manuelles (menschliches) Testen.

8 - Treffen - haben eine Agenda und ein Ziel. Gehen Sie, wenn Sie müssen. Lehnen Sie ab, wenn Sie müssen. Zeitverschwendung ist unprofessionell.

Stand-Ups: Was habe ich gestern gemacht, was werde ich heute machen, was hält mich auf? Weniger als 1 Minute pro Person

Prioritätsinversion für schwierige Aufgaben, vermeiden Sie es. Vermeiden Sie schwierige Aufgaben nicht, nur weil sie schwierig sind.

9 - Schätzungen. Unternehmen sehen sie als Verpflichtungen und Entwickler sehen sie als Vermutungen.

Programmevaluierungs- und Überprüfungstechnik (PERT) US Navy 1957: Die trivariate Analyse bestand aus optimistischen, nominalen und pessimistischen Schätzungen.

Mu = (O + 4N + P) / 6 = erwartete Dauer der Aufgabe.

Q = (P - O) / 6 ist die Standardabweichung der Wahrscheinlichkeitsverteilung der Aufgabe.

"Wideband Delphi" - Eine Gruppe kommt zusammen, um eine Aufgabe zu diskutieren und zu schätzen, und wiederholt ihre Schätzung, bis sie zu einer Einigung kommt.

Der professionelle Entwickler ist unter Druck ruhig und entschlossen.

Benachrichtigen Sie die Stakeholder, wenn Sie sich nicht sicher sind, ob Sie Ihre Verpflichtungen erfüllen können.

Profis erliegen nicht der Versuchung, ein Chaos zu verursachen, um sich schnell zu bewegen.

Wählen Sie Disziplinen aus, in denen Sie sich in einer Krise wohl fühlen, und verwenden Sie diese dann ständig.

Unter Druck: Keine Panik. Kommunizieren. Verlassen Sie sich auf Ihre Disziplin. Hilfe erhalten.

Die erste Priorität eines Fachmanns ist es, die Bedürfnisse seines Arbeitgebers zu erfüllen.

Teams sind schwerer aufzubauen als Projekte. Erstellen Sie ein Team, das von Projekt zu Projekt wechseln kann, anstatt für jedes neue Projekt ein neues Team zu erstellen.

Anhang A. Werkzeuge.

Verwenden Sie die Quellcodeverwaltung. Vorzugsweise Open Source, da diese fubu geschrieben wurden. Git über CVS / SVN.

Erfahren Sie, wie Sie IDE-Funktionen verwenden. vi <emacs <intellij / eclipse <welcher Editor auch immer speziell auf die Sprache Ihrer Wahl abzielt.

Problemverfolgung: Verwenden Sie Pivotal Tracker, Lighthouse, einen Kanban. Wie groß ist Ihr Team und das Projekt? Überbezahlen Sie nicht zu viel.

Kontinuierlicher Build: Verwenden Sie Jenkins oder ähnliches, das an Ihre Versionskontrolle angeschlossen ist, damit bei jedem Einchecken automatisch Tests ausgeführt werden und das Team über wichtige Änderungen informiert wird. Jedes Commit, das das Programm unterbricht, sollte als Show-Stopper betrachtet werden, und alle Programmierer sollten zusammenarbeiten, bis ein festes Commit Build / Test besteht.

Machen Sie niemals eine bahnbrechende Veränderung. Führen Sie den Build auf Ihrem Computer aus und stellen Sie sicher, dass er funktioniert, bevor Sie ihn einchecken.

Unit-Tests sollten: schnell und einfach ausgeführt werden, Bestehen oder Nichtbestehen anzeigen, Testfortschritt anzeigen, einfach zu schreiben sein und einzelne Tests von der Kommunikation untereinander abhalten.

Komponententest: Wenn möglich, sollte Business + QS geschrieben sein und beschreiben, was das Unternehmen davon hält, dass das Programm das tut, was beabsichtigt war. Testen auf API-Ebene.

Komponententest-Tools sind die Mittel, mit denen wir festlegen, dass eine Aufgabe erledigt wird. Das Unternehmen war sich einig, dass dies der Fall sein sollte, wenn es diesen Test bestanden hat.

Komponenten-Test-Tools, die Bob mag: Fitness, RobotFX, grüner Pfeffer, Gurke, Verhalten.

Integrationstests: UI-Tests sind spröde, aber Existenz- (Render-) Tests der UI sollten es sein. End-to-End-Tests müssen auch die Benutzeroberfläche testen.

Bob mag Selen und Waitr für UI-Tests.

UML / Model Driven Architecture sollte das Programmieren in Text der Vergangenheit angehören lassen. Architekten würden ein System auf hoher Ebene über Diagramme entwerfen und es an einen Interpreter weitergeben, um den eigentlichen Code zu schreiben.
Dies hat nicht funktioniert, da alles kompliziert ist und Codierer wissen müssen, wie Details zu verwalten sind, die mit MDA sehr schwierig wären.

Die Geschichte von Newline und Carriage Return / n / r wurde diskutiert und wie wir immer noch damit kämpfen, da es von Menschen von physischen Maschinen auf Computercode portiert wurde. Entweder nicht zustimmen oder die Spezifikation vergessen / verwechseln.

Programmierer müssen diese Details verwalten.

für (int i = 0; i <Integer.MAX_VALUE; i ++) {
System.out.println ("Bestes Buch aller Zeiten!");
}
Nicht wirklich. Sie haben dieses Buch nach Clean Code, Pragmatic Programmierer, gelesen. Dies ist genau das, was Sie brauchen, wenn Sie selbst in die Handwerksrichtung fahren.

Rezension auch in meinem Blog unter: http://codependentcodr.blogspot.ca/20...

Dieses Buch ist größtenteils eine Fortsetzung von Martins anderem sehr bekannten Buch "Clean Code". Während sich dieses Buch auf die Artefakte (Code) konzentriert, die wir Entwickler produzieren, konzentriert sich dieses Buch auf den Entwickler selbst. Wie sollen wir als professionelle Entwickler handeln? Was ist der Unterschied zwischen einer Verpflichtung und einer Schätzung? Was sind unsere Aufgaben? Wann können wir nein sagen und wie machen wir das? Wann müssen wir ja sagen? Wie werden wir besser in dem, was wir tun?

Martin versucht, seine fast 40-jährige Erfahrung in hart umkämpften Lektionen zusammenzufassen. Während es sehr geschätzt wird, "Geschichten aus den Schützengräben" zu hören, hat das Buch einen ziemlich hartnäckigen "Do as I say" -Ton. Mach kein TDD? Na dann bist du kein Profi. Erstellen Sie ehrgeizige Schätzungen? Na dann bist du kein Profi. Aus rhetorischer Sicht stützt sich das Buch auf diesen Ansatz des "Beweises durch Berufung auf Professionalität", anstatt solide Beweise und Daten zu liefern, um viele seiner Argumente zu stützen. Zum Beispiel hat das TDD-Kapitel die Passage:


Yes there have been lots of controversial blogs and articles written about TDD over the years and there still are. In the early days they were serious attempts at critique and understanding. Nowadays, however, they are just rants. The bottom line is that TDD works, and everybody needs to get over it.

Ich denke, der Absatz hätte mit "QED" enden sollen. Kaum ein schlüssiges Argument für TDD, und die spontane Ablehnung jeglicher Kritik an der Praxis schadet wirklich dem Punkt, den er macht.

Trotzdem ist es sicher klar, dass vieles, was er anbietet, ein guter Rat ist und eine offene Herausforderung für Entwickler darstellt, besser zu werden. Wenn Sie die Rhetorik "Wenn Sie dies nicht tun, sind Sie nicht professionell" beiseite lassen, ist dieses Buch im Kern ein Aufruf an die Entwickler, der Verantwortung für den Job, für den sie eingestellt wurden, gerecht zu werden. Oft möchten wir als Entwickler uns abschotten, uns auf unsere eng definierten technischen Aufgaben konzentrieren, und das ist einfach unrealistisch. Ein Teil der Verantwortung als Entwickler besteht darin, den Kontext Ihrer Arbeit zu verstehen, warum dies wichtig ist und warum es dem Kunden / Kunden / Unternehmen / etc. Einen Mehrwert bietet. Und wenn dieser Wert nicht vorhanden ist, liegt es an Ihnen, ihn zu finden.

Als solches fand ich dieses Buch sowohl erfrischend als auch erschreckend. Erfrischend, eine Stimme aus der agilen Community zu hören, die nicht das Gefühl zu haben scheint, dass die Bestellung die einzige Stelle ist, die für die Identifizierung des Werts verantwortlich ist.
Es ist erschreckend zu glauben, dass ich als introvertierter Softwareentwickler die Pflicht habe, mehr zu tun als nur guten, sauberen Code zu schreiben.

In Bezug auf die Struktur ist das Buch in 14 verschiedene Kapitel unterteilt, die jeweils ein Thema behandeln, das für professionelle Entwickler von Interesse ist. Zwar gibt es einige technische Diskussionen, diese sind jedoch relativ selten. Im Großen und Ganzen konzentrieren sich die Kapitelthemen eher auf "weiche" als auf technische Fähigkeiten.

Alles in allem ist es, obwohl es hartnäckig und manchmal "predigend" ist, eine sehr lohnende Lektüre für jeden, der eine Karriere in der Softwareentwicklung in Betracht zieht oder lebt.