Faut-il toujours utiliser les meilleures pratiques de codage [fermé]

Lors du codage d'un logiciel, l'architecture doit-elle toujours être les meilleures pratiques ou les pratiques pratiques en ce qui concerne l'application en cours de construction?

Si je crée une application Web de deux pages pouvant vivre 5 ans et avoir 2 améliorations au cours de ces 5 années, dois-je coder en injection de dépendance, modèles de conception, modèle-vue-contrôleur avec modèles de vue, etc.

Faut-il toujours utiliser les meilleures pratiques de codage

Toujours? Non, c'est idiot.

Les meilleures pratiques sont des lignes directrices. Pour la plupart des gens, pour la plupart des situations, s'ils sont mis en œuvre avec une certaine finesse, ils donneront les meilleurs résultats. C'est là que vous commencez lorsque vous envisagez des solutions. Mais il y aura des endroits où les meilleures pratiques peuvent et doivent être ignorées, car il existe de meilleures solutions.

Le problème est que les humains ne peuvent pas voir l'avenir. Et les débutants (et un tas de non-débutants) pensent inévitablement qu'ils sont dans ce scénario spécial où les règles ne s'appliquent pas à eux. En cas de doute, utilisez les meilleures pratiques. Des années de débat et d'expérience à travers des tonnes d'ingénieurs plus intelligents que vous ou moi ont trouvé qu'ils produisent toujours de bons résultats. Mais aucun (ou presque aucun) d'entre eux ne connaît votre problème particulier aussi bien que vous. Parfois, vous rencontrerez des cas exceptionnels où les règles peuvent être contournées.

Oui. Cela va de soi. Pourquoi ne feriez-vous pas ce qui est le mieux?

Ce n'est pas le problème cependant. La partie difficile est de savoir quelle est la meilleure pratique, car pour répondre à cela, vous devez savoir exactement quelles exigences vous avez et comment le projet est susceptible d'évoluer au fil des ans, et c'est diaboliquement difficile.

Cependant, une bonne règle de base: il n'est PAS recommandé de prendre les noms d'un tas de modèles de conception et de les coincer sans réfléchir.

À part cela, votre question ne peut vraiment pas être répondue. Déterminer exactement ce qu'est une «meilleure pratique» pour une situation donnée, c'est ce qu'est un ingénieur logiciel. Tu vas devoir le réduire pour obtenir de meilleures réponses.

La meilleure pratique est celle qui remplit le plus efficacement les exigences fonctionnelles et non fonctionnelles de votre logiciel en termes de fonctionnalités, de maintenabilité, de performances, etc. Mais si ce n'est pas le cas, le pragmatisme l'emporte.

Là où je travaille actuellement, nous construisons une nouvelle interface Web pour notre produit à partir de zéro. Il ne sera en aucun cas RESTful; il utilise exclusivement POST. Ce n'est pas à plusieurs niveaux, n'utilise aucun microservice et n'utilise pas de base de données NoSQL. Il n'a aucune sorte d'architecture comme Enterprise Java.

En d'autres termes, ce n'est pas du tout la hanche.

Mais il intègre un cadre HTML5 à la pointe de la technologie qui comprend une liaison de données de type angulaire, une mise à l'échelle automatique vers différents types d'appareils comme le mobile et le bureau, une intégration avec l'interface utilisateur Kendo de Telerik pour effectuer tous les travaux lourds, et un chiffrement et une sécurité entièrement cryptés canal de données.

Mieux encore, cela se fera en 30 jours, un exploit qui nécessiterait une armée de développeurs Java dans une architecture d'entreprise par an. Le code est ES6 / Typescript; c'est le code le plus propre que j'aie jamais vu.

Non . Les meilleures pratiques sont des choses qui sont généralement considérées comme la meilleure chose à faire 99% du temps, mais cela ne signifie pas qu'elles s'appliquent toujours à chaque situation.

En tant que développeur, votre travail consiste à connaître et à utiliser ces meilleures pratiques, mais aussi à savoir quand il est sûr de les mettre de côté.

Ce n'est pas censé être une auto-promotion, mais j'ai récemment écrit un article de blog lié à mon travail sur la plate-forme Salesforce.com qui détaillait l'une de ces occasions . L'une des règles d'or est «Ne faites jamais de requête à l'intérieur d'une boucle», mais récemment, pour la première fois en 7 ans de travail sur la plateforme, j'avais une raison parfaitement valable de ne pas respecter cette règle.

