Hallo, mein Name ist Dmitry Karlovsky und ich bin ein professioneller Radfahrer. Im Laufe meiner Karriere habe ich ein paar Fahrräder gebaut: groß und klein, schnell und bequem, krumm und gerade. Daher ist es für mich ziemlich wild zu sehen, wie intelligente Programmierer große und komplexe Anwendungen erstellen, aber gleichzeitig ein anderes linkes Pad mit dem Projekt verbinden, anstatt ein paar einfache Zeilen mit meinen eigenen Händen zu schreiben. Der Grund dafür ist die Angst vor Fahrrädern in der Produktion, die sich unter Programmierern entwickelt hat und sich selbst unterstützt.

Programmer Evolution

Zur Vereinfachung der Darstellung unterscheiden wir 3 bedingte Gruppen von Programmierern. Bedingt, weil es keine klare Grenze zwischen ihnen gibt und dieselbe Person in verschiedenen Bereichen zu verschiedenen Gruppen gehören kann.

Neuling

• Er hat noch wenig Erfahrung und Wissen, aber er lernt schnell neue, da er noch keine Gewohnheiten hat.
• Aufgrund der Wirkung der Neuheit sieht er die Mängel bestehender Lösungen gut und hat den starken Wunsch, sich ohne diese Mängel selbstständig zu machen.
• Er weiß nicht, wie und warum diese oder andere Praktiken und Prinzipien entstanden sind, und wenn er dies tut, hat er die Gründe für ihr Auftreten auf seiner eigenen Haut nicht gespürt.
• Der größte Teil des von ihm geschriebenen Codes wird entweder weggeworfen oder bis zur Unkenntlichkeit überarbeitet. Bestenfalls mit eigenen Händen unter der Leitung erfahrener Kollegen.
• Er wird gnadenlos geschlagen, weil er Fahrräder schreibt, weil sich herausstellt, dass eine Bibliothek eines Drittanbieters in Bezug auf viele Kriterien besser ist.

Spezialist

• Die überwiegende Mehrheit der populären Bibliotheken wurde von ihm in seiner Freizeit aus seinem Hauptwerk heraus geschrieben, da sie sowohl für Fahrräder als auch zum Öffnen von Quellcodes immer noch die Hände schlagen.
• In der Regel entspricht die Qualität des Codes der durchschnittlichen Qualität des Codes im Ökosystem. Wenn jeder Nudeln aus Rückrufen schreibt, bleibt ihm nichts übrig.
• In der Regel wird Code von Drittanbietern verwendet, da der eigene Code aus zeitlichen Gründen nicht viel besser oder sogar schlechter ist.
• Dementsprechend erhält es weiterhin explizit (bei einer Codeüberprüfung) oder implizit (Fehlerberichte) Hände auf Fahrräder.
• Wenn ihn ein Problem komplett beschäftigt, sägt er ein Fahrrad. Und da es eine Mehrheit solcher Programmierer gibt, stellt sich heraus, dass 100.500 Fahrräder nicht miteinander kompatibel sind, unterstützt von eineinhalb Entwicklern.

Professionell

• Er ist in der Lage, jedes der Probleme besser als der Durchschnitt des Krankenhauses zu lösen, aber aufgrund begrenzter Ressourcen ist er gezwungen zu entscheiden, wofür er Zeit aufwenden möchte.
• Aus Gewohnheit schlugen sie ihn auf die Hände. Insbesondere wenn das Unternehmen Scrum praktiziert, bei dem alle Entscheidungen von der Mehrheit getroffen werden, vorbehaltlich des Mahn-Krüger-Effekts.
• Oft beschränkt er sich aufgrund der in den ersten beiden Phasen gebildeten Komplexe auf sich selbst und glaubt, dass er nichts Besseres tun kann als eine Drittanbieter-Bibliothek, die "getestet", "durchdacht" und "von einer großen Anzahl von Entwicklern unterstützt" wird.

Ursachen der Angst

Nach der Entwicklung des Programmierers ist leicht zu bemerken, dass er zunächst nur wenige Fähigkeiten, aber keine Angst hat, und wenn er Fähigkeiten erwirbt, tritt die Angst vor Fahrrädern auf und verstärkt sich. Um mit dieser Angst fertig zu werden, müssen Sie ihre Ursachen analysieren.

