Aujourd'hui, nous ne parlerons pas d'ambitions et d'idéaux, ni de technologies spécifiques. Nous parlerons de plusieurs erreurs typiques dans le point de vue des programmeurs. Les questions suivantes sont celles que j'ai rencontrées, ou des problèmes que mes amis ont rencontrés. Ce sont toutes mes compréhensions personnelles, et j'espère qu'elles seront utiles à tout le monde.

À propos des patrons de conception et des principes de conception

Certaines personnes pensent qu'une fois que l'on connaît les patrons de conception et les principes de conception, on a appris la conception. En fait, les patrons de conception et les principes de conception ne sont que des résumés et des synthèses élaborés par les prédécesseurs à partir de la pratique de la conception. La conception, en dernière analyse, consiste à résoudre des problèmes - transformer les solutions à des problèmes spécifiques, par un certain degré d'abstraction, en langage du programmeur.

J'ai vu certaines personnes qui sont savantes et cultivées, et qui peuvent même vous expliquer des théories avec des termes ronflants, mais lorsqu'il s'agit de résoudre réellement des problèmes, elles ne parviennent pas à proposer des solutions astucieuses et élégantes. Ce sont des personnes typiques de la tour d'ivoire.

D'un autre côté, il y a aussi des personnes qui méprisent celles qui apprennent les patrons de conception. Elles estiment avoir déjà maîtrisé les secrets de la conception logicielle, et ces mots n'ont aucun sens pour elles. Vous pouvez simplement en rire.

Parfois, nous sommes au contraire pieds et poings liés par une maîtrise grossière des patrons de conception ou des principes de conception. Par exemple, j'ai rencontré un cas comme celui-ci : le code conçu par un programmeur assidu utilisait la composition partout (par exemple, placer un objet User à l'intérieur de Administrator). J'ai demandé avec curiosité : certaines relations entre classes et objets correspondent clairement aux caractéristiques de l'héritage ; pourquoi ne voulaient-ils pas l'utiliser ? Il a dit : les principes de conception nous disent de privilégier la composition plutôt que l'héritage. Je pense que si ces excellents patrons, principes et méthodologies ne peuvent pas être maîtrisés à fond et ne peuvent pas être appliqués de manière appropriée selon les scénarios réels, ne vaudrait-il pas mieux ne pas les comprendre du tout ?

À propos de l'apprentissage de plusieurs langages informatiques

Certaines personnes estiment qu'apprendre un seul langage suffit, et qu'apprendre autant de langages est inutile. En fait, maîtriser un langage informatique supplémentaire adapté ne consiste pas seulement à acquérir un outil de plus pour gagner sa vie. Si un nouveau langage peut considérablement changer votre point de vue sur la programmation et la conception, alors il vaut peut-être la peine de l'apprendre.

Par exemple, le langage C peut cultiver une pensée rigoureuse ; les langages dynamiques, par exemple, peuvent aider les programmeurs à mieux faire de la programmation orientée objet ; les langages fonctionnels, par exemple, jouent un rôle irremplaçable dans les domaines de la production industrielle et du calcul.

Bien sûr, cela dit, comme le dit l'adage, « la maîtrise vient de l'expertise ciblée ». Une maîtrise approfondie d'un langage informatique particulier (y compris l'environnement d'exécution requis par le langage, et les principes de sa compilation ou interprétation) est très nécessaire.

De plus, on voit souvent des débats sur le langage informatique qui est meilleur ou moins bon. En dernière analyse, les langages informatiques sont des outils, et les outils sont améliorés et changés au fil de l'évolution du temps. Un simple débat pour savoir lequel est meilleur ou moins bon a peu de sens.

À propos de l'anglais

Pourquoi les Chinois doivent-ils apprendre l'anglais ? Pourquoi les programmeurs doivent-ils apprendre l'anglais ? Quand je nomme tous ces noms de méthodes et de variables en pinyin, ça marche tout aussi bien. Qui a établi cette foutue règle ?

