Pourquoi est-il encore si difficile d'écrire un logiciel?

Question

Logiciel d'écriture, je trouve, est composé de deux parties:

1. l'Idée, et
2. la mise en Œuvre.

L'Idée est de penser de: "je n'ai ce problème; comment puis-je le résoudre?" et "comment puis-je le résoudre de façon élégante?" Les réponses à ces questions sont obtenus par réflexion sur des algorithmes et de l'architecture. Les idées viennent en partie grâce à l'analyse et en partie grâce à la perspicacité et de l'intuition.

L'Idée est généralement la partie la plus facile. Vous parlez à vos amis et collègues et vous écrou elle lors d'une réunion ou d'un café. Il faut une heure ou deux, en plus des révisions que vous mettre en œuvre et de trouver de nouveaux problèmes.

La phase de Mise en oeuvre de développement de logiciels est tellement difficile que nous plaisanter à ce sujet. "Oh," nous disons, "le reste est une Simple Question de Code". Car il devrait être simple, mais il ne l'est jamais.

Nous avons utilisé pour écrire notre code sur des cartes perforées, et c'était dur: des erreurs ont été très difficiles à repérer, nous avons donc dû dépenser plus d'effort à faire en sorte que chaque ligne a été parfait. Puis nous avons eu la borne serial (série): nous avons pu voir tout notre code à la fois, de la recherche à travers elle, de les organiser de façon hiérarchique et de créer des choses abstraites à partir de matières de code machine.

Nous avons d'abord eu d'assemblage, et d'un niveau de code machine. Mnémoniques nous a libérés de se souvenir du code machine. Puis, nous avons eu des compilateurs, qui nous a libérés de rappeler les instructions. Nous avons eu des machines virtuelles, qui permettent de s'éloigner de la machine détails spécifiques.

Et maintenant, nous avons avancé des outils comme Eclipse et Xcode que d'effectuer une analyse sur notre code pour nous aider à écrire du code plus rapide et d'éviter les pièges les plus courants.

Mais l'écriture de code est toujours difficile. L'écriture de code est de comprendre les grands systèmes complexes, et les outils que nous avons aujourd'hui n'est tout simplement pas aller très loin pour nous aider avec ça. Lorsque je clique sur "rechercher toutes les références" dans Eclipse, j'en obtenir une liste au bas de la fenêtre. Je clique sur l'un, et je suis déchiré loin de ce que je regardais, l'a forcé à changer le contexte. Architecture Java est généralement de plusieurs niveaux de profondeur, de sorte que je dois changer et basculer et switch jusqu'à ce que je trouve ce que je suis vraiment à la recherche de -- j'ai oublié d'où je venais. Et je fais ça tous les jours jusqu'à ce que j'ai compris un système. C'est la taxation mentalement, et Eclipse n'a pas beaucoup de qui n'a pas pu être fait en 1985 avec grep, à l'exception de manger des centaines de mégas de RAM.

L'écriture de code a à peine changé depuis que nous avons été à regarder orange sur noir. Nous avons les bases théoriques pour beaucoup plus d'outils de pointe, des outils qui fonctionnent réellement pour nous aider à comprendre et à étendre les systèmes complexes, nous travaillons tous les jours.

Alors, pourquoi est-écriture de code toujours aussi dur?

Answer 1

Vous ne pouvez pas battre la perspicacité de Edsger Dijkstra en 1972 Prix Turing conférence, "L'Humble Programmeur:"

tant qu'il n'y avait pas de machines, la programmation était pas du tout un problème; quand nous avons eu un peu de faiblesse de l'informatique, la programmation est devenue un léger problème, et maintenant nous avons gigantesques ordinateurs, la programmation était devenu également un énorme problème. En ce sens, l'industrie de l'électronique n'a pas résolu un seul problème, il a créé, il a créé le problème de l'utilisation de ses produits.

