Crainte que l'application Web ne soit «à l'épreuve du temps»

Je suis développeur Web d'une petite application Web SaaS locale. Il compte actuellement une demi-douzaine de clients.

Au fur et à mesure que je continue à concevoir l'application, il est de plus en plus difficile pour moi de me convaincre de m'engager à tout moment dans le projet, ce qui s'est produit dans sa phase initiale. Étant attaché au projet et au code que j'ai déjà écrit, je crains que tout travail supplémentaire que je commette ne soit annulé dans un proche avenir, lorsque l'application ne sera plus à la hauteur de la croissance de l'entreprise.

En tant qu'étudiant à l'université qui postule pour un stage, des employeurs m'ont demandé de ne pas utiliser de framework Web pendant les entretiens, ce qui m'a amené à douter davantage de mon travail précédent. Je ne connais tout simplement aucun framework Web et je ne sais pas par lequel commencer.

J'ai eu un stage en tant que développeur full-stack en janvier, où je vais commencer à apprendre les frameworks front-end, mais la pression pour finir l'application est de plus en plus forte, et j'envisage de supprimer complètement l'application et de recommencer, c'est quelque chose que j'ai déjà fait. L'application est actuellement construite en PHP et jQuery (pour les appels AJAX) et utilise MySQL pour sa base de données. Avez-vous des idées sur la façon dont je peux surmonter ce blocage mental et assurer que mon application sera évolutive? Merci d'avance.

Parfait est l'ennemi du bien.

Ou en d'autres termes, ne vous inquiétez pas à ce sujet aujourd'hui. Si votre application fait ce qu'elle doit faire, c'est bien. Ce n'est pas une mauvaise chose de réécrire des parties de logiciels plus tard. à ce stade, vous 1) savez plus clairement ce que vous essayez de construire et 2) savez quels bits constituent réellement le goulot d'étranglement. Vous pourriez passer beaucoup de temps à écrire une application pouvant atteindre un million d'utilisateurs, mais ce ne serait pas mieux pour vos six clients actuels que ce que vous avez aujourd'hui .

Avez-vous des idées sur la façon dont je peux surmonter ce blocage mental et assurer que mon application sera évolutive?

Le noeud du problème n’est pas l’évolutivité. Le nœud du problème est de penser que vous vous en sortirez du premier coup .

Vous devriez vous concentrer sur l'écriture de code propre. Parce que le code propre maximise la commodité lorsque vous devez (inévitablement) changer quelque chose dans le futur. Et c'est le véritable objectif que vous devriez avoir.

Ce que vous essayez maintenant de faire, c'est d'essayer de penser au code parfait à écrire. Mais même si vous y parvenez, qui a déclaré que les exigences ne changeraient pas ou que vous avez peut-être pris vos décisions en vous basant sur des informations erronées ou une mauvaise communication?

Vous ne pouvez pas éviter de faire des erreurs, même si ce n'est pas de votre faute. Concentrez-vous sur l'écriture de code dans lequel il est facile de changer les choses plus tard, au lieu d'espérer écrire un code que vous n'aurez pas besoin de changer à l'avenir.

Ayant grandi attaché au projet et au code que j'ai déjà écrit,

Je sympathise absolument avec ce sentiment. Mais s’attacher au code que vous avez écrit est un problème.

La seule chose qui devrait être constante est votre désir de résoudre un problème spécifique . Comment résoudre ce problème n’est qu’une préoccupation secondaire.

Si demain nous publions un nouvel outil réduisant votre base de code de 80%, vous allez être contrarié par le fait que votre code n'est plus utilisé; ou allez-vous être heureux que votre base de code est devenue plus petite et beaucoup plus propre / plus facile à gérer?