L'essentiel est que la plate-forme a des limites sur le nombre de requêtes que vous pouvez effectuer dans un contexte d'exécution donné, mais dans ce cas, j'ai dû interroger à l'intérieur d'une boucle pour éviter de manquer d'espace de tas et je savais que je serais bien dans la requête limite.

C'est donc rare, mais il y a des moments où les meilleures pratiques ne sont pas pertinentes pour un scénario, donc si elles ne correspondent pas, ne les forcez pas.

Je suppose que par "meilleures pratiques", vous entendez une liste de règles que quelqu'un a écrites dans un livre. Car bien sûr, si vous entendez l'expression littéralement, alors bien sûr, vous devez toujours écrire le meilleur code possible.

Dois-je souligner qu’il n’existe pas un ensemble unique de «meilleures pratiques» universellement acceptées? Pour toute règle promue par un expert, vous pouvez presque toujours trouver un autre expert avec des informations d'identification égales qui dit quelque chose de différent.

Mais au fait: Réponse courte: généralement, mais pas toujours.

Chaque domaine a ses «meilleures pratiques» et ses «solutions de manuels». Ceux-ci représentent l'expérience accumulée et la sagesse de beaucoup, beaucoup de gens au cours de nombreuses années et ne doivent pas être ignorés. MAIS! Il y a toujours des circonstances spéciales, des cas marginaux, etc. La personne vraiment capable dans n'importe quel domaine sait quand suivre les règles et quand les enfreindre.

Je dirais en général: commencez par suivre les règles du manuel. Lorsque le respect des règles du manuel conduit à des problèmes - complexité inutile, performances médiocres, peu importe - alors examinez si enfreindre cette règle une seule fois ne serait pas une meilleure idée.

Si vous ignorez les règles et allez où votre caprice du moment vous mène, votre code sera probablement un gâchis. Quelle que soit votre intelligence, vous n'êtes pas le premier programmeur au monde. Il est logique d'apprendre de l'expérience des autres. Dans notre vie quotidienne, c'est pourquoi nous avons des parents, des enseignants et des prédicateurs: nous n'avons donc pas à répéter chaque erreur stupide nous-mêmes pour apprendre que c'est une erreur stupide à faire.

Mais si vous suivez servilement une liste de règles d'un livre 100% du temps, vous vous retrouverez souvent à marteler une cheville carrée dans un trou rond. Les personnes qui ont écrit le livre de règles n'ont peut-être pas rencontré un cas comme le vôtre. Et même s'ils l'ont fait, si c'est assez rare, ils l'ont peut-être ignoré. Une règle qui fonctionne 80% du temps est une excellente règle - tant que vous comprenez qu'elle fonctionne 80% du temps et non 100% du temps.

J'ai écrit un livre sur la conception de bases de données qui comprend de nombreuses règles que je conseille aux concepteurs de bases de données de suivre. (Je m'abstiendrai de donner le titre pour ne pas avoir l'air de glisser sans vergogne dans l'autopromotion.) J'encourage certainement tous ceux qui veulent concevoir une base de données à lire un livre comme le mien et à apprendre tout ce qu'ils peuvent en tirer. . Mais bien sûr, il y a des moments où vous devez enfreindre les règles que j'énumère.

J'ai écrit une fois un document sur les normes de programmation pour une équipe de développeurs que je dirigeais à l'époque. Et la dernière règle était la suivante: "Si vous avez une bonne raison d'enfreindre l'une des règles ci-dessus, alors allez-y, MAIS vous devez inclure un commentaire dans votre code expliquant pourquoi vous avez enfreint la règle. Si vous ne pouvez pas venir avec une bonne raison, puis suivez la règle. Si écrire le commentaire est plus difficile que de suivre la règle, alors suivez la règle. " Nous n'avons eu qu'une poignée de fois que quelqu'un a trouvé une violation d'une règle qui valait la peine d'avoir à expliquer pourquoi.

Par les meilleures pratiques , je suppose que vous voulez dire "des règles informelles que la communauté du développement logiciel a apprises au fil du temps, ce qui peut aider à améliorer la qualité du logiciel" et non une sorte de meilleure façon littérale de faire une tâche spécifique.

Oui, jusqu'à ce que vous ayez une raison de ne pas le faire. Ce devrait être une bonne raison pour laquelle vous avez sérieusement pris en considération et appliqué les circonstances et les limites de la tâche à accomplir. Cela signifie que vous comprenez parfaitement la pratique et êtes en mesure de l'appliquer. N'entrons pas dans cette notion que si vous ne la comprenez pas, alors ce ne doit pas être la meilleure façon de penser. Voir la définition.

