Was ist das Einfachste, was benötigt wird?

Es gibt ein Zitat, das oft Albert Einstein zugeschrieben wird und das mir sehr gefällt (und ich bin mir sicher, dass es den meisten gefällt):

Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher.

Es gibt einige Untersuchungen darüber, ob er es gesagt hat oder nicht, aber der Punkt bleibt unabhängig davon, wer es gesagt hat.

Es ist einfach, diese Idee zu nehmen und sie auf Dinge anzuwenden, die wir im täglichen Leben tun, die wir nicht tun wollen, oder?

• Ich will mein Zimmer nicht aufräumen, also werde ich es gerade genug aufräumen.
• Ich werde gerade genug arbeiten, um die Kunden zufrieden zu stellen, und das ist genug.
• Ich werde [welche Verantwortung auch immer] bis zum [niedrigstmöglichen Grad] erfüllen, und weil Einstein es [angeblich] gesagt hat, wer bin ich, da zu argumentieren.

Auch wenn ich damit nicht einverstanden bin (und die Diskussion darüber den Rahmen dieses Beitrags sprengen würde), betrachte ich diese Idee im Kontext der Webentwicklung.

Und um es klar zu sagen, ich spreche nicht von Webdesign. Ich bin kein Designer. Ich möchte nicht für etwas sprechen, von dem ich kein Teil bin. Aber in Bezug auf die Bereitstellung von Lösungen für Leute, die Software oder besser gesagt Webentwicklung verwenden, bin ich viel eher geneigt und positioniert, darüber zu sprechen.

Genau genommen frage ich mich oft, ob wir die Webentwicklung komplizierter gemacht haben (und warum wir das getan haben) und ob die Verwendung der einfachsten Dinge, die benötigt werden, alles ist, was wirklich benötigt wird, wenn Lösungen für andere entwickelt werden.

Das Einfachste, was benötigt wird

Ich habe kürzlich nur über die verschiedenen Aspekte der Front-End-Entwicklung geschrieben (im Zusammenhang damit, schnell etwas aus der Tür zu bekommen) und darüber, wie wir jetzt Build-Tools ausschließlich für diesen Aspekt des Webentwicklungs-Stacks haben.

Wenn es um Tools wie dieses geht, unabhängig davon, auf welcher Ebene des Stacks wir arbeiten, frage ich mich:

Ist dieses Dienstprogramm notwendig, um es effektiv und positiv zu erleichtern, die Lösung für jemand anderen zu entwickeln?

Zum Beispiel finde ich, dass Composer etwas sehr Nützliches ist. Es ermöglicht mir, Bibliotheken von Drittanbietern einfach zu verwalten, sie nach Bedarf zu aktualisieren und sie in meine Projekte einzubinden.

In ähnlicher Weise finde ich Tools, die meine Commits untersuchen, bevor sie an GitHub gesendet werden, nützlich, da sie es mir ermöglichen, Probleme mit der Codequalität zu erkennen, die sonst während des Codeüberprüfungsprozesses mehr Zeit in Anspruch nehmen würden.

Nehmen wir zum Beispiel einige der Front-End-Build-Tools wie Grunt, Gulp, Yarn, Node, Mix und so weiter. Um es klar zu sagen, einige davon tun dasselbe wie andere, während andere einem anderen Zweck dienen.

Der Punkt, auf den ich hinarbeite, ist folgender:

An welchem ​​Punkt behindern die Tools, die wir für die Entwicklung verwenden, unsere Fähigkeit, etwas aufzubauen und effektiv zu liefern?

Es gibt etwas in unserem Bereich, das uns dazu zwingt, das Bedürfnis zu verspüren, auf dem neuesten Stand der Technik zu bleiben. Aber ich denke, es gibt eine wichtige Unterscheidung: Es ist eine Sache, sich eines Tools bewusst zu sein, aber es ist eine Sache, es zu benutzen.

Bewusstsein

Das Tolle daran zu wissen, dass etwas verfügbar ist, ist die Möglichkeit, es zu recherchieren und festzustellen, ob es für uns von Nutzen ist.

Dies ist keine bahnbrechende oder neue Idee, aber es ist eine Sache, die meiner Meinung nach einige von uns umgehen. Anstatt zu recherchieren und zu bewerten, überspringen wir es oft und sehen, wie schnell wir es verwenden können.

Es zum Einsatz bringen

Der Vorteil, etwas Neues zu nutzen, besteht darin, dass wir den Nutzen – oder den erwarteten Nutzen – erhalten, den der Nutzen bieten soll.

Die Gefahr dabei besteht darin, dass das Tool möglicherweise nicht in sechs Monaten, einem Jahr oder sogar zwei Jahren verfügbar ist und die Technologien, die verbessert werden sollen, sich ändern können, während es nicht Schritt hält.

Aus diesem Grund ist es wichtig, sich dieses Dienstprogramms bewusst zu sein und gleichzeitig festzustellen, ob es nützlich ist oder nicht.

Über diese Sache der Einfachheit

Um jedoch auf meinen ursprünglichen Punkt zurückzukommen, ist Folgendes: Wenn Sie so viel Zeit benötigen, um ein neues Tool in Ihrem Workflow zu konfigurieren, zu lernen, zu entwickeln, zu implementieren und zu verwenden, denke ich, dass es sich lohnt zu überlegen, ob es sich wirklich lohnt oder nicht Zeit in Ihrem Werkzeugstapel.

Den Kunden ist es egal, ob Sie das von Ihnen verwendete Tool verwenden oder nicht. Sie vertrauen darauf, dass Sie ein guter Verwalter der Lösung sind, für deren Implementierung sie Sie bezahlen, und Teil dieser Verantwortung, weise und gewissenhaft mit Ihrer Zeit umzugehen.

Wenn das von Ihnen verwendete Dienstprogramm diese Verantwortung in irgendeiner Weise behindert, lohnt es sich möglicherweise nicht, es für ein bestimmtes Projekt zu verwenden.

Und darauf kommt es mir letztendlich an: Wenn das, was ich verwende, mir hilft, die bestmögliche Lösung zu bauen, ohne dabei auf Kosten des Kunden zu gehen, dann lohnt es sich wahrscheinlich, es zu verwenden. Zu diesem Zweck ist oft das einfachste Set an Werkzeugen alles, was benötigt wird, und nicht mehr.

Andernfalls lohnt es sich vielleicht, es für ein zukünftiges Projekt zu prüfen, aber nicht für die Zeit Ihres Kunden.