Ich kann es nicht besser machen

Ein Anfänger kann das wirklich nicht. Er sollte seine Bemühungen darauf richten, erfahreneren Kollegen und Bibliotheksentwicklern das Wesentliche und die Bedeutung der Probleme zu erklären, die er mit seinem frischen Aussehen sieht.

Ein Spezialist wird höchstwahrscheinlich keinen schlechteren Erfolg haben, wenn er sich mit den Problemen auskennt und sich mit anderen Spezialisten und Fachleuten berät.

Ein Fachmann kann es in den meisten Fällen besser machen, da er sich bereits mit dem Thema auskennt und sogar über die Fähigkeit einer umfassenden Analyse verfügt. Leider gibt es normalerweise niemanden, der sich mit ihm beraten kann, da es nur wenige andere Fachleute gibt, die sich mit anderen Themen beschäftigen. Und Spezialisten haben keinen Horizont.

Es wird niemanden geben, der Mängel repariert

Normalerweise ist der Autor des Fahrrads gut motiviert, Fehler in seiner Idee zu reparieren. Aber früher oder später vergeht diese Motivation, wenn er es nach Stunden tut. Und hier können Sie anscheinend mit einer Drittanbieter-Bibliothek Ressourcen sparen, da andere Personen, die nicht zahlen müssen, sich für deren Unterstützung engagieren. Es ist jedoch nicht möglich, sie zu beeinflussen. Um die Frist einzuhalten, müssen Sie die Ärmel hochkrempeln und den Defekt selbst beheben. Danach ist es lang und schwierig, Ihren Patch ohne Erfolgsgarantie in das Haupt-Repository einzubrechen.

Niemand wird sich verbessern und entwickeln

Hier ist die Situation dieselbe wie bei Mängeln. Wenn jedoch bei Defekten normalerweise allen klar ist, dass sie repariert werden müssen, ist die Sicht auf die Entwicklungsrichtung für alle unterschiedlich. Ein Drittentwickler entwickelt seine Bibliothek dort, wo er sie benötigt, und nicht für Sie. Mit der Geschwindigkeit, die für ihn und nicht für Sie günstig ist. Wenn also ein bestimmter Entwicklungsvektor erforderlich ist, bietet Ihnen Ihr Fahrrad Kontrolle und Vorhersehbarkeit - zwei Eigenschaften, die für das Management viel wichtiger sind als Zeit und Geld.

Ich kann es nirgendwo anders benutzen

Wenn Sie das Fahrrad außerhalb des Unternehmens verwenden möchten, müssen Sie es entweder in Ihrer Freizeit entwickeln oder sich auf die Öffnung der Quelle einigen, was normalerweise schwieriger, aber durchaus möglich ist. Schließlich erhält das Unternehmen bei potenziellen Mitarbeitern fast kostenlos PR sowie kostenlose Betatester (oder sogar Mitwirkende, auf die Sie sich jedoch nicht verlassen sollten) in der Person anderer Fahrradbenutzer.

Zeit und Geld werden verschwendet

Hier lohnt es sich zunächst, mit Alternativen zu vergleichen. Wenn es keine gibt, gibt es keine Wahl - Sie müssen es schneiden. Wenn es Alternativen gibt, lohnt es sich, Geld und Zeit zu vergleichen:

• Die Kosten für das Schreiben Ihres Fahrrads sind von guter Qualität. Dies umfasst den tatsächlichen Zeitpunkt des Schreibens des Codes sowie das Schreiben von Tests, das Übertragen des Projekts auf ein Fahrrad und die Bewertung der Kosten für eingeführte Fehler.
• Die Vorteile, die ein Fahrrad bietet. Dies kann zu Einsparungen aufgrund bestimmter Funktionen, immer weniger Fehler und anderer Faktoren führen.
• Die Kosten für die Integration einer Drittanbieterlösung. Wiederum einschließlich einer Bewertung der Testkosten und der eingeführten Mängel.
• Einschränkungen durch eine Drittanbieterlösung. Es kann sich herausstellen, dass eine Lösung von Drittanbietern überhaupt nicht passt. Oder dass es die Entwicklung um das Zweifache verlangsamt.

