9 1/2 Tipps wie man ein guter Programmierer vong code her wird
Oft ist es hilfreich, Ziele mal aus einer anderen Perspektive (z.B. mit der Kopfstandmethode) heraus zu betrachten. Ich habe ganze 9 1/2 Tipps wie man ein guter Programmierer wird gefunden. Hier das Ergebnis meiner Nachforschung.
Die Befolgung nachstehender Tipps erfolgt auf eigene Gefahr 🙂 und
garantiert interessante aber in jedem Fall erfolglose Bewerbungsgespräche…Frage lieber nicht nach Hilfe
Wenn man als Programmierer eine Sache nicht machen sollte, dann Hilfe holen wenn das Hirn mal beim Coden nicht weiterkommt. Schon gar nicht sollte man diese Hilfe bei Softwareentwicklern holen. Wie soll denn auch jemand helfen, dessen Berufsbezeichnung noch weniger geschützt ist als die eigene? Der absolute Tiefpunkt ist erreicht, wenn man Kollegen im Team fragen muss. Offenbart man nicht nur, dass man selber keine Ahnung hat. Nein, man deutet damit auch an, dass der Kollege genau diese Ahnung zu haben scheint und erhebt damit selbigen über das eigene Denkmal. Ein Fauxpas ohnegleichen. Schlimmer geht nimmer, sag ich nur. Jetzt weiß der ganze Laden wie elendig schlecht du beim Coden bist und wie toll der Kollege eingegriffen hat um das Projekt zu retten. Also merke:
Nie, nie, nie Kollegen um Hilfe bitten, es sei denn man kann sie anschließend ohne Zeugen Disposen().
Fasse Kritik immer negativ auf und nicht positiv
Ja das mit der Kritikfähigkeit ist so eine Sache. Hast du sie bist du schwach und jeder merkt’s. Hier ein paar Tipps:
Auf Distanz gehen: Die Kritik richtet sich immer direkt gegen dich persönlich. Versuche deswegen, das Problem ganzheitlich zu betrachten und nicht konstruktiv zu nehmen. Ein Tipp vom Kollegen wie „die Folien bei deiner Präsentation waren aber sehr dunkel…“ solltest du mit „Was kann ich dafür, dass du Fischauge einen Sehfehler hast?“ quittieren. Das schafft die nötige Distanz zum Fußvolk und eine geheime Terminanfrage beim Optiker um die Ecke.
Zuhören: Höre dir erst gar nicht an, was der andere sagt. Das heißt vor allem: Den Anderen nicht zu Wort kommen lassen!
Auf „Ich hätte da eine Anmerku…“ muss sofort ein „Lassen Sie mich bloß in Ruhe, Sie Querulant!“ aus dir herausschießen
Undankbar sein: Bedanke dich nie für die Anregungen und sieh die Kritik immer als Beginn für ein gemeinsames Problem mit dem Kritiker an.
Nachfragen: Frage sporadisch nach und wiederhole dabei das Gesagte, ob du die Kritik richtig verstanden hast. Mach anschließend eine kurze Atempause und beantworte deine eigene Frage selbst mit „Pfff, mir doch egal“
Benenne deine Variablen nicht nach ihrer Funktion die sie haben soll sondern nach ihren Datentypen
Variablen mit toll klingenden Namen wie TemperatureToHigh, displayName, _instanceOfWhateverFactory sind verpönt. Nutze lieber Variablen wie stringVar, retBoolA
oder Int0815. Damit bist du dir den Respekt der Programmierer die irgendwann mal deinen Code warten oder erweitern müssen sicher. Ja, sie werden dich in ihre
allabendlichen Gebete mit einschließen.
Nutze Magic numbers oder Stringliterale
Konstanten oder Enums werden nicht gerne gesehen. Der Grund liegt in einer allgemeinen Abneigung für fest vergebene Werte die gute Programmierer von Geburt an haben. Warum das so ist konnte noch nicht erforscht werden.
Wende nie die Pfadfinder-Regel an
Solltest du an Codestellen vorbeikommen die dir komisch vorkommen oder einen potentiellen Bug enthalten könnten gibt es nur eine Vorgehensweise:
Also, wenn Pfadfindern, dann nur im Wald und unter Anleitung eines Wanderführers.
Vergib den Methoden allgemeine Namen und pack so viele Funktionen wie möglich rein
Auch wenn es sehr schwer ist:
Versuche stets so viel Funktionalität in eine Methode wie möglich zu packen. Das macht den Code kompakter und man muss nicht an vielen Stellen im Code suchen sondern hat alles sehr schön in einer Datei stehen. Auch wenn die Methode über 500 Zeilen geht, was soll’s.
Hallo?! Klar kann man in einer einzigen Methode Abfragen diverser Datenbanken und neue Instanzen von assemblyfremden Klassen erzeugen und gleichzeitig Berechnungen sowie Logging verpacken. Sehr schön wird es zudem, wenn für die Methode ein allgemein gehaltener Name vergeben wird.
Ein GetOrSetCollectionOfBooksAndInitializeQueryDatabaseAndSetSomeCommonProperties_ ForUpcomingFunctionalities() ist doch total lesbar – außerdem deutet es ja auf zukünftig vorgesehene Funktionalität hin und man weiß genau, wo man diese Erweiterungen programmieren soll (gemäß YAGNI –> you absolutely gonna need it). Das GetOrSet am Anfang ist nur konsequent, weil man ja je nach Parameter das eine oder andere oder beides gleichzeitig machen können soll.
Übrigens, fast vergessen: Überladungen von Parametern (und damit mehrere, gleichlautende Methoden) in diesem Zusammenhang sind echt verpönt. Also, all das Zeug in eine Methode rein und gut ist.
Nutze Magic numbers oder Stringliterale
Konstanten oder Enums werden nicht gerne gesehen. Der Grund liegt in einer allgemeinen Abneigung für fest vergebene Werte die gute Programmierer von Geburt an haben. Warum das so ist konnte noch nicht erforscht werden.
Wende nie die Pfadfinder-Regel an
Hier nochmal der Hinweis.
Sicher
ist
Do repeat yourself
Wiederhole den selben Code so oft es dir möglich ist.
Vermeide Refaktorisierungs-Tools wie ReSharper um Code in separate Methoden zu unterteilen die ihn mehrfach nutzbar oder testbar macht.
Durch die ständige Wiederholung von gleichen Codefragmenten wird man besser. Indianerehrenwort!
Teile dein Wissen nicht mit anderen
Mein Schatz! Wir wollen ihn! Wir brauchen ihn! Wir müssen ihn haben, den Schatz! Sie haben uns den Schatz gestohlen! Garstige kleine Hobbits! Böse, tückisch, falsch!
Gollum
So wie Gollum seinen Schatz mit niemanden teilen möchten sollten Programmierer mit ihrem Wissen umgehen…Hä? Warum sollte man denn sein Wissen nicht preisgeben?
Nun, da gibt es einige Gründe.
Nehmen wir zunächst an, das eigene Wissen sei nicht besonders ausgeprägt. Es reicht also gerade noch aus um den aufrechten Gang zu gehen, den Wecker morgens zu stellen um nicht zu spät zur Arbeit zu kommen und auf jede kritische Frage der Kollegen zu Arbeitsabläufen o.ä. mit dem Standardsatz „Das haben wir schon immer so gemacht“ zu antworten. Ansonsten macht man mit diesem eingeschränkten Wissen alles wie die anderen oder äfft deren Verhaltensweisen nach.
Beim Smalltalk mit wirklich gescheiten Menschen merken diese bereits bei der dritten Silbe, dass gerade wertvolle Lebenszeit an ihnen vorbeigeht, weshalb sie deine Satzaussagen aus lauter Langeweile nach den 4 Fällen hin untersuchen. Was ihnen wiederum viel Schapass macht, da das deklinieren deiner eingeschränkten Sätze doch recht kompliziert ist.
Bei dieser Art von Wissen zeigt man der Umwelt, dass man sich durchaus vom Primaten unterscheidet, dieser Unterschied aber eher auf einer nicht so ausgeprägten Behaarung beruht.
Ähm? Sorry..bei einer Gruppe von Entwicklern, den sogenannten Hipstern, die mit Vollbart und in gebückter Haltung auf einem Waveboard kriechend einen 360er Kickflip beim Eintritt ins Büro machen hilft nichts mehr – diese sind tatsächlich kaum von unseren Freunden im Zoo zu unterscheiden. Wissen hin oder her. Zusammenfassung:
Hier ist Weniger mehr. Also lieber Klappe halten, am Satzbau arbeiten, so wenig wie möglich auffallen und das spärliche Wissen für sich behalten.
Nehmen wir nun an, das eigene Wissen ist groß. Wirklich groß. Derart groß, dass man nach Gesprächen mit Personen die weniger Wissen haben ein gewisses Unbehagen fühlt.
Nicht zuletzt deswegen, weil man sich nicht mehr sicher ist in der Schule aufgepasst zu haben und es doch einen fünften Kasus beim Satzbau gibt.
Ansonsten hat man immer alles richtig gemacht und ist immer Einserschüler gewesen. Die kompliziertesten Aufgaben hat man immer dir gegeben und du hast sie mit Bravour gelöst.
Warum sollte man dieses Wissen an andere weitergeben?
Man möchte doch weiterhin unentbehrlich sein. Bei Krankheit oder versehentlich genehmigten Urlaub sollen die Kollegen merken, dass man fehlt. „Wikis verfassen und Wissen streuen? Das liest eh niemand. Das hält mich nur von der richtigen Arbeit ab.“ Und was passiert, wenn dein weitergegebenes Wissen jemanden anderen als dich befördert? „Ich, der Tesla unter all den Primaten hier und der Edison da kriegt jetzt ein eigenes Büro!“
Auch hier ist Weniger mehr. Also lieber Klappe halten, den Satzbau bei Primaten studieren, bei Krankheit / Urlaub extrem auffallen und das immense Wissen für sich behalten…ganz genauso wie Gollum seinen Schatz.
Unterbreche Kollegen während sie im Flow sind
Wer kennt diese Situation nicht auch. Wochenlang arbeitet man an dieser einen UserStory…
As a highly complex Mars Robot-Unit
I want to be able to do extraordinary stuff with global significance on a very aggressive and inhospitable planet
So that my exceptionally gifted creator will be awarded with the next Nobel Prize
…und ist kurz davor den Durchbruch im Algorithmus für die Eintrittsphase in die Marsatmosphäre zu programmieren, da kommt der eine nette Kollege an deinen Tisch und fragt ob man Zeit hätte seinen Einzeiler zu reviewen. Jaaaa!,… da ist man doch echt froh für so eine Ablenkung. Vor allem dann, wenn die Stakeholder einem im Nacken sitzen und schon Andeutungen gemacht haben dich persönlich statt der Robot-Unit zum Mars zu schießen, wenn das Projekt nicht bis morgen fertig ist.
Als angehender Programmierer ist man bei den Senior-Entwicklern und Architekten die gerade im „Flow“ unterbrochen werden immer gerne gesehen. Schließlich waren sie ja auch mal jung, wenn auch exponentiell talentierter und schlauer als du jemals sein wirst. Klar lassen die alles sofort liegen um dir den Sinn oder Unsinn von Prefixen bei lokalen Variablen zu erklären. Schließlich gehört das fachsimpeln über diesen Bereich zu der Königsdisziplin im Code-Universum. Für das tolle Timing der Fragestellung werden sie dich bei deinem Vorgesetzen besonders lobend erwähnen.
Nicht zu verschweigen ist auch der Lebenslauf (Platin Status) der einem winkt:
…Herr Otto Frage-Bohrer stach durch seine einfühlsame und wissensbegierige Natur im hochdynamischen Projektgeschäft hervor. Seine Kollegen vermissen jetzt schon seine ständige Rumfragerei…
Beitragsbild von Carsten Bach: https://www.flickr.com/photos/carstingaxion/