JH Rainwater "Comment faire paître les chats": de l'autre côté du développement

Nous continuons de partager des extraits du manuel pour ceux qui se préparent à diriger l'équipe de développement. Dans la partie précédente, nous avons parlé de tout ce qui était étranger, qui attend le leader technique dans le nouveau poste, maintenant nous revenons à des choses familières et familières - la programmation elle-même. Ici, le développeur d'hier peut se sentir dans son élément, mais il n'a pas à se détendre - le domaine de responsabilité s'agrandit et évolue. Sous cat, nous présentons un bref aperçu de toutes les nouvelles responsabilités et des conseils d'adaptation que Rainwater apporte dans son livre.

La différence fondamentale réside dans deux nuances. Premièrement, le plomb entre beaucoup plus tôt dans le processus et ne s'arrête pas avant la fin victorieuse. Deuxièmement, alors que le développeur se concentre sur l'étroite tâche qui lui est assignée, son patron revoit le produit dans son intégralité, sans oublier de rentrer dans les détails lorsque la situation l'exige. Allons de pair avec l'auteur afin d'essayer de décrire le rôle du chef d'équipe à chaque étape de la création de l'application.

Définition des exigences et des spécifications

Un bon techlide commence à fonctionner avec le produit même lorsqu'il est à l'état périnatal - c'est-à-dire sous la forme d'une idée générale, d'une demande ou d'une liste de fonctions. Cependant, ici, vous devez clarifier immédiatement: Rainwater croit fermement que le développeur ne devrait pas être engagé dans le travail d'un agent de commercialisation ou d'un chef de produit - ou plutôt, il devrait éviter ce scénario de toutes ses forces. Non pas qu'il était impossible ou répréhensible pour le «technicien» de comprendre les réalités du marché et les exigences commerciales, mais combiner ces deux rôles est très difficile. Entre autres choses, il y a un plus grand risque que le développeur interne gagne et que les caractéristiques du produit soient adaptées aux intérêts de l'équipe de programmeurs plutôt qu'à celle de l'utilisateur final. Il est beaucoup plus facile et plus sûr de travailler lorsque la vision générale du produit en termes de fonctionnalités est déjà préparée et testée pour la viabilité par des personnes compétentes.

Pour le mélange des deux rôles, les développeurs qui, dans notre classification, appartiennent souvent à la race des cow-boys préconisent souvent - ils aspirent à des temps de "garage" où de petites équipes fabriquaient le produit entier de et vers et il n'y avait pas besoin d'interaction externe. L'auteur est pressé de dissiper toutes les illusions sur ce point: dans les conditions modernes, l'interaction entre les groupes techniques et non techniques devrait se produire régulièrement, tout au long du cycle de vie de l'application. Les premières réunions ont lieu pour la préparation conjointe d'un cahier des charges. Le responsable du développement (ou l'un des principaux développeurs) se familiarise avec la description du produit, exclut tout ce qui lui semble injustifié ou irréaliste d'un point de vue technique et reprend le plan final afin de le traduire dans le langage des technologies. Ensuite, les groupes se réunissent de temps en temps pour «vérifier l'horloge» et s'assurer que la mise en œuvre ne s'écarte pas trop du plan d'origine.

La fréquence recommandée de ces réunions est d'environ une fois par semaine, bien que, bien sûr, vous deviez ajuster le rythme général de développement et les caractéristiques de l'organisation des processus pour une entreprise particulière.

Des réunions régulières seront également nécessaires pour une autre raison - les tentatives de s'écarter du cours d'origine ne proviendront probablement pas uniquement du développement. La plupart des applications, afin de rester compétitives, sont en constante évolution avec des outils et des capacités supplémentaires. Par conséquent, le processus d'examen, d'évaluation et d'abandon des idées peut être répété à l'infini, uniquement à une échelle plus petite que pour les spécifications principales. Il est extrêmement important pour Tehlid de se tenir au courant des plans de développement de produits - cela lui donne non seulement une marge de manœuvre d'un point de vue organisationnel (répartition des responsabilités, détermination des termes), mais permet également de calculer à l'avance les conséquences pour le système dans son ensemble, son bien-être et durabilité.

Avant d'accepter de prendre une nouvelle fonction au travail, vous devez vous poser un certain nombre de questions:

• Quel impact le changement proposé aura-t-il sur l'architecture du système à court et à long terme?
• Comment le changement proposé affectera-t-il l'infrastructure de réseau dans laquelle il aura lieu?
• Comment le changement proposé affectera-t-il la capacité de l'utilisateur à interagir efficacement et de manière productive avec ce produit?
• Quel impact le changement proposé aura-t-il sur les actions des collaborateurs qui doivent travailler en étroite collaboration avec lui - mettre en œuvre, accompagner?

Ces réflexions permettront d'identifier les écueils et de définir des orientations générales pour le dialogue avec d'autres groupes.

La conception

Lorsque les exigences sont approuvées et bénies par tous les participants au processus, le moment est venu pour ce que Rainwater appelle la coordination des décisions architecturales et de conception. En d'autres termes, le guide technique doit décrire le système qui exécutera les fonctions spécifiées au stade des spécifications et réfléchir aux composants responsables de procédures spécifiques. Il est essentiel d'agir dans cet ordre:

L'architecture d'abord, puis les composants.

L'auteur le souligne à plusieurs reprises, car de nombreux développeurs qui ne sont pas familiers avec l'art de la conception de produits tombent dans ce piège. Il semble logique de prendre une liste d'exigences, de prescrire les composants nécessaires pour chacun et de considérer le produit comme une simple combinaison d'entre eux. Mais en réalité, cette approche mécaniste donne naissance à des monstres rigides et organisés de manière aléatoire qui sucent tous les jus des développeurs impliqués dans le soutien du projet. Pour éviter cela, il faut aller dans l'autre sens, du tout au particulier. Vous avez déjà une vision fonctionnelle commune du produit avec une perspective de développement - vous devez le «refléter» dans votre vision technique générale avec une perspective de développement, c'est-à-dire l'architecture.

Architecture du bâtiment

Si l'on recourt à une métaphore galvaudée, l'architecture est le squelette du produit, sur lequel se construit alors la chair des décisions privées sur la mise en œuvre des procédures. Nous ravivons un peu cette métaphore, en ajoutant une précision: le squelette doit être aiguisé pour faire pousser de nouveaux membres. Les deux exigences principales de l'architecture sont une organisation logique claire des composants et une flexibilité qui en ajoutera de nouveaux au fur et à mesure que le projet se développera.

Peut-être cette étape du développement peut-elle être considérée comme la plus responsable - les experts disent que c'est précisément la négligence des problèmes d'architecture qui conduit le plus souvent à l'effondrement des projets. Parmi les causes courantes d'échec, elles citent:

• Manque de réflexion, organisation bâclée (ou son absence totale).
• Rigidité excessive et simplicité du système, empêchant son expansion en fonction des besoins commerciaux.
• Interconnectivité excessive des composants, manque de flexibilité dans la configuration.
• Complexité excessive aux niveaux supérieurs, rendant difficile la modification des composants de base.

En conséquence, la tâche de construire l'architecture doit être abordée avec le plus grand sérieux, sans ménager les ressources. N'oubliez pas que vous posez les fondations avec lesquelles vous devez travailler jusqu'à la fin - il doit résister à tous les changements qui attendent le projet à l'avenir. Ce processus est largement créatif et visionnaire, mais les méthodes standard de structuration sont utiles pour équilibrer le système. Par exemple, dessinez un diagramme avec un ensemble complet de connexions ou même implémentez une disposition simple (un ensemble de composants de bas niveau avec des stubs et des valeurs de retour) pour vous assurer que l'architecture fonctionne dans une projection verticale. Ce dernier est très souhaitable à faire avant de commencer le développement de véritables composants à part entière - éliminer les bugs avec des éléments "jouets" est beaucoup plus facile et plus indolore.

À la fin du travail à ce stade, vous devriez être prêt à répondre aux questions suivantes:

• Comment l'utilisateur interagira-t-il avec le système?
• Quels composants doivent être assemblés pour assurer le fonctionnement du système?
• Quel sera le mécanisme d'interaction des composants qui assure le fonctionnement du système?
• Quelles technologies sont les mieux adaptées pour créer cette application?
• Comment est-il censé livrer le système au client?

Planification des composants

Lorsque le cadre général est développé, il est temps de fouiller en particulier et d'implanter les composants actuellement pertinents dans la structure organique. La principale difficulté ici est de résister à la mesure nécessaire de connectivité. D'une part, les composants ne doivent pas être considérés comme des conteneurs strictement isolés pour des ensembles spécifiques d'opérations - plutôt comme un système d'organes, chacun communiquant avec les autres, mais remplissant ses fonctions. Dans le même temps, une forte interdépendance entre les régions doit être évitée, de sorte que la modification d'un composant entraînera toute une chaîne de changements, voire de dysfonctionnements, à travers le système.

La pile technologique a été décrite à la dernière étape, vous devez maintenant la comprendre en détail. Dans le choix de la langue, des bibliothèques, et plus encore, il est logique d'être guidé non seulement par des motifs professionnels, mais aussi strictement pragmatiques. Disons, aurez-vous suffisamment de personnel compétent pour prendre en charge des systèmes construits sur la base de technologies avancées, rares ou complexes? Et vice versa, si vous privilégiez les technologies plus anciennes, à quel point est-ce prometteur - continueront-elles de fonctionner tout au long du cycle de vie, des problèmes de compatibilité commenceront-ils à apparaître? Tous les problèmes liés aux solutions matérielles, à la création, à la configuration et à la maintenance de l'infrastructure doivent être considérés avec le même soin.

Développement et contrôle qualité

Ainsi, la planification est enfin terminée et le projet se met en route - le développement proprement dit de l'application commence. Le rôle du leader technique dans ce processus consiste principalement dans le suivi, afin que tout se déroule conformément aux termes et normes; il est directement impliqué dans la création de code, en règle générale, uniquement dans des cas de force majeure. Pour l'essentiel, le chef exerce les fonctions d'une police du code, c'est-à-dire qu'il effectue régulièrement des examens critiques du code pour s'assurer qu'ils ne contredisent pas le cadre architectural et les principes de base de la programmation.

Lors des inspections, un responsable technique peut rencontrer différents types d'erreurs. L'eau de pluie concentre le lecteur sur deux variétés:

• Violation des normes . Cela comprend le style, la dénomination, les commentaires - en général, tout ce qui aide un tiers à comprendre ce qui se passe dans le code, ainsi que la négligence dans l'esprit de plusieurs points de sortie ou les opérateurs GoTo détestés. Il est nécessaire de s'assurer que tous les participants au processus de développement parlent le même langage - cela rend le code transparent et vous permet de démêler rapidement les mouvements erronés. Les noms des paramètres et des variables doivent clairement indiquer leur contenu, les commentaires doivent aider à retracer le code des pensées d'un développeur, justifier ses décisions. Soit dit en passant, si quelqu'un de l'équipe refuse obstinément de commenter le code, cela vaut la peine de se demander pourquoi. Souvent, ce n'est que de la paresse ou une particularité de penser, mais dans certains cas, cela peut s'avérer être un symptôme que l'employé lui-même ne comprend pas vraiment ce qu'il fait - confus ou simplement copier des morceaux du code de quelqu'un d'autre pour une bonne raison. Il est également nécessaire de surveiller attentivement ceux qui négligent régulièrement la gestion des erreurs: l'incapacité à identifier les sources de bogues est un grave défaut pour le développeur.
• Une faible connectivité et une forte interdépendance sont deux zones de perturbation qui peuvent être considérées ensemble, car la présence de l'une implique la présence de l'autre. Ici, en fait, tout dépend du degré de ramification et de son type. Avec un degré élevé de ramification en termes de production, le fonctionnement de la procédure implique l'accès à de nombreuses autres procédures, ce qui, bien sûr, n'est pas souhaitable. La ramification à l'entrée, au contraire, a un effet positif, car elle indique une encapsulation stricte. Si vous avez des doutes lors de l'analyse du code de ces paramètres, il serait bon de dresser un schéma fonctionnel avec une hiérarchie d'objets marquée. Il révèle immédiatement tout ce que vous devez savoir: est-il possible de retracer le pedigree de l'objet, y a-t-il une logique dans la disposition des flèches, ou tout semble-t-il désordonné.

Si la police du code a révélé des violations dans ces domaines et dans d'autres, la procédure d'arrestation ressemble à ceci: le code est renvoyé au développeur avec les commentaires nécessaires, le travail sur le composant correspondant est suspendu jusqu'à ce que les défauts soient corrigés. Il est hautement souhaitable que le développeur gère cela lui-même, bien qu'avec des conseils - si vous faites tout pour lui, la composante de mentorat de l'inspection du code est perdue.

Ne remettez pas à plus tard la révision. Tout d'abord, il peut fortement revenir à l'avenir et nécessiter beaucoup plus de ressources pour résoudre toute la boule de neige des problèmes. Deuxièmement, la théorie des fenêtres cassées fonctionne également en programmation - le code désordonné et confus génère un code encore plus désordonné et confus, simplement parce qu'il semble valide.

Enfin, en parlant de contrôle de la qualité, on ne peut qu'évoquer le problème du fameux facteur humain. Rainwater recommande au gestionnaire de prendre une position intermédiaire. Une certaine résistance aux interférences avec le code est naturelle et bénigne. Une volonté complète de suivre les instructions de quelqu'un d'autre et d'accepter l'opinion de quelqu'un d'autre devrait même vous alerter - cela signifie souvent que le développeur, en fait, ne se soucie pas de ce qu'il publie. Mais d'un autre côté, l'incapacité à percevoir une critique saine entrave à la fois la croissance professionnelle et le travail d'équipe. En conséquence, la technlide devra grossir la peau et ne pas avoir peur d'insister d'elle-même, sans réagir négativement à son cœur.

Test

Ici, il est important que le leader garde à l'esprit deux règles de base: les tests doivent être effectués et l'organisation de sa conduite est de votre responsabilité. Si l'entreprise dispose d'un service de test naturellement impliqué dans les processus, cela ne posera aucun problème. Sinon, vous devrez allouer une ressource de vos propres réserves à ce sujet.
Dans le deuxième scénario, selon l'auteur, il y a certains avantages: le test est une compétence utile pour le développeur. Il est particulièrement utile d'attirer de nouveaux arrivants à ces tâches, afin qu'ils acquièrent rapidement des qualifications. Au début, vous pouvez entreprendre des tâches de test jusqu'à la moitié de leur temps de travail.

Sinon, afin d'assurer une bonne qualité d'inspection, il est nécessaire de s'assurer que le produit ne cuit pas tout le temps dans le même groupe - idéalement, il doit être testé «sur le côté». Si une entreprise a plusieurs équipes de développement, il peut être judicieux de s'entendre avec d'autres dirigeants pour créer un groupe mixte.