La peur que l'application Web ne soit pas "à l'épreuve du temps"
Je suis développeur Web d'une petite application Web locale SaaS. Elle compte actuellement une demi-douzaine de clients.
Alors que je continue de concevoir l'application, il est devenu de plus en plus difficile pour moi de me convaincre de m'engager à tout moment dans le projet, ce qui s'est produit au début. Après m'être attaché au projet et au code que j'ai déjà écrit, j'ai peur que tout le travail supplémentaire que j'engage soit annulé dans un proche avenir, lorsque l'application se révélera mal évoluer à mesure que l'entreprise se développera.
En tant qu'étudiant universitaire postulant pour des stages, des employeurs ont remis en question mon choix de ne pas utiliser de framework Web lors des entretiens, ce qui ne fait que douter de mon travail précédent. Je ne connais tout simplement aucun framework web et je ne sais pas lequel utiliser.
J'ai décroché un stage en tant que développeur full-stack en janvier, où je vais commencer à apprendre les frameworks frontaux, mais la pression pour terminer l'application monte, 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 intégrée à PHP et jQuery (pour AJAX)) et utilise MySQL pour sa base de données. Toute réflexion sur la façon de surmonter ce blocage mental, et pour que mon application soit évolutive? Merci d'avance.
Ou, autrement dit, ne vous en faites pas aujourd'hui. Si votre application fait ce qu'elle doit faire, ça va. Ce n'est pas une mauvaise chose de réécrire des parties du logiciel plus loin; à ce stade, vous 1) savez plus clairement ce que vous essayez de construire et 2) savez quels bits sont en fait le goulot d'étranglement. Vous pourriez passer énormément de temps à écrire une application qui pourrait 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 de surmonter ce blocage mental et de garantir que mon application sera évolutive?
Le nœud du problème n'est pas l'évolutivité. Le nœud du problème est de penser que vous aurez raison la première fois .
Vous devez vous concentrer sur l'écriture de code propre. Parce que le code propre maximise la commodité lorsque vous (inévitablement) devez changer quelque chose à l'avenir. Et c'est le véritable objectif que vous devriez avoir.
Ce que vous essayez de faire maintenant, c'est de penser au code parfait à écrire. Mais même si vous parvenez à le faire, qui dit que les exigences ne changeront pas, ou que vous avez peut-être pris vos décisions sur la base d'informations erronées ou d'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 du code que vous n'aurez pas besoin de changer à l'avenir.
Après m'être 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 une constante est votre désir de résoudre un problème spécifique. La manière de résoudre ce problème n'est qu'une préoccupation secondaire.
Si demain un nouvel outil est publié qui réduit votre base de code de 80%, allez-vous être contrarié que votre code ne soit plus utilisé; ou allez-vous être heureux que votre base de code soit devenue plus petite et beaucoup plus propre/plus gérable?
Si le premier, vous avez un problème: vous êtes ne voyez pas la solution pour le code . En d'autres termes, vous vous concentrez sur le code et ne voyez pas l'image plus grande (la solution qu'il vise à fournir).
J'ai peur que tout le travail supplémentaire que j'engage soit annulé dans un proche avenir, lorsque l'application se révélera mal évoluer à mesure que l'entreprise se développera.
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 défauts qu'il pourrait encore montrer. Ce que vous faites actuellement, c'est retenir la première tâche de peur de devoir ensuite effectuer la deuxième tâche.
Mais quelle autre option existe-t-il? Vous ne pouvez pas dire l'avenir . Si vous passez votre temps à réfléchir aux possibilités futures, vous allez finir par deviner de toute façon. Une supposition a toujours tendance à se tromper.
Au lieu de cela, générez l'application et prouver qu'il y a bien un problème. Et une fois que le problème est clair, vous commencez à le résoudre.
En d'autres termes: Henry Ford n'a jamais construit une voiture conforme aux normes/attentes de 2018. Mais s'il n'avait pas construit la Model T, une voiture défectueuse 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 qu'ils auraient pu ensuite essayer d'améliorer.
Des employeurs ont remis en question mon choix de ne pas utiliser de framework Web lors des entretiens, ce qui ne fait que douter de mon travail précédent.
La partie importante ici n'est pas le cadre que vous utilisez (tout employeur qui vous juge sur ce point 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 framework existant spécifiquement parce que vous voulez apprendre pourquoi un framework est utile en le faisant à la dure d'abord. 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 c'est un drapeau rouge pour un employeur.
Je ne connais tout simplement aucun framework web et je ne sais pas lequel utiliser.
Le même problème se pose ici. La solution n'est pas de penser plus, mais plutôt d'agir:
- Arrêtez de réfléchir à la réponse parfaite .
- Choisissez un cadre. Sauf si vous avez une préférence, choisissez-en une au hasard. Utilisez un jeu de fléchettes, lancez un dé, lancez une pièce, choisissez une carte.
- Utilise le.
- Vous avez aimé l'utiliser? Y a-t-il quelque chose que vous avez trouvé agaçant?
- Cherchez à éviter ces mauvais éléments. Avez-vous mal utilisé le cadre, ou est-ce simplement ainsi que le cadre est censé fonctionner?
- Une fois que vous sentez que vous avez une prise sur le cadre (que cela vous plaise ou non), choisissez un nouveau cadre et répétez le cycle.
Pour en savoir plus à ce sujet, lisez L'état d'esprit faisant> l'état d'esprit pensant . L'auteur l'explique mieux que moi.
mais la pression pour terminer l'application monte, et j'envisage de supprimer complètement l'application et de recommencer
Sauf si la base de code actuelle est un gâchis absolument impossible à maintenir; vous prenez la décision inverse.
Les développeurs pensent souvent que jeter des objets serait le meilleur choix. C'est un sentiment très courant. Mais c'est rarement le bon choix.
Jeter du code et recommencer à zéro, c'est comme rester coincé dans la circulation sur le chemin du travail, craignant d'être en retard au travail (ne pas respecter la date limite), et plutôt de rentrer à la maison et d'essayer de reprendre la même route. Ça 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 à la maison.
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:
- Tout d'abord, 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, pertinents pour la logique client supplémentaire nécessaire pour prendre en charge le premier point, ils fournissent des contextes d'exécution isolés afin que vous puissiez entasser le code d'autres personnes dans une page sans rien casser.
Vous n'avez probablement besoin de rechercher un framework pour résoudre ces problèmes que si votre application est intrinsèquement dynamique, si la quantité d'état d'application que vous enregistrez côté client est assez complexe, si vous attendez un grand nombre de clients avec une latence réseau mauvaise (mobile, ou éloigné du serveur), ou s'il existe un fort besoin commercial de prendre en charge la création d'éléments CSS ou dynamiques particulièrement avancés.
Le marketing de framework veut que vous croyiez que leur méthode spéciale d'architecture augmente la vitesse de développement et facilite la maintenance. C'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 un produit plus rapidement. Il offre beaucoup moins pour une équipe de développement d'une seule personne travaillant sur un projet déjà fonctionnel.
Vous passerez plus de temps à apprendre à intégrer du code fonctionnel existant dans le cadre que vous n'implémenterez réellement des fonctionnalités, et il est fort probable que quelqu'un quelque part mettra à jour quelque chose, et le code écrit dans ce cadre cessera de fonctionner dans un délai de 18 mois, sauf si quelqu'un est là pour le maintenir constamment.
Vanilla JS, et dans une moindre mesure mais toujours significative JQuery, ne souffrent pas de ces problèmes. À quelques exceptions notables près, les applications JQuery + AJAX ne reposant pas sur des comportements spécifiques au navigateur et renonçant aux dépendances externes lorsque cela est judicieux) continuent de fonctionner 10 à 15 ans après leur écriture initiale avec des modifications très mineures.
Les cadres sont parfaits pour les startups classiques qui prennent en charge des applications Web continues, complexes et accessibles au public. Ils permettent aux grandes équipes de bien se coordonner, s'intègrent bien avec les cadres d'ajout de fournisseurs et prennent en charge de nouveaux widgets et paradigmes de conception flashy pour vous aider à rester compétitif.
Rien de tout cela n'a d'importance pour un petit outil logiciel avec un public fixe que vous êtes sur le point d'abandonner. L'adoption d'un cadre ralentit votre vitesse de développement à mesure que 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 du risque de compatibilité diminue considérablement. Les navigateurs changeront, les URL CDN cesseront de fonctionner, les dépendances seront obsolètes - Mais personne ne touche à ce serveur, et il continuera à fonctionner très bien.
N'adoptez pas un cadre à moins qu'il ne résout un problème architectural spécifique que vous avez aujourd'hui ou que vous pouvez prévoir bientôt, et envisagez fortement de répondre à cette préoccupation par un autre moyen si cela est tout à fait tenable.
La meilleure chose que vous puissiez faire pour "pérenniser" votre application est de suivre les meilleures pratiques dans la conception de votre système afin de maximiser le couplage 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 impacté par X.
Cependant, je dirais que votre préoccupation devrait être moins pour la croissance/l'évolutivité de votre application que le taux de croissance de votre propre expérience et de vos capacités. Le blocage mental que vous décrivez me semble comme apprendre la stagnation ou la conscience de nombreuses inconnues connues sans la stratégie ou les outils pour y faire face.
Les cadres ne sont pas particulièrement bien adaptés pour résoudre le défi de la "pérennité", bien qu'ils puissent fournir des conseils initiaux pertinents aux inexpérimentés, généralement via des modèles de conception de haut niveau comme MVC. Au contraire, ils ont tendance à être plus utiles en tant que moyens d'accélérer le développement en fournissant une forte cohésion et souvent aux dépens d'un couplage plus étroit. Par exemple, supposons que vous utilisiez un système de mappage relationnel objet fourni par le framework dans toute 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 basculer vers une banque de données non relationnelle et maintenant tout qui l'utilise est affecté.
Le gâchis que vous avez maintenant ne vient pas de ce que vous avez utilisé, mais où vous l'avez utilisé (probablement à peu près partout sur le back-end). Vous vous sentirez beaucoup mieux si le code qui rend une page ne récupère jamais les données qu'elle rend.
Supposons que vous souhaitiez ajouter un petit widget à une page qui nécessite des scripts et des ressources supplémentaires pour fonctionner correctement. Si vous utilisez un framework, vous pouvez demander "Comment veut-il que j'ajoute les dépendances à une page pour cette chose?" Si vous ne l'êtes pas, la question est plus ouverte: "Quelles sont les préoccupations techniques que je touche et qui devraient être séparées d'une manière ou d'une autre?" Cette question prend plus d'expérience pour répondre, mais voici quelques conseils:
- Que se passerait-il si demain vous déplaciez toutes vos ressources statiques (scripts, images, etc.) vers un serveur distinct, un réseau de diffusion de contenu, etc., ou si vous commenciez à les regrouper toutes 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 A-B sur différentes versions du widget?
Si tout cela vous semble écrasant, je vous suggère d'utiliser un framework pour l'instant, pas tant pour le bien de votre application que pour votre propre croissance personnelle. Mais ne recommencez pas nécessairement. Utilisez plutôt des frameworks comme curriculum pour guider l'évolution de votre application.
Il n'y a que deux façons d'apprendre. L'une est par essais et erreurs, et l'autre par apprentissage par l'expérience des autres. Les essais et erreurs ne peuvent pas être éliminés. Le développement logiciel 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 qui est déjà écrit.)
L'astuce consiste à la minimiser en recherchant de manière proactive les connaissances préexistantes (stratégies, meilleures pratiques et code/bibliothèques/frameworks) à chaque étape du processus de développement afin de ne pas vous retrouver constamment à réinventer la roue.
En ce qui concerne l'application que vous écrivez actuellement, cependant, votre première préoccupation devrait être simplement de la faire avec un minimum d'effort banal (qui est un peu comme une odeur de code, mais pour processus de développement). Étant donné la nature de l'apprentissage humain, le moyen le plus rapide d'atteindre une qualité élevée est de commencer avec quelque chose . Il est beaucoup plus facile de comprendre l'objectif lorsque vous pouvez le façonner 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 bons designs, cela vous motivera 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 toujours présent si ce que vous faites en vaut la peine (voir la déclaration "apprentissage continu" ci-dessus).
Par-dessus tout, "supprimer la chose et recommencer" est jamais une option ... après tout, n'a pas vous dites que vous avez "une demi-douzaine clients?" Avez-vous encore fait une pause pour réfléchir à ce que ils pourraient penser à votre déclaration, étant donné qu'ils sont actuellement (vraisemblablement) "parfaitement satisfaits de votre travail?!"
Voici une analogie que j'aime utiliser:
"Mon travail consiste à construire des maisons pour que les gens vivent, pour que les gens créent des entreprises, etc." Mon travail consiste à faire "ces morceaux de sable incroyablement minuscules et trop glorifiés " pour faire un travail utile. (Tout comme les constructeurs de maisons fabriquent 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" que les constructeurs de maisons utilisent n'ont vraiment pas beaucoup changé en deux cents ans (sauf pour passer de "carré" à "rond", puis être rendus utiles avec des cloueuses pneumatiques), la technologie que nous utilisons est en constante évolution et subit parfois des changements très profonds. ("Alors ça va.")
"Néanmoins, chaque maison, une fois construite, restera pour toujours habitée in." 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 qu'il est en ce moment, et cela durera très longtemps.
Une grande partie de mon entreprise ces jours-ci consiste à aider les clients à faire face à un logiciel qui a été construit il y a dix, vingt, trente ans ou plus, en utilisant les technologies "de pointe" qui existaient à l'époque - (et qui, ahem, je me souviens) - et qui sont toujours en service (!) aujourd'hui.
Il est presque impossible de garantir la pérennité de quelque chose. Il n'est pas trop difficile de vérifier que l'application est évolutive. Il vous suffit d'écrire un test de performances pour l'application et de voir combien de clients elle peut gérer. L'écriture de tests rendra certainement votre application plus pérenne car vous pourrez évaluer le comportement de l'application après y avoir implémenté plus de modifications.
par rapport au framework, je ne serais pas trop inquiet en termes de performances/évolutivité. C'est quelque chose que vous pouvez facilement vérifier et probablement corriger. Le plus gros problème est la sécurité. Les frameworks Web vous aident généralement à écrire le bon code d'authentification, les cookies, la protection CSRF, etc. Surtout étant donné votre manque d'expérience, mieux vous concentrer dans ce domaine.
J'ai commencé à écrire un commentaire sur les cadres d'apprentissage, mais finalement cela s'est transformé en quelque chose ressemblant plus à une réponse, alors voici.
Ne pas connaître de frameworks semble être un problème. Dans pratiquement n'importe quel travail webdev, vous devrez travailler avec un cadre . Apprendre un autre cadre une fois que vous en savez un n'est pas si très important, mais apprendre le premier peut prendre un certain temps - c'est pourquoi les employeurs peuvent s'en soucier. Éviter les cadres peut indiquer syndrome non inventé ici , ce qui est une approche largement impraticable.
Comme le point principal de connaître vos premiers frameworks est d'apprendre un langage commun, essayez peut-être simplement d'apprendre quelque chose de populaire parmi vos pairs. Vous pouvez essayer de modifier un projet simple écrit dans un framework. Démarrer un projet à partir de zéro dans un cadre que vous ne connaissez pas est un moyen d'apprentissage très inefficace.
Maintenant, votre véritable question portait sur un projet spécifique et son portage vers un framework. Pour cela, la réponse semble être: cela dépend, et nous ne pouvons pas vraiment vous le dire. Cependant, porter des trucs vers un framework que vous ne connaissez pas est presque certainement une mauvaise idée, car vous ne pouvez même pas savoir si cela a du sens . Par conséquent, il semble que vous devriez le laisser tel quel et revoir cette décision à un moment donné, une fois que vous connaissez et aimez un cadre. D'autres réponses contiennent de bons points sur ce que vous devez rechercher lorsque vous prenez une telle décision.
Cet article a attiré beaucoup d'attention sur Hacker News il y a 2,5 ans: Écrivez du code qui est facile à supprimer, pas facile à étendre. Cette perspective peut ou non vous aider à gérer votre base de code actuelle, mais dans l'avenir, cela pourrait aider à prévenir la frustration due au perfectionnisme/à la suringénierie.
Si nous considérons les "lignes de code" comme des "lignes dépensées", alors lorsque nous supprimons des lignes de code, nous réduisons le coût de la maintenance. Au lieu de construire des logiciels réutilisables, nous devrions essayer de construire 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.