Malheureusement, de nombreux supports d'apprentissage, articles et ressources techniques (en particulier certaines technologies récemment publiées) sont en anglais. D'autre part, les normes internationales et la manière courante dont les programmeurs communiquent sont toutes en anglais. Je pense qu'il serait certainement difficile d'imaginer à quoi ressemblerait le code source de ces frameworks et bibliothèques célèbres si les noms de variables étaient écrits en pinyin.

Donc, si votre anglais n'est pas bon (au moins en lecture et en écriture), ne cherchez pas d'excuses. L'anglais est un outil pour maîtriser d'autres outils, à moins que vous ne croyiez fermement que le chinois deviendra bientôt la langue la plus universelle au monde dans l'industrie informatique.

À propos des algorithmes

L'importance des algorithmes - cette question a toujours été très controversée.

Les logiciels, en dernière analyse, servent à résoudre des problèmes. Quand on parle d'algorithmes, on ne peut pas éviter de parler de mathématiques (c'est aussi pourquoi de nombreux maîtres dans le domaine du logiciel ont une solide formation mathématique). Pour résoudre des problèmes, cela peut se résumer simplement en deux étapes :

• (1) Abstraire le problème réel en un modèle mathématique simplifié
• (2) Utiliser des algorithmes pour résoudre ce problème mathématique

Le terme algorithme, ici, doit être compris comme un concept large (l’algorithme dont il est question ici ne désigne pas seulement les algorithmes spécifiques et étroits appris à l’université). Un algorithme est une méthode permettant de résoudre les problèmes mathématiques mentionnés ci-dessus. Si vous n’êtes pas conscient de son existence dans votre travail, cela signifie simplement que le modèle mathématique que vous avez abstrait est relativement simple, que la méthode de résolution de ce modèle est elle aussi simple, ou qu’il existe des approches toutes faites à imiter, ou encore qu’un framework prêt à l’emploi l’a fait pour vous, de sorte que vous n’y prêtez pas attention ou ne vous en souciez pas.

Si ce que vous faites revêt une grande portée innovante et constitue une chose que d’autres n’ont jamais faite auparavant, alors les algorithmes peuvent devenir le facteur qui détermine votre réussite ou votre échec.

Dans l’environnement actuel en Chine, les personnes dotées d’une vision large et d’une riche expérience sont faciles à trouver, mais il est en réalité très difficile pour les entreprises de recruter des personnes qui possèdent les deux capacités susmentionnées pour résoudre des problèmes.

À propos de l’expérience

Il y a beaucoup de personnes pour qui seule l’expérience compte. Elles croient que, dans les entreprises de logiciels, le poste, le salaire et même la capacité de décision dépendent tous de l’expérience. Un ingénieur avec 5 ans d’expérience peut certainement trouver un meilleur emploi qu’un ingénieur avec 3 ans d’expérience :

« Je suis un employé senior, j’ai travaillé pendant 5 ans. Pourquoi lui, qui n’a travaillé que 3 ans, obtient-il un salaire bien plus élevé que le mien ?! »

En fait, de nombreux facteurs, notamment l'accumulation de domaine (cela est lié au métier, comme le domaine d'Internet ou le domaine du logiciel traditionnel, qui n'a pas de relation directe avec ce qu'on appelle la technologie pure), la vision, la capacité à résister à la pression, etc., dépendent souvent en grande partie de l'accumulation de « l'expérience ». Cependant, ce n'est pas absolu. Il y a un dicton : « Une carrière se construit à moitié en faisant et à moitié en synthétisant. » En effet, certains programmeurs exceptionnels sont doués pour la synthèse, doués pour l'observation et l'accumulation, et doués pour la réflexion continue. De tels programmeurs sont ceux qui possèdent une expérience plus excellente.

D'un autre côté, les programmeurs sont là pour résoudre des problèmes. L'expérience ne peut pas remplacer la résolution de problèmes. Si certaines personnes ont de meilleures capacités de résolution de problèmes, pourquoi ne pourraient-elles pas obtenir un salaire plus généreux ?

Source : http://www.raychase.net/359