Pourquoi est-il préférable pour un programmeur de concevoir l'algorithme avant de commencer à écrire le code?

Un algorithme approprié aide-t-il vraiment à améliorer la qualité et, finalement, l'efficacité d'un programme?

Peut-on encore produire un programme de bonne qualité sans l'algorithme?

Un algorithme approprié est-il un MUST dans la programmation moderne?

Je pense que cette question appelle une perspective historique.

À l'époque "d'antan" (dont je ne suis pas un témoin personnel, ce n'est donc que ma reconstruction de cette époque - n'hésitez pas à me corriger si vous avez vécu les choses différemment) L'espace matériel et les performances étaient nuls par rapport à aujourd'hui. Donc, tout ce que les gens écrivaient devait être très efficace. Ainsi, ils devaient réfléchir et rechercher pour inventer les meilleurs algorithmes pour atteindre les performances spatio-temporelles nécessaires pour faire le travail. Un autre facteur était que les développeurs travaillaient principalement sur ce que vous pouvez appeler l' infrastructure : systèmes d'exploitation, piles de protocoles, compilateurs, pilotes de périphériques, éditeurs, etc. Tout cela est beaucoup utilisé par beaucoup de gens, donc les performances font vraiment une différence .

De nos jours, nous sommes gâtés d'avoir un matériel incroyable avec des processeurs multicœurs et des gigaoctets de mémoire, même dans un ordinateur portable de base (diable, même dans un téléphone mobile). Ce qui signifie naturellement que dans de nombreux cas, les performances - donc l'algorithme - ont cessé d'être le problème central, et il est plus important de fournir une solution rapidement que de fournir une solution rapide. OTOH, nous avons des tas de frameworks qui nous aident à résoudre les problèmes et encapsulent un grand nombre d'algorithmes en même temps. Donc, même lorsque nous ne pensons pas aux algorithmes, nous pouvons très bien en utiliser beaucoup en arrière-plan.

Cependant, il y a encore des domaines où la performance compte. Dans ces domaines, vous devez toujours réfléchir à vos algorithmes avant d'écrire du code. La raison en est que l'algorithme est le centre de la conception, déterminant un grand nombre de structures de données et de relations dans le code environnant. Et si vous découvrez trop tard que votre algorithme ne se met pas à l'échelle correctement (par exemple, il est O (n ³ ), il avait l'air bien et rapide lorsque vous l'avez testé sur 10 éléments, mais dans la vraie vie, vous en aurez des millions), il est très difficile, sujet aux erreurs et prend du temps pour le remplacer dans le code de production. Et les micro-optimisations ne vont pas vous aider si l'algorithme fondamental n'est pas adapté au travail.

Juste pour signaler quelque chose:

Un algorithme est en soi une solution générale étape par étape de votre problème. Donc, si vous avez résolu le problème, vous avez en fait utilisé un algorithme.

Le point le plus important ici est que vous devez utiliser des algorithmes pour résoudre le problème, d'une manière ou d'une autre. La plupart du temps, il est préférable de réfléchir à votre problème avant de passer au codage - cette phase est souvent appelée conception. Mais combien et de quelle manière allez-vous le faire dépend de vous.

De plus, vous ne devriez pas mélanger le concept d'algorithme avec des organigrammes (je soupçonne que cela se passe ici). Les organigrammes ne sont qu'une représentation graphique qui peut être utilisée et a été utilisée dans les anciens jours pour illustrer un algorithme. Il est à peu près obsolète de nos jours.

ÉDITER:

Il existe en effet de nombreuses façons de représenter un algorithme et le code du langage de programmation lui-même en fait partie. Cependant, bien souvent, il est beaucoup mieux ou plus facile de ne pas résoudre tout le problème en même temps, mais juste un plan, puis de remplir les blancs au fur et à mesure.

• Mon préféré ici est le pseudo-code, et uniquement pour couvrir un aperçu abstrait général de l'algorithme en question - c'est ridicule d'entrer dans les détails avec le pseudocode , c'est à cela que sert le vrai code.

• Mais le vrai code peut être utilisé pour le contour. Par exemple, les gens de TDD aiment concevoir l'algorithme comme ils codent, et comme ils ne peuvent pas tout résoudre en même temps, ils conçoivent un aperçu de l'exécution du programme en code réel, et utilisent des objets fictifs (ou des fonctions, des méthodes .. .) sous forme d'espaces à remplir ultérieurement.

• Les diagrammes d'activité UML semblent être une incarnation moderne d'organigrammes à l'ancienne avec une notation ajoutée pour les nouveaux trucs comme le polymorphisme et le multithreading. Je ne peux pas vraiment dire à quel point c'est utile, car je ne les ai pas beaucoup utilisés - je le mentionne simplement pour être complet.