Es lohnt sich auch, die Kosten für den Wechsel von einer Drittanbieterlösung zu einem Fahrrad separat zu bewerten, wenn sich plötzlich herausstellt, dass einige der Einschränkungen inakzeptabler sind. Es kommt häufig vor, dass es jetzt rentabler ist, eine Drittanbieterlösung zu implementieren und sie dann schnell auf Ihr Fahrrad zu übertragen, wenn (und wenn) Sie sie benötigen, als jetzt Zeit mit dem Fahrradbau zu verbringen.

Diese Einschätzung hilft sowohl zu verstehen, ob das Spiel die Kerze wert ist, als auch dem Management zu erklären, warum es sich lohnt, ein eigenes zu schreiben und nicht das eines anderen zu nehmen (oder umgekehrt).

Ich werde verflucht sein, wie ich meinen Vorgänger verflucht habe

Es ist zweifelhaft, dass das Fahrrad einen bedeutenden Teil des Projekts einnahm. Sie werden also mehr für den Rest des Codes fluchen. Das Bike muss also zumindest nicht schlechter gemacht werden. Und noch besser, wenn niemand den Wunsch hatte, es durch eine Bibliothek eines Drittanbieters oder ein anderes Fahrrad zu ersetzen. Dazu benötigen Sie:

1. Das Vorhandensein eines klaren, wichtigen Vorteils für das Projekt.
2. Eine einfach zu bedienende Oberfläche, damit Sie Ihre Wrapper nicht herumarbeiten müssen.
3. Flexible API, damit Sie kein neues Fahrrad mit einer kleinen Änderung der Anforderungen sehen müssen.
4. Gute Testabdeckung, die weniger Flashen in Fehlerberichten ermöglicht und das Refactoring gut nacherlebt.
5. Umfassende Dokumentation, damit Sie nicht nach dem Autor des Fahrrads suchen müssen, um zu verstehen, wie man es fährt.

Ich möchte keine Verantwortung übernehmen

Es ist normal, wenn Sie sich nicht um das Projekt kümmern, an dem Sie arbeiten. Wenn es Ihnen egal ist, was Sie ein Drittel Ihrer Zeit an einem Tag widmen, müssen Sie Ihren Standpunkt verteidigen. Und je höher Ihr Status ist, desto verantwortungsbewusster ist es, sich dem zu nähern, was Sie sagen sollen. In der Tat hängt es nicht nur von Ihrer Stimme ab, wie Sie arbeiten, sondern auch davon, wie andere arbeiten und wohin das Projekt insgesamt gehen wird.

Empfehlungen

Ich hoffe, ich konnte die unbegründeten Ängste vor Fahrrädern zeigen. Je näher Sie der Professionalität kommen, desto ehrgeiziger können Sie Fahrräder fahren. Es ist besser, mit kleineren Fahrrädern zu beginnen, die ein geringeres Risiko aufweisen, aber einiges an Erfahrung auf diesem Gebiet bieten. Und nehmen Sie mit diesem Portfolio immer mehr coole und interessante Dinge auf. Es ist wichtig, nicht zu vergessen, dass ein echter Profi nicht nur coole Dinge macht, sondern auch weiß, wann er seine Kreation aufgeben muss. Führen Sie daher immer eine Analyse durch, die Ihnen das Vertrauen gibt, dass Sie alles richtig machen, und das Management wird auf Ihrer Seite sein, und diejenigen, die nach Ihnen kommen, werden verstehen, um welche Art von Fahrrad es sich handelt, warum es hier ist und warum es sonst unmöglich war.

Um Ihnen bei der Analyse von Bibliotheken von Drittanbietern zu helfen, habe ich im Laufe des Abends eine Anwendung aufgeschrieben , mit der Sie die Zeit abschätzen können, um die Probleme von Projekten auf dem GitHub zu lösen . Je größer die Anzahl, desto schlechter das Projekt mit Unterstützung und desto länger müssen Sie auf eine Lösung für Ihr Problem warten. Zum Beispiel: ein Vergleich von Angular, VueJS, React und natürlich dem $ mol, auf dem dieses Fahrrad geschrieben ist. Denken Sie daran, dass der letzte Link einmalig ist, da das Herauspumpen aller offenen Probleme von Angular alle Grenzen des GitHub aufzehrt, was eloquent zeigt, dass seine Betreuer mit der Unterstützung des Monsters, das sie hervorgebracht haben, nicht fertig werden können.