Steve McConnell citations célèbres

Il est déjà assez difficile de trouver une erreur dans votre code lorsque vous le recherchez; c'est encore plus difficile lorsque vous avez supposé que votre code est sans erreur.

Le travail du manager moyen nécessite un changement d'orientation toutes les quelques minutes. Le travail du développeur de logiciels moyen exige que le développeur ne change pas de focus plus souvent que toutes les quelques heures.

Un bon code est sa propre meilleure documentation. Lorsque vous êtes sur le point d'ajouter un commentaire, demandez-vous: "Comment puis-je améliorer le code pour que ce commentaire ne soit pas nécessaire?"Améliorez le code, puis documentez-le pour le rendre encore plus clair.

Les projets logiciels échouent pour l'une des deux raisons générales suivantes: l'équipe de projet n'a pas les connaissances nécessaires pour mener à bien un projet logiciel, ou l'équipe de projet n'a pas la détermination nécessaire pour mener un projet efficacement.

Dans le logiciel, la chaîne n'est pas aussi forte que son maillon le plus faible; elle est aussi faible que tous les maillons faibles multipliés ensemble.

Le mouvement par défaut sur un projet logiciel devrait aller dans le sens de retirer des éléments du logiciel pour le rendre plus simple plutôt que d'ajouter des éléments pour le rendre plus complexe.

Il vaut mieux attendre qu'un programmeur productif devienne disponible que d'attendre que le premier programmeur disponible devienne productif.

Il n'y a pas de secrets sur un projet logiciel réussi. Les bonnes et les mauvaises nouvelles doivent pouvoir monter et descendre dans la hiérarchie des ptojets sans restriction.

... la programmation exige plus de concentration que les autres activités. C'est la raison pour laquelle les programmeurs s'énervent à propos des "interruptions rapides" - de telles interruptions équivalent à demander à un jongleur de garder trois balles en l'air et de tenir vos courses en même temps.

C'est bien de comprendre les mystères du meurtre, mais vous ne devriez pas avoir besoin de comprendre le code. Vous devriez pouvoir le lire.

Le problème avec quick and dirty est que dirty reste longtemps après que quick a été oublié.

Les tests en eux-mêmes n'améliorent pas la qualité du logiciel. Les résultats des tests sont un indicateur de qualité, mais en eux-mêmes, ils ne l'améliorent pas. Essayer d'améliorer la qualité du logiciel en augmentant le nombre de tests, c'est comme essayer de perdre du poids en se pesant plus souvent. Ce que vous mangez avant de monter sur la balance détermine combien vous pèserez, et les techniques de développement logiciel que vous utilisez déterminent le nombre d'erreurs que les tests trouveront. Si vous voulez perdre du poids, n'achetez pas une nouvelle balance; changez votre alimentation. Si vous voulez améliorer votre logiciel, ne testez plus; développez mieux.

Un bon code est sa propre meilleure documentation.

La création de logiciels implique diverses étapes de planification, de préparation et d'exécution qui varient en nature et en degré en fonction de ce qui est construit. [...] La construction d'une tour de quatre pieds nécessite une main ferme, une surface plane et 10 canettes de bière intactes. Construire une tour 100 fois plus grande ne nécessite pas simplement 100 fois plus de canettes de bière.

Une bonne mise en page visuelle montre la structure logique d'un programme.

Une solution de force brute qui fonctionne est meilleure qu'une solution élégante qui ne fonctionne pas.

Même lorsque vous avez des personnes qualifiées, motivées et travailleuses, une mauvaise structure d'équipe peut saper leurs efforts au lieu de les catapulter vers le succès. Une mauvaise structure d'équipe peut augmenter le temps de développement, réduire la qualité, nuire au moral, augmenter le chiffre d'affaires et finalement conduire à l'annulation du projet.

L'ingénierie est l'application de principes scientifiques à des fins pratiques. Si l'ingénierie n'est pas pratique, c'est une mauvaise ingénierie.

Essayer d'appliquer des méthodes formelles à tous les projets logiciels est tout aussi mauvais que d'essayer d'appliquer le développement de code et de correctifs à tous les projets.

L'heuristique est un algorithme en costume de clown. Câ € ™ est moins prévisible, c’est plus amusant, et il est livré sans garantie de remboursement de 30 jours.

Une tentative générale d'éviter les erreurs est la plus grande erreur de toutes.

Dans le logiciel, les consultants vous disent parfois d'acheter certaines méthodes de développement de logiciels à l'exclusion d'autres méthodes. C'est malheureux parce que si vous adhérez à 100% à une méthodologie unique, vous verrez le monde entier en termes de méthodologie. Dans certains cas, vous manquerez des occasions d'utiliser d'autres méthodes mieux adaptées à votre problème actuel.

95% sur le contenu et le langage informatique reste le même.