L'auteur du matériel, dont nous publions la traduction aujourd'hui, dit que la plupart des programmeurs travaillent en équipe. Cependant, à un moment donné de la carrière, un développeur peut avoir besoin de travailler seul. Le champ d'application principal des approches de l'organisation du travail sur les produits logiciels est conçu spécifiquement pour une utilisation en équipe. Ces approches sont exprimées dans les règles adoptées par les organisations. Ces règles rationalisent le travail, aident les programmeurs à faire leur travail rapidement et efficacement. Quelque chose de similaire serait très utile pour les programmeurs qui travaillent seuls.
Et celui qui travaille seul? Sur quoi se concentrer, s'efforcer de créer un flux de travail clair et efficace? Quels principes et règles suivre? Nous vous suggérons de rechercher ensemble des réponses à ces questions.
À propos des programmeurs isolés
Ici, en parlant de «programmeurs isolés», je veux dire tous ceux qui travaillent dans un environnement non officiel et non structuré. Il peut s'agir d'un seul programmeur ou d'un petit groupe de personnes engagées, disons, pendant leur temps libre, avec une sorte de projet. Voici quelques exemples:
- Développement d'un projet open source, tel qu'un package ou une sorte de bibliothèque.
- Le projet personnel de quelqu'un, qui peut être commercial ou gratuit.
- Freelance.
Tous ces exemples sont unis par le fait que le travail des programmeurs engagés dans quelque chose de similaire n'est généralement pas réglementé par un certain ensemble de règles, telles que celles qui existent généralement dans les entreprises.
Pourquoi un seul programmeur devrait-il se soucier des règles?
Les règles, en les appliquant au travail indépendant des programmeurs sur certains projets, sont importantes pour plusieurs raisons. Considérez-les.
▍ Règles personnelles et travail d'équipe possible
Un programmeur dont le travail indépendant est bien organisé peut très bien rejoindre une certaine équipe. Dans ce cas, les chances sont bonnes qu'il devienne un membre précieux d'une telle équipe. À savoir, nous parlons de ce qui suit:
- S'il rejoint une équipe qui suit les mêmes règles que lui, il n'aura pas à perdre de temps à tenter de se plonger dans les problèmes d'organisation. Lui, littéralement dès le premier jour, sera prêt pour un travail productif.
- S'il fait partie d'une équipe dont les règles adoptées diffèrent de ce à quoi il est habitué, il ne lui faudra pas beaucoup de temps pour apprendre ces nouvelles règles. Après tout, lui, habitué à organiser rationnellement son travail, est guidé par certaines idées générales, qui, à coup sûr, sont similaires à celles qui sous-tendent les règles de l'équipe. En conséquence, il peut rapidement atteindre un niveau élevé de productivité du travail.
- S'il est entré dans une équipe où il n'y a pas de règles du tout, alors, en fonction, bien sûr, de l'équipe, il peut lui proposer sa vision de l'organisation du travail des programmeurs, ce qui pourrait bien améliorer le travail d'une telle équipe. Si les membres d'une équipe mal organisée refusent de changer quelque chose, alors c'est l'occasion de penser à quitter une telle équipe.
En conséquence, un seul programmeur qui organise rationnellement son travail, en tout cas, est le gagnant.
▍ Règles et niveau professionnel d'un programmeur
Le développement de logiciels n'est pas seulement un processus d'écriture de code. De nombreux détails sont responsables de la transformation d'une idée en projet fini, puis de son maintien en état de fonctionnement. L'introduction de techniques de développement logiciel avancées dans le flux de travail personnel aidera un seul programmeur à suivre en toute confiance l'objectif pour lequel le projet est créé et à éviter les situations où tout semble si confus qu'il n'est pas clair où aller.
Si vous, comme moi, souhaitez programmer, vous serez toujours tenté de démarrer un nouveau projet et immédiatement, sans regarder en arrière, vous précipitez dans l'abîme de l'écriture de code. Mais l'expérience me dit que, si j'ai un certain plan de travail de haut niveau, cela, sans nuire à la flexibilité dans laquelle le développement individuel diffère, aide à éviter de nombreux problèmes d'échelles différentes.
Parlez des meilleures pratiques pour le développement de logiciels.
Suivez les règles qui décrivent votre flux de travail.
«Workflow» est une séquence d'étapes que vous devez suivre pour convertir une idée en produit fini. Voici quelques questions auxquelles doivent répondre les règles régissant le processus de travail sur un produit logiciel:
- Quand il est décidé de modifier un produit - quel est l'ordre de sa mise en œuvre?
- Comment se passe le transfert de nouvelles versions du produit aux utilisateurs?
- Comment les changements de produits sont-ils suivis?
- Comment la surveillance des messages d'erreur et des problèmes rencontrés par les utilisateurs est-elle organisée?
- Quel est le processus de planification des nouvelles fonctionnalités du produit?
Pourquoi réglementer tout cela, le conduire dans une sorte de cadre, s'il peut sembler que le travail sur les projets ira beaucoup plus vite sans un flux de travail spécifique? N'est-il pas plus facile d'imaginer l'ensemble du «workflow» sous cette forme: «il suffit d'écrire le code et de l'envoyer à la branche master»? En fait, à mesure que la complexité du projet augmente, il s'avère que la présence de règles claires simplifie la définition de ce qui doit être fait dans le travail sur ce projet et, en conséquence, sans autre réflexion, vous permet de vous concentrer sur ces questions. Lorsque vous travaillez en équipe, le flux de travail se transforme en quelque chose comme un tapis roulant qui améliore l'efficacité de chaque membre de l'équipe.
Voyons maintenant comment organiser le processus de travail sur un produit logiciel.
▍Utilisez des trackers de tâches
Ici vous trouverez les mécanismes des plateformes sur lesquelles vous placez le code utile - GitHub, Gitlab, BitBucket et autres. Les tâches permettent de suivre les messages d'erreur, les demandes d'ajout de nouvelles fonctionnalités au produit et d'organiser les informations sur les modifications importantes du projet. Il convient de noter que lorsque vous entrez le titre et la description de la tâche, cela vous oblige à formuler clairement vos pensées et à décrire clairement le problème et les moyens possibles de le résoudre. L'idée d'utiliser des tâches peut être développée en introduisant un outil de gestion des tâches comme les projets Trello ou GitHub dans votre flux de travail.
Défi▍Utilisez les demandes de tirage
De nombreux développeurs préfèrent envoyer les modifications, à l'aide de requêtes push, directement à la branche principale de leur projet, appelée maître. Cependant, l'approche pour apporter des modifications au code du projet à l'aide de demandes d'extraction présente certains avantages importants. Premièrement, ces requêtes facilitent l'analyse des changements concernant l'introduction d'une nouvelle fonctionnalité ou correction de bogue dans le projet, et comment ils, après avoir fusionné avec la base de code principale, l'affecteront. De plus, si les demandes d'extraction sont associées à des tâches du traqueur de tâches, leur utilisation facilite la compréhension de l'évolution du projet, éliminant ainsi la nécessité de le savoir lors de la lecture du code.
Détails de la demande d'extraction▍ Effectuer des révisions de code personnalisées
La recommandation de revoir le code natif peut sembler étrange, mais malgré cela, les développeurs doivent analyser leur propre code comme si quelqu'un d'autre l'avait écrit. Certains programmeurs conseillent de faire une demande d'extraction, de distraire pendant un certain temps, puis de la vérifier avant de l'inclure dans le code. Effectuer des vérifications de code effectuées en dehors de l'environnement habituel pour le programmeur sous la forme de son IDE vous permet de jeter un nouveau regard sur le code. Cela permet de trouver des erreurs et de détecter dans le code quelque chose qui, dans des conditions normales, peut être ignoré. Les revues de code obligent en outre le développeur à se poser diverses questions: «Pourquoi cette opportunité a-t-elle été implémentée de cette manière? Que pourrait-on faire de mal ici? Existe-t-il un moyen plus efficace de résoudre ce problème? »
▍ Conservez un historique significatif du projet dans le référentiel
Essayez de faire des commits comme si vous travaillez en équipe. À savoir - éviter les commits trop importants, essayez de vous assurer que les messages des commits décrivent clairement et clairement leur signification. Tout comme dans le cas des revues de code, l'écriture de messages de validation de haute qualité oblige le développeur à réfléchir soigneusement à leurs actions, en se posant des questions comme celles-ci: «Qu'est-ce que j'essaie de réaliser avec cette validation? Comment j'essaye d'y parvenir? "
Il peut y avoir des situations dans lesquelles vous pouvez vous permettre de vous écarter des règles. Par exemple, vous pouvez décider que, afin de ne pas ralentir le travail en raison de bagatelles, vous, lorsque vous apportez des modifications très mineures au code (comme la correction de fautes de frappe), vous pouvez, sans mouvements inutiles, envoyer une demande push directement à la branche principale.
Quelles que soient les règles qui sous-tendent votre flux de travail, le plus important est que tout ce que vous faites soit fait intentionnellement et non par coïncidence. Les projets réussis ne surgissent pas d'eux-mêmes: ils sont créés avec amour et soin. Les actions réalisées intentionnellement impliquent certaines périodes d'analyse de la situation, d'analyse de cas complexes et de réflexion sur la manière, par exemple, à l'aide de quels outils vous pouvez y faire face.
Construire des composants et des modules réutilisables
Mettez en œuvre les principes de
SEC ,
SOLIDE et
PREMIER . Créez des programmes à partir de petits composants atomiques encapsulés pouvant être réutilisés. Gardez ces composants à jour, assemblez-les dans des collections en utilisant des plateformes appropriées comme
Bit . Tout cela vous aidera à augmenter la vitesse et la qualité du travail.
Rédiger la documentation
Documentation ... Pour beaucoup, c'est un point sensible. Beaucoup de gens savent que les projets logiciels ont besoin de documentation. Ceux qui écrivent une bonne documentation sont déjà beaucoup moins nombreux, et encore moins qui aiment le faire. Une fois la prochaine étape fascinante de l'écriture du code terminée, la nécessité de le documenter devient souvent une tâche que vous voulez juste oublier. Comment, sous forme de texte brut, exprimer toutes les subtilités du code programme?
Et, soit dit en passant, il convient de se demander pourquoi tout cela est nécessaire. Le fait est que les gens ont tendance à faire des erreurs. Nous pouvons oublier quelque chose. Nous avons de mauvais jours. Ou, en travaillant sur un certain projet, nous pouvons simplement passer à autre chose. La documentation vous permet de capturer des connaissances sur le code, qui, sinon, sera lié à une certaine personne. La documentation du code aide également les développeurs à voir le code en termes plus généraux que ceux disponibles lors de sa rédaction et à mieux comprendre les objectifs des projets.
Les idées suivantes vous aideront à rédiger une bonne documentation.
- Comprenez que votre documentation n'est pas quelque chose comme un livre. La documentation ne doit pas constituer un exemple de haut art littéraire. Personne ne l'évaluera en fonction de son mérite artistique. N'essayez pas de tout expliquer. Efforcez-vous d'être clair et compréhensible. Parfois, quelques phrases suffisent pour décrire quelque chose.
- Rédaction de documentation avant d'écrire du code. Documentez les interfaces de vos modules, décrivez l'ordre de leur travail du point de vue d'un observateur externe. Cette documentation jouera le rôle de spécifications de produit et vous aidera dans le processus de développement.
- Écrire de la documentation après avoir écrit du code. Ici encore, il vaut la peine d’adhérer à la position d’un «observateur extérieur». Qu'est-ce qui est important dans le fragment de code décrit? Ce que vous devez savoir sur son utilisation (ou pour contribuer à son développement?). Les spécifications spécifiées par la documentation créée avant l'écriture de code pendant le développement sont susceptibles d'être modifiées. Par conséquent, il est important de vérifier que ces documents sont conformes à la situation réelle une fois les travaux terminés.
- Rédaction de documentation en cours d'écriture de code. Cette approche de la documentation est principalement applicable à quelque chose comme des commentaires ajoutés au code pendant le développement. Il existe de nombreux documents sur ce sujet, donc je n'entrerai pas dans les détails ici.
- Documentation et "modules". Tous les principes ci-dessus s'appliquent aux modules. Ici, le concept de "module" est utilisé dans un sens assez large. Cela peut être une fonction, une classe, une nouvelle opportunité, un changement dans le comportement d'un programme, en fait, un certain module de programme, ou l'ensemble du projet. Si la documentation de tels «modules» vous semble trop difficile, essayez de les diviser en parties plus petites. Ou, s'il vous est plus facile de penser dans des catégories plus générales, envisagez d'écrire de la documentation pour les blocs les plus importants du projet.
Communiquez avec vos clients et ceux qui sont impliqués dans le développement de produits avec vous
Ici, ce que nous appelons «communication» s'applique principalement aux situations où un projet est développé par une petite équipe ou réalisé sur commande.
Pourquoi est-ce nécessaire? Le fait est que la transparence du travail entraîne une augmentation de la responsabilité de ses interprètes. Lorsque vous savez que vous devez dire quelque chose à quelqu'un (un membre de l'équipe ou un représentant de la clientèle), cela vous aide à faire plus attention à ce que vous faites. C'est pourquoi de nombreuses entreprises pratiquent de courtes réunions au cours desquelles les employés rendent compte de leur travail.
De plus, souvent un membre de l'équipe est confronté à un problème qui lui est difficile, qui peut être facilement résolu simplement en en discutant avec un client ou avec un autre membre de l'équipe. J'ai déjà perdu le compte, me rappelant les cas où j'ai vraiment laissé tomber mes mains, essayant de comprendre pourquoi ce que j'ai écrit ne fonctionne pas. Et la raison en est qu'un autre membre de l'équipe a apporté des modifications au projet qui ont interféré avec mon code. Pour comprendre cela, il suffisait de porter le problème au débat public.
Voici quelques directives pour communiquer avec les clients et les membres de l'équipe de programmeurs.
- Si vous rencontrez un problème inattendu - informez-en les membres de l'équipe ou le représentant du client.
- Informer régulièrement le client de l'avancement du projet. Dans le même temps, essayez que ces informations ne soient pas uniquement liées à des problèmes techniques.
- Informez l'équipe des changements de plan.
- Essayez d'organiser un environnement commode pour la communication, qui, par exemple, permet à n'importe quel membre de l'équipe de découvrir rapidement ce que fait quelqu'un d'autre. Vous pouvez le faire en utilisant une variété d'outils, disons - cela peut être WhatsApp, e-mail, Slack ou tout autre élément qui convient à votre situation.
En général, on peut noter que vous devez essayer de vous assurer que l'interaction entre toutes les parties intéressées est organisée de manière simple et pratique, afin que, pour ainsi dire, la «boucle de rétroaction» fonctionne sans délai. Cela aide à organiser un environnement de travail sain et productif.
Organiser un système de suivi
La surveillance dans le domaine du développement de logiciels est une question très importante. Les ordinateurs sont sujets aux plantages. Pendant le déploiement du projet, des erreurs se produisent. Les oublis des développeurs conduisent au fait que les programmes qui semblent avoir passé tous les contrôles possibles et mis en œuvre avec succès tombent avec des exceptions. C'est pourquoi le développeur doit prendre soin du système de surveillance du programme. Cela facilitera la résolution des problèmes pouvant survenir à différentes étapes du cycle de vie du produit. Les données de surveillance du programme font partie de la «boucle de rétroaction» susmentionnée. La surveillance donne au programmeur un lien avec la réalité, avec l'environnement dans lequel ses programmes fonctionnent.
Voici quelques suggestions pour contrôler le comportement des programmes:
- Enregistrez les journaux et les résultats de l'analyse automatique du code. N'hésitez pas à utiliser console.log () là où vous en avez besoin. Il vaut mieux déposer trop d'informations que trop peu. Cependant, essayez de trouver un «terrain d'entente» afin que les journaux de vos programmes ne contiennent pas de détails inutiles sur leur travail. Cela facilitera la recherche d'informations importantes dans les journaux.
- Découvrez où vont les journaux de vos applications et configurez les mécanismes qui facilitent leur utilisation. Le rôle des «mécanismes» mentionnés ci-dessus peut être n'importe quoi - de la connexion au serveur à l'aide de SSH et l'affichage des derniers événements enregistrés dans le journal, à quelque chose comme l'utilisation de la pile ELK. La chose la plus importante est de savoir où les journaux d'application sont générés par console.log () ou tout autre moyen.
- N'ignorez pas les exceptions. Bien que tout développeur devrait s'efforcer de garantir la stabilité de son application, c'est-à-dire qu'il pourrait restaurer la capacité de travail en cas d'erreur, se «débarrasser» des exceptions inattendues, simplement les «verrouiller» dans un bloc catch serait une erreur. Il serait préférable de consigner des informations sur les exceptions inattendues. Par exemple, si vous utilisez une sorte d'API pour charger des données créées par l'utilisateur (par exemple des tweets), vous devez être prêt à gérer l'erreur 404. Mais ces erreurs que vous ne traitez pas, vous devez vous connecter. J'étais dans une situation où, sans enregistrer d'informations sur des erreurs inattendues, je ne savais tout simplement pas que j'avais épuisé la limite d'appels vers un système. Cela a conduit au fait que l'accès à l'API correspondante à mon programme a été fermé.
- Vérifiez les journaux. La vérification des journaux générés par les résultats des applications peut être organisée manuellement ou en utilisant certains moyens pour leur analyse automatique. Une fois que je ne me suis pas particulièrement soucié du contrôle des journaux, j'ai résolu un petit problème dans le programme et j'ai continué à m'occuper tranquillement de mes affaires. Comme il s'est avéré plus tard, ma correction était inopérante. Depuis lors, je suis attentif à la vérification des journaux d'application après leur déploiement, ce qui me permet de vérifier l'exactitude de leur travail.
La surveillance de l'activité des applications et le suivi des indicateurs de performance peuvent prendre plusieurs formes. Dans sa forme la plus simple, cela peut générer des données sur le programme à l'aide de la commande console.log (), enregistrer ces informations dans des fichiers texte et analyser manuellement ces fichiers. La surveillance peut également être un système assez avancé, qui comprend des outils spécialisés tels que Sentry, Bugsnag et Elastic APM. L'essentiel est de choisir ce qui vous convient et de l'utiliser de manière cohérente.
Observer le projet, tirer des conclusions des résultats des observations et l'améliorer
Vous regardez, mais n'observez pas, et c'est une grande différence.
Arthur Conan Doyle, «Le scandale en Bohême»Ce qui sera discuté dans cette section peut être considéré à la fois comme une recommandation indépendante et une approche pour utiliser les autres recommandations présentées ici. Le fait est qu'il n'y a pas de formule universelle pour organiser le travail sur un produit logiciel. Différentes personnes sont impliquées dans le développement de logiciels de différentes manières, utilisent différentes méthodes de surveillance, documentent le code différemment, etc. C'est pourquoi, quelles que soient les règles de travail sur les programmes que vous avez choisis, il est important de toujours s'efforcer de faire en sorte que le projet soit suivi, que les conclusions soient tirées des résultats du suivi, et que finalement tout cela mène à des améliorations de programme.
Le suivi d'un programme implique une analyse critique de son comportement ou, disons, des indicateurs de sa performance. En observant le programme, vous établissez un lien entre ce que vous voyez et ce que vous savez sur le système, pour arriver finalement à des conclusions logiques sur ce qui se passe. Celui qui travaille seul est généralement privé de la capacité d'analyser les programmes utilisés dans les organisations (tels que les tests A / B ou les études du public cible). En conséquence, il doit collecter des indices sur la vie de son programme à partir de sources "informelles" - telles que les commentaires des utilisateurs, les rapports de problèmes dans les trackers de tâches et les journaux d'application.
. , . — , « — — ».
. , , . , UTC-. , .
, UTC. , , , 5:30 pm, 5:30 pm UTC. , . , . ? , . .
, , , — , . , , , . «5 » «2 ». , , , .
. , . , , , , , . , , .
Résumé
, , — , . ( ), , , . , , ( , ), , . , , . , , , , .
Chers lecteurs! , «-»?
