Programmeur fanatique. Résumé partie 2 + tableau abstrait. Poissons, géants et mentors

Dans les commentaires de la première partie, certains ont écrit que le synopsis peut être raccourci. Mais dans ce cas, les transitions logiques seraient perdues quelque part. Par conséquent, pour ceux qui veulent très brièvement et seulement de manière concise l'essence même, j'ai fait un tableau récapitulatif . Elle est à la toute fin de l'article. Il y a aussi un vote avec la question "Quel est le succès de ce format?"


Partie 2. Investir dans votre produit


Fowler se considère comme un musicien très talentueux (nous croyons sur parole). En raison de la facilité avec laquelle il a pu jouer, il a rapidement grandi au tout début de sa carrière et s'est presque arrêté à la fin.

Il a cessé d'être exigeant envers lui-même et a cessé d'investir dans ses compétences professionnelles. Et investir consciemment dans votre carrière (de diverses manières) est l'une des idées clés de tout le livre.

Astuce 11. Apprendre à pêcher


Il n'y a aucun moyen de se passer d'une métaphore, sinon le titre de ce chapitre ne sera pas clair.
Lao Tzu a déclaré: «Donnez un poisson à l'homme et il sera rassasié toute la journée. Apprenez-lui à pêcher et il sera rassasié toute sa vie. "

Poissons dans le développement de logiciels:

Processus de travail avec un outil, un certain aspect de la technologie ou certaines informations du secteur d'activité dans lequel vous travaillez.

La possibilité de tester une partie spécifique du système de gestion de code source avec lequel votre équipe travaille, ou de configurer le serveur d'applications.
etc.

Le conseil, de mon point de vue, est similaire au conseil 8. Soyez un spécialiste (profondément versé dans votre domaine) et le conseil 7. Soyez un généraliste (versé dans des domaines connexes).

Dans les commentaires de la première partie, certains ont écrit sur la contradiction entre ces deux conseils.

Pour citer un utilisateur lxsmkv interprétant cette idée de Fowler:

Il n'y a aucune contradiction. Cela fait référence à ce que l'on appelle maintenant les personnes en forme de T en agile. Vous avez un domaine très développé, mais vous comprenez les domaines connexes liés au cycle de vie du logiciel.

Astuce 12. Comprenez comment fonctionne une entreprise.


Hm. Tout est dans le titre, le reste est de l'eau. Astuce: pour comprendre comment fonctionne la composante financière de l'entreprise, dont le développement fait partie.

L'auteur du livre recommande fortement d'étudier le livre de Steven Silbiger «MBA en 10 jours» (Steven Silbiger «The Ten-Day MBA»). Je n'ai pas lu ce livre, donc je ne peux rien en dire, mais les notes et les critiques semblent bonnes.



Astuce 13. Trouvez un mentor


Nous parlons d'une personne plus expérimentée qui parfois incitera et donnera le sens du mouvement pour une étude indépendante.

Astuce 14. Devenez un mentor


Si vous voulez vraiment apprendre quelque chose, essayez d'enseigner cela à quelqu'un d'autre. Il n'y a pas de meilleur moyen de généraliser votre compréhension du problème que de vous forcer à expliquer des choses étranges à une autre personne pour qu'elle comprenne tout.

Astuce 15. Pratiquez, pratiquez et répétez


Fowler conseille de prendre du temps pour les exercices de programmation et la logique.
Ces tâches se trouvent sur de nombreux sites. Par exemple, sur ceux-ci:


Astuce 16. Approche du travail


Parfois, il semble que le titre des conseils ait peu à voir avec l'idée du chapitre.

Il est recommandé d'étudier les pratiques de développement de logiciels. Un autre domaine à explorer pour le conseil 7. Soyez un généraliste.

Astuce 17. Sur les épaules des géants


Apprenez du code et des modèles étrangers de qualité.

Astuce 18. Automatisez les tâches


Si quelque chose se répète souvent, il est logique d'automatiser. Ou d'une autre manière: s'il est conseillé d'automatiser quelque chose, il est logique de le faire.

Recommande d'apprendre l'architecture pilotée par les modèles - Architecture pilotée par les modèles.

Pensez aux petits problèmes auxquels votre groupe est confronté chaque jour.

Faites-en la liste sur papier. Quelles sont ces petites choses ennuyeuses qui font que le groupe perd chaque jour quelques minutes avec lesquelles personne ne peut ou ne veut rien faire?

Quelles tâches manuelles du projet actuel pourraient être automatisées? Faites-en la liste.

Il est temps de clarifier le synopsis lui-même. Le but de l'abrégé est de transmettre le plus fidèlement possible les pensées de l'auteur du livre sous la forme la plus concise. Par conséquent, même les choses évidentes, je pars toujours. Par exemple, les modèles. Tout le monde comprend qu'ils doivent savoir. Mais je le laisse une fois que Fowler a écrit à ce sujet, ainsi que ses pensées controversées.

Fowler n'est pas un prophète et ses approches sont sa vision subjective de ces problèmes et la solution aux problèmes auxquels le développeur est confronté.

Et maintenant, le tableau récapitulatif promis pour la deuxième partie du livre



Partie 1


3e partie


Partie 4 et 5

Source: https://habr.com/ru/post/fr481458/


All Articles