"Si le développement logiciel est difficile, pourquoi est-il difficile ?"
D'abord, laissez-moi dire que le développement logiciel n'est probablement pas aussi difficile que beaucoup d'autres domaines. Cependant, il est difficile, mais pas de la manière dont les personnes qui ne le connaissent pas le voient vraiment.
Les exigences correspondent rarement à l'architecture interne du logiciel
Cela ne signifie pas que l'architecture ou les exigences sont mauvaises. Cela signifie qu'elles utilisent des vocabulaires différents et des abstractions différentes. Les exigences spécifient les comportements du logiciel visibles de l'extérieur. Il y a une complexité cachée à l'intérieur.
Les clients connaissent rarement toutes les exigences
Imaginez que vous devez expliquer à votre enfant comment nettoyer le sol de la cuisine. C'est quelque chose que vous avez déjà fait de nombreuses fois. Vous n'avez même pas besoin de réfléchir aux détails. Vous expliquez toutes les étapes et l'enfant rayonne de fierté d'avoir pu contribuer de manière utile. La semaine suivante, vous êtes interrompu pendant que vous faites autre chose par votre enfant qui vous demande où est le balai parce que la semaine dernière, vous l'avez sorti en commençant l'explication et vous ne lui avez pas dit où vous l'aviez trouvé.
Chaque projet est unique
Vous n'êtes pas en train de développer la Fun App 1.0 encore et encore. Tu développes la Fun App 1.0, la Fun App 1.1, l'autre Fun App 2.0 (parce que tu as rejoint ce projet plus tard), la Fun App pour Windows 1.2, etc. Il y a des éléments qui sont les mêmes, et d'autres qui sont uniques à chaque projet. Les parties qui sont les mêmes peuvent représenter 80% du code. Ils représentent 20% de l'effort. Vous passez presque tout votre temps sur les morceaux qui sont différents.
La programmation est une question d'abstractions et d'indirection
Pour le faire efficacement, vous devez généralement être capable de tenir au moins trois vues de quelque chose dans votre tête en même temps. Vous devez voir ce qui se passe du point de vue de l'appelant ou de l'utilisateur d'une abstraction. Vous devez voir ce qui se passe du point de vue de la fonction appelée ou des internes d'une classe que vous utilisez. Et vous devez le voir du point de vue de ce qui devrait se passer (si vous déboguez) ou de ce qui doit être implémenté (si vous travaillez sur une nouvelle fonctionnalité).
Programmer implique de garder la trace de l'état et du processus
On a observé que l'un des obstacles nécessaires pour apprendre à programmer tout court est de comprendre le changement d'état du programme au fil du temps. C'est-à-dire, au départ, juste saisir comment les affectations changent la valeur des variables. Finalement, il faut être capable de suivre l'évolution de l'état général au fur et à mesure de l'exécution du code. Pour revenir au point précédent, une grande partie de l'effort consiste à voir quels invariants devraient être vrais entre les appels et à faire face au fait qu'au milieu d'un appel, l'état interne les viole parce que le code ne passe pas simplement de façon atomique d'un état à un autre.
Une grande partie de la programmation consiste à faire respecter des contraintes
Les modificateurs d'accès, les déclarations de constantes, les conventions de nommage, etc. sont autant de contraintes que nous plaçons sur notre code. Les contraintes ne sont généralement pas exécutables. Elles indiquent au compilateur des choses que nous savons sur le code, et limitent ce que nous pouvons faire. Pour un débutant, elles donnent l'impression de rendre le processus plus difficile, alors qu'en réalité elles permettent de s'attaquer à des problèmes plus importants, car le code limite ce à quoi il faut penser.
De meilleurs outils élargissent la taille des problèmes que nous pouvons aborder
L'amélioration des outils ne facilite pas notre travail. La difficulté reste à peu près la même, et les problèmes s'élargissent.
Les outils sont plus faciles à utiliser.