Article original : The reality of being a junior software engineer at a small startup
Par Tan Le Tian
Le développement logiciel dans le monde réel est effectivement très différent de ce qu'on enseigne à l'école.
Voici ce que j'ai appris après avoir travaillé dans une startup qui développe une application web adaptée aux exigences spécifiques des clients.
1. Être un ingénieur full stack n'est pas une option mais une nécessité
En tant que petite entreprise avec seulement 7 personnes, il n'y a tout simplement pas assez de ressources pour embaucher des personnes spécialisées uniquement dans le frontend, le backend, la base de données ou le design. Cela est probablement très différent de la façon dont les grandes entreprises fonctionnent.
Nous avons généralement plusieurs projets de différents clients en cours simultanément. Tout le monde doit compléter différents projets de manière indépendante. Ainsi, il est nécessaire que chacun connaisse tous les aspects du développement web pour implémenter des fonctionnalités et corriger des bugs.
Par exemple, nous avons dû implémenter entièrement une fonctionnalité qui permet à l'utilisateur d'ajouter et de modifier des enregistrements dans un système. Nous devons utiliser HTML, CSS et JavaScript pour construire des formulaires sur le frontend. Alors que sur le backend, les langages PHP et MySQL sont nécessaires pour effectuer des opérations de lecture et d'écriture dans la base de données.
2. Livrer un produit qui répond étroitement au budget et aux exigences des clients
Le client a parfois besoin de logiciels de toute urgence pour résoudre un problème. Ils fixent des délais serrés et offrent un budget limité.
Il y a toujours un compromis entre le temps de développement, le prix et la qualité d'un produit logiciel. Il est vraiment difficile de livrer un produit de haute qualité et bon marché dans un délai serré.
Ainsi, nous devons prioriser le développement des exigences principales du logiciel. Un produit de haute qualité prend du temps à construire. Pour livrer le produit à temps et dans le budget, nous sommes parfois obligés de faire des compromis sur les aspects esthétiques et l'expérience utilisateur.
Mais pour être honnête, le client nous a clairement mentionné qu'il voulait simplement une application web qui fonctionne. Il a insisté à plusieurs reprises sur le fait qu'il ne se souciait pas de l'esthétique de l'interface utilisateur, tant que nous lui facturions le prix le plus bas possible.
Cela peut sembler comme si le client voulait un produit médiocre. Mais je dirais plutôt qu'il veut simplement un "Produit Minimum Viable" ou une "Preuve de Concept". Ce n'est pas parfait, mais c'est suffisamment bon pour être utilisé afin d'automatiser certains travaux manuels dans son entreprise.
De plus, le développement logiciel est un processus itératif. Si le logiciel s'est avéré utile dans une utilisation réelle, le client ne hésitera probablement pas à payer plus pour que nous l'améliorions.
3. Le code bricolé et les solutions de contournement sont parfois inévitables
Personne n'aime écrire du code laid qui fonctionne mais qui n'est pas maintenable et évolutif. Personne n'aime accumuler de la dette technique et en payer le prix plus tard.
Personnellement, j'ai toujours essayé d'écrire du code lisible et propre. Mais parfois, il n'y a tout simplement pas le choix.
Lors de l'intégration de certaines API tierces, elles peuvent parfois renvoyer des résultats inattendus. Habituellement, leur documentation n'expliquera jamais clairement pourquoi.
Lors de l'utilisation de certaines bibliothèques open source externes, il est inévitable qu'il y ait quelques bugs mineurs ici et là. Selon mon expérience, l'incompatibilité entre différentes versions de bibliothèques est souvent la principale cause de bugs inattendus.
Tout cela peut provoquer le plantage de l'application, et vos clients vont être extrêmement mécontents. Bien que les bugs soient dans le code de quelqu'un d'autre, ils penseront que c'est entièrement de votre faute et vous en tiendront définitivement responsable.
Dans ce cas, la seule façon de résoudre ces bugs dans le code tiers est de mettre en œuvre une solution de contournement astucieuse dans votre code. Le correctif peut être laid, mais il fonctionne et permet de livrer le produit rapidement.
4. Il n'y a rien de mal à utiliser des technologies anciennes (comme PHP, jQuery)
Ces dernières années, de nombreuses technologies plus récentes et plus cool ont émergé. Nous avons React.js, Vue.js, express.js, Golang, Scala, etc.
Beaucoup de gens commencent à mépriser les technologies plus anciennes comme PHP, jQuery et Java parce qu'elles sont si "ennuyeuses" et omniprésentes.
En tant que développeur, il est toujours excitant d'apprendre de nouvelles technologies et de construire des choses avec elles. Mais d'un point de vue commercial, il n'y a souvent aucune raison impérieuse d'utiliser la dernière et la meilleure technologie.
Dans mon lieu de travail, l'ingénieur senior a plus de 10 ans d'expérience dans le développement d'applications PHP. Ainsi, nous avons accès à une base de code PHP approfondie sur des fonctionnalités courantes comme l'envoi d'e-mails, l'envoi de notifications à une application mobile et le téléchargement d'images vers AWS S3.
Cela signifie que pour implémenter une nouvelle fonctionnalité dans un projet, nous pouvons copier-coller du code de projets plus anciens et apporter quelques modifications nécessaires. Cela nous permet de développer rapidement des applications web.
Bien que PHP ait ses propres défauts en tant que langage, il est suffisamment bon en tant qu'outil pour construire le produit qui répond aux exigences de nos clients.
De plus, il y a beaucoup de débats houleux sur le fait de savoir si le bon vieux jQuery devrait être abandonné au profit de JavaScript vanilla pur.
Certaines personnes n'aiment pas utiliser jQuery car il nécessite de charger une bibliothèque de 30 ko (minifiée et compressée) lors du chargement de la page web. Ils prônent l'utilisation de JavaScript vanilla car il peut rendre les applications web plus légères et plus rapides à charger.
Mais compte tenu de la popularité de jQuery, la plupart des développeurs autour de moi sont beaucoup plus familiers avec jQuery. Ils peuvent accomplir les tâches rapidement avec. Utiliser une bibliothèque de 30 ko semble être un prix relativement faible à payer pour une vitesse de développement plus élevée.
De plus, pourquoi ne pas utiliser les frameworks plus récents et plus cool comme React.js ou Angular.js ?
Dans mon cas, la plupart des projets que j'ai réalisés sont liés à des systèmes de gestion des stocks utilisés en interne par les entreprises des clients. Le bon vieux jQuery semble suffisant pour implémenter toutes les fonctionnalités requises par les clients.
Certes, l'utilisation de frameworks JavaScript pour construire une application monopage peut offrir une meilleure expérience utilisateur. Mais cela semble un peu excessif pour les petites applications web utilisées en interne par quelques administrateurs d'entreprise.
Cela dit, nous ne sommes pas contre l'utilisation de nouvelles technologies. Nous n'hésiterons pas à utiliser les frameworks JavaScript modernes si notre client exige une application web dynamique avec des fonctionnalités frontend complexes.
Conclusion
Être ingénieur logiciel est bien plus que simplement écrire du code. En fin de compte, le vrai défi réside dans la compréhension du problème auquel le client est confronté. Ensuite, développer une solution dans le cadre du budget et des délais.
Merci beaucoup d'avoir lu ! ? N'hésitez pas à me suivre sur Twitter pour plus d'histoires comme celle-ci. ?
Publié à l'origine sur https://getsudocode.com le 14 avril 2019.