La philosophie Unix met l'accent sur l'aspect pratique, dérivé d'une riche expérience, et n'est pas limitée par les méthodologies ou les normes traditionnelles. Cette connaissance est plus latente et semi-instinctive. Les connaissances que les programmeurs Unix accumulent grâce à leur expérience de développement peuvent profiter à d’autres programmeurs.
(1) Chaque programme doit se concentrer sur l'accomplissement d'une tâche et recommencer lorsqu'il est confronté à une nouvelle tâche pour éviter d'ajouter de nouvelles fonctions au programme d'origine, ce qui entraînerait une complexité accrue. (2) En supposant que la sortie d'un programme deviendra l'entrée d'un autre programme, même si le prochain programme n'est pas encore connu, assurez-vous que la sortie ne contient pas d'informations non pertinentes. (3) Mettez le logiciel conçu et écrit en essai le plus tôt possible, abandonnez de manière décisive le code de mauvaise qualité et réécrivez-le. (4) Utilisez des outils avant des moyens auxiliaires inefficaces pour réduire le fardeau des tâches de programmation. Pour viser l'excellence, vous devez faire bon usage des outils.
L'essence de la philosophie Unix n'est pas seulement ce que les sages ont transmis verbalement, mais se reflète davantage dans leurs pratiques et la conception du système Unix lui-même. Cette philosophie peut se résumer en quelques points clés :
Lorsque vous apprenez le génie logiciel pour la première fois, vous devez avoir une compréhension approfondie de ces principes. Bien que la plupart des articles promeuvent ces principes, de nombreux systèmes manquent d'outils pratiques et de traditions qui empêchent les programmeurs de mettre en œuvre ces principes. Ils sont souvent gênés par un outillage médiocre, une mauvaise conception, un surmenage et un code redondant.
Le cœur de la programmation est la gestion de la complexité. La résolution des bugs prend la majeure partie du temps de développement. Le succès d’un système utilisable est davantage le résultat d’essais et d’erreurs que d’un simple talent ou compétence en conception.
Le langage assembleur, le langage compilé, les organigrammes, la programmation procédurale, la programmation structurée, les méthodologies orientées objet et de développement logiciel sont trop vantés. Mais ils augmentent la complexité du programme au-delà des capacités de traitement du cerveau humain.
Pour réussir à développer des logiciels complexes, il est essentiel de réduire la complexité globale et de combiner des modules simples via des interfaces claires. Cela permet de localiser le problème sur une partie spécifique, ce qui facilite son amélioration sans affecter l'ensemble.
Écrivez du code en gardant à l'esprit la complexité et les coûts de la maintenance future. Le code doit être facile à lire et à comprendre afin qu'il puisse être facilement modifié et maintenu par d'autres ou par vous-même si nécessaire.
Dans la tradition Unix, ce principe s'applique à bien plus que de simples commentaires de code. Les meilleures pratiques Unix mettent également l'accent sur la prise en compte de l'évolutivité future lors de la sélection des algorithmes et des implémentations. Bien qu’il puisse être tentant d’ajouter de la complexité technique et de la confusion afin d’améliorer légèrement les performances du programme, cette approche n’en vaut pas la peine. Ce n’est pas seulement parce que le code complexe est sujet aux bogues, mais aussi parce que cela le rend plus difficile à lire et à maintenir à l’avenir. Au contraire, un code élégant et clair est non seulement plus stable, mais aussi plus facile à comprendre et à modifier pour les autres. Ceci est crucial, d’autant plus que la personne qui devra peut-être revenir en arrière et modifier ce code dans quelques années sera peut-être vous.
Ne luttez jamais pour déchiffrer trois fois un morceau de code obscur. Vous pouvez vous en sortir du premier coup, mais si vous constatez que vous devez le réinterpréter à nouveau - cela fait trop longtemps depuis la première fois et vous ne vous souvenez pas des détails spécifiques, alors il est temps de commenter le code, donc que la troisième fois sera relativement moins douloureuse.
Si les programmes ne peuvent pas communiquer efficacement entre eux, le logiciel s'enlisera inévitablement dans la complexité.
En termes d'entrée et de sortie, la tradition Unix préconise fortement l'utilisation de formats simples, textuels, orientés flux et indépendants du périphérique. Sous Unix classique, la plupart des programmes adoptent autant que possible la forme de filtres simples, c'est-à-dire qu'ils traitent un flux de texte d'entrée en une simple sortie de flux de texte. Contrairement aux idées reçues, les programmeurs Unix préfèrent cette approche non pas parce qu'ils détestent les interfaces utilisateur graphiques, mais parce qu'il est extrêmement difficile d'interfacer les programmes s'ils n'utilisent pas de simples flux d'entrée et de sortie de texte.
Les flux de texte sous Unix sont aux outils ce que les messages sont aux objets dans un environnement orienté objet. La simplicité de l'interface de flux de texte améliore l'encapsulation de l'outil. De nombreuses méthodes de communication inter-processus sophistiquées, telles que les appels de procédures à distance, ont tendance à impliquer un trop grand nombre de processus.
Pour rendre un programme composable, il faut rendre les programmes indépendants les uns des autres. Les programmes situés à une extrémité du flux de texte doivent, dans la mesure du possible, ne pas tenir compte des programmes situés à l'autre extrémité du flux de texte. Il devrait être facile de remplacer un programme à une extrémité par un programme complètement différent sans perturber du tout l'autre extrémité. L'interface graphique peut être une bonne chose. Avant de créer une interface graphique, vous devez vous demander si vous pouvez séparer le programme interactif complexe du programme algorithmique qui effectue le gros travail. Chaque partie peut être transformée en une pièce distincte, puis utiliser une simple commande. flux ou protocole d’application pour les combiner ensemble.
Avant de concevoir un format de transmission de données sophistiqué, il est nécessaire de vérifier sur place si un simple format de données texte peut être utilisé ; le coût d'analyse d'un petit peu de format vaut l'avantage de pouvoir utiliser des outils généraux pour construire ou interpréter le flux de données.
Lorsqu'un programme ne peut pas naturellement utiliser des interfaces sérialisées basées sur des protocoles, la conception Unix correcte consiste au moins à organiser autant d'éléments de programmation que possible dans un ensemble d'API bien définies. De cette manière, les applications peuvent au moins être appelées via des liens, ou différentes interfaces peuvent être collées ensemble en fonction des besoins des différentes tâches.
La stratégie et le mécanisme changent selon différentes échelles de temps, et la stratégie change beaucoup plus rapidement que le mécanisme. La combinaison de la stratégie et du mécanisme a deux effets négatifs : premièrement, cela rendra la stratégie rigide et difficile à adapter aux changements des besoins des utilisateurs. Deuxièmement, cela signifie également que tout changement de stratégie est susceptible d’ébranler le mécanisme ; Au contraire, supprimer les deux ne suffira peut-être pas à briser le mécanisme lors de l’exploration de nouvelles stratégies. De plus, il est plus facile d’écrire de meilleurs tests pour le mécanisme.
Un moyen de réaliser le stripping consiste à diviser l'application en processus front-end et back-end qui peuvent collaborer et communiquer via un protocole d'application dédié sur la couche supérieure du socket. Stratégie de mise en œuvre frontale, mécanisme de mise en œuvre back-end. Par rapport à la mise en œuvre globale utilisant un seul processus, cette conception à double extrémité réduit considérablement la complexité globale et devrait réduire les bogues, réduisant ainsi le coût du cycle de vie du programme.
La pression provenant de nombreux aspects rend souvent le programme plus complexe (ce qui rend le programme plus cher et comporte plus de bugs). L'une des pressions vient de la vanité technique. Les programmeurs sont intelligents et sont souvent fiers de leur capacité à jouer avec des choses complexes et des concepts abstraits, et à juste titre. Mais pour cette raison, ils rivalisent souvent avec leurs pairs pour voir qui peut bricoler les choses les plus complexes et les plus belles. Leurs capacités de conception dépassent largement leurs capacités de mise en œuvre et de débogage, et le résultat est une ferraille coûteuse.
« Des choses d'une beauté complexe » semblent être une contradiction. Les programmeurs Unix rivalisent entre eux pour savoir qui peut être « simple et beau ». Bien que cela ne soit qu'implicite dans ces règles, cela mérite d'être mentionné publiquement et souligné.
Au moins dans le monde des logiciels commerciaux, une complexité excessive provient souvent des exigences du projet, et ces exigences sont souvent basées sur des arguments de vente plutôt que sur les besoins des clients et ce que le logiciel peut réellement fournir. De nombreuses bonnes conceptions sont tuées par une longue « liste de fonctionnalités » requises pour le marketing, mais en fait, ces fonctionnalités ne sont presque jamais utilisées. C’est alors qu’un cercle vicieux commence. Pour être plus chic que les autres, il faut devenir encore plus chic soi-même. Bientôt, le bloat est devenu la norme de l'industrie. Tout le monde utilisait des logiciels surchargés avec tellement de bugs que même les développeurs de logiciels n'osaient pas le prendre au sérieux.
La seule façon d'éviter ces écueils est d'encourager une culture logicielle alternative où la simplicité est la beauté. Il s'agit d'une tradition d'ingénierie qui valorise les solutions simples, essaie toujours de diviser un système de programme en petites parties pouvant fonctionner ensemble et résiste instinctivement à toute tentative d'édulcorer un programme avec trop de gadgets.
« Big » a deux significations : grande taille et grande complexité. Plus le programme est vaste, plus il est difficile à maintenir. La difficulté de se séparer de quelque chose qui a nécessité beaucoup d’efforts pour créer aboutit à un gaspillage d’investissement dans un énorme programme voué à l’échec ou qui n’est pas la meilleure solution. Évitez le code et la logique inutiles et gardez votre code simple.
Étant donné que le débogage prend souvent les trois quarts ou plus du temps de développement, il est utile de faire un peu plus de travail au début pour réduire la quantité de travail de débogage plus tard. Un moyen efficace de réduire la charge de travail de débogage consiste à prendre pleinement en compte la transparence et la visibilité lors de la conception.
La transparence des systèmes logiciels signifie que vous pouvez voir ce que fait le logiciel et comment il le fait en un coup d'œil. La visibilité signifie qu'un programme a la capacité de surveiller et d'afficher son état interne, de sorte que non seulement le programme fonctionne correctement, mais que l'on puisse également voir de quelle manière il s'exécute.
Si ces exigences sont pleinement prises en compte lors de la conception, cela apportera des avantages à l'ensemble du processus du projet. Le paramétrage des options de débogage ne doit pas être effectué après coup, mais doit être pris en compte au début de la conception. Le programme doit non seulement être en mesure de démontrer son exactitude, mais également d'informer les retardataires de la résolution du problème par le développeur d'origine. modèle de pensée.
Si un programme souhaite démontrer son exactitude, il doit utiliser un format d'entrée et de sortie suffisamment simple pour garantir qu'il est facile de vérifier si la relation entre une entrée valide et une sortie correcte est correcte. Dans un souci de transparence et de visibilité, une interface simple devrait également être favorisée pour faciliter son fonctionnement par d'autres programmes, notamment les outils de surveillance des tests et les scripts de débogage. Suivez le compte public WeChat [Système Embarqué]
La robustesse du logiciel signifie que le logiciel peut non seulement bien fonctionner dans des circonstances normales, mais également bien fonctionner dans des conditions inattendues au-delà de l'imagination.
La plupart des logiciels ne supportent pas les chocs et rencontrent de nombreux problèmes car il est trop complexe et difficile de tout considérer. Si vous ne parvenez pas à comprendre correctement la logique d’un programme, vous ne pouvez pas être sûr qu’il est correct et vous ne pouvez pas le réparer en cas de problème. La manière de rendre un programme robuste est de rendre la logique interne du programme plus facile à comprendre. Il existe deux manières principales d'y parvenir : la transparence et la simplicité.
En termes de robustesse, il est également important de concevoir en gardant à l’esprit la capacité de résister à des sollicitations extrêmes. En cas de saisie anormale, une stratégie très importante pour garantir la robustesse du logiciel consiste à éviter les cas particuliers dans le code. Les bogues sont généralement cachés dans le code qui gère les cas particuliers et dans le code qui gère les opérations interactives de différentes situations particulières. .
La transparence du logiciel signifie que vous pouvez voir ce qui se passe en un coup d'œil. Un programme est simple si « ce qui se passe » n’est pas complexe, c’est-à-dire si tous les scénarios possibles peuvent être déduits sans se creuser la tête. Plus le programme est simple et transparent, plus il sera robuste.
La modularisation (code simple, interface simple) est un moyen d'organiser des programmes pour atteindre des objectifs plus concis.
Les données sont plus faciles à contrôler que la logique de programmation. Lors de la conception, la complexité du code doit être activement transférée aux données.
Cette considération n'est pas originale pour Unix, mais de nombreux codes Unix en sont influencés. En particulier, la fonction du langage C pour contrôler l'utilisation des pointeurs favorise la modification dynamique des structures de référence à différents niveaux de codage au-dessus du noyau. Les tâches qui peuvent être accomplies avec des opérations de pointeur très simples dans des structures nécessitent souvent des procédures plus complexes dans d'autres langages.
Lorsque vous effectuez une programmation basée sur les données, vous devez clairement séparer le code et la structure de données sur laquelle le code agit. De cette façon, lorsque vous modifiez la logique du programme, il vous suffit de modifier la structure des données au lieu du code. La programmation basée sur les données est parfois confondue avec la programmation orientée objet, un autre style centré sur l'organisation des données. Il existe au moins deux différences entre eux. Premièrement, dans la programmation basée sur les données, les données ne sont pas seulement l'état d'un objet, mais définissent en fait le flux de contrôle du programme ; deuxièmement, la programmation orientée objet considère d'abord l'encapsulation, tandis que la programmation basée sur les données valorise l'écriture. que possible. Moins de code fixe.
C'est également connu sous le nom de « principe de la moindre surprise ». Le programme le plus simple à utiliser est celui qui demande à l'utilisateur d'apprendre le moins de nouvelles choses et qui correspond le mieux à ses connaissances existantes. Par conséquent, la conception de l’interface doit éviter toute nouveauté et toute ingéniosité injustifiées.
Si vous programmez une calculatrice, « + » doit toujours signifier un ajout. Lors de la conception d'interfaces, essayez de les modéliser selon les mêmes interfaces fonctionnelles et applications similaires que celles que les utilisateurs connaissent le plus.
Concentrez-vous sur votre public cible, il peut s'agir d'utilisateurs finaux, d'autres programmeurs, d'administrateurs système. Le moins surprenant signifie des choses différentes pour ces différents groupes de personnes. Concentrez-vous sur les conventions traditionnelles, qui existent pour une bonne raison : faciliter la courbe d’apprentissage.
L’autre aspect du principe d’innovation minimale est d’éviter que les choses paraissent similaires mais soient en réalité légèrement différentes. Cela peut être extrêmement dangereux, car une similarité apparente conduit souvent les gens à faire des hypothèses erronées. Il est donc préférable d'avoir des choses différentes qui sont clairement différentes, plutôt que de paraître presque identiques.
Un programme bien élevé doit fonctionner en silence et ne jamais bavarder. Le silence est d'or. Ce principe vient du fait qu'à la naissance d'Unix, il n'y avait pas de moniteurs vidéo. Chaque ligne de sortie redondante consommait sérieusement un temps précieux de l'utilisateur. Cette situation n’existe plus, mais la belle tradition de tout garder simple perdure encore aujourd’hui.
La simplicité est le style de base des programmes Unix. Une fois que la sortie d’un programme devient l’entrée d’un autre programme, il est facile de sélectionner les données requises. D'un point de vue humain, les informations importantes ne doivent pas être mélangées à de longues informations sur le comportement interne du programme. Si les informations affichées sont toutes importantes, il n’est pas nécessaire de les rechercher. Un programme bien conçu traite l'attention de l'utilisateur comme une ressource limitée et précieuse, ne nécessitant son utilisation que lorsque cela est nécessaire pour éviter de déranger l'utilisateur avec des informations inutiles.
Le logiciel doit avoir la même logique transparente lorsqu'une erreur se produit que lors d'un fonctionnement normal. Le meilleur des cas est, bien sûr, que le logiciel puisse s'adapter et faire face à des opérations anormales ; le pire des cas est que les mesures correctives échouent manifestement, mais enfouissent silencieusement le risque de crash, qui n'est révélé que bien plus tard. .
Par conséquent, le logiciel doit gérer diverses entrées incorrectes et ses propres erreurs d'exécution aussi calmement que possible. S'il ne peut pas le faire, laissez le programme se terminer de manière à faciliter autant que possible le diagnostic de l'erreur.
"Recevez avec tolérance et envoyez avec prudence." Même si les données d'entrée ne sont pas standardisées, un programme bien conçu essaiera d'en comprendre la signification et de coopérer autant que possible avec d'autres programmes ; le prochain maillon de la chaîne de travail.
La tolérance doit être prise en compte lors de la conception, et ne pas utiliser une mise en œuvre trop indulgente pour compenser les lacunes de la norme, sinon vous mourrez moche si vous ne faites pas attention.
Au début de l'ère des mini-ordinateurs d'Unix, ce point de vue était encore assez radical ; avec le développement de la technologie, les sociétés de développement et la plupart des utilisateurs peuvent se procurer des machines bon marché, la rationalité de ce principe va donc de soi.
Dans le but de garantir la qualité, essayez d'utiliser les ressources informatiques pour effectuer des tâches et réduire la charge des programmeurs. Une autre façon de gagner considérablement du temps aux programmeurs est d'apprendre à la machine comment effectuer davantage de travaux de programmation de bas niveau. Suivez le compte public WeChat [Système Embarqué]
Nous savons tous que les humains sont terribles pour faire un travail de détail difficile. Tout travail manuel dans un programme est un terrain fertile pour les erreurs et les retards, et le code généré par le programme est presque toujours moins cher et plus fiable que le code écrit à la main.
Pour les générateurs de code, les codes de langage de haut niveau répétitifs et engourdis qui nécessitent une écriture manuscrite peuvent être produits en masse, tout comme les codes machine. L'utilisation d'un générateur de code est payante lorsqu'elle augmente le niveau d'abstraction, c'est-à-dire lorsque les instructions déclaratives du générateur sont plus simples que le code généré et que le code généré élimine le besoin d'un traitement manuel laborieux. Les générateurs de code sont largement utilisés sous Unix pour automatiser un travail détaillé et sujet aux erreurs.
Le principe le plus fondamental de la conception de prototypage est le suivant : « 90 % des fonctions peuvent être réalisées maintenant, ce qui est mieux que 100 % des fonctions qui ne pourront jamais être réalisées ». Un bon prototypage peut éviter d’investir trop de temps juste pour un petit profit.
"Nous ne devrions pas considérer l'amélioration de l'efficacité par de petits gains. Une optimisation prématurée est la racine de tous les maux." Se précipiter pour optimiser sans savoir où se trouve le goulot d'étranglement peut être la seule erreur qui endommage davantage la conception que l'ajout de fonctions aléatoires. Du code déformé à la présentation désorganisée des données, la recherche unilatérale de la vitesse au détriment de la transparence et de la simplicité engendre d'innombrables bugs et fait perdre du temps à des millions de personnes. Ce petit avantage est loin de compenser les coûts de dépannage ultérieurs.
Une optimisation locale prématurée peut en fait entraver l'optimisation globale, réduisant ainsi les performances globales. Les modifications qui apporteraient de plus grands avantages à la conception globale sont souvent gênées par une optimisation locale prématurée, ce qui aboutit à un produit aux performances médiocres et au code trop complexe.
Dans le monde Unix, il existe une tradition très claire et de longue date : prototyper d'abord, puis affiner. Avant de l'optimiser, assurez-vous qu'il peut être utilisé. D'abord, vous pouvez marcher, puis apprendre à courir. En étendant efficacement cela à partir d'une culture différente : courez en premier, soyez juste ensuite et allez vite en dernier.
L'essence de tous ces mots signifie en fait la même chose : commencez par concevoir une implémentation non optimisée, lente, gourmande en mémoire mais correcte, puis effectuez des ajustements systématiques pour trouver ceux qui peuvent obtenir de meilleurs résultats en sacrifiant un minimum de simplicité locale ou de performances. est amélioré.
Même le meilleur logiciel est souvent limité par l'imagination de ses concepteurs. Personne n’est assez intelligent pour tout optimiser, ni pour prévoir toutes les utilisations possibles d’un logiciel.
Pour la conception et la mise en œuvre de logiciels, l'un des points positifs de la tradition Unix est qu'elle ne croit jamais à une quelconque « approche universelle ». Unix poursuit l'utilisation généralisée de plusieurs langages, de systèmes ouverts évolutifs et de mécanismes de personnalisation par l'utilisateur ; il absorbe et s'appuie sur diverses excellentes idées de conception et améliore continuellement ses propres méthodes et styles de conception.
Laissez de la place à l'expansion des formats de données et du code, sinon vous vous retrouverez souvent coincé par des choix peu judicieux d'origine, car vous ne pouvez pas les modifier tout en conservant la compatibilité avec l'original.
Lors de la conception d'un protocole ou d'un format de fichier, rendez-le suffisamment auto-descriptif pour être extensible. Soit vous incluez un numéro de version, soit vous utilisez des instructions indépendantes et auto-descriptives pour organiser le format de manière à ce que de nouvelles puissent être insérées et les anciennes remplacées à tout moment sans casser le code qui lit le format. L'expérience Unix montre qu'en augmentant légèrement les coûts liés à l'auto-description du déploiement des données, vous pouvez évoluer sans détruire l'ensemble, et un petit effort peut être récompensé des milliers de fois.
Lors de la conception du code, il doit être bien organisé afin que les futurs développeurs puissent ajouter de nouvelles fonctionnalités sans démolir ni reconstruire l'intégralité de l'architecture. Ce principe ne signifie pas que vous pouvez ajouter des fonctions qui ne sont pas utilisées à volonté, mais que vous devez tenir compte des besoins futurs lors de l'écriture du code afin de faciliter l'ajout de fonctions à l'avenir. L'interface du programme doit être flexible. Ajoutez le commentaire "Si l'expansion... nécessite..." dans le code. Vous êtes obligé de faire quelque chose de bien pour ceux qui utilisent et maintiennent le code que vous avez écrit à l'avenir. le code vous-même à l'avenir et concevez-le en pensant à l'avenir. Ce que vous économiserez peut être votre propre énergie.
Ces principes philosophiques ne sont en aucun cas vagues et généraux. Dans le monde Unix, ces principes sont directement issus de la pratique et forment des règles spécifiques.
En utilisant la philosophie Unix, vous devez constamment rechercher l'excellence. La conception de logiciels est un métier digne de sagesse, de créativité et de passion. Sinon, vous n'irez pas au-delà de ces conceptions et implémentations simples et démodées ; vous vous précipiterez pour programmer alors que vous devriez réfléchir, vous compliquerez le problème alors que vous devriez impitoyablement éliminer le complexe et simplifier, et vous vous plaindrez du pourquoi. le code est tellement gonflé et difficile à déboguer.
Pour faire bon usage de la philosophie Unix, n'agissez jamais de manière imprudente ; utilisez plus de compétences et économisez votre énergie pour l'utiliser en cas de besoin. Profitez des outils et automatisez tout autant que possible.
La conception et la mise en œuvre de logiciels sont un art plein de joie, un jeu de haut niveau. Pourquoi devriez-vous vous lancer dans la conception de logiciels plutôt que dans autre chose ? Peut-être que maintenant c'est juste pour gagner de l'argent ou passer le temps, ou peut-être avez-vous déjà pensé que la conception de logiciels changeait le monde et valait la passion.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
La différence entre Unix et Linux
Quels programmes peuvent être développés avec php
Comment résoudre l'échec DNS
base de données de connexion jndi
numéro de série Photoshop CS5
Principales utilisations du système d'exploitation Linux
Quels sont les algorithmes de cryptage GSM ?
Fonctions de la commande tracert
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