• De plus, si vous basez votre algorithme sur la commutation entre les états, un diagramme d'état est très utile.

• En règle générale, tout moyen que vous devez simplement esquisser l'idée derrière un certain algorithme est une bonne façon de procéder.

Une bonne analogie est que vous devez connaître une recette avant de commencer à cuisiner. Ok, vous pouvez le modifier au fur et à mesure, mais vous devez toujours savoir ce que vous voulez faire avant de commencer. Si je veux faire un ragoût d'agneau, je ferai des choses très différentes que si je veux faire une miche de pain.

Le code implémente des algorithmes. Essayer d'écrire du code sans avoir conçu l'algorithme, c'est comme essayer de peindre une maison avant la construction des murs. Les algorithmes sont un "MUST" depuis le début de la programmation.

La maîtrise de votre langue contribue à améliorer la qualité et la productivité. Et résoudre de petits problèmes algorithmiques est beaucoup plus utile pour cela que de répéter 100 fois la même chose MVC.
Bien, je suppose qu'il existe d'autres façons d'atteindre la maîtrise.

L'algorithme deviendra-t-il un MUST dans le domaine de la programmation moderne?
C'est déjà un «must», sauf si vous êtes un «php ninja» qui écrit «cool codez». Toutes les «meilleures» entreprises (Google, Amazon, etc.) testent votre expérience algorithmique en interview, et j'imagine qu'elles ne le feraient pas sans raison.

Mais pour revenir au point d'origine, vous devez constamment vous mettre au défi si vous voulez vous améliorer. Et comme les tâches normales (alias "écrire maintenant des gestionnaires CRUD pour 100 objets supplémentaires") ne fournissent pas toujours un bon défi, les algorithmes compensent cela.

Je dirais que vous avez besoin d'au moins une idée initiale d'un algorithme avant de commencer à coder. Vous réviserez probablement votre idée tout en codant en fonction des structures de données, etc.

Plus tard, vous pouvez réviser à nouveau le code si le profilage suggère qu'il existe un problème de performances dans ce domaine.

La raison en est qu'il est plus rapide de corriger les erreurs avant d'avoir écrit le code erroné.

Plus prosaïquement, il y a régulièrement des différences de productivité mesurées de 10 à 1 entre les différents programmeurs. Lorsque vous regardez les programmeurs qui sont au niveau de productivité 10 fois, ils passent la plus petite fraction de leur temps à coder. Le temps de taper du code ne doit pas être le goulot d'étranglement. Au lieu de cela, ils passent une plus grande partie de leur temps à s'assurer qu'ils ont des exigences claires, à planifier, à tester, etc.

Inversement, lorsque vous regardez les programmeurs qui plongent dans le codage sans pause, ils doivent inévitablement écrire le code encore et encore car ils rencontrent des problèmes entièrement prévisibles, et le résultat final est moins maintenable et plus bogué. (Soit dit en passant, vous saviez qu'en moyenne 80% de l'argent dépensé pour le développement de logiciels est dans la phase de maintenance? Rendre les choses maintenables. Beaucoup.)

Généralement, les algorithmes et les structures de données d'abord, le code plus tard. Mais cela dépend beaucoup du domaine de programmation. J'avais l'habitude de faire beaucoup de choses de type mathématique appliqué et j'ai vraiment regardé le modèle de cascade alors répandu. En effet, les algorithmes de bas à moyen niveau pouvaient rarement être tenus pour acquis. Concevez une grande structure autour de l'existence de sous-systèmes non écrits, puis découvrez à la fin du jeu que les calculs pour l'un de ces sous-systèmes cruciaux ne fonctionnent pas (est instable ou autre). J'ai donc toujours pensé aux sous-systèmes les plus difficiles en premier, et s'il y avait une raison de douter, je les ai écrits et testés en premier. Mais, pour certains domaines problématiques, vous pouvez simplement avancer sans trop de planification.

Concevez un algorithme en sections, puis divisez ces sections et codez chacune d'elles individuellement. De cette façon, vous pouvez mélanger les deux points de vue:

1. Utilisez vos capacités linguistiques pour faire fonctionner l'algorithme
2. Essayez de penser avant le code, afin que votre idée ne fusionne pas avec la langue (un jour, vous devez déplacer votre algorithme vers une autre langue et vous finirez un en spagetthi)

Pour moi, c'est à peu près tout le code. Je pense que c'est vrai pour les programmeurs les plus productifs. Je peux écrire du code aussi facilement que j'écris du texte.

Autant que possible, j'essaie de capturer les exigences sous forme de tests exécutables (code). La conception n'est qu'un codage de haut niveau. Il est plus rapide et plus précis de capturer le design dans la langue cible que de le capturer sous une autre forme, puis de le traduire.

