Adaptabilité d’apprentissage
Il y a quelques semaines, mon ordinateur portable est tombé en panne lors d’une réunion. C’était pénible car j’étais sur le point de commencer une nouvelle fonctionnalité passionnante que mon Product Owner (PO) venait de proposer. Je me suis immédiatement précipité vers le service informatique pour obtenir de l’aide, et ils m’ont informé qu’ils devaient effectuer une sauvegarde et reconstruire complètement mon ordinateur portable. Ils ont estimé que la reconstruction prendrait un peu plus d’une demi-journée. Frustré, je me suis demandé : « Puis-je coder sans mon ordinateur portable ? ». Dans le passé, j’aurais répondu « NON » sans hésitation. Mais à la réflexion, j’ai réalisé que je connaissais bien mon système et que je connaissais également le domaine. Après plus d’introspection, j’ai reconnu que je le faisais déjà sans m’en rendre compte consciemment. Alors, je suis allé voir mon bon de commande et lui ai demandé d’imprimer les nouvelles exigences pour moi.
Des exigences aux critères de réussite
Un ingénieur logiciel doit prendre en compte de nombreux facteurs avant d’écrire ne serait-ce qu’une seule ligne de code. D’abord et avant tout, il faut comprendre le problème de l’entreprise et qui sont les acteurs. Une fois que vous avez une compréhension claire des exigences, cela vous permet d’identifier tout défaut dans les exigences ou s’il contredit des fonctionnalités existantes. Vous pouvez ensuite le décomposer en éléments gérables et réfléchir à la façon de réutiliser ces éléments ou de déterminer si quelque chose existe déjà. Ce processus vous aide à définir les critères de réussite finaux.
Stratégies et considérations
Une fois que vous avez compris le paysage du problème, l’étape suivante consiste à commencer à réfléchir à des solutions et à des stratégies. Demandez-vous si l’opération sera gourmande en calculs ou en données. Pouvez-vous décharger tout travail sur le client pour réduire la charge du serveur ? Existe-t-il des solutions, des modèles ou des techniques connus et réussis qui peuvent être utilisés ? Les résultats doivent-ils être mis en cache, et si oui, où ? De plus, envisagez de décomposer la fonctionnalité et de déléguer le travail à d’autres membres de l’équipe pour travailler en parallèle. En plus des considérations techniques, il est crucial de considérer la nature de l’application que vous développez. Est-ce une application Web ou une API ? Vous devez également déterminer qui consommera le service : clients Web, clients iOS, Android, B2B et B2C. De plus, vous devez vous concentrer sur les contrats et les canaux de communication, qui sont tous deux des éléments cruciaux.
Au-delà du développement
Avons-nous déjà parlé de sécurité ? Envisagez-vous de placer cette nouvelle fonctionnalité derrière des flux d’authentification et des pare-feu déjà disponibles ? Avez-vous pris en compte les données en transit et les données au repos ? Existe-t-il des mécanismes d’alerte en cas de problème ? Jusqu’à présent, tout semble parfait. Vous connaissez le problème, la stratégie pour développer la solution, le client consommateur, le déploiement et la sécurité. Une fois la fonctionnalité prête, elle sera déployée en production. Cependant, avez-vous réfléchi à ce qui se passe lorsqu’il est en production ? Avez-vous besoin de modifications de configuration ? Existe-t-il des obstacles potentiels à la mise à l’échelle de l’application ? Comment allez-vous résoudre les problèmes de performances qui surviennent en production ? Existe-t-il un tableau de bord prédéfini pour signaler les métriques critiques de la nouvelle fonctionnalité ?
Produire du code robuste et maintenable
Ahh, nous avons presque tout répertorié, et il est maintenant temps de commencer à écrire du code. Mais, avant de commencer, vous devez considérer la testabilité et la maintenabilité de votre code. Vous pensez d’abord à votre test avant le code. Le développement piloté par les tests (TDD) doit guider votre processus de développement pour créer une fonctionnalité robuste. Cette technique peut vous aider à résoudre les problèmes de manière plus efficace et efficiente. Maintenant que vous avez terminé le travail de base nécessaire, il est temps de traduire votre heuristique bien pensée en code en utilisant votre langage de programmation préféré et de revendiquer les points d’histoire.
Parcours pour offrir une haute qualité
Les développeurs juniors n’ont peut-être pas encore développé la capacité de penser cela de manière globale, tandis que les ingénieurs en logiciel chevronnés savent ce qu’il faut pour fournir un composant. Et au fur et à mesure que vous progresserez en tant que responsable technique, vous effectuerez des tâches similaires, mais pour de nombreux composants, simultanément. Bien que cela puisse sembler beaucoup de travail, une fois que vous commencez à le faire, cela deviendra plus intuitif. La seule partie fastidieuse de tout ce processus est en fait de taper le code et de le valider, pour lequel j’ai besoin de mon ordinateur portable.