Que considérez-vous comme le premier principe de programmation?

J'ai toujours aimé me demander "quel est le premier principe de ceci?" après avoir appris les bases de quelque chose (par exemple, la programmation). C'est une question inspirante, OMI, qui peut vous obliger à réfléchir aux principes les plus importants derrière quelque chose, en particulier une compétence telle que la programmation.

Alors, quel est selon vous le (s) premier (s) principe (s) de la programmation? Je donnerai ma réponse ci-dessous un peu plus tard.

1. KISS - Keep It Simple Stupid
2. SEC - Ne te répète pas
3. YAGNI - Vous n'en aurez pas besoin

Écrivez le code comme si c’était vous qui auriez à le conserver.

Soyez aussi paresseux que possible.

Zen, partie I: La programmation n'est que la route, pas le chemin.

La programmation n’est que la technique pour enseigner à un ordinateur ce qu’il doit faire. Pour réussir à créer un logiciel rapide et fiable, vous devez connaître vos algorithmes, vos meilleures pratiques et tous les autres éléments qui ne sont pas nécessairement liés à votre programmation (langage).

Zen, partie II: Si vous êtes pressé, marchez lentement. Si vous êtes vraiment pressé, faites un détour.

Cela semble idiot, mais ne vous laissez pas aller à des compromis qui pourraient vraiment vous déranger par la suite. J'ai une règle: si vous êtes au cœur d'un programme, essayez d'être aussi précis et précis que possible. Si vous utilisez des méthodes profondément ancrées dans votre logiciel, essayez d’être plus rapide dans le codage. Si vous codez au-dessus de ces deux là, vous pouvez même obtenir un peu plus de travail.

Les erreurs de conception sont les plus difficiles à trouver et / ou à corriger, la prochaine étape consiste en des erreurs de programmation dans des pièces sur lesquelles tout le monde se fonde, puis dans les "véritables pièces de logiciel montrant". Si vous devez corriger une erreur de conception à la fin d'un projet, hum, ce n'est pas bien ... ;-)

Zen, partie III: Connais ton chemin, Neo.

Connaissez votre environnement, vos outils et les éléments sur lesquels vous comptez au quotidien, et faites le tri pour qu'il fonctionne pour vous. Idéal si vous utilisez votre "environnement" de programmation si naturel que vous n’aurez même pas à y penser. Si vous devez faire un travail, n'introduisez pas de "nouveautés fantaisistes" mais faites votre travail. Ces éléments peuvent être introduits dans un nouveau projet, notamment lorsque vous avez le temps de les préparer et de les utiliser.

KISS (restez simple, stupide).

Cela pose en effet la question "Comment définissez-vous simple?" Et aussi "Quand quelque chose est trop simple pour la tâche à accomplir?" C'est pourquoi vous ne pouvez pas devenir un bon programmeur simplement en connaissant le premier principe de la programmation.

L'optimisation prématurée est la racine de tout Mal. - Donald Knuth

Ne réinventez pas la roue.

Comprenez d'abord le problème!

YAGNI - Vous n'en aurez pas besoin . L’idée de YAGNI est de programmer en fonction de vos besoins et non des caractéristiques potentielles. Le principe est qu’en vous limitant à ce que vous avez besoin de programmer, vous réduirez entre autres le fardeau du code, réduirez la complexité, éviterez les déformations des fonctionnalités et réduirez les restrictions sur ce qui peut être fait (et comment cela peut être fait) futur.

Je suppose que cela fonctionne en tandem avec la conception modulaire: les fonctionnalités futures peuvent être améliorées sans modifier le code existant.

Savoir quand ne pas programmer.

Entrée de café, codage.

S'il n'a pas été testé, il est cassé.

Il existe deux manières de concevoir un logiciel: l’une est de simplifier les choses de manière évidente, mais l’autre est de compliquer les choses au point de compliquer les choses. La première méthode est bien plus difficile.

- Charles Antony Richard Hoare

1. Distinguer cause à effet (travailler avec des ordinateurs)

2. Distinguer les faits et les opinions (travailler avec des personnes)

3. Aussi simple que possible, mais pas plus simple (design)

La programmation est un moyen et non une fin. Ou peut-être, "peut ne signifie pas devrait."

1. Comprenez pourquoi le programme rendra quelqu'un heureux (sinon, pourquoi ne jouez-vous pas à l'extérieur avec tous les autres enfants?). (Cette personne peut être vous.)
2. Développez un modèle conceptuel du domaine métier qui capture toute la complexité nécessaire, sans plus.
3. Développez un modèle conceptuel de l' architecture logicielle qui capture toute la complexité nécessaire, sans plus.
4. Gardez impitoyablement toute autre complexité.

À mon avis, le principe le plus important est la réduction de la complexité par la création de bonnes abstractions .

Ceci comprend

• comprendre le problème à résoudre,
• concevoir une solution appropriée pour cela et
• la mise en œuvre,
• de préférence de manière à ce que le code soit compréhensible et maintenable,

mais aussi la détermination du point où il faut arrêter de créer des abstractions et se pencher sur les propriétés fondamentales des technologies de mise en œuvre (par exemple, système de base de données, langage de programmation) afin d’empêcher la création d’une complexité supplémentaire évitable.

Programme avec un public en tête. Par là, ne supposez pas que tout ce que vous écrivez ne sera pas lu et maintenu par vous ou par quelqu'un d'autre.

Un corollaire à cela: Prouvez que vous comprenez le problème que vous essayez de résoudre en nommant bien vos variables, fonctions et classes!

ça ne marche pas avant de l'avoir montré dans un test

Pensez d'abord, codez plus tard.

Vous êtes loin d'être aussi intelligent que vous le pensez. Poser des questions. Apprenez à valoriser vos pairs.

Lors du débogage, la première réponse sera presque toujours fausse.

Le code que vous écrivez dans le but de le jeter tend à devenir la pierre angulaire de processus beaucoup plus vastes. Ne laissez jamais rien écrit au hasard.

Tout problème peut être résolu avec une autre couche d'indirection.

Connaissez vos outils.

Principe: le logiciel est la capture de connaissances .

Conséquences: De nombreuses techniques de représentation des connaissances, toutes fondées sur l’ abstraction . Nous donne des couches, des niveaux, une encapsulation, une séparation des préoccupations.

De nombreuses techniques de représentation de procédure, toutes fondées sur Séquence , Choix , Répétition .

Écrivez le code pour le prochain gars.

Écrivez toujours le code comme si la personne qui le conservera est un tueur en série psychotique qui sait où vous habitez

Aussi, ne pensez jamais que vous savez tout sur la programmation, continuez à apprendre

Je me suis initié à la programmation en étudiant l’électronique numérique. J’imagine donc que les bases logiques de base (non, et, ou, xor, implique) étaient les premiers principes de la programmation.

Tout est à propos de l'utilisateur.

Garbage in - Garbage Out Peu importe la qualité de l'interface utilisateur, si les données sont mauvaises.

DRY, à peu près tout le reste en résulte. KISS est l’autre côté de l’équilibre: vous assurer de ne pas poursuivre l’élégance logicielle à un niveau insensé.

Commencez par la sortie et avancez.