J'ai constaté que la plupart des utilisateurs ne peuvent pas examiner efficacement les exigences textuelles. Ils fonctionnent bien avec les cas d'utilisation séquentiels, mais les cas d'utilisation ne peuvent pas capturer tous les aspects de l'interface utilisateur. Le mieux est de loin de prendre une première coupe lors de l'implémentation, de laisser les utilisateurs l'essayer, d'obtenir leurs commentaires et de modifier le code en conséquence.

Lorsque vous vous asseyez et commencez à coder, vous avez un algorithme en tête, qu'il soit "conçu" ou non.

Si vous vous asseyez et commencez à coder sans aucun algorithme complet à l'esprit, vous effectuez l'une des opérations suivantes:

1) écraser les clés au hasard. Cela produira probablement une erreur de compilation

2) écrire du code compilable qui fait probablement tout sauf la chose que vous voulez qu'il fasse

3) écrire du code pour résoudre de petites parties du problème et en tirer parti au fur et à mesure de l'agrégation, mais sans vraiment anticiper - donc le problème est finalement résolu - mais le code n'est pas très efficace, et avec possibilité de revenir en arrière et de perdre du temps en cours de route

Donc, les gens programment généralement avec un algorithme dans leur tête. Il peut avoir été étoffé ou raisonné sur du papier ou tout autre support.

Cela peut être une bonne discipline de penser à votre attaque contre un problème loin du clavier, en particulier dans vos premiers jours en tant que programmeur. Comme d'autres réponses l'ont noté, à mesure que vous acquérez de l'expérience, vous pouvez améliorer le codage de morceaux de problème plus gérables "à la volée". Cependant, pour les problèmes difficiles ou importants, il est utile de penser et de concevoir loin du clavier: lorsque vous vous engagez avec du code, vous êtes plus susceptible de penser en termes de constructions du langage et de la façon d'aborder la tâche la plus immédiate dans le problème. Tandis que penser au problème avec, disons, un stylo et du papier, vous libère davantage de l'aspect linguistique du code et vous permet de penser à un niveau plus abstrait plus élevé.

Vous devez cesser de considérer la construction de logiciels comme un élément fondamental de la construction de tout autre élément de valeur. Ce n'est pas. Donc, comme toute autre chose, un plan ou un design bien pensé, même succint, est toujours nécessaire.

Un algorithme approprié aide-t-il vraiment à améliorer la qualité et, finalement, l'efficacité d'un programme?

Un plan / schémas de construction approprié aide-t-il à construire efficacement une maison de qualité?

Peut-on encore produire un programme de bonne qualité sans l'algorithme?

Pouvez-vous construire efficacement une maison de bonne qualité sans un plan de construction approprié? Selon le théorème des singes infinis , probablement, oui (tout comme un million de singes tapant au hasard pour l'éternité finiront par taper les œuvres complètes de Shakespeare.

Un algorithme approprié est-il un MUST dans la programmation moderne?

Si vous ne voulez pas être un singe de code et que vous voulez vous assurer de ne pas fournir de logiciel qui ressemble et fonctionne comme de la merde, oui, c'est un must. Chaque projet que j'ai dû sauver (parce que le code ressemblait à de la merde non conservable) a invariablement commencé par une réponse négative à cette question.

En fait, la programmation moderne a été l'abandon de l'ingénieur logiciel de programmation cowboy où la planification d'une certaine sorte si un must.

Même lorsque vous avez une bibliothèque d'algorithmes et de structures de données à votre disposition (.ie. Boost en C ++ ou la bibliothèque de collections Java), vous devez savoir comment fonctionne ce truc pour l'utiliser de manière appropriée, et pour le composer en raisonnable, supérieur- algorithmes de niveau.

Ce n'est pas mieux. Il vaut mieux ne rien "concevoir". C'est pour les gens qui n'écrivent pas de programmes. Vous savez, les personnes ayant une réelle expérience du problème à portée de main. Si vous êtes mathématicien, ingénieur ou logisticien, très bien, vous devez travailler sur le processus ailleurs. Mais ce n'est pas de la «programmation».

Mettez d'abord une sorte de test et de référence en place.

Ensuite, écrivez quelque chose, n'importe quoi. Refactorisez-réécrivez-boucle jusqu'à ce que vous manquiez de temps ou que vous ne puissiez plus vous améliorer.

Alors que beaucoup semblent penser que l'on peut faire des choses avec un ordinateur sans rien faire sur un ordinateur, je pense que c'est l'un des mythes les plus courants. Astronautismes d'architecture.

De plus, vous ne pouvez pas optimiser votre algo avant qu'il ne soit écrit.

IOW, "restez proche du métal".