Kaffeepause Nr. 13: Was jeder Programmierneuling wissen sollte; 4 Möglichkeiten, Design Thinking in Ihren Entwicklungsprozess zu integrieren

Was jeder Programmier-Neuling wissen sollte

Quelle: Stackoverflow Als Entwickler werden Sie viele verschiedene Theorien darüber hören, wie Code aussehen sollte. Manche Leute glauben, je weniger Codezeilen eine Anwendung hat, desto einfacher ist sie zu lesen. Aber das stimmt nur teilweise. Ich bevorzuge die Bewertung der Codequalität anhand der folgenden Kriterien:

1. Der Code sollte konsistent, informativ und gut dokumentiert sein.
2. Der Code sollte stabile, moderne Funktionen verwenden.
3. Der Code sollte nicht unnötig komplex oder fehlerhaft sein.

Wenn Sie sich entscheiden, die Anzahl der Codezeilen auf Kosten eines der oben genannten Kriterien zu reduzieren, wird dies zu einem Problem. TU das nicht.

Es ist schwierig, den Code einer anderen Person zu lesen

Tatsächlich beträgt das Verhältnis der Zeit, die für das Lesen und Schreiben von Code aufgewendet wird, mehr als 10 zu 1. Aber Sie können nicht darauf verzichten, den Code anderer Leute zu lesen. Sie müssen den Code einer anderen Person lesen. Und je früher Sie Ihre Fähigkeiten verbessern, desto besser. Versuchen Sie, den Code anderer Leute mithilfe offener GitHub-Repositorys zu studieren. Sie können jederzeit üben: Finden Sie einfach ein Projekt, das zu Ihnen passt, und vertiefen Sie sich in jede Zeile. Eine weitere Möglichkeit, Ihre Fähigkeit, den Code anderer Leute zu lesen, zu verbessern, besteht darin, mit dem Kopieren des Stils zu beginnen. Wenn Sie Code im Stil einer anderen Person schreiben, verbessert das nicht nur Ihre Lesefähigkeiten, sondern macht Ihnen den Code auch vertrauter. Versuche es.

Sie werden niemals „perfekten“ Code schreiben

Ich war vier Jahre lang Einzelentwickler, bevor ich anfing, in einem Team zu arbeiten. Die meiste Zeit habe ich geglaubt, dass jeder erfahrene Programmierer perfekten Code schreiben würde. Meiner Meinung nach ist es nur eine Frage von Zeit und Mühe, zu lernen, wie man perfekten Code schreibt. Aber als ich dem Team beitrat, wurde mir klar, dass niemand „perfekten“ Code schreibt. Zwar war der Code, der letztendlich in das System integriert wurde, fast immer „perfekt“. Warum ist das passiert? Es dreht sich alles um Code-Analyse. Ich arbeite mit einem Team wirklich brillanter Ingenieure. Dies sind einige der kompetentesten und selbstbewusstesten Programmierer, die man für Geld einstellen kann. Aber jeder von ihnen (einschließlich mir) würde eine echte Panikattacke bekommen, wenn jemals jemand vorschlagen würde, ungetesteten Code in die Anwendung aufzunehmen. Selbst wenn Sie denken, Sie seien der nächste Bill Gates, werden Sie Fehler machen. Ich spreche nicht einmal von logischen Fehlern, ich spreche von Tippfehlern und fehlenden Zeichen. Dinge, die Ihr Gehirn manchmal einfach nicht versteht. Dinge, die man nur mit frischen Augen wahrnehmen kann. Versuchen Sie, mit Menschen zusammenzuarbeiten, die auf Details achten und bereit sind, Ihre Arbeit zu kritisieren. Es wird zunächst schwierig sein, Kritik zu ertragen, aber es ist die einzige zuverlässige Möglichkeit, die Qualität Ihres Codes zu verbessern. Geben Sie Ihr Bestes, um beim Überprüfen des Codes nicht in die Defensive zu geraten, und nehmen Sie Kritik nie persönlich. Du bist nicht dein Code.

Sie sollten nicht 8 Stunden am Tag Code schreiben

Niemand kann Ihnen genau sagen, wie viel Zeit er täglich mit dem Schreiben von Code verbringt. Aber in Wirklichkeit schreiben nur wenige Menschen mehr als 4 Stunden am Tag Code. Wer damit nicht einverstanden ist, ist entweder die Ausnahme oder arbeitet für Unternehmen, die ihre Mitarbeiter schlecht behandeln. Programmieren ist eine intensive, geistig anstrengende Arbeit. Es ist völlig falsch zu glauben, dass jemand 8 Stunden am Tag, 5 Tage die Woche Code schreibt. Es wird selten vorkommen, dass Sie eine Frist einhalten müssen, aber wenn ich selten sage, meine ich fast nie. Lassen Sie nicht zu, dass die Arbeit Sie belastet und Sie zu Überstunden zwingt. Ich schlage nicht vor, dass Sie nur vier Stunden am Tag arbeiten. Die verbleibenden vier Stunden verbringen Sie normalerweise am besten mit folgenden Dingen:

• Erlernen neuer Tools, Funktionen, Anwendungen;
• Arbeitsabläufe mit Kollegen besprechen;
• Hilfe für Kollegen, die Schwierigkeiten bei der Arbeit haben;
• Aufgabenplanung;
• Code-Analyse;
• Geschäftstreffen/Meetings.

Ich empfehle außerdem dringend, über den Tag verteilt regelmäßig Pausen einzulegen und sich (zumindest ein wenig) zu bewegen. Die positiven Auswirkungen von Bewegung sind seit langem bewiesen.

4 Möglichkeiten, Design Thinking in Ihren Entwicklungsprozess zu integrieren

Source Tech Beacon Um ein Produkt zu entwickeln, das den Bedürfnissen Ihrer Kunden entspricht, müssen Sie überlegen, was sie wollen. Wenn Sie eine App mit verwirrender Navigation oder einer unnötig langen Ladeoberfläche geschrieben haben, bereiten Sie sich auf zukünftige Misserfolge vor. Als Programmierer müssen Sie sich möglicherweise tiefer mit dem Design des Produkts befassen, an dem Ihr Team arbeitet. Diese Art der Zusammenarbeit ist sehr nützlich, da jede Person Dinge bemerkt, die der andere möglicherweise nicht bemerkt. Ich biete Ihnen 4 Tipps, wie Entwickler und Designer zusammenarbeiten können.

1. Seien Sie von Anfang an dabei

Gehen Sie nicht davon aus, dass Design immer an erster Stelle und Entwicklung an zweiter Stelle steht. Das mag stimmen, bedeutet aber nicht, dass Entwickler nicht in den Designprozess einbezogen werden sollten. Der Programmierer kann wichtige technische Informationen darüber liefern, wie das Projekt umgesetzt werden kann, während die Designer die Wünsche der Benutzer besser verstehen. Besser ist es, so früh wie möglich herauszufinden, welche Funktion technisch nicht möglich ist oder den Nutzeranforderungen nicht entspricht. Wenn Designer und Entwickler zusammenarbeiten, können Probleme sofort erkannt und gelöst werden, anstatt erst nach der Genehmigung des Entwurfs. Viele Unternehmen verfolgen bei der Softwareentwicklung einen kollaborativen Ansatz. Das bedeutet, dass die Teammitglieder nicht nur für ihre eigene Phase oder ihren eigenen Codeabschnitt verantwortlich sind, sondern gemeinsam die Verantwortung für alles vom Design bis zum Testen übernehmen.

2. Lernen Sie den UX-Prozess

Diejenigen, die mit UX (Benutzererfahrung) nicht vertraut sind, verstehen möglicherweise nicht, warum Teams Designs wegen scheinbar unbedeutender Details immer wieder ändern. Jeder Schritt im UX-Prozess geschieht aus einem Grund: dem Benutzer das bestmögliche Erlebnis zu bieten. Daher ist es wichtig, von Anfang an auf die Erstellung eines UX-Prozesses zu achten. Es kann Folgendes umfassen:

• Recherche zum Zweck des Projekts;
• Erstellen eines Wireframes – ein einfaches Design, mit dem Sie die Hauptmerkmale des Produkts bestimmen können;
• Hinzufügen feinerer Details zum Projektdesign, beispielsweise der Benutzeroberfläche;
• Benutzertests von Designs. Dies ist vielleicht die wichtigste Phase der UX-Entwicklung. Dadurch erhalten Sie wertvolle Informationen über das Produkt, bevor Sie Zeit in die Entwicklung investieren.
• Iteration: Iterieren Sie das Design mithilfe der Analyse der Testergebnisse, um die Benutzererfahrung zu verbessern.

Die Teams wiederholen die Entwurfs- und Testschritte mehrmals, bis keine Änderungen mehr vorhanden sind oder wenn die Zeit es erlaubt. Dies bedeutet normalerweise, dass Sie über mehrere Versionen des Designs verfügen.

3. Verfolgen Sie die Designentwicklung

Es ist sehr schlimm, wenn Designer ein Projekt erstellen, ohne die Entwickler zu konsultieren. Es ist kontraproduktiv. Für DevOps ist es wichtig, Regeln festzulegen, damit Entwickler Zugriff auf Design-Blaupausen in leicht zugänglichen Formaten wie PNG oder PDF haben. Eine effektive Zusammenarbeit zwischen Entwicklern und Designern ist entscheidend für die erfolgreiche Implementierung einer Anwendung. Vermeiden Sie auf jeden Fall die blinde Übergabe eines fertigen Entwurfs. Es ist besser, einen Fehler am Anfang zu korrigieren, als am Ende.

4. Vereinbaren Sie, zu welchem ​​Zeitpunkt Ihnen das Projekt gezeigt wird

Wenn Entwickler gebeten werden, eine minimal lebensfähige Version eines Produkts (MVP) zu erstellen, müssen sie die Anforderungen an die endgültige Version von Anfang an kennen. Dies ist notwendig, um Probleme mit ungerechtfertigten Erwartungen zu vermeiden. Designer müssen dem Entwickler beide Versionen des Designs zeigen: sowohl das MVP als auch die endgültige Version. Dies hilft bei der Implementierung des MVP und berücksichtigt dabei, was der Kunde in der endgültigen Version erwartet. Wenn Designer und Entwickler zusammenarbeiten, profitieren sie von vielen Vorteilen. Jeder von ihnen verfügt über Wissen, das auf die Erfahrungen des anderen angewendet werden kann. Entwickler können wertvolle Einblicke in die Funktionen geben, die im Design nicht implementiert werden können. Andererseits entlastet die Zusammenarbeit mit einem Programmierer den Designer von der Notwendigkeit, das Projekt erneut zu erstellen, was dementsprechend Zeit für das gesamte Team spart.