Si l'ancien, vous avez un problème: vous ne voyez pas la solution pour le code . En d'autres termes, vous vous concentrez sur le code sans voir la situation dans son ensemble (la solution qu'il vise à fournir).

J'ai peur que tout travail supplémentaire que j'engage ne soit annulé dans un proche avenir, lorsque l'application ne sera plus à la mesure de la croissance de l'entreprise.

C'est un problème différent pour un jour différent.

Tout d'abord, vous construisez quelque chose qui fonctionne. Deuxièmement , vous améliorez le code pour corriger les éventuels défauts. Ce que vous êtes en train de faire, c’est de retenir la première tâche par crainte d’avoir à faire la deuxième.

Mais quelle autre option existe-t-il? Vous ne pouvez pas dire le futur . Si vous passez votre temps à réfléchir aux possibilités futures, vous finirez par deviner de toute façon. Une supposition est toujours sujette à la mort.

Au lieu de cela, construisez l'application et prouvez qu'il y a bien un problème. Et une fois que le problème est clair, vous commencez à vous en occuper.

En d'autres termes: Henry Ford n'a jamais construit de voiture conforme aux normes / attentes de 2018. Mais s'il n'avait pas construit le modèle T, une voiture imparfaite selon les normes modernes, personne n'aurait commencé à utiliser des voitures, il n'y aurait pas d'industrie automobile et personne n'aurait eu une voiture à améliorer.

Des employeurs ont demandé à mon choix de ne pas utiliser de framework Web pendant les entretiens, ce qui ne m'a fait que douter davantage de mon travail précédent.

La partie importante ici n’est pas de savoir quel cadre vous utilisez (un employeur qui vous juge sur qui ne fait pas son travail correctement). La partie importante ici est de savoir ce que vous faites et pourquoi vous le faites .

Par exemple, vous pourriez éviter le cadre existant spécifiquement parce que vous voulez savoir pourquoi un cadre est utile en le faisant à la dure. Ou vous pourriez essayer de créer votre propre cadre.

La seule mauvaise réponse ici est "je ne sais pas", car cela montre un manque de prise de décisions éclairées. C'est un drapeau rouge pour un employeur.

Je ne connais tout simplement pas de framework Web et je ne sais pas lequel utiliser.

Le même problème se pose ici. La solution ne consiste pas à penser plus, mais plutôt à agir:

• Arrêtez de penser à la réponse parfaite .
• Choisissez un cadre. À moins que vous n'ayez une préférence, choisissez-en une au hasard. Utilisez un jeu de fléchettes, lancez un dé, lancez une pièce de monnaie, prenez une carte.
• Utilise le.
• Avez-vous aimé l'utiliser? Avez-vous trouvé quelque chose d'énervant?
• Cherchez comment prévenir ces mauvais éléments. Avez-vous mal utilisé le cadre ou s'agit-il simplement de la manière dont le cadre est censé fonctionner?
• Une fois que vous sentez que vous maîtrisez le cadre (que vous le vouliez ou non), choisissez un nouveau cadre et répétez le cycle.

Pour en savoir plus à ce sujet, lisez L’état de faire> l’état de pensée . L'auteur l'explique mieux que moi.

mais la pression pour finir l'application est en train de monter, et j'envisage de supprimer complètement l'application et de recommencer

Sauf si la base de code actuelle est un gâchis absolument incontrôlable; vous prenez la décision opposée.
Les développeurs pensent souvent que jeter les choses serait le meilleur choix. C'est un sentiment très commun. Mais c'est rarement le bon choix.

Lancer le code et repartir de zéro, c'est comme se retrouver coincé dans la circulation sur le chemin du travail, craignant d'être en retard pour le travail (manquer la date limite) et de rentrer à la maison et d'essayer à nouveau dans la même voie. Cela n'a pas de sens. Vous êtes peut-être coincé dans la circulation, mais vous êtes toujours plus près du travail que lorsque vous étiez chez vous.

Malgré l'énorme somme d'argent que Facebook et Google ont investie dans le marketing pour vous convaincre du contraire, les cadres frontaux existent pour deux raisons principales:

• Premièrement, décharger les demandes matérielles / réseau vers les opérations côté client en mettant l'état et la logique dans le client
• Deuxièmement, en rapport avec la logique client supplémentaire nécessaire pour prendre en charge le premier point, ils fournissent des contextes d’exécution isolés de sorte que vous pouvez insérer le code d’autres personnes dans une page sans rien casser.

Vous n'avez probablement besoin que d'un framework pour résoudre ces problèmes si votre application est intrinsèquement dynamique, si l'état de l'application que vous sauvegardez côté client est assez complexe, si vous attendez un grand nombre de clients avec une latence réseau mauvaise (mobile, etc.). ou éloignés du serveur), ou s’il existe un besoin important pour les entreprises de prendre en charge des CSS ou des éléments dynamiques particulièrement avancés.

Framework marketing veut vous faire croire que leur méthode d'architecture particulière accélère le développement et facilite la maintenance. Ceci est manifestement faux pour les petites équipes travaillant sur des projets simples. Isoler le code et organiser les importations peut aider une grande équipe à commercialiser plus rapidement un produit. Il fournit beaucoup moins à une équipe de développement composée d’une seule personne travaillant sur un projet déjà fonctionnel.

Vous passerez plus de temps à apprendre à intégrer le code fonctionnel existant dans la structure qu'à la mise en œuvre de fonctionnalités. Il est fort probable que quelqu'un quelque part mettra à jour quelque chose, et le code écrit dans cette structure cessera de fonctionner dans les 18 mois, à moins que quelqu'un est là pour le maintenir constamment.

Vanilla JS et, dans une moindre mesure, mais dans une large mesure, JQuery, ne souffrent pas de ces problèmes. À quelques exceptions près, les applications JQuery + AJAX ne s'appuyant pas sur des comportements spécifiques à un navigateur et renonçant aux dépendances externes lorsque cela est nécessaire, continuent de fonctionner 10 à 15 ans après avoir été écrites avec des modifications très mineures.

Les cadres sont parfaits pour les startups typiques prenant en charge des applications Web complexes, en continu et faisant face au public. Ils permettent aux grandes équipes de bien se coordonner, s’intègrent bien aux infrastructures d’ajout de fournisseurs et prennent en charge de nouveaux widgets et de nouveaux paradigmes de conception pour vous aider à rester compétitif.

Rien de tout cela n’importe pour un petit logiciel avec un auditoire fixe que vous êtes sur le point d’abandonner. L'adoption d'un framework ralentit votre vitesse de développement lorsque vous vous adaptez à un nouveau paradigme et introduit des risques de compatibilité inutiles. Garder le code côté client simple (et idéalement auto-hébergé) signifie que la surface de risque de compatibilité diminue considérablement. Les navigateurs changeront, les URL de CDN cesseront de fonctionner, les dépendances seront périmées - Mais personne ne touche à ce serveur, et il continuera à fonctionner correctement.

N'adoptez un cadre que s'il résout un problème architectural particulier que vous avez aujourd'hui ou que vous pouvez prévoir, et envisagez vivement de résoudre ce problème par un autre moyen, si celui-ci est supportable.

La meilleure chose à faire pour «pérenniser» votre application est de suivre les meilleures pratiques de conception de votre système afin de maximiser le couplage lâche et la séparation des problèmes. Aucune partie de votre application n'est à l'abri de devenir obsolète, mais vous pouvez faire beaucoup pour isoler le code qui devient obsolète pour la raison X du code qui ne doit pas nécessairement être affecté par X.

Cependant, je soutiendrais que votre croissance / l'évolutivité de votre application devrait être moins préoccupante que le taux de croissance de votre propre expérience et de vos propres capacités. Le blocage mental que vous décrivez me semble être un apprentissage de la stagnation ou une prise de conscience de nombreux inconnus connus sans la stratégie ou les outils pour les combattre.

Les cadres ne sont pas particulièrement bien adaptés pour résoudre le problème de la "pérennité", bien qu'ils puissent fournir des indications initiales pertinentes aux inexpérimentés, généralement via des modèles de conception de haut niveau tels que MVC. Au contraire, ils ont tendance à être plus utiles pour accélérer le développement en offrant une cohésion forte et souvent au détriment d'un couplage plus étroit. Par exemple, supposons que vous utilisiez un système de mappage objet-relationnel fourni par la structure dans l'application pour interagir avec votre base de données, avec l'intégration du système de mise en cache. Peut-être que plus tard, vous devrez passer à un magasin de données non relationnel et maintenant tout ce qui l'utilise est affecté.

Le désordre que vous avez maintenant ne provient pas de ce que vous avez utilisé, mais de l' endroit où vous l'avez utilisé (probablement un peu partout sur le back-end). Combien vous serez mieux si le code qui rend une page ne récupère jamais les données qu’il restitue.

Supposons que vous souhaitiez ajouter un petit widget à une page nécessitant des scripts et des ressources supplémentaires pour fonctionner correctement. Si vous utilisez un framework, vous pouvez demander "Comment cela veut-il que je rajoute les dépendances à une page pour cette chose?" Si vous ne l'êtes pas, la question est plus ouverte: "Quels problèmes techniques dois-je toucher qui devraient être séparés d'une manière ou d'une autre?" Il faut plus d'expérience pour répondre à cette question, mais voici quelques astuces:

• Que se passerait-il si, demain, vous déplaciez toutes vos ressources statiques (scripts, images, etc.) sur un serveur séparé, un réseau de diffusion de contenu, etc., ou tentiez de les regrouper pour améliorer les performances?
• Que se passerait-il si vous commenciez à placer ce widget sur différentes pages ou plusieurs instances de celui-ci sur la même page?
• Comment pourriez-vous commencer à effectuer des tests AB sur différentes versions du widget?

Si tout cela semble écrasante, alors je vous suggère de vous devriez utiliser un cadre pour l' instant, non pas tant à cause de votre application , mais le bien de votre propre croissance personnelle. Ne recommencez pas forcément. Au lieu de cela, utilisez des cadres en tant que programme pour vous aider à guider l'évolution de votre application.

Il n'y a que deux façons d'apprendre. L'un est par essais et erreurs, et l'autre en apprenant de l'expérience des autres. Les essais et les erreurs ne peuvent pas être éliminés. Le développement de logiciels est par nature un domaine d’apprentissage continu et tout code qui ne fait rien de nouveau ou de différent est par définition inutile. (Utilisez plutôt le code déjà écrit.)

L'astuce consiste à le minimiser en recherchant de manière proactive les connaissances préexistantes (stratégies, meilleures pratiques et codes / bibliothèques / frameworks) tout au long du processus de développement, afin de ne pas réinventer constamment la roue.

En ce qui concerne l'application que vous écrivez actuellement, votre première préoccupation devrait simplement être de le faire avec un minimum d' effort ordinaire (ce qui est un peu comme une odeur de code, mais pour le processus de développement). Compte tenu de la nature de l’apprentissage humain, le moyen le plus rapide d’atteindre un niveau de qualité élevé est de commencer par quelque chose . Il est beaucoup plus facile de comprendre l'objectif lorsque vous pouvez le définir en critiquant quelque chose que vous avez déjà.

Si vous pouvez accepter qu’une grande partie du code que vous écrivez est un processus d’apprentissage jetable et nécessaire pour trouver de bonnes conceptions, cela vous incitera utilement à continuer. Après tout, c’est le défi de la résolution de problèmes qui rend le développement de logiciels attrayant, et ce défi est omniprésent si ce que vous faites vaut la peine (voir la déclaration «apprentissage continu» ci-dessus).

Par-dessus tout, "abandonner la chose et recommencer" n'est jamais une option ... après tout, n'avez-vous pas dit que vous aviez "une demi-douzaine de clients?" Avez-vous déjà pris le temps de réfléchir à ce qu’ils pourraient penser de votre déclaration, étant donné qu’ils sont en ce moment (vraisemblablement) "parfaitement satisfaits de votre travail ?!"

Voici une analogie que j'aime utiliser:

• "Mon travail consiste à construire des maisons pour que les gens puissent y vivre, pour que ceux-ci créent des entreprises, etc." Mon travail consiste à faire en sorte que "ces morceaux de sable incroyablement minuscules et trop glorifiés " fassent un travail utile. (Tout comme les constructeurs de maisons construisent des maisons à partir de panneaux de gypse, de carreaux de céramique, de blocs de béton et de 2x4.)

• Cependant, alors que les "clous" utilisés par les constructeurs de maisons n’ont vraiment pas beaucoup changé en deux cents ans (sauf pour passer de "carré" à "rond", puis pour être utiles avec des machines à clouer pneumatiques), la technologie que nous utilisons change constamment et subit parfois de très profonds changements. ("Alors ça va.")

• « Néanmoins, chaque maison, une fois construit, restera à jamais après- être vécu dans. » Vous ne pouvez pas les expulser. Une fois que vous l'avez construit et remis les clés, "ce n'est plus" votre "maison." C'est ce qui est en ce moment, et cela durera très longtemps.

Une grande partie de mes affaires ces jours-ci consiste à aider les clients à faire face aux logiciels construits il y a dix, vingt, trente ou plus, utilisant les technologies "de pointe" qui existaient à l'époque - (et qui, heu, Je me souviens) - et qui sont encore en service (!) Aujourd'hui.

S'assurer que quelque chose est à l'épreuve du temps est presque impossible. Vérifier que l'application est évolutive n'est pas trop difficile cependant. Il vous suffit d'écrire un test de performance pour l'application et de voir le nombre de clients qu'elle peut gérer. En écrivant des tests, votre application sera définitivement plus pérenne, car vous pourrez évaluer son comportement une fois que vous aurez implémenté plus de modifications.

En ce qui concerne le cadre, je ne serais pas trop inquiet en termes de performances et d’évolutivité. C’est quelque chose que vous pouvez facilement vérifier et probablement réparer. Le plus gros problème est la sécurité. Les frameworks Web vous aident généralement à écrire le code d’authentification, les cookies, la protection CSRF, etc., en particulier compte tenu de votre manque d’expérience.

J'ai commencé à écrire un commentaire sur les cadres d'apprentissage, mais cela a fini par devenir quelque chose qui ressemblait davantage à une réponse, alors le voici.

Ne pas connaître les cadres semble être un problème. Dans pratiquement n'importe quel travail webdev, vous devrez travailler avec un framework. Apprendre dans un autre cadre une fois que vous savez que ce n’est pas si grave, mais l’apprentissage du premier peut prendre un certain temps - c’est pourquoi les employeurs peuvent se préoccuper de cela. Éviter les cadres peut indiquer le syndrome non inventé ici , ce qui est une approche très peu pratique.

Comme le principal objectif de connaître vos premiers cadres est d'apprendre une langue commune, essayez peut-être simplement d'apprendre quelque chose de populaire parmi vos pairs. Vous pouvez essayer de modifier un projet simple écrit dans un cadre. Commencer un projet à partir de zéro dans un cadre que vous ne connaissez pas est une méthode d'apprentissage très inefficace.

Maintenant, votre question portait sur un projet spécifique et son transfert dans un cadre. Pour cela, la réponse semble être: ça dépend, et on ne peut pas vraiment vous le dire. Cependant, le portage de choses dans un framework que vous ne connaissez pas est certainement une mauvaise idée, car vous ne pouvez même pas savoir si cela a un sens . Par conséquent, il semble que vous devriez la laisser telle quelle et revoir cette décision à un moment donné, une fois que vous connaissez et appréciez certains cadres. D'autres réponses contiennent de bons arguments sur ce que vous devriez rechercher lorsque vous prenez une telle décision.

Cet article a beaucoup attiré l'attention sur Hacker News il y a 2,5 ans: écrivez un code facile à supprimer et difficile à étendre. Cette perspective peut vous aider ou non à gérer votre base de code actuelle, mais à l'avenir, elle pourrait aider à éviter les frustrations dues au perfectionnisme / à l'ingénierie excessive.

Si nous voyons les «lignes de code» comme des «lignes dépensées», nous réduisons le coût de la maintenance lorsque nous supprimons des lignes de code. Au lieu de créer des logiciels réutilisables, nous devrions essayer de créer des logiciels jetables.

Je n'ai pas besoin de vous dire que supprimer du code est plus amusant que de l'écrire.

(c'est moi qui souligne)

Le fil de l'article sur Hacker News pourrait également valoir la peine d'être lu.

S'agissant de la pérennité et de l'application des principes d'échelle et de cadre, c'est une tâche de taille à prendre en charge par vous-même, je ne m'inquiéterais probablement pas pour ça, mais si vous deviez:

Gardez votre code propre, suivez les principes SOLID, DRY> google.

Appliquez un équilibreur de charge dès que possible.

Mettez en place au moins deux serveurs Web, gérez les scénarios d'équilibrage de la charge dans le code.

Enfin, il existe de meilleures solutions pour traiter un million d'utilisateurs que LAMP, mais je suis sûr que c'est tout à fait faisable.

Cas et point, voir: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade Le point est valide, mais 10 Go est trivial en tant que sujet de test.