Très souvent, vous devez respecter la recommandation «ne réinventez pas la roue». Parfois avec une négligence prononcée et une affirmation de soi, parfois, ostensiblement , comme un bon conseil. Cependant, même s’il était appelé à être un conseil avisé, il montre dans un certain nombre de contextes que l’incompétence du locuteur.
Le but imbriqué de la phrase est de vous sauver du travail inutile, de l'appel à utiliser une solution prête à l'emploi pour la tâche, et du point de vue d'un observateur extérieur, cela semble vraiment raisonnable.
Mais en même temps, un facteur clé qui est caractéristique non seulement pour le développement de logiciels, mais aussi pour résoudre tout problème est ignoré : lors du changement du contexte dans lequel la tâche est définie, la solution change également .
Perdre de vue ce principe revient à admettre sa propre incapacité à résoudre les problèmes appliqués.
Prenons quelques cas.
Source
API sur API
L'un des cas courants d'accusations de cyclisme est l'encapsuleur d'API auto-écrit de certains services, dont la mise en œuvre est déjà disponible.
Un cas de ma pratique.
Il était nécessaire de mettre en œuvre le téléchargement des données de Facebook vers notre service. La langue dominante et la bibliothèque de Facebook elle-même ont été googlé en 2 minutes.
La documentation de la bibliothèque ne correspondait pas à l'interface du programme actuel , de nombreuses actions inutiles étaient enroulées autour de chaque manipulation. La bibliothèque s'est avérée de très mauvaise qualité .
Résultat: après 1,5 heures de travail avec lui, il n'a même pas été possible de se connecter.
Un collègue a implémenté son propre wrapper web-api Facebook. Au total, il lui a fallu environ une heure pour créer un wrapper et les fonctionnalités associées côté service. À la question «pourquoi faites-vous du vélo ici», a-t- il répondu les jours suivants.
Cela est particulièrement évident dans les langues traditionnelles avec une grande communauté: il y a une tendance malsaine à publier des wrappers d'API sur une autre API, sous les slogans "Pour les humains" et "D'une manière simple". De tels wrappers deviennent obsolètes dès que l'interface enveloppée est mise à jour, et les auteurs abandonnent de tels "projets", rendant le code qui les utilise inopérant.
Une bonne question : et quoi, à chaque fois pour écrire de tels wrappers manuellement?
Réponse: Une solution beaucoup plus efficace pour les grands wrappers serait d'utiliser un générateur de code qui interprète les spécifications.
Contrôle de la base de code et refus de répondre des erreurs des autres
Dans les cercles en herbe dans le développement de jeux informatiques, cette phrase s'adresse à toute personne qui ose implémenter son moteur. "Pourquoi réinventer la roue? Prenez l'unité!" . Ou Game Maker, ou, Dieu nous en préserve, Defold.
Il semblerait que le constructeur dviglo \ fournisse tous les outils nécessaires au développement. Beaucoup d'entre eux sont multiplates-formes et simplifient généralement la vie.
Comment le contexte devrait-il changer ici pour qu'il devienne nécessaire de créer votre propre moteur?
Au minimum, il s'agit du contrôle de la base de code et des fonctions du moteur (par exemple, sur un certain nombre de modèles de contrôleurs, le fabricant de jeux est constamment bogué, et résoudre ce problème peut être extrêmement problématique). Autrement dit, il est nécessaire de réduire la probabilité de rencontrer un «bogue étranger» , qui est soit impossible, soit extrêmement difficile à corriger par lui-même.
Cela est particulièrement prononcé dans les jeux qui ne sont pas saturés de cloches et de sifflets graphiques et / ou physiques - ringard, pas tellement le moteur conditionnel prend sur lui-même.
De plus, il n'est pas nécessaire d'augmenter la quantité totale de la base de code si une petite partie de ses fonctions est utilisée par le moteur / constructeur, et les outils nécessaires doivent encore être ajoutés indépendamment , contrôlant simultanément l'exactitude de leur travail avec le moteur.
Par exemple, sur la base de ces prémisses, Tommy Refenes a écrit son propre moteur pour Super Meat Boy .
Quelqu'un objectera: "Mais dans l'entrepôt \ un autre stockage, il y a une montagne de presets \ tools \ extensions!" .
Oui, c'est merveilleux, et donne quelques points d'avance, mais dans les moteurs avec une large base d'utilisateurs actifs, le même effet «mourir jeune» décrit dans la section précédente est assez observé. Sans contexte et sans tâche spécifique, il ne peut être affirmé sans ambiguïté que, l' abondance des extensions utilisateur dans le magasin jouera entre les mains.
Identité imaginaire. Tirer la tâche par les oreilles.
Parfois, après avoir formulé le problème, il s'avère que les solutions existantes qui viennent à l'esprit ... ne conviennent pas. En raison de sa «teneur en matières grasses» ou de l'insatisfaction d'une des conditions clés de la tâche ( oui, il y en a plusieurs ).
Bon exemple: CluNet.
Cluster dans son article décrit assez complètement les raisons des décisions qu'il a prises lors de l'élaboration du protocole de la maison intelligente. L'exemple est très révélateur et bien décrit, je recommande de le démonter vous-même.
Conclusion
Lors de la recherche d'une solution à un problème , le contexte et toutes les conditions données doivent être pris en compte .
Même dans des cas simples, de petits détails du contexte bouleversent la solution, et l'habileté à résoudre des problèmes appliqués est largement basée sur la capacité de voir et d'évaluer les prémisses initiales .
Est-ce que l'expression «ne réinvente pas la roue» parle de l'incapacité du conseiller à résoudre les problèmes? Si le conseiller a mentionné les vélos avant d'hésiter après quelques minutes, très probablement oui.
Ou, dans la généralisation du capitaine:
Réfléchissez avant de décider.
Réfléchissez avant de parler.
Et en général - pensez.