Überwindung langsamer Problemlösungen aufgrund eines erhöhten Wissens darüber, was schief gehen könnte [geschlossen]

Das beunruhigt mich schon seit einiger Zeit und ich würde mich sehr über die Beiträge anderer Fachleute freuen.

Kurzer Hintergrund: Ich fing an zu programmieren, als meine Eltern mir 1988 meinen ersten Computer kauften (im Alter von 14 Jahren bin ich jetzt 39). Ich habe ein paar andere Karrierewege eingeschlagen, bevor ich 1997 zum professionellen Programmierer wurde. Vielleicht ein Spätzünder, aber so war es. Ich bin immer noch glücklich mit meiner Wahl, ich liebe das Programmieren und ich betrachte mich als gut in dem, was ich tue.

In letzter Zeit ist mir aufgefallen, dass je mehr Erfahrung ich sammle, desto länger dauert es, Projekte oder bestimmte Aufgaben in einem Projekt abzuschließen. Ich werde noch nicht senil. Es ist nur so, dass ich so viele verschiedene Arten gesehen habe, wie etwas schief gehen kann. Und die potenziellen Fallstricke und Fallstricke, die ich kenne und an die ich mich erinnere, werden immer größer.

Triviales Beispiel: Früher war es nur "okay, schreibe eine Datei hier". Jetzt mache ich mir Sorgen über Berechtigungen, Sperren, Parallelität, atomare Operationen, Indirektion / Frameworks, verschiedene Dateisysteme, die Anzahl der Dateien in einem Verzeichnis, vorhersehbare temporäre Dateinamen, die Qualität der Zufälligkeit in meinem PRNG und Stromausfälle in der Mitte Betrieb, eine verständliche API für das, was ich tue, ordnungsgemäße Dokumentation usw. usw. usw.

Kurz gesagt, die Probleme haben sich längst von "Wie mache ich das?" Zu "Was ist der beste / sicherste Weg, dies zu tun?" Verlagert.

Das Ergebnis ist, dass ich länger brauche, um ein Projekt zu beenden, als ein Neuling. Meine Version ist zwar absolut stabil und so undurchdringlich, wie ich es schaffen kann, aber es dauert länger.

Das obige Beispiel "Datei erstellen" war genau das, ein Beispiel. Reale Aufgaben sind offensichtlich komplexer, aber für eine allgemeine Frage wie diese weniger geeignet. Ich hoffe du verstehst, wohin ich damit gehe. Ich habe kein Problem damit, effiziente Algorithmen zu entwickeln, ich liebe Mathematik, ich mag komplexe Themen, ich habe keine Schwierigkeiten mit der Konzentration. Ich glaube, ich habe ein Problem mit der Erfahrung und folglich mit der Angst vor Fehlern (intrinsisch oder extrinsisch).

Ich verbringe fast zwei Stunden am Tag damit, mich über neue Entwicklungen, neue Techniken, Sprachen, Plattformen, Sicherheitslücken usw. zu informieren. Das Rätsel ist, dass ich umso langsamer Projekte abschließe, je mehr Wissen ich erhalte.

Wie gehst du damit um?

Sie sind nicht langsamer beim Abschließen von Projekten. Zuvor dachten Sie, Ihre unerfahrenen Projekte wären erledigt, als dies wirklich nicht der Fall war. Sie sollten diese Qualität an Kunden verkaufen.

"Diese Firma kann es vielleicht schneller und billiger machen, aber ist es wirklich so? Oder werden Sie jahrelang Wanzen jagen?"

Darüber hinaus müssen Sie die alte Redewendung kennen und akzeptieren: "Perfekt ist der Feind des Guten."

Klingt so, als ob es Zeit für Sie ist, sich der dunklen Seite anzuschließen: dem Management.

Ich schlage nicht vor, dass Sie die Programmierung aufgeben und Manager werden. Aber es scheint, dass all die Erfahrungen, die Sie bisher gemacht haben, technischer Natur sind. Beim einfachen Schreiben einer Datei fallen Ihnen 10 verschiedene Aspekte ein, die ein weniger ausgereifter Entwickler niemals berücksichtigen würde. Nicht unbedingt eine schlechte Sache, aber ...

Die dunkle Seite dreht sich alles um Barwert. Es geht um minimale Investitionen für maximalen Gewinn (Kosten-Nutzen-Analyse). Im Geschäftsleben läuft alles darauf hinaus, wie viel mich das kosten wird, wie hoch die Wahrscheinlichkeit eines Erfolgs, eines Scheiterns, eines spektakulären Scheiterns und eines potenziellen Gewinns ist. Rechne nach; handle entsprechend.

