Comment démarrer un projet logiciel : un guide pour les développeurs juniors
« OK, commençons à coder ! » Aussi excitants que soient ces mots, ils sont bien plus réconfortants quand ce ne sera pas toi qui doit faire tout le travail pour tout lancer.
Par conséquent, le démarrage d’un projet logiciel est un véritable séparateur entre le senior expérimenté et le junior enthousiaste – et je recommande donc aux développeurs débutants de se familiariser avec tous les domaines qui doivent être couverts, puis de se lancer dans un projet qui ne le fait pas. avoir trop d’yeux dessus. De nombreuses décisions peuvent être retardées et certaines choses peuvent être modifiées de manière triviale sans aucun effet secondaire, mais certains éléments sont plus coûteux à modifier ultérieurement. Cet article explique par où commencer et quels éléments sont les meilleurs pour commencer dès le début.
À quoi ressemble le bien
Le tueur numéro un de tous les projets – même ceux qui ne sont en aucun cas examinés – est que leur valeur ne peut être mesurée. Même les petites habitudes que vous commencez pour vous-même, comme aller au gymnase ou commencer un régime, sont discrètement abandonnées si vous ne voyez aucun progrès mesurable. Dans l’industrie, les projets non mesurables peuvent sembler bons, mais ils ont un kill switch intégré car vous ne pouvez pas prouver comment ils ajoutent de la valeur. Vous souvenez-vous de tous ces sondages un peu ennuyeux que vous avez reçus dans votre boîte de réception et qui vous posaient des questions sur un site Web ou un service que vous venez d’utiliser ? Ce sont des personnes qui font un effort considérable pour mesurer des éléments intangibles comme le « partage des connaissances ». Aussi hokey soit-il, essayez de construire une piste de mesure dans votre projet dès le début. Il y a différentes choses à mesurer, de l’adoption précoce aux pages vues uniques. À l’inverse, vous pouvez mesurer le déclin d’une mauvaise chose que votre projet tente d’empêcher.
Maintenir un wiki de projet à jour est la clé pour empêcher les premiers problèmes de se propager en raison d’objectifs peu clairs. Notez ce que le projet doit accomplir, les composants de base que vous pensez nécessaires, qui sont les parties prenantes et, oui, quelques dates cibles. De nouvelles situations se produiront toujours et les gens feront les mauvaises choses – et franchement, certaines des décisions que vous prendrez au début seront erronées. Aucun de ceux-ci ne provoque le chaos. Cela est dû au fait que les gens ne partagent pas une idée assez forte de la direction d’un projet avec qui que ce soit d’autre. Le simple fait d’écrire suffisamment est assez facile à faire et suscite beaucoup de doutes.
Le MVP et les faux
La première chose que vous produisez ou construisez doit correspondre à ce dont vous avez besoin, mais rien d’autre. Si le produit est un site Web, il doit correspondre au format souhaité, mais être simplement rempli par un « Lorem ipsum » remplissage d’espace réservé. Ce qui compte, c’est que le MVP (minimum viable product) vous oblige à vous concentrer sur l’infrastructure dont vous avez besoin pour vous mettre en place.
Avez-vous besoin d’accéder à un service coûteux? Chargez-vous de l’argent ? Votre service dépend-il du temps d’une manière ou d’une autre ? Dans presque tous les cas, vous devrez simuler un ou plusieurs composants de votre projet afin de le tester, sans invoquer de coûts ou de conditions réels.
Parfois, un peu de travail est nécessaire pour créer le faux environnement, mais cela doit être fait. Par exemple; bien qu’il soit beaucoup plus facile de facturer de l’argent qu’auparavant, nous avons tous vu des services qui essaient d’introduire la facturation pour découvrir qu’il n’est pas si facile de se brancher plus tard (à cause de toutes les hypothèses précédentes).
Des services comme AWS Lambda sont très bons pour créer des contrefaçons bon marché, car ils ne facturent que lorsqu’ils sont déclenchés. Les fausses données doivent également être prises en compte. Tester sur des données qui ne correspondent pas à l’utilisation réelle de votre produit par les clients entraînera inévitablement de mauvais résultats. Un exemple concret était une institution qui utilisait des données en direct obscurcies pour les tests. Mais les données étaient tellement masquées qu’elles ont détruit la relation naturelle entre les clients (par exemple, de vraies personnes vivent ensemble) et ont donc causé des problèmes plus tard.
Identités et qui fait quoi
L’une de ces décisions « difficiles à modifier ultérieurement » est d’oublier de créer des adresses e-mail, des entrées de domaine et des comptes pour votre projet, et de les faire à la place sur les détails de votre propre compte, car vous vouliez gagner du temps. Ne fais pas ça. Peu importe si vous utilisez un nom de domaine ou une adresse e-mail qui ne correspond pas à l’identité finale – il importe qu’ils ne soient pas connectés à vous ou à quelqu’un d’autre. Sinon, tout le projet part en vacances quand vous le faites.
Si vous avez la chance d’avoir de l’aide, vous devez diviser le travail en portions raisonnables. Heureusement, la méthodologie agile fonctionne très bien pour les développeurs en démarrage de projets — car au départ vous n’avez rien d’autre qu’une liste de tâches à accomplir. Les gens ne peuvent assumer les tâches que s’ils les comprennent, ce qui vous oblige à les définir clairement. Il en va de même si vous prévoyez d’utiliser l’aide de l’IA – enregistrez toutes les invites que vous utilisez. Pour commencer, c’est tout ce dont vous avez besoin. Le mantra agile est :
Faites-le fonctionner, faites-le bien, faites-le vite.
Commencez donc par le faire fonctionner avec qui que ce soit à bord.
Environnements et AQ
Si vous commencez par comprendre ce qu’il faut mesurer et où falsifier, vous constaterez probablement que les tests et l’assurance qualité (AQ) suivront naturellement. Vous pouvez utiliser Jira ou Trello pour communiquer avec vos testeurs, mais tout ce que vous choisissez doit s’intégrer aux outils que vous utilisez pour diviser vos histoires et vos tâches. Le monde des conteneurs a considérablement amélioré les chances que tout environnement dans lequel vous construisez soit très proche de l’environnement utilisé par vos testeurs.
Si vous êtes derrière un pare-feu, il est maintenant temps de vous faire de bons amis avec l’équipe de sécurité. Sinon, vous constaterez rapidement que vous ne pouvez rien partager avec des testeurs délocalisés.
Quand je dis environnement, je veux dire mise en scène, QA et production. Si vous supprimez ces termes un instant, nous ne parlons généralement que d’espaces informatiques virtuels avec différentes configurations. Ainsi, par exemple, l’environnement QA permet à vos testeurs de jouer avec la dernière version stable et est configuré pour fonctionner avec de faux services. La création de scripts pour créer votre environnement impliquera un certain type de livre de jeu – assurez-vous d’avoir les compétences disponibles pour le faire.
Outils de développement
La façon d’écrire réellement le code vient beaucoup plus bas dans la liste des priorités que vous ne l’auriez imaginé, car il est beaucoup plus facile à configurer et à modifier. Vous ne pouvez pas reprocher aux développeurs de logiciels de vouloir se concentrer sur les frameworks, les normes de codage et les éditeurs, car c’est notre métier. La plupart des décisions initiales peuvent être modifiées ultérieurement. En fait, réécrire votre base de code devrait être quelque chose que vous visez à faire à un moment donné ; ce n’est pas quelque chose à éviter complètement. Mais, comme pour aller aux toilettes, n’attendez pas d’y être obligé.
Les plus grands IDE ont tendance à inclure des projets factices et de nombreux services qui peuvent aider tout le monde à démarrer. Oui, ils veulent vous lier à leurs autres services, mais leur utilité peut faire la différence entre démarrer ou non. L’astuce avec l’utilisation de services hautement intégrés de sociétés tierces est de vous assurer que vous avez défini votre architecture avant de commencer, afin que Microsoft (ou quiconque) ne redéfinisse pas votre projet en fonction de ses outils. La dépendance physique est simple à changer, la dépendance mentale est un peu plus difficile à déplacer.
Si vous programmez à l’air libre, vous voudrez utiliser git avec Github pour votre référentiel de code central. Mais dans la plupart des cas, vous souhaiterez exécuter des référentiels privés avec l’un des nombreux services de référentiel central. Si vous savez que vous allez produire de nombreux artefacts à évolution lente, vous aurez peut-être besoin d’un référentiel d’artefacts (ou DockerHub), et si vous traitez de nombreux fichiers volumineux et non textuels (tels que de grandes images), vous aurez peut-être besoin pour éviter complètement git et utiliser quelque chose comme PlasticSCM (qui est maintenant dans Unity).
Configuration CI/CD
Un exemple de pipeline CI/CD ; via dev.to
(Sauf si vous écrivez Go, ne vous attendez pas à voir des gaufres bleus près de votre écran)
Le centre de votre projet sera toujours le pipeline de construction – le cœur de l’intégration continue/déploiement continu (CI/CD). En termes simples, vous devez créer une version à partir de la branche de code appropriée de votre produit ou service et la déployer dans un ou plusieurs environnements à partir d’un seul signal. En d’autres termes, automatisez le déploiement. Ce n’est pas quelque chose dont vous avez besoin immédiatement, mais ne faites rien dès le début pour prévenir automatisation plus tard.
Les équipes utilisent toujours le favori open source Jenkins pour vérifier, créer et déployer, mais il existe de nombreuses autres options. Si vous gardez un œil sur la maintenance des fichiers de configuration qui fonctionnent pour vous, la modification du pipeline ne devrait pas être trop pénible.
Une fois qu’une automatisation de construction de base est en place, vous pouvez intégrer d’autres services, tels que la couverture du code et les tests de sécurité.
Conclusion
Vous avez donc défini votre projet, déterminé à quoi ressemble le bien, décrit ce que vous pensez que les composants et les processus devraient être, compris l’infrastructure, trié les rôles, vérifié le premier MVP et actionné la poignée sur le pipeline.
L’important dans les projets n’est pas la manière dont ils démarrent (personne ne se souviendra si tout se passe bien), mais la qualité de leur maintenance tout au long de leur cycle de vie. Et oui, vous devez également savoir quand et comment les retirer.
Créé avec Sketch.
