Basé sur ce que j'ai enseigné et appris jusqu'à présent J'ai essayé de résumer le contenu que j'étais content (ou aurais dû faire) de la standardisation de l'équipe.
J'ai écrit quelques règles générales sur les règles nécessaires pour constituer l'équipe. J'espère que ceux qui seront des dirigeants et des membres penseront que cela peut être utilisé. De plus, si vous avez quelque chose comme «Je faisais quelque chose comme ça», j'aimerais avoir de vos nouvelles.
Les documents de conception sont susceptibles d'être exposés au monde extérieur, assurez-vous donc d'éliminer le flou en termes d'apparence. De plus, en supposant que vous ayez créé un modèle et que vous l'ayez créé à partir de celui-ci, Si vous pensez que le modèle ne correspond pas à votre projet, vous devez également le revoir régulièrement.
Les détails sont les suivants.
Si le contenu n'est pas unifié entre les documents de conception, il sera directement lié à la difficulté de lecture.
Cependant, si les règles ont tendance à être fixes, il y aura un traitement qui ne peut pas être exprimé dans le document de conception actuel. Un certain degré de polyvalence est requis.
Comme solution, il est efficace de formater le traitement répétitif. En général, formatez les parties et processus suivants liés à l'interface. ・ Accès à la base de données ・ Lecture / écriture de fichiers ・ Appel API ·boucle · Branche
De plus, voici une liste de contenus qui devraient être unifiés, ce qui est souvent oublié. C'est bien, mais je pense que les germes du conflit au sein de l'équipe viennent de cet endroit. .. ..
| Contenu | Exemple |
|---|---|
| Description de la même signification | ・ S'inscrire dans DB ・ Insérez 〇〇 sur la table ・ Inscrivez-vous 〇〇 dans le tableau ⇒ Je pense que le fond est le meilleur en termes d'écriture aussi concrètement que possible et plus proche du document de conception. |
| Mots à usage général | Méthodes de classe DAO et Util"API"Appelé uniformément ⇒Parce qu'il y a une possibilité de discordance de reconnaissance, unissons-nous s'il y a un problème. |
| Nom de classe / nom de méthode | Noms japonais et anglais mixtes ex) Nom japonais:Inscription des informations des membres nom anglais:registerCustomerInfo ⇒ Si ce n'est pas unifié, le refactoring ne sera pas possible. .. .. |
Considérez les caractéristiques de la langue que vous utilisez et pensez à la division des composants (dans quelle unité la classe est créée). Par exemple, Java est basé sur l'orientation de l'objet.
L'idée de base de l'orientation objet est l'encapsulation, l'héritage et le polymorphisme. En le comparant à une chose (classe) dans le monde réel, nous imaginerons quel type d'informations il possède (propriété) et quel type de comportement (méthode) il fera, et le diviserons.
Cependant, les programmes que vous créez réellement sont tout ce qui ne peut pas être comparé aux objets du monde réel. Par exemple, si la majeure partie du traitement consiste à traiter les données reçues et à les enregistrer dans la base de données, seules des variantes telles qu'une coopération externe sont ajoutées. Je pense que je suis désespéré, "N'est-ce pas vraiment le cas?"
Par conséquent, concentrons-nous une fois sur les données. Les données sont stockées dans une table et récupérées en cas de besoin. La table est normalisée et a une conception logique et physique.
** Il est préférable de créer une classe autour de cette table divisée logiquement. ** **
Le but est de le considérer comme une fenêtre (chose) spécialisée dans la gestion de ces données. Cet exemple ne s'applique pas dans tous les cas, Je pense que le placement correct des fonctions permet le placement actif des méthodes.
Le retrait est le squelette de la spécification, mais je pense que vous pouvez l'aimer dans une certaine mesure.
Cependant, s'il est plus profond que l'exemple de retrait ci-dessous, il est recommandé de revoir le processus en raison de la lisibilité (ou d'autres problèmes). Aussi, en stipulant que les branches et les boucles doivent être abaissées. Ce sera cohérent avec le programme.
Exemple de retrait
1.
___1).
______(1).
_________➀.
____________a.
_______________a).
__________________(a).
(sujet) Lorsqu'un nouvel employé arrive, demandez-lui d'écrire le processus à partir du numéro d'article principal, En examinant chaque numéro d'article, vous pouvez rendre les titres uniformes dans le même numéro d'article que la retouche.
TODO Décidons où quitter le TODO, Si cela n'est pas décidé en premier, les membres peuvent oublier de quitter TODO. Aussi, s'il est possible de résumer le contenu de TODO, c'est aussi une bonne idée de numéroter et de gérer le code pour TODO. Cela présente l'avantage de pouvoir approcher mécaniquement TODO de la même cause.
** Déchiffrez le code que j'ai écrit pendant des décennies ... **
Je ne me souviens certainement pas de ça w Si vous ne vous en souvenez pas, créons un mécanisme dont vous n'avez pas à vous souvenir!
Lire les codes lisibles et les modèles de conception, Créez des règles qui imposent des implémentations intelligentes pour chaque langage (hautement lisibles, résistantes au changement et le comportement de chaque fonction peut être déduit).
Voici un exemple typique.
Je me souviens avoir été signalé jusqu'à ce que j'entende une pieuvre dire: «Le nom est important». .. .. Transformons le contenu de base en règles!
** Plutôt que de s'effondrer sans décider, si vous l'unifiez, vous pouvez vous débrouiller avec le refactoring! ** **
Lorsque vous donnez des noms de méthode, de classe et de variable, le contenu que vous utiliserez probablement est défini comme une convention.
ex) S'inscrire: s'inscrire Mise à jour: mise à jour Inscription: insérer
Je n'ai pas de traits d'union ou pas.
ex) Constante: cas de serpent (et tout en majuscules) ⇒ MAX_RANGE Nom de variable / nom de méthode / nom de classe: cas de chameau ⇒ getUserInfo URL / nom de fichier: cas de la colonne vertébrale ⇒ user-info
Je pense que les Japonais peuvent adopter la méthode Hebon pour éviter les erreurs typographiques et les abus. Dans les deux cas, c'est bien, mais il est embarrassant de trouver une faute de frappe à la Hebon.
Il existe des outils WEB, alors utilisons-les efficacement.
** Une fois écrit, n'écrivez plus (faites-en une fonction!) ** C'est peut-être le contenu.
Les éditeurs de développement tels qu'eclipse ont la capacité de fonctionner (refactor). Vous voudrez peut-être étudier la fonctionnalité de l'outil que vous utilisez dans une certaine mesure.
Demandez-leur de déterminer si le processus est spécifique à une méthode ou à une classe (ou spécifique à une application). En créant d'abord la classe Util et la classe constante, je pense que vous pouvez aborder la marge.
En outre, même s'il s'agit d'une fonction unique à ce processus, vous pouvez lui demander de fonctionner au niveau de retrait grand / moyen de la conception détaillée. (La révision du code spaghetti est très difficile.)
Je voudrais coller entièrement le retrait de niveau d'élément grand et moyen de la conception détaillée.
Cependant, ce qui est important, c'est la pertinence par rapport à la conception détaillée. Soulignez les commentaires inutiles lors de l'examen.
La phase est si importante qu'il y a aussi le mot test en premier. De plus, si le point de vue fluctue, il devient difficile de revoir l'exhaustivité.
fondamentalement, ** Boîte blanche pour la partie de code que j'ai écrite ** ** Boîte noire pour appeler les composants ** Sera la base de la réflexion en fonction de la phase telle que UT et IT.
S'il y a de la capacité disponible, créez des données de test couvrant toutes les variations de données pour chaque table, C'est également un moyen efficace de demander à un expert en affaires de créer les données.
Faisons une feuille d'autocontrôle. Le simple fait de mettre les règles que vous avez définies cette fois sur la feuille de contrôle vous évitera beaucoup de retouches.
** Le contenu de l'indication d'examen est presque le même. ** ** De plus, les erreurs commises par quelqu'un le seront par quelqu'un d'autre. Assurez-vous de partager le tout et de prendre quelques mesures (outils, etc.).
Même si l'indication n'existe que dans un processus spécifique, si la reprise est importante, vous pouvez envisager de l'écrire sur la feuille d'autocontrôle.
Avant de vous lancer dans le vrai travail, débarrassez-vous des tâches que vous avez oubliées ou simplement reportées.
** En cherchant où il se trouvait, je n'ai pas compris pourquoi je voulais le matériel. .. .. ** **
Cela n'est-il pas arrivé? (J'étais w) Créez une collection de liens vers votre framework et la documentation de votre bibliothèque.
C'est également une bonne idée de coder en couleur le contenu minimum que vous devriez lire pour les nouveaux arrivants. (Je suis sûr que ce sera utile plus tard.)
Identifions dans MECE et séries chronologiques, et créons un dossier qui sera utilisé à l'avenir à l'avance. (C'est difficile à faire plus tard.)
.
├─00_Commun
│ ├─
│ │
│ └─
├─01_Conception détaillée
├─02_la mise en oeuvre
├─03_UT
└─04_IT
** Je pense que c'est la chose la plus importante que j'ai introduite jusqu'à présent. ** **
Si vous avez un bel outil, utilisez-le moyennant des frais! Pour rappel, ne créez pas plusieurs outils de partage d'informations. Envisagez un système capable de gérer de manière centralisée les informations, quelle que soit la source des informations.
Nous vous recommandons également de donner à votre contenu partagé un titre descriptif.
Pour que les membres atteignent leur plein potentiel, ils doivent montrer des objectifs clairs et le degré de discrétion qu'ils doivent faire. Par conséquent, la création de règles pour déterminer le pouvoir discrétionnaire d'une tâche est un processus très important.
En outre, les erreurs commises par les membres sont dues en premier lieu au mécanisme. Le chef qui n'a pas établi une telle règle est responsable.
C'est pourquoi les règles sont incroyablement importantes.
Cela semble très difficile à formuler, mais l'idée est simple. Assurez-vous que les règles vous donnent: ** · Soit simple ** ** ・ Être quantitatif **
Si vous gardez cela à l'esprit, vous ne serez pas loin de la route!
Recommended Posts