Vous n'allez pas toujours faire ce qui est le mieux. Lorsque le patron vous dit de "expédier ce morceau de merde ou vous êtes viré!" Vous l'expédierez et irez probablement chercher un autre emploi, mais vous l'expédierez toujours. Parfois, vous vous retrouverez à faire quelque chose qui est assez bon. Bien sûr, vous ne voulez pas prendre l'habitude de cela, mais parfois vous devez faire rouler les wagons et vous ne pouvez pas vous inquiéter de la cécité des chevaux.

Certaines choses sont importantes, d'autres non.

Vous devez adapter votre choix de langue et de style au problème en question.

Par exemple, une «meilleure pratique» pour la gestion des exceptions peut être de toujours intercepter les exceptions et de les journaliser, mais lors de la création d'un test unitaire, la meilleure pratique est souvent de les laisser sortir afin que le cadre de test unitaire puisse les signaler correctement.

En revanche, considérons la règle "SEC". Il est toujours bon de rechercher du code qui ne se répète pas, non seulement pour des raisons évidentes, mais aussi parce que plus vous codez de cette façon, mieux vous devenez un codeur - c'est un excellent moyen de fléchir vos compétences de codage / réflexion. au lieu de vos compétences de frappe et de copier / coller, et à long terme, vous vous sentirez généralement mieux revisiter votre code (même si vous vous attendiez à ce qu'il soit à jeter) si vous avez suivi certaines règles raisonnables.

En résumé, soyez flexible, mais ne codez pas seulement des fichiers indésirables illisibles, car vous pensez que c'est du code jetable.

Je vais essayer de voir d'un point de vue différent.

Les cadres modernes d'aujourd'hui facilitent la configuration d'un projet de base avec mvc, l'injection de dépendances, l'architecture en couches, etc. (amateur de bottes de printemps ici). Je dirais commencer par une base générée et utiliser les outils fournis jusqu'à ce que vous tombiez sur quelque chose qui nécessite une solution à la main. Ensuite, vous pouvez couper les coins de ces meilleures pratiques.

Il n'est pas plus difficile d'utiliser quelque chose comme l'application Web Spring Boot pour 2 pages, puis de lancer vos propres servlets, requêtes jdbc et d'autres choses.

D'après mon expérience, il n'y a qu'une seule meilleure pratique que je considère comme obligatoire:

Restez simple, stupide (KISS)

En d'autres termes: quels que soient les outils, les API, les architectures, etc. que vous choisissez - si vous restez simple, il est plus probable qu'il soit facile de travailler sur l'avenir, d'avoir moins de bogues, d'être rapide, efficace en mémoire et tout ce que vous pourriez souhaiter.

Toutes ces autres choses dont les gens parlent: principes, modèles, pratiques, etc. Ils fournissent tous des techniques et des idées pour résoudre les problèmes. L'astuce consiste à déterminer si vous avez ces problèmes en premier lieu.

Les meilleures «meilleures pratiques» contiennent toujours une section dans laquelle vous devez utiliser votre intelligence et votre expérience pour identifier les éléments inappropriés du manuel. Ils peuvent également contenir une section sur l'examen, l'approbation et la documentation de ces exceptions et leur intégration dans les "meilleures" pratiques.

Lors du codage d'un logiciel, l'architecture doit-elle toujours être les meilleures pratiques ou les pratiques pratiques en ce qui concerne l'application en cours de construction?

En théorie, oui.

Dans le monde réel, [toujours] oui, tant que vous pouvez vous le permettre.

Ce qui, bien sûr, signifie «non».

Les pressions de temps et d'argent essaieront toujours de vous pousser sur la voie d'une solution «rapide et sale», car elle offre une «meilleure» valeur au client. La façon dont cela est mis en œuvre n'a aucun intérêt pour le client ou ses comptables. Si vous pouvez [mal] faire un travail en deux jours ou parfaitement en trois mois, que pensez-vous qu'ils vont vous demander?

L'écart entre les deux - les meilleures pratiques et ce avec quoi vous devez «vous en tirer» - est appelé «dette technique»; c'est parfaitement acceptable, tant que vous avez un plan pour le "rembourser", c'est-à-dire pour revenir en arrière et améliorer les choses plus tard. Encore une fois, ce n'est pas quelque chose pour lequel vous obtenez toujours (jamais?) Le budget.

Une tactique consiste à publier une version bêta précoce avec le correctif «rapide», mais assurez-vous que les améliorations architecturales nécessaires sont prioritaires avant la version «complète». Encore une fois, ce n'est pas quelque chose que vous (toujours?) Faites.