Nettoyage et optimisation du code, par où commencer?

Question

Je veux optimiser mon application frontale angularjs et nettoyer le code pour fournir une meilleure qualité de code.

J'ai pensé à introduire plus d'abstraction, puisque j'ai implémenté beaucoup de contrôleurs similaires, mais légèrement différents.

Ma question (s) sont les suivantes:

• Y at-il des techniques communes pour reconnaître le mauvais code et optimiser?
• Comment peut-on déterminer si le code est bon, mauvais ou redondant?
• Où devrait-on commencer, en essayant de fournir une meilleure qualité de code dans un projet de logiciel existant?

Answer 1

Pour répondre à vos questions:

1. Oui, il y a: en regardant le code lui-même les programmeurs expérimentés peuvent dire si le code a certaines caractéristiques ou non. Certaines métriques existent qui pourraient indiquer des signaux d'alarme en termes de qualité comme "beaucoup de points" dans les langages orientés objet (même en Javascript) qui indique un couplage proche. Voici un comprehensive list. En le regardant ou comme écrit précédemment avec l'analyse de code statique.
2. Comme d'autres l'ont indiqué ne pas optimiser ou refactoriser juste pour le bien d'avoir une base de code beau. Lorsque vous devez à nouveau toucher un code existant, par exemple ajoutez une fonctionnalité ou corrigez un bogue puis commencez à rechercher les redondances de code et de nombreux autres signaux qui pourraient indiquer de refactoriser le code. Martin Fowler a écrit un excellent book à ce sujet avec des exemples étape par étape, qui est un incontournable pour chaque développeur. Un bon point de départ est également le site de Misko. Il parle de testabilité mais le "bon" code est bien testable.

Ce qui est vraiment important avant de refactoriser, c'est d'avoir une solide base de test automatisée sur laquelle s'appuyer. Si ce n'est pas le cas, ajoutez des tests et allez très lentement pour vous assurer de ne pas casser les fonctionnalités existantes.

Le sujet est vraiment énorme et impossible à traiter dans un post ici, mais je pense que c'est l'un des plus importants qui fait un programmeur expérimenté.

Answer 2

Si un code est bon ou mauvais est votre propre opinion.

Pour rendre le code une meilleure apparence et plus efficace que je ferais quelque chose comme ceci:

• Ne pas faire les lignes longues.
• Utilisez des variables qui ont du sens.
• Utilisez les onglets et entrez-le lorsque c'est trop sale.

Il ya beaucoup plus de choses à faire pour nettoyer votre code, mais ce ne sont là que quelques exemples.

Answer 3

Si le code fonctionne - ne touchez pas :)

Ensuite, lorsque vous travaillez sur des corrections de bugs ou de nouvelles fonctionnalités \ modifications - voir si vous pouvez également améliorer progressivement des morceaux de code que vous travaillez. Plus vous travaillerez avec le code, mieux vous comprendrez l'image globale que vous devriez avoir et les possibilités d'amélioration et d'optimisation deviendront plus évidentes. (vous devriez aussi continuer à apprendre d'autres sources - livres, internet, autres bases de code)

Il existe maintenant une solution magique «taille unique» :) mais oui, vous pouvez commencer avec des changements simples de style comme suggéré dans l'autre réponse .

Answer 4

Le processus auquel vous faites référence est communément appelé Refactoring. Il existe un certain nombre de techniques standard pour améliorer le code; Le livre "Refactoring" de Martin Fowler a une liste, avec des exemples.

Beaucoup d'IDE populaires ont des outils de refactoring intégrés.

L'un des processus du développement agile est connu sous le nom de "red/green/refactor". Rouge signifie que votre code ne réussit pas ses tests unitaires; le vert signifie qu'il passe (c'est-à-dire qu'il fait ce qu'il est censé faire), et «refactoriser» signifie que vous le rendez élégant, entretenu et propre. Parce que vous avez un test unitaire, vous savez que le refactoring ne casse pas le code.

Par où commencer est une question difficile - je recommande généralement de refactoring lorsque vous corrigez des bugs. Vous pouvez aussi écrire un test unitaire pour exposer le bogue, et ranger le code tout en corrigeant le bogue. Parce que ce module a un bug, il est susceptible d'être à haut risque, donc vous devriez améliorer la qualité du code.