Le goulot d'étranglement dans le développement de programmes est la clarté du code source pour les programmeurs. Lorsque vous souhaitez maintenir, ajouter des fonctionnalités et accélérer le code que d'autres membres ont écrit jusqu'à présent, le plus gros goulot d'étranglement est la clarté de votre code source existant.
Si elle n'est pas facile à comprendre, la validité de la conception ne peut être ni vérifiée ni testée. Pour déterminer quels sont les critères quand une routine existante peut être remplacée, comment la précision des résultats de calcul s'améliorera et quels résultats peuvent être acceptés pour accélérer, cette routine Il est facile de comprendre ce qu'ils font (ce qu'ils sont censés faire). À moins que cela ne soit respecté, le code existant aura du mal à écrire une seule ligne pour déchiffrer ce qu'il voulait faire.
・ Vous pouvez demander à créer un test. -Si vous avez besoin d'accélérer le code, vous pouvez demander à un tiers de développer une version rapide de la fonction.
Plus vous êtes occupé à écrire du code, plus il est facile d'écrire du code. Si le code est facile à comprendre, vous pouvez obtenir l'aide d'autres personnes.
-Plus le nombre d'arguments de fonction est petit, mieux c'est. -Il n'y a pas de prérequis pour que les arguments soient utilisés correctement (il y en a peu). -Il n'y a pas de cas selon l'état de l'argument. -Passer un pointeur (*) utilisé uniquement lors du passage de quelque chose qui ne peut pas être réalisé en passant par référence (&) -Utiliser [] lors du passage d'un tableau comme argument.
double sum(double data[]);//Recommandation
double sum(double *data);//Non recommandé
-L'argument formel de la fonction doit être décrit de manière à pouvoir facilement distinguer les entrées et les sorties.
copyObj(const dataType &src, dataType &dst);//Recommandation
copyObj(dataType *data1, dataType *data2);//Non recommandé
Ce que vous voulez réaliser, c'est quelque chose qui aurait dû être communiqué dans votre travail, mais qui n'a pas été entièrement communiqué. Dans les commentaires du code source, décrivez les informations nécessaires pour connaître le but et l'intention du développement, qui ne peuvent être compris que par la description dans le code source. Décrivez les informations de l'article décrivant l'algorithme utilisé, les informations sur les spécifications de développement du département et les informations essentielles à la compréhension du programme. (Cependant, il y a aussi des problèmes tels que d'anciens commentaires laissés pour compte et de mensonge.) La partie importante de la compréhension du code doit être écrite pour éviter les malentendus. Exemple: Définition de la transformée de Fourier Il existe plusieurs définitions de la transformée de Fourier (intégration de Fourier), qui est souvent utilisée en mathématiques. Comment définir +/- du signe d'une fonction exponentielle imaginaire et le coefficient de standardisation d'intégration par transformation de Fourier et transformation de Fourier inverse. (Il existe deux styles dans lesquels un coefficient est égal à 1 et le style est distribué de la même manière aux deux). Par conséquent, il existe six définitions de la transformée de Fourier. Par conséquent, il est important de clarifier la définition de l'intégrale de Fourier que vous utilisez actuellement et d'effectuer un traitement cohérent et cohérent. (Comme il y a peu de programmeurs qui utilisent le code de la transformée de Fourier, c'est devenu un exemple que je ne comprends pas ce que je dis. (M_ _) m) Exemple: définition de l'écart type Il est nécessaire de confirmer si la valeur appelée «écart type» est divisée par le nombre d'échantillons n ou n-1, quelle valeur est requise et quelle valeur est implémentée. Je vais. Lorsque le nombre d'échantillons est extrêmement petit, par exemple un chiffre, on ne peut ignorer que cette erreur peut conduire à une erreur de jugement. Cela peut conduire à accepter ce qui aurait dû être exclu comme un défaut comme un bon produit. Demandez à quelqu'un qui connaît les statistiques. Exemple: Le mot «déduction» a trop de significations différentes. Vous pouvez le confirmer en lisant la section Deduction de Wikipedia. Heureusement, je n'ai jamais construit un système dans un tel domaine, mais dans un tel domaine, il faut être conscient de ce qu'il faut soustraire et bien comprendre. Il s'avère que la compréhension de ce que vous essayez de réaliser et de la manière dont vous écrivez le code source est essentielle pour développer votre programme.
Si la personne qui a écrit le code est toujours là, faites une entrevue. Si vous ajoutez un commentaire de documentation pour la fonction et que vous ne comprenez pas ce que cela signifie, écoutez autant que vous le pouvez. À ce moment-là, essayez de garder le respect de l'autre personne. La personne qui a écrit le code avant a probablement travaillé dur pour écrire un programme qui fonctionnerait de toute façon dans une situation chargée. Qu'il s'agisse d'un code en retrait inhabituellement profond ou d'une fonction de plus de 1000 lignes, il aurait fallu beaucoup de travail pour écrire un programme qui fonctionnerait de toute façon pour le processus souhaité. Des entretiens peuvent être menés Si vous êtes dans une situation privilégiée, faites un entretien. Cela vaut la peine d'écouter et de confirmer, même s'il s'agit d'une reconfirmation que vous avez déjà lu et compris le code.
Si vous ne savez pas ce que fait le code et comment, écrivez un programme qui appelle et exécute simplement la fonction. Même dans le cas d'une bibliothèque open source, il peut ne pas être possible de dire simplement en regardant le code ce que la fonction de bibliothèque renvoie réellement et comment l'utiliser. Ainsi, même dans le cas d'un code hérité, il est possible d'aider à la compréhension en adoptant une telle approche.
Addendum: ce qui devient clair en déplaçant un morceau de code Si vous essayez de déplacer un morceau de code, vous pouvez obtenir une erreur avec la combinaison d'arguments. Cette connaissance est également importante. Il s'avère que la combinaison d'arguments produite par l'appelant doit être vérifiée pour voir si elle provoque une telle erreur.
Même si vous ne connaissez pas la partie pertinente du code hérité, vous pouvez le faire si le programme sait quoi faire. Expérimentez avec quel type d'entrée de données, ce qu'il faut traiter et quel type de résultat doit être produit, y compris le travail manuel. Cela vous donnera une meilleure compréhension de ce que vous devez développer.
Je pense qu'il peut être préférable d'expérimenter différents langages et bibliothèques pour comprendre ce qu'il faut développer. Plutôt qu'un système automatisé, efficace et astucieux qui n'a pas été validé (ce qui devrait probablement fonctionner), nous expérimenterons une bibliothèque bien caractérisée, même avec la saisie manuelle des données. Essayer. Si vous savez quoi faire, essayez ces techniques pour avoir une meilleure idée de ce que vous faites et du code source. J'utilise beaucoup OpenCV, donc j'utilise la liaison python d'OpenCV comme import cv2 depuis Python. En réécrivant le fragment de code à l'aide d'OpenCV en python et en l'exploitant, cela aide à en comprendre le sens. Expérimenter avec différents langages et bibliothèques peut vous aider à comprendre le code que vous recherchez.
Donnez la priorité à la clarté. En atteignant la clarté, ce que vous voulez réaliser et les méthodes que vous pouvez choisir pour le faire aideront la personne prenant en charge la maintenance à comprendre. En conséquence, une réécriture efficace est possible et la quantité de calcul peut être réduite à une fraction en utilisant des fonctionnalités uniques à la cible de calcul.
Quoi qu'il en soit, donnons la priorité à la clarté du programme. La compréhensibilité du programme facilite le développement du programme et le rend plus efficace.
Utilisez assert () pour vérifier les valeurs d'entrée et de retour de la fonction. Non seulement cela fournit une vérification à l'exécution du programme en mode débogage, mais cela donne également au lecteur de code source un indice sur les données attendues. .. Si vous écrivez assert (img.channels () == 1), cela signifie que vous supposez une image en échelle de gris au lieu d'une image en couleur.
Dans le cas du type vectoriel, la méthode d'ajout d'éléments et la méthode pour déterminer si un élément est le dernier sont standardisées, et tout le monde peut le comprendre de la même manière. Cependant, lors de l'implémentation à l'aide de pointeurs, le dernier élément peut avoir une valeur spécifique pour déterminer qu'il s'agit du dernier élément. La personne qui a écrit le code sait quelle est la valeur particulière pour indiquer qu'il s'agit du dernier élément, mais la personne qui lit le code pour la première fois ne connaît pas la valeur particulière. (Remarque: je ne dis pas qu'il est mauvais d'utiliser des pointeurs, mais je déplore que le côté qui utilise la structure de données ait une interface qui ne peut être utilisée qu'avec des opérations de pointeur nues. Je ne veux pas que le code incrémenté soit dispersé autour du code source et non encapsulé.)
Si vous écrivez en utilisant le type std :: vector <> et sa méthode, vous pouvez voir ce que vous essayez de faire en un coup d'œil. Lorsqu'une fonction équivalente à celle-ci est implémentée par une implémentation unique et qu'un nom de fonction unique est utilisé, une bonne compréhension de la fonction entraîne des coûts inutiles à comprendre. (Si vous utilisez simplement la méthode STL, le nombre d'éléments à tester unitaire est considérablement réduit. Pour ceux qui utilisent la structure de données d'origine pour "l'efficacité", l'effort requis pour le développement et le développeur C'est dommage que beaucoup de gens n'aient pas remarqué que cela nuisait à l'efficacité du développement.)
・ C = a> b? A: b; C = std :: max (a, b) est plus facile à comprendre que. ・ C = a> b? A --b: 0; C = std :: max (a-b, 0); est plus facile à comprendre que.
if( (a < x) && (x < b)){} Est mieux if( (x > a) && (x < b)){} C'est plus facile pour moi de comprendre que (peut-être parce que je peux imaginer une ligne droite numérique).
Les expressions qui incluent le déni ont tendance à être difficiles à comprendre, alors essayez de ne pas utiliser le déni à moins qu'il ne soit plus facile à comprendre.
Il existe de nombreuses façons d'accélérer le développement du programme si la structure globale du programme, les rôles des modules individuels et la fonctionnalité de chaque fonction sont bien compris. Il existe de nombreuses façons d'améliorer la vitesse d'exécution, tant que les spécifications sont claires. L'article sur le cas d'échec de développement d'un système à grande échelle indique qu'il n'a pas été possible de fixer une spécification suffisamment claire pour le développement.
Résumé: Un codage facile à comprendre accélère le développement du programme.
Informations de référence ["Méthode de programmation"](http://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F% E3% 83% B3% E3% 82% B0% E4% BD% 9C% E6% B3% 95-% E3% 83% 96% E3% 83% A9% E3% 82% A4% E3% 82% A2% E3 % 83% B3-% E3% 82% AB% E3% 83% BC% E3% 83% 8B% E3% 83% 8F% E3% 83% B3 / dp / 4756136494) Chapitre 1 Style recommandé aux collègues S'il vous plaît. Il déclare qu'il ne suffit pas d'écrire du code grammaticalement correct et que la cohérence, les expressions idiomatiques, etc. sont nécessaires à la compréhensibilité.
Recommended Posts