Pour le mettre d'une autre manière: en tant que la puissance des ordinateurs a augmenté par un facteur de plus d'un mille, la société a pour ambition de faire appliquer ces machines a augmenté en proportion, et c'était le mauvais programmeur qui trouve son emploi dans cette explosé champ de tension entre les fins et les moyens.

et vers la fin:

En aparté, je voudrais insérer un avertissement à ceux qui s'identifient à la difficulté de la tâche de programmation de la lutte contre les insuffisances de nos outils actuels, parce qu'ils pourraient en conclure que, une fois que nos outils sera beaucoup plus adéquate, la programmation ne sera plus un problème.

La programmation restera très difficile, parce qu'une fois que nous nous sommes affranchis de l'événementiel des lourdeurs, nous sommes libres de s'attaquer à des problèmes qui sont maintenant bien au-delà de notre capacité de programmation.

L'ensemble de la conférence est bien la peine de lire.

Answer 2

En fait j'ai trouvé tout le contraire pour être vrai.

Il n'est pas difficile à mettre en œuvre une fois que vous disposez de toutes les informations. Il est vraiment pas. Mon groupe viens de terminer une libération et une énorme quantité de temps a été passé sur la FAÇON dont le système devrait fonctionner à la fois de l'INTERFACE utilisateur et backend.

Le problème, c'est que vous n'avez généralement pas besoin de toutes les informations a priori. Vous devez aller d'avant en arrière avec les parties prenantes sur la façon dont le système devrait fonctionner.

Surprenantes, les problèmes ont été résolus avec les langages de programmation et un très court laps de temps. Juste google les nombreux défis de programmation comme l' ICFP .

Je dirais un bon logiciel outils/langages de programmation vous permettent de modéliser le problème de sorte que vous ne trouverez des questions que vous n'avez pas de questions sur le problème (à mon humble avis très fortement typé des langages comme Haskell sont bons). Cependant un rôle encore plus important des critères de langage de programmation/de l'outil est comment il est facile de faire des changements.

Certains langages de programmation sont plus faciles à faire de changements que d'autres et je serais heureux de les échanges d'opinions-la facilité d'utilisation de la langue à très adaptable langue. Donc j'aime les langues qui font qu'il est facile de ré-facteur et écrire des tests unitaires.

Outre le changement constant avec le Monde Réel, les Problèmes et les Projets d'une Autre, c'est la communication. Mais pas de communication avec l'homme à l'ordinateur, mais de l'homme à l'homme. L'homme à la communication humaine composant est là où je pense que nous avons besoin de plus de recherche.

Donc, pour résumer: Je crois que le changement et la communication sont le véritable défi pas le problème lui-même.

En remontant la récente libération, je dirais que le temps de pause a été comme suit: 70% Design de 30% de la programmation.

Alors que 30% de la programmation:

• 20% de l'Unité de Test de code
• 20% de la mise en Œuvre de
• 40% correction d'un Bug

La correction d'un bug a été en grande partie à cause de pas assez de tests unitaires et de certains problèmes de conception.

Answer 3

Code Bubbles permet de résoudre ce problème et constitue un pas dans la bonne direction. Nous devons prendre des outils comme Code Bubbles, l' analyseur statique de clang et les visualisations de graphiques d'appel pour acquis dans toutes les langues, sur tous les systèmes.

Answer 4

Il n'y a rien de mal à ce que quelque chose soit dur, après tout, c'est comme ça que vous êtes payé beaucoup d'argent. Sérieusement, cependant - nous résolvons toujours des problèmes personnalisés et essayons d'adapter la meilleure technologie à leur disposition. Il est difficile de prédire tout ce qui peut mal tourner, et la séparation des préoccupations permet de résoudre ce problème. Développement orienté interface, TDD, IoC et bien d'autres concepts, lorsqu'ils sont appliqués correctement, s'ils ne rendent pas le développement logiciel simple, au moins le rendent gérable.

Answer 5

Écrire du code est difficile car il nécessite de la concentration .