Dies funktioniert genauso gut, wenn Sie ein Entwickler sind: Erstellen Sie eine temporäre Datei, ignorieren Sie Berechtigungen und Namenskollisionen - 5 Minuten. Der Rest des Teams kann an dem Code arbeiten, der vom Vorhandensein dieser Datei abhängt. Ist es eine perfekte Lösung? Absolut nicht. Bekommst du 99%, 95%, vielleicht 90%? Ja, das wird es wahrscheinlich.

Noch eine Frage: Wie stehen Sie zu technischen Schulden? Einige Leute denken, dass es beseitigt werden muss. Ich denke, diese Leute sind falsch. Genau wie in der Geschäftswelt können Sie mit technischen Schulden "Bargeld" oder "Zeit" ausleihen, um etwas schneller zu liefern. Was ist besser: Eine perfekte Lösung in 2 Jahren oder ein kompletter Hack, den ein Kunde in 4 Monaten nutzen und kaufen kann? Jede Situation ist anders, aber in manchen Situationen, wenn Sie 2 Jahre warten, wird sich Ihr Kunde bereits bei Ihrer Konkurrenz anmelden.

Der Schlüssel ist, die technischen Schulden genauso zu verwalten, wie ein gut geführtes Unternehmen die finanziellen Schulden verwaltet. Wenn Sie nicht genug auf sich nehmen, erzielen Sie keine optimale Kapitalrendite. Wenn Sie zu viel annehmen, wird das Interesse Sie töten.

Mein Rat: Beginnen Sie mit der Bewertung Ihrer Arbeit, indem Sie prüfen, ob Sie Ihren Wert maximieren, anstatt Ihre Gründlichkeit zu maximieren. Und wenn Sie dies üben, entwickeln Sie die gleiche Intuition, die Sie bereits in Ihrem technischen Bereich entwickelt haben.

Als Randnotiz habe ich kürzlich angefangen, die Pomodoro-Technik anzuwenden, und sie hat mir sehr geholfen. Konzentrieren Sie sich statt auf einen Tangens auf einen Tangens in kleinen Zeitintervallen und weisen Sie dann Pomodoros für die zukünftige Arbeit / Forschung zu. Es ist erstaunlich, wie oft ich mir eine Notiz gemacht habe, um ein Thema zu recherchieren, aber eine Stunde später, als es soweit war, dachte ich mir: "Es gibt mindestens drei andere Dinge, die ich mit meiner heutigen Zeit machen könnte, die umso wertvoller sind."

Ich hatte vor vielen Jahren (wahrscheinlich) das gleiche Problem, es dauerte ein paar Jahre und ich habe es überwunden. Vielleicht wäre es für Sie interessant zu wissen, wie ich das geschafft habe, auch wenn ich nicht sicher bin, ob mein Weg auch für Sie gilt.

Hier sollten Sie auch einen Blick werfen: Die sieben Stufen der Erfahrung im Software Engineering Es zeigt, dass Produktivität zu einem großen Teil ein Nebeneffekt des Kenntnisstands ist. Es kann sein, dass Sie sich zwischen Stufe 3 und Stufe 4 der Technologie befinden, die Sie derzeit verwenden (die Fähigkeit hängt von der Technologie ab, Sie können einige Technologien beherrschen, während Sie andere noch erlernen).

Jetzt beginne ich mit einem biografischen Zeugnis.

Ein bisschen Kontext. Ich bin 47 Jahre alt. Ich habe mit 12 in den 80ern angefangen zu programmieren. Während meiner Schulzeit arbeitete ich auch als Teilzeit-Spielprofi. Im Grunde hat es mir nicht so viel Geld gebracht, gerade genug, um Hardware zu kaufen, aber ich habe es genossen und viel gelernt. Mit 18 Jahren begann ich ein formales Informatikstudium.

Als ich 20 Jahre alt war, kannte ich beim Starten einer Programmieraufgabe viele Möglichkeiten, um die gegebenen Probleme zu lösen, und war mir der vielen Parameter und Fallen sowie der Nachteile und Grenzen jeder Methode sehr bewusst.

An manchen Stellen (etwa im Alter von 26 Jahren) wurde es für mich wirklich schwierig, überhaupt ein Programm zu schreiben. Es eröffneten sich so viele Möglichkeiten, dass ich nicht mehr zwischen ihnen wählen konnte. Für ein paar Jahre (mache es 6) habe ich sogar aufgehört zu programmieren und bin technischer Nachrichtenschreiber geworden.

Trotzdem habe ich nie aufgehört zu programmieren. Und irgendwann kam es zurück. Der Schlüssel für mich war extreme Programmierung, genauer gesagt das Prinzip der Einfachheit: "Schreiben Sie die einfachste Sache, die möglicherweise funktionieren könnte".

Grundsätzlich habe ich mich gezwungen, mich nicht um Code-Effizienz zu kümmern (das war mein Hauptproblem, um ineffiziente Designs zu vermeiden), sondern einfach den einfachsten Weg zu gehen. Ich habe mich auch gezwungen, mich weniger um Fehler zu kümmern und die Fehlerbehandlung auf einen späteren Zeitpunkt zu verschieben, nachdem ich Tests geschrieben habe, die den Fehler auslösen (das ist eigentlich TDD).

Das habe ich beim Schreiben gelernt. Wenn ich nicht weiß, was ich schreiben soll oder was ich schreibe, ist das schlecht . Mach einfach weiter. Schreibe eigentlich die schlechten Sachen. Ich werde es später korrigieren. Oder wenn es wirklich so schlimm ist, löschen Sie es und schreiben Sie es neu, aber es ist schneller, Dinge zweimal zu schreiben, die beim ersten Mal alles Perfekte schreiben.

Es ist sehr wahrscheinlich, dass ein Code, von dem Sie glauben, dass er auf den ersten Blick gut ist, genauso verbessert werden muss wie ein wirklich schlechter.

Wenn Sie dem Einfachheitspfad folgen, erhalten Sie zusätzlich einen Bonus. Sie akzeptieren es einfach, das ursprüngliche Design / die Codierung zu entfernen / zu ändern. Sie erhalten einen flexibleren Verstand.

Ich hatte auch die Angewohnheit, einen temporären Kommentar in den Code einzufügen und zu erklären, was ich jetzt nicht tue und später tun möchte, wenn der Code im normalen Anwendungsfall funktionsfähig wäre.

Ich habe auch an einem XP Dojo teilgenommen und mich mit anderen Programmierern über geübte Code Katas ausgetauscht, um die XP-Praktiken zu verinnerlichen. Es half. Es hat die obigen formalen Methoden instinktiv gemacht. Pair-Programmierung hat auch geholfen. Die Arbeit mit jungen Programmierern gibt etwas Schwung, aber mit der Erfahrung sieht man auch, was sie nicht tun. In meinem Fall sehe ich zum Beispiel oft, dass sie sich mit übermäßig komplizierten Designs beschäftigen, und ich kenne den Design-Albtraum, der dazu führen kann. Auf diese Weise gegangen. Tat dies. Hatte Probleme.

Der wichtigste Punkt für mich ist, den Fluss zu halten. Schnell zu sein gelingt es wirklich, den Fluss zu halten.

Jetzt bin ich zurück als professioneller Programmierer und ich glaube, ich bin besser und schneller mit einem tieferen Verständnis dessen, was ich tue. Übe ich TDD? Ich bin vielleicht noch etwas langsamer als in jungen Jahren (und habe nichts getestet), aber ich habe auch keine Angst vor dem Refactoring und verbringe viel weniger Zeit mit dem Debuggen (fast keine Zeit, mache es weniger als 10% der Zeit) ).

Fazit: Ich habe meinen Codeblock mit agilen Methoden (XP) überwunden, mich der Einfachheit und dann dem Refactoring verschrieben und mich darauf geübt, diesen instinktiv zu machen. Es hat bei mir funktioniert. Ich bin nicht sicher, ob es auf andere verallgemeinert werden kann.

In Bezug auf das Niveau des Erwerbs von Fähigkeiten habe ich meistens gelernt zu akzeptieren, dass ich jedes Mal, wenn ich die Technologie ändere (neue Sprache, neue Rahmenbedingungen usw.), eine Phase durchlaufen werde, in der ich langsamer werde. Das ist normal und wird das irgendwann überwinden. Ich kann das auch mit guter Methodik und allgemeinen Programmierkenntnissen ausgleichen und es wird kein so großes Problem sein.

Ein wichtiger Teil der Programmierung ist das Management und die Kontrolle der Komplexität. Für mich persönlich ist dies eines der Hauptthemen. Wenn dies ignoriert wird, steigt entweder die Häufigkeit von Mängeln oder, wie in Ihrem Fall, die ETA der fertigen Software dramatisch an.

Die Softwarekomplexität kann auf vielen verschiedenen Ebenen und auf verschiedenen Wegen gesteuert und verwaltet werden. Eine gute Faustregel, um eine Perspektive zu erhalten, lautet jedoch: "Oberste Priorität eines Softwareprojekts ist die Kundenzufriedenheit, die von ihren Erwartungen abhängt."

Mit anderen Worten, die Komplexität der Software hängt in hohem Maße davon ab, wie gut Sie die Erwartungen Ihrer Kunden steuern können.

Wenn man diese Ansicht annimmt, werden zwei wichtige Punkte offensichtlich:

1. Kundenerwartungen müssen explizit gemacht werden (in welcher Form auch immer);
2. Kundenerwartungen können jederzeit geändert werden, und dies geschieht durch Verhandlungskunst.

Ihr Beispiel ist sehr gut, schreiben Sie es einfach gegen unzählige andere Überlegungen. Denken Sie darüber nach - wenn jemand umfassende Anforderungen für beide Varianten aufschreiben sollte, kann es eine Äquivalenz bei den beschriebenen Merkmalen geben oder nicht?

Der Bau einer F16 unterscheidet sich vom Bau einer Cessna, obwohl beide fliegen können.

Die einfache Antwort lautet: Akzeptiere es.

In allen Systemen müssen Kompromisse zwischen Zuverlässigkeit, Robustheit, Sicherheit, Geschwindigkeit, Hardwarekosten, Entwicklungskosten und Markteinführungszeit geschlossen werden. Sie werden nicht immer damit einverstanden sein, wie der Kunde diese Kompromisse eingeht, aber Sie sind nicht derjenige, der diese Entscheidungen trifft. Alles was Sie tun können, ist eine überlegte Meinung abzugeben. Die Softwareentwicklung deckt die gesamte Bandbreite ab, von "meiner persönlichen Webseite" bis "den Kernreaktor betreiben", und der Code muss entsprechend geschrieben werden. Wenn ein Absturz "Meine persönliche Webseite neu laden" bedeutet, wen interessiert das dann wirklich? Aber wenn ein Absturz "Tschernobyl" bedeutet, ist Ihre Vorliebe für soliden Code eher etwas ungezwungen für meinen Geschmack.

Es gibt einige Kunden, die gerne den Code auf "Proof of Concept" -Ebene akzeptieren und in ihren Live-Systemen ausführen, und oft haben sie Systemadministratoren, die gut daran gewöhnt sind. IME-Systeme sind normalerweise ungefähr eine Stunde lang mitten in der Nacht nicht verfügbar, während eine Reihe geplanter Neustarts stattfinden. Aber sie haben die Geschäftsentscheidung getroffen, dass sie so rollen wollen. Idealerweise, weil sich ihr Feld so schnell bewegt, dass ein qualitativ hochwertiger Code niemals bereit sein würde, aber oft, weil sie den Wert nicht sehen können (wenn ein System "einfach funktioniert", bemerken sie ihn nie, deshalb repräsentiert dieses System keinen Wert für Geld). Wenn es Sie zu sehr stört, versuchen Sie, diese Clients zu vermeiden.

Auf dem Laufenden zu bleiben ist Zeit, die wir alle verbringen müssen oder sollten. Manchmal bringt dich das zur Arbeit, manchmal hält es deinen Geist nur in guter Verfassung. Versuchen Sie es auf jeden Fall zu genießen.

Es hört sich so an, als wären Ihre Fähigkeiten sehr nützlich für die Entwicklung von geschäftskritischen Systemen von sehr hoher Qualität, wie Anwendungen für Finanzen / Handel, Rundfunk, Luft- und Raumfahrt, Verteidigung ...

Fehler in dieser Art von Anwendungen sind sehr kostspielig und sie beschäftigen Leute, die wie Sie denken, da Sie alle Fälle abdecken können.

Die Wahrheit ist, dass moderne Systeme immer komplexer werden. Der Computer ähnelt jetzt dem Spiel "Jenga", in dem sich all diese Teile auf viele der anderen Teile verlassen. Ziehen Sie das falsche Teil heraus, und Sie haben einen Fehler. Ziehen Sie ein korrektes / notwendiges Teil heraus, und es kann immer noch zu einem Fehler kommen. Je komplexer das System ist, desto mehr Zeit werden Sie wahrscheinlich damit verbringen, über Möglichkeiten nachzudenken, Ihren Code robuster und hoffentlich auch sicherer zu machen. Geschwindigkeit wäre schön, aber ich denke, Geschwindigkeit tritt heutzutage viel in den Hintergrund, wenn man in den Nachrichten hört, dass die Firma "XYZ" gehackt und die Kreditkartennummern von 6 Millionen Kunden gestohlen wurden.

Ihre Kunden möchten vielleicht nicht hören, dass ihr Programm sicher, robust usw. sein muss. Sie können ihnen jedoch sagen, dass ihr Auto weder Sicherheitsgurte und Airbags benötigt, noch dass ihr Haus Schlösser und Türen benötigt ... denn wer möchte alles hören? Das?

Wenn Sie überdenken, gehen Sie die Dinge richtig an, mit der Ausnahme, dass Sie eine Strategie wählen müssen, die "konkret" zu sein scheint, und einfach mitmachen.

Es hört sich so an, als ob Sie sich Ihrer Tendenz bewusst sind, über alles nachzudenken, was schief gehen kann.

Erfahrene, vorsichtige Entwickler lernen oft, das Mantra zu befolgen YAGNI. Sie werden es nicht brauchen, wenn sie versuchen, zu einem schlanken, agilen und produktiven Arbeitsablauf zurückzukehren, nachdem sie sich zu sehr mit dem Unkraut der Fehlermodusanalyse beschäftigt haben.

Wenn Sie jedoch in der Tat etwas in einem Bereich schreiben, in dem diese Sorgfalt nicht weniger als die Professionalität erfordert, sollten Sie sich darüber im Klaren sein, dass Ihre "Geschwindigkeit", Ihre "Produktivität", netto ausgedrückt, daran messbar ist, wie gut ( oder Schaden zufügen), den Sie Ihrem Unternehmen, Ihren Kunden und der Software-Suite oder Produktfamilie antun, die Sie erstellen oder pflegen.

Erinnere dich an:

• Berücksichtigen Sie die Gesamtkosten für die Wartung, die Gesamtbetriebskosten und die Gesamtkosten für die Bereitstellung und Wartung von Lösungen, wenn Sie Änderungen in Ihrem Ansatz berücksichtigen. Schneller zu werden und mehr Fehler zu machen kann die Dinge verbessern oder auch nicht.

• Wenn Sie in einem guten Unternehmen arbeiten, können Sie dies wahrscheinlich in Ihrem eigenen Team und mit Ihrem Vorgesetzten besprechen, ohne dass dies ein karrierebeschränkender Schritt ist. Wenn Sie nicht können, ist jetzt ein guter Zeitpunkt, um das herauszufinden und einen neuen Job zu finden.

Ich sehe nur: "Sie werden immer wertvoller".

Wenn Sie mehr Erfahrung sammeln, lernen Sie Dinge, die Sie vermeiden sollten, und das macht Sie besser als andere.

Eine Sache, die Sie bemerkt hätten, wäre, dass Ihr Code jetzt sicherer und wartbarer wäre.

• Sie müssen Ihrem Kunden nur erklären, warum es Zeit gekostet hat und wie es für ihn nützlich wäre.
• Sie müssen ihnen Tiefe Ihres Wissens zeigen.
• Sie müssen ihnen sagen, warum Sie es getan haben, was Sie getan haben und wie wichtig es für sie und ihre Geschäfte ist.

Mein Vorschlag wäre, sich auf diesen Teil zu konzentrieren.

Wenn Sie Zweifel haben, zitieren Sie Knuth ...

"Vorzeitige Optimierung ist die Wurzel allen Übels."

Hier ist, was ich vorschlagen würde, wie es scheint, dass Sie ein Problem haben, das ich von Zeit zu Zeit habe ...

Was bei mir wirklich funktioniert ...

1. Schreiben Sie die Komponententests so, als wäre der gesamte Code fertig.
   
2. dokumentieren Sie die Schnittstelle.
   
3. implementieren Sie die Schnittstelle.

was du wirklich getan hast:

1. Arbeiten Sie die Anforderungen der Modellebenen durch
2. Richten Sie wirklich die Arbeitsteilung ein, welche Objekte für was verantwortlich sind
3. Machen Sie sich an die Arbeit in einer Umgebung, in der Sie tatsächlich den Arbeitscode durchgehen können, wodurch die Dinge viel schneller und genauer werden ...

Verlassen Sie sich auch auf Asserts in der frühen Entwicklung ... und finden Sie heraus, welche Abhilfemaßnahmen implementiert werden müssen, und Sie werden keinen Code schreiben, der nicht erreichbar oder schwer zu testen ist.

Ich denke, Sie sollten sich an Ihre Kodierungsstandards halten, aber stellen Sie sicher, dass Sie mit Ihren Kunden vorne dabei sind. Viele Kunden wissen nicht, was es kostet, gute Software zu erstellen. Es gehört zum Beruf des professionellen Entwicklers, sie auszubilden.

Unabhängig davon, ob Sie agil oder wassersicher sind, erhalten Sie vom Kunden eine gewisse Einigung darüber, was er von der Anwendung erwartet. Zu viele Entwickler (OK, vielleicht mehr Verkäufer) haben sich des Sandsacking schuldig gemacht . "Sie sagten nicht, dass sie eine hochsichere Website wollten." In den meisten Fällen, weil sie nicht gefragt wurden. "Stört es Sie, wenn Ihre E-Commerce-Website gehackt wird?" Natürlich interessiert es sie und warum sollten Sie es bauen, damit jemand in die Sicherheit eindringt? Sie müssen sie erziehen.

Stellen Sie nur sicher, dass Sie nur das tun, wofür der Kunde Sie bezahlt. Ein Teil Ihrer Dienstleistung ist Ihre Erfahrung. Kunden erwarten, dass Sie die Fallstricke kennen, ohne dass sie danach fragen müssen. Es liegt an ihnen, die Anforderung aufzunehmen. Vielleicht möchten Sie Kunden weitergeben, die etwas Billiges wollen.

Denken Sie über die praktischen Konsequenzen eines Fehlers im Vergleich zu allen anderen Problemen nach, die gelöst werden müssen.

Berücksichtigen Sie die folgenden Konsequenzen, wenn Sie einen schlecht geschriebenen Code erstellen:

1. Die gesamte Datenbank wird alle zwei Monate gelöscht. 48 Stunden Ausfallzeit, während die Backups wiederhergestellt werden.
2. Kundendaten werden vernetzt. Bestellungen im Wert von 200 USD werden pro Monat an die falschen Kunden versendet.
3. Einmal pro Woche bleibt eine Bestellung in einem falschen Status hängen. Bestellen Sie Schiffe, aber das Lager muss jedes Mal den Helpdesk anrufen.
4. Ungefähr nach zwei Wochen stürzt die App ab und der Benutzer muss Daten im Wert von 2 Minuten erneut eingeben.
5. Einmal im Monat bleibt die App beim Start hängen. Der Benutzer muss den Prozess beenden und neu beginnen.

Der erste ist offensichtlich inakzeptabel. Nr. 2 - Nr. 5 können oder können nicht sein, abhängig von der Art des Geschäfts. # 2 - # 5 müssen im Zusammenhang mit anderen Problemen bewertet werden, mit denen das Unternehmen konfrontiert ist.

Im Idealfall würden 2 - 5 niemals passieren. Im wirklichen Leben möchten die Leute, die Ihren Gehaltsscheck unterschreiben, mit widersprüchlichen Prioritäten möglicherweise, dass Sie an anderen Dingen arbeiten, anstatt perfekten Code zu schreiben, der niemals ein Problem hat. Sie werden nicht beeindruckt sein, wenn # 5 auf Kosten der Behebung eines schwerwiegenderen Fehlers in einem anderen Programm behoben wird.

Die Lösung besteht darin, eine Sammlung von Bibliotheken mit häufig verwendeten Funktionen zu erstellen, die Sie projektübergreifend wiederverwenden können. ZB habe ich eine StringFunctions.dll .NET-Bibliothek, die Dinge wie Kodierung, Verschlüsselung, Entschlüsselung, Auswertung von regulären Ausdrücken usw. ausführt. Auf diese Weise muss ich nicht ständig Dinge umschreiben, die sich nicht ändern.

Ein Wrapper für Dateierstellungsaufgaben ist ebenfalls sehr sinnvoll. Ihre Bibliothek könnte eine Methode namens GetFile () bereitstellen, die alle Überprüfungen für Sie durchführt und entweder null oder eine Datei (oder was auch immer Sie für nützlich halten) zurückgibt.

Ich denke, Sie müssen lernen, zu entscheiden, wie viel für welches Projekt getan werden muss. Einige Projekte können trivial sein und Sie müssen wirklich nicht die ganze Zeit damit verbringen, sie zu perfektionieren. Nicht alles wird eine solide Verschlüsselung erfordern, und auch nicht alles wird auf Millionen Benutzer skaliert.

Das Schreiben eines Programms, das für mehr als eine Million Benutzer gut skaliert werden kann, erfordert Zeit und Erfahrung, die Sie jetzt haben. Wenn Sie jedoch wissen, dass Ihre Anwendung nicht von maximal 1000 Benutzern verwendet wird, ist es sinnlos, alles auszugeben dieses Mal, es zu perfektionieren.

Ich denke, dies ist eine wichtige Phase in Ihrer Programmierkarriere und jetzt müssen Sie zum nächsten Level übergehen, was mit Reife und nicht mit Programmieren zu tun hat. Sie müssen in der Lage sein, richtig zu entscheiden, wie viel Zeit und Code für ein bestimmtes Projekt ausreichen sollen.

Und wie alles andere können Sie dies auch mit Übung erreichen. Versuchen Sie also, dies zu entscheiden, bevor Sie ein Projekt starten, auch wenn Sie bereits daran arbeiten. Mit der Erfahrung werden Sie auch darüber hinwegkommen. Es mag am Anfang ein paar Hits und Misses geben, aber mit der Zeit werden Sie es perfektionieren (Entscheidungsfindung, nicht Code).

@ Zilk, ich bin kein großartiger Programmierer und programmiere seit 1998. Auch ich stehe jetzt vor diesem Problem. Aber was mir klar wurde, ist letztendlich Qualität. Wenn ich heute sterbe, sollte jemand in der Lage sein, das, was ich jetzt tue, von der Stelle aufzunehmen, an der ich abgereist bin. Dies sollten die Standards der Programmierung sein (Universal).

Ich bin jetzt vom Entwickler zum Architekten gewechselt. Der Wechsel zu Management verändert die Linie. Wenn Sie mit Ihrer Leidenschaft weitermachen möchten, können Sie Architekt werden.

Zunächst als Technical Architect -> Solution Architect -> Enterprise Architect -> Chief Architect und so weiter.

Als Architekt führen Sie Menschen zum Erfolg. Menschen wie Sie, die jahrzehntelang Erfahrung programmiert haben, die Sie nutzen können, um andere zu führen.

Wie ein Vogel höher fliegt er mehr Land als er sehen kann, so ist auch Ihre Erfahrung.

Lassen Sie mich auch sagen, dass die Programmierung einer korrekten Implementierung wichtiger ist als die schnellere Programmierung einer falschen Implementierung. Kürzlich hat einer meiner Junioren etwas Falsches programmiert und es hat eine Bank viel Geld gekostet. Natürlich hatten wir früher pünktlich geliefert, aber das brachte nichts! Wurde mir die Rolle des Leiters übertragen, obwohl derselbe Junior dieses Problem kodiert hätte, wäre es nicht passiert. Ich gebe dieses Beispiel, um zu betonen, dass es auch wichtig ist, eine gute Anleitung zu geben. Manche nennen diesen Job Beratung.

Eine andere Möglichkeit ist: Hören Sie auf, Code zu schreiben, und verkaufen Sie stattdessen Ihr Fachwissen, um die Probleme im Voraus zu erkennen.

Mit anderen Worten: Werden Sie Berater .

Viele Unternehmen zahlen gerne teure Dollars (wenn nicht Top-Dollars), um die Probleme zu erkennen, bevor sie Monate damit verbringen, den Code zu erstellen, der die Probleme verursacht. Es ist bekannt, dass das Beheben eines Fehlers im Design um Größenordnungen billiger / einfacher ist als das Beheben, nachdem er codiert, getestet und bereitgestellt wurde.

Sie werden nicht so viel Code schreiben, und Sie werden das wahrscheinlich verpassen, aber dann scheint es, dass die tatsächlichen Codezeilen nicht Ihre Kernstärke sind, sondern darin, zu wissen, welche Codezeilen geschrieben werden sollen - und welche nicht.

Konzentrieren Sie sich auf Ihre Stärken.
(na wenn es dir gefällt ...)

Meine beste Empfehlung für Sie ist: Bausteine.

Erstellen Sie einen Dateibaustein, dem Sie immer vertrauen können, erstellen Sie einen für Ihre API, und verschwenden Sie nicht mehr Ihre Zeit damit, immer wieder dasselbe zu schreiben. Denken Sie einmal über jedes Problem nach und beheben Sie es ein für alle Mal.

Keiner wird das nachholen, schon gar nicht der Neuling, der 80% seiner Zeit damit verbringt, Code zu debuggen, der in unerklärlichen Fällen fehlschlägt.

Beheben Sie vor allem keine Probleme, die nicht auftreten können, z. B. falsche Berechtigungen.

Wenn die Berechtigungen falsch sind, stimmt etwas bereits nicht, und Sie sollten dies beheben, anstatt Ihr Programm kugelsicher zu machen.

Irgendwann muss man sich einfach nicht mehr in den Fuß schießen, anstatt immer zu prüfen, ob man es getan hat oder nicht.

Nehmen Sie sich keine Zeit für die Dokumentation, sondern gestalten Sie Ihren Code selbstdokumentierend und so kurz wie möglich. Ersetzen Sie alle diese doppelten Funktionen. Verkleinern Sie Ihre Bibliothek und benennen Sie die Objekte präzise um.

Sei nicht zu hart mit dir. Sie arbeiten in einem immer komplexer werdenden Beruf, der mehr menschliche Intelligenz, Wissen und Erfahrung erfordert als jemals zuvor.

Die Rechenleistung des Computers verlangsamt sich - möglicherweise kommt es bald zum Stillstand - und es müssen Mehrkernchips, gpu-gesteuerte Zahlen, Parallelität usw. eingeführt werden. Es gibt nur so viele Transistoren, die auf einem Chip platziert werden können.

Daher werden die großen Fortschritte, die derzeit und in Zukunft erzielt werden, von Programmierern kommen - fortschrittliche Algorithmen und effizienterer Code.

Wenn man sich GTA 4 und GTA 5 ansieht, sind die Unterschiede verblüffend. Beide laufen jedoch auf der gleichen Hardware. Dies ist das Ergebnis einer sehr intelligenten und fortschrittlichen Programmierpraxis, die vor 10 Jahren einfach nicht erforderlich oder verfügbar war.

Dies könnte auch dazu führen, dass erfahrene Programmierer in Zukunft wertvoller werden - ähnlich wie bei anderen Berufen wie dem Ingenieurwesen, bei denen Spitzenverdienste normalerweise erst spät im Berufsleben anfallen.

Genau wie Sie begann ich mit 14 Jahren mit dem Programmieren, auch als ich meinen ersten Computer bekam (obwohl ich zu diesem Zeitpunkt einige Monate studiert hatte). Allerdings bin ich jetzt "nur" 33. :-)

Ich schlage vor, dass Sie bei der Entwicklung jedes dieser Probleme (Dateiberechtigungen, Anzahl der Dateien in einem Verzeichnis usw.) berücksichtigen und dann Ihre gesamte Erfahrung nutzen, um ein paar Fragen zu diesem Thema zu beantworten:

• Wie lange würde es dauern, um dieses Problem in Ihrem Code richtig zu behandeln?
• Wenn du nicht richtig damit umgehst, wie wahrscheinlich ist es, dass dich dieses Ding später beißt?
• Wenn es dich beißt, was sind die Konsequenzen?

Mit diesen Antworten ausgestattet, wird ein so erfahrener Mann keine Probleme haben, eine kluge Entscheidung zu treffen. ;-)

Es liegt in der Verantwortung von "Veteranen" wie Ihnen, diese Art von Anforderung zu entwickeln. Dies beinhaltet sowohl das Erkennen, was schief gehen kann, als auch die Entscheidung, welchen potenziellen Problemen Sie Aufmerksamkeit schenken sollten.

Die Kenntnis aller möglichen Kriterien bei der Entwicklung einer App ist das Wichtigste bei der Entwicklung eines Qualitätsprodukts. Du machst das gut. Eine Sache, die Sie tun können, ist, Sie können die Anforderung in Qualitätsstufen einteilen und dann die Stufe mit der angegebenen Frist abbilden. Auf diese Weise können Sie den Projekttermin einfach einhalten.

Mit den Worten von Edsger Dijsktra: „Wenn das Debuggen das Entfernen von Softwarefehlern ist, muss das Programmieren das Einspielen dieser Fehler sein.“ Sie machen nur weniger von letzteren, also müssen Sie weniger von ersteren machen. Es ist nur eine Frage des Lernens, Zeit damit zu verbringen, es richtig zu programmieren. Ich bin noch ein relativ junger Programmierer (lese 20ish) und strebe danach, einmal etwas völlig Richtiges zu programmieren. Eine Stunde Planen und 10 Minuten Codieren ist viel besser als 10 Minuten Planen, eine Stunde Codieren und drei Minuten Debuggen.