Page d'accueil > Programmation > ComputerScience > Technologie > The Clean Coder: un code de conduite pour les programmeurs professionnels Évaluation

The Clean Coder: un code de conduite pour les programmeurs professionnels

The Clean Coder: A Code of Conduct for Professional Programmers
Par Robert C. Martin
Avis: 30 | Évaluation globale: Bien
Lauréat du prix
14
Bien
10
Médias
4
Le mal
2
Terrible
0
Les programmeurs qui endurent et réussissent dans une incertitude tourbillonnante et une pression continue partagent un attribut commun: ils se soucient profondément de la pratique de la création de logiciels. Ils le traitent comme un artisanat. Ce sont des professionnels. Dans The Clean Coder: A Code of Conduct for Professional Programmers, le légendaire expert en logiciels Robert C. Martin présente les disciplines, les techniques,

Avis

05/12/2020
Reel Troendle

L'oncle Bob est à nouveau extrême et dépeint une personne, qui est notre objectif asymptotique, pas quelque chose que n'importe qui peut atteindre.

La surhumaine (alias The Clean Coder) est toujours responsable de ses actions, peut dire non même dans les moments les plus difficiles et aux gestionnaires et clients les plus difficiles, dort au moins 7 heures par jour, passe 20 heures par semaine pour son personnel professionnel développement, fait régulièrement la programmation de kata, fait TDD 100% du temps, n'écrit pas de fonctionnalités à moins qu'il y ait des tests d'acceptation, n'a pas besoin de la zone, se soucie autant des objectifs commerciaux que de la qualité technique, écrit des vérifications si elle a causé problèmes, refacteurs sans pitié.

Dans quelques endroits, Oncle Bob a mélangé les niveaux d'abstraction et les détails d'implémentation (TDD), alors que l'objectif supérieur d'avoir du code de travail aurait dû être l'objectif principal. De plus, certaines des histoires n'étaient pas les meilleurs exemples. Les années 70 étaient différentes :-)

En général, je l'ai beaucoup aimé. J'ai appris quelques choses, mais j'avais déjà entendu le plus de choses sous une forme ou une autre. C'est une bonne recommandation pour les amis.
05/12/2020
McCafferty Washam

Il y a des tonnes de livres similaires sur le marché. Le plus remarquable est "Pragmatic Programmer" d'Andy Hunt et Dave Thomas. Les deux livres couvrent un ensemble assez similaire de sujets - des aspects de conception à certaines pratiques spécifiques. La principale différence entre eux est que «programmeur pragmatique» couvre un ensemble plus large de sujets et avec beaucoup plus de profondeur.

Je vois quelques problèmes avec "The Clean Coder":

1. Des tonnes d'histoires inutiles de la vie personnelle des auteurs.
Dans la plupart des cas, ils ne sont pas très pertinents pour le sujet des chapitres et presque tout le temps

2. Livre sur le "codeur" parfait et le gestionnaire de vidage
Tout au long de plusieurs chapitres, vous pouvez voir des discussions similaires entre le gestionnaire et le développeur où le gestionnaire essaie d'imposer un délai qui devrait être atteint par tous les moyens par le développeur unique. Dans de nombreux cas, l'auteur suppose que le «codeur» doit être patient, sage, doit connaître les différentes pratiques de planification et conduire l'entreprise.

3. Absence de pratiques de codage
Le titre du livre suppose que les développeurs réguliers sont le public cible du livre. Mais ce livre ne comporte qu'un seul chapitre consacré au codage (chapitre 4) mais ce chapitre ne couvre aucune pratique de codage ni aucun sujet lié au codage. RIEN!

4. Des tonnes de répétition
Le livre contient au moins 3 endroits avec des paragraphes presque identiques sur FitNess. Certaines histoires sont répétées plusieurs fois. Je sais que DRY est un principe très difficile, mais la répétition de certaines choses non pertinentes ne semble pas professionnelle.

5. Arrogance et manque d'arguments
Dans certains cas, aucun argument ne prouve la pensée de certains auteurs. Par exemple, l'auteur affirme que tout le monde devrait s'efforcer d'obtenir une couverture de code à 100%, utiliser TDD et la programmation en paire tout le temps. J'apprécie une couverture de code raisonnable, une bonne conception et des tests automatisés et je crois que la programmation par paires est utile. Mais une couverture de code à 100% est nuisible, TDD en tant que pratique est subjective (les artefacts de cette pratique ne le sont pas, mais personne ne devrait imposer la façon dont ces artefacts seraient produits) et la programmation par paires n'est utile que dans certaines circonstances.

Ce livre est relativement petit et si vous excluez des récits presque inutiles, vous aurez à penser à un très petit ensemble de sujets. Il existe de nombreux livres de bien meilleure qualité (comme «Programmeur Pragmatique») qui vous encourageront vraiment et ouvriront votre esprit de «codeur» beaucoup mieux.

Examen plus approfondi en russe: http://sergeyteplyakov.blogspot.com/2...
05/12/2020
Migeon Vansant

J'ai tendance à lire au moins un de ces livres «comment être un programmeur plus professionnel» chaque année. Historiquement, ils ne m'ont pas impressionné. Celui-ci était la rare exception - il m'a vraiment parlé, pour une raison quelconque.

Rien dans ce livre n'est vraiment nouveau ou unique. Mais Martin a soulevé beaucoup de très bons points et certaines choses auxquelles je n'avais jamais vraiment réfléchi par le passé ont soudainement cliqué pour moi.

Je suppose que cela se résume vraiment à la présentation - Martin (pour la plupart) a présenté "les mêmes vieux trucs" que la plupart des livres dans ce domaine, mais il l'a présenté de la bonne manière pour moi. Ce n'est peut-être pas la bonne façon pour tout le monde, et ça va, mais c'est une lecture rapide et j'encourage tous les développeurs de logiciels à au moins essayer.
05/12/2020
Lusa Vandevelde

Surtout ce livre est assez bon. Il s'agit d'une série d'anecdotes sur la vie de l'auteur dans l'industrie du logiciel. Ils rappellent des choses que vous pourriez voir sur le quotidien, mais ils sont suivis d'une explication de la réponse correcte à chaque situation. Cela rend le livre plus lisible que le précédent de la série, qui était beaucoup plus technique. Cela rend également plus difficile l'application à sa propre vie. Il ne s'agit plus seulement de parcourir une liste de contrôle des points de style de code. Je suppose que dans l'ensemble, le lecteur a une idée de la «bonne» façon de gérer les interactions commerciales, mais je crains qu'il ne soit très vite oublié s'il ne le relit pas et ne prend pas de notes.

Il est intéressant de noter que de nombreux exemples présentent une mauvaise communication causée par une personne utilisant un langage ambigu pour éviter une confrontation. Par exemple, le patron insiste pour que le programmeur termine le projet dans la semaine même après avoir été informé que cela est impossible, alors le programmeur dit qu'il "essaiera de le faire". Le patron entend ce qu'il veut entendre et s'en va. L'auteur considère moralement cela comme un mensonge. Je pense qu'en Angleterre, cette utilisation du langage pour éviter les conflits est en fait considérée comme une vertu, donc je doute que nous puissions arrêter de le faire, mais peut-être qu'il a raison et que nous devrions être plus directs.

Bien sûr, je ne suis pas convaincu que les estimations de projet soient vraiment la chose qui aurait dû être utilisée dans tous les exemples de programmeurs collant à leurs armes contre les patrons, car je pense que les patrons doivent savoir que les estimations sont fréquemment divisées par un facteur de dix et il n'est donc pas complètement ridicule de s'attendre à ce que le programmeur raccourcisse son estimation.

Un problème persiste: la définition nébuleuse de «professionnel». Le lecteur est constamment rappelé qu'en tant que professionnel, il doit être autonome et ne pas avoir peur de dire non à son patron lorsqu'il en sait plus que le patron, ou lorsqu'on lui demande de faire quelque chose de «non professionnel». Des comparaisons sont faites avec des médecins et des avocats. Le problème est que ces professionnels sont des travailleurs indépendants. Ils sont embauchés par des clients mais ne travaillent pas pour des patrons. Bien qu'il soit possible pour un programmeur d'être un consultant indépendant de la même manière, ce n'est pas la norme, et tous les exemples présentés dans le livre sont des programmeurs qui sont des employés. Il existe des exemples de développement de logiciels pour les clients, mais les programmeurs ici sont toujours des employés d'une société de conseil et ne sont pas directement engagés par les clients.

La confusion est pire dans le premier chapitre, qui a failli faire abandonner le livre. L'auteur semble avoir complètement adhéré à la propagande utilisée par les capitalistes américains pour justifier de traiter leurs employés comme de la merde. Il nous dit que nous avons le devoir de travailler 60 heures par semaine - parce que nous sommes des «professionnels» et donc nous le devons à nous-mêmes - mais que puisque nous sommes des professionnels, nous sommes également responsables de notre propre bien-être et donc nous n'avons pas le droit de attendez-vous à toute sorte d'avantages de notre employeur. Fondamentalement, il s'attend à ce que les esclaves salariés travaillent avec la même ferveur que les propriétaires de l'entreprise. Un excellent exemple du truisme "Le socialisme n'a jamais pris racine en Amérique parce que les pauvres ne se considèrent pas comme un prolétariat exploité mais comme des millionnaires temporairement embarrassés."
05/12/2020
Hubble Charnley

Critique: The Clean Coder - et pourquoi je ne l'aime pas

Robert C. Martin en tant qu'auteur est probablement plus connu pour «Clean Code»
ce qui est aujourd'hui considéré comme une lecture incontournable pour les nouveaux collègues.

Son livre «Le codeur propre: un code de conduite pour les programmeurs professionnels» de 2011 examine une autre perspective du codage d'aujourd'hui et essaie d'enseigner «ce que signifie se comporter comme un véritable artisan logiciel». Dans mes propres mots: les aspects sociaux du travail quotidien d'un programmeur.

Ce que j'aime dans le livre

Les histoires de la vie réelle de Martin remontant aux années 70 donnent une idée de ce que c'était que d'être programmeur à cette époque - et du travail manuel qu'il impliquait. En outre, il est ouvert sur la façon dont il a échoué et pourquoi.
J'aime l'idée générale des chapitres «Dire non» et «Dire oui». C'est quelque chose d'important à apprendre. Cependant, les exemples sont très artificiels et difficiles à généraliser ...

Pourquoi je n'aime pas le livre

Fondamentalement, j'ai 3 principaux points de plainte concernant ce livre. Veuillez être conscient qu'ils sont mon opinion subjective et liés à mes situations quotidiennes et à mon expérience en tant que Product Owner.

1. Je pense que l'auteur voit Agile comme un processus pour améliorer le développement et les développeurs, pas comme un moyen de transformer les entreprises en un lieu plus centré sur l'homme et plus performant. En particulier, le livre ne va même pas dans le sens des mécanismes Scrum pour faire face à des situations typiques entre les parties prenantes et les équipes de développement.

2. les exemples de discussions entre «gestion» et «codeurs» sont si extrêmes que je préférerais changer le projet plutôt que de recommander une technique pour faire face à ce genre d'attentes irréalistes.

3. le livre n'enseigne aucune technique de réflexion, comment donner du feedback, comment gérer les conflits, comment communiquer, pas même un peu de psychologie. Pour moi, c'est un aspect principal sur lequel chaque développeur doit se pencher. Personnellement, j'ai le plus profité de ces informations.
Résumé

Pour être honnête, je pense que tout le point d'apprentissage de ce livre pourrait être ramené à 2 articles de blog de peut-être 10 pages avec beaucoup de liens vers des personnes qui ont expliqué les détails beaucoup mieux que Martin. Et 2 déclarations à garder à l'esprit.
Pour un débutant, ce livre pourrait convenir. À mon avis, parler à vos collègues fonctionne beaucoup mieux.

Article de blog 1
Ce sont les 10 choses que vous devriez penser et lire en tant que développeur de logiciels professionnel

Article de blog 2
Pourquoi j'ai échoué dans la vie de mes développeurs de logiciels professionnels et ce que j'en ai appris

Déclaration 1
Dites NON quand vous voudriez dire peut-être

Déclaration 2
Habituellement, un OUI est accompagné d'un ensemble de conditions. Rendez-les transparents.
05/12/2020
Roley Doten

Chapeau Robert Martin !!

Incroyable. M'a cliqué. C'est vraiment fantastique de se retrouver à dire "Oui, exactement. C'est ce que je cherchais." avec chaque ligne que vous lisez.

Je considère ce livre comme le complément ou l'autre face du livre Clean Code. Le code propre gère le côté technique et celui-ci gère le côté personnel. Vous devez les lire tous les deux!

La partie que j'ai le plus appréciée est la pratique et l'estimation. L'estimation n'est en effet pas du tout une tâche facile. J'ai fait face à de nombreuses situations difficiles dans lesquelles l'estimation en était le goulot d'étranglement.

De plus, le développement piloté par les tests et les stratégies de test sont le carburant pour moi maintenant pour commencer à travailler avec cette tendance et j'ai de grandes attentes à ce sujet.

Je recommande fortement ce livre à tous les développeurs qui veulent être professionnels - et qui ne le font pas? !! -.
05/12/2020
Dehnel Woofter

Dans la culture populaire, les programmeurs informatiques, parfois confondus avec les administrateurs système, sont souvent décrits comme des punks adolescents, assis dans l'obscurité, éclairés uniquement par la lueur de leur moniteur, des cartons vides de pizza et des bouteilles de Mountain Dew dispersées stratégiquement, piratant frénétiquement leur clavier.

Que signifie être programmeur professionnel? Porte-t-il un costume et une cravate pour travailler? Possède-t-il des certifications ou des diplômes décorant les murs de votre bureau? Travaille-t-il dur, parfois des heures supplémentaires et des week-ends, juste pour montrer votre dévouement?

Pour Oncle Bob, ce n'est pas ce que signifie un programmeur professionnel. Les choses généralement confondues avec le professionnalisme, comme un code vestimentaire, ne sont pas ce qui est important, à la fin de la journée. Cependant, faire en sorte que les développeurs agissent professionnellement envers le code et les uns envers les autres l'est.

"Clean Coder" est une collection d'anecdotes et d'histoires sur la carrière de programmation de 42 ans de Robert Martin, et il partage sa riche expérience de ce que signifie être un programmeur professionnel. C'est savoir quand dire non même aux gestionnaires les plus persistants, et dire oui en s'engageant dans une tâche et en soutenant votre engagement. C'est écrire le meilleur code possible en ne sacrifiant aucun des principes de bonnes pratiques de codage, même en période de pression. C'est demander de l'aide et aider les autres, au lieu de pirater avec vos écouteurs.

Si vous appréciez la profession que vous avez choisie, vous devriez certainement lire ce livre, surtout si vous travaillez dans un environnement d'entreprise moins qu'idéal - c'est à vous de conduire des changements dans votre lieu de travail, si les paramètres ne vous permettent pas d'agir professionnellement . Si votre entreprise n'utilise pas le contrôle de code source, configurez-le vous-même et assurez-vous d'apprendre à votre équipe comment l'utiliser. Si vous n'écrivez pas de tests unitaires ou n'attendez pas que QA teste les bogues - apprenez à tester votre code, afin que vous puissiez être sûr qu'il fonctionne. Gardez vos compétences pointues et vos outils plus pointus. Voilà ce que signifie être un programmeur professionnel!
05/12/2020
Rellia Danchetz

J'aime vraiment bien ça. J'aime le style dans lequel le livre est écrit et je pense que la majorité sinon la totalité des personnes dans ce domaine devraient le lire pour avoir un aperçu d'un peu d'histoire, d'expérience et de quoi faire pour devenir un professionnel. :)
05/12/2020
Vitkun Hannon

Robert C.Martin (1952-) programme professionnellement depuis 1970, mais a commencé à faire sa marque en tant que praticien et consultant en génie logiciel exceptionnel une fois qu'il a commencé à développer des logiciels orientés objet dans les années 1980 et plus tard lorsqu'il était parmi les signataires du Manifeste Agile (2001 ), a transformé une partie de son expérience en conception en cinq principes SOLID bien connus (2003) et a co-développé le cadre des tests d'acceptation FitNesse. Il est également un conférencier très recherché et puissant. Ce livre constitue la réflexion personnelle de Robert C. Martin sur ce que signifie être un développeur de logiciels professionnel - étant donné sa vaste expérience dans le domaine et son articulation, tout ingénieur logiciel agile orienté objet ou étudiant digne de ce nom devrait prêter attention à son mots.

Pour Martin, être un professionnel du logiciel est un ensemble comprenant l'attitude, le comportement, l'éthique et les habitudes de travail, le mentorat et l'apprentissage continu tout au long de la vie. Il s'agit de travailler quarante heures par semaine pour votre employeur et de consacrer encore vingt heures par semaine à suivre le domaine que vous avez choisi, il s'agit de savoir quand dire oui et, plus important encore, quand (et comment) dire non à votre employeur et vos clients. Il s'agit de faire des estimations honnêtes des efforts, d'assumer l'entière responsabilité de votre travail, de prendre des engagements contraignants, un grand savoir-faire, un travail d'équipe et une collaboration, une communication claire avec vos coéquipiers, vos collègues, votre employeur et vos clients. Il s'agit d'une gestion du temps disciplinée, d'une pratique incessante, de la maîtrise des bons outils et d'une pause quand c'est nécessaire.

Bien sûr, vous pourriez ne pas être d'accord avec tout ce que dit Martin; dans une mise en garde rare, il avertit le lecteur que ce qu'il présente fonctionne pour lui. Par exemple, je ne suis pas d'accord avec son rejet radical et cavalier de MDA (Model Driven Architecture) et UML. Je vous suggère de donner quelques-unes de ses suggestions - programmation en binôme, développement piloté par les tests (TDD), programmation de katas, timeboxing, planification de poker avec des estimations basées sur Pert - aller de l'avant avec un esprit ouvert; l'expérience sera enrichissante même si vous trouvez que les techniques qu'il recommande ne fonctionnent pas pour vous. Martin est plus un évangéliste pour les techniques de développement orienté objet agile qu'un évaluateur objectif, mais je n'ai pas trouvé que cela porte atteinte au livre, mais cela peut être parce que je suis d'accord avec l'essentiel de ses recommandations ;-)

Personnellement, j'ai trouvé les derniers chapitres marqués et l'annexe sur les outils qu'il préfère intéressants mais un peu trop brefs; par exemple, sa description du système de contrôle de version distribué Git laissera les lecteurs peu familiers avec ce sentiment un peu laissé de côté.

Si vous n’avez pas vu le personnage de «l’oncle Bob» Martin plus grand que nature en action, consultez quelques vidéos YouTube de ses discours -il est un superbe showman de la variété du feu et du soufre. Soyez averti que certains lecteurs peuvent trouver les explications de Martin trop superficielles, son style énergique trop égocentrique et juste et donc peu sympathique.

Un avantage supplémentaire pour moi en tant que proche contemporain de Martin a été le voyage dans le passé en racontant ses anecdotes sur ce que les jeunes lecteurs sont probablement l'histoire informatique ancienne: retours de chariot de machine à écrire et de téléscripteur et sauts de ligne, cartes perforées, mini-ordinateurs et liens comme exigences commerciales obligatoires pour les programmeurs, pour n'en nommer que quelques-uns.

Il y a beaucoup de bons conseils dans ce livre, mais, comme toujours, n'oubliez pas d'exercer vos facultés critiques - se battre intellectuellement avec Martin est, à mon avis, une excellente façon de construire le personnage dont vous avez besoin pour réussir professionnellement ...
05/12/2020
Loss Corvera

Eh bien, ce livre est une lecture incontournable pour tous les développeurs qui visent à être des professionnels et pas seulement des techniciens.
Ce n'est pas un livre technique, c'est une simple lecture facile expliquant les sujets avec des exemples réels. J'ai adoré le chapitre qui définit l'estimation de différents côtés («Les entreprises aiment voir les estimations comme des engagements. Les développeurs aiment voir les estimations comme des suppositions»). J'ai également aimé le chapitre qui traite de la gestion de la pression et de la façon dont une personne devrait s'appuyer sur ses disciplines dans de tels cas. L'oncle Bob souligne l'importance de la collaboration, de la programmation en binôme et du mentorat dans d'autres grands chapitres et je ne peux qu'être d'accord.
05/12/2020
Sergei Gailun

4.3 / 5 Ceci devrait être obligatoire pour tous ceux qui cherchent à améliorer leur savoir-faire en programmation.
05/12/2020
Ignacius Loh

Oui, "The Clean Coder" est une suite du "Clean Code" d'oncle Bob. Ceci est un excellent livre et explique ce que signifie vraiment être un développeur professionnel tel qu'il est délivré par une source bien respectée.

Le livre est très lisible et contient des conseils mélangés avec des histoires du passé et du dialogue de l'auteur. J'aime l'utilisation de la boîte de dialogue pour montrer les problèmes de communication comme dire «terminé» ou commettre trop. Même l'avant-propos était une histoire.

Je pense qu'il y avait trop de répétition des histoires entre les chapitres. Presque comme les chapitres ont été écrits de manière autonome. J'ai eu l'impression d'avoir lu plusieurs fois sur le même employeur (présenté de toutes pièces). C'était intéressant d'entendre parler du monde des cartes perforées avec des leçons et comment les choses ont changé. Idem pour FitNesse. Je comprends qu'il a des tests unitaires.

Le conseil est excellent. Mes trois préférés (qui étaient assez uniques pour la littérature informatique):
1) différence entre performance et pratique
2) TDD sur l'attaque contre la défense
3) Concentrer la manne sur la gestion du temps

Le seul conseil contre lequel je me suis fortement opposé est que le «flux» est une mauvaise chose. Tant que vous définissez le problème hors du flux, je ne vois pas le problème de vous isoler temporairement de la vue d'ensemble.

---
Divulgation: J'ai reçu une copie de ce livre de l'éditeur en échange de la rédaction de cette critique au nom de CodeRanch.
05/12/2020
Madeleine Mohrman

Un très bon livre, spécialement le chapitre 7, c'est super (estimer le calendrier des projets)
05/12/2020
Hernardo Dower

The Clean Coder

Un autre livre de Robert C.Martin! Je l'attendais. Je me souviens quand je suis arrivé
Le Clean Code, qui est l'un de mes livres préférés. J'en ai beaucoup appris
et c'est sur mon bureau depuis que je l'ai acheté.

Je pensais que The Clean Coder serait similaire. Malheureusement, j'ai des sentiments mitigés à ce sujet.
Tout d'abord ce n'est pas un livre technique. Vous n'en tirerez aucune valeur technique.
Il s'agit de compétences générales et de comment rester fou dans un environnement de codage.
Oui, cela peut parfois être difficile;)

Deuxièmement, je pense que ce livre n'est pas pour tout le monde. Développeurs moins expérimentés, comme les juniors
ou même des habitués, n'en tireront pas beaucoup de valeur. Il décrit des situations comme
dire NON au client ou comment estimer correctement les tâches et comment rester fort et ne pas changer vos estimations et vos meilleures pratiques sous la pression que tout le monde essaie de vous imposer. Lorsque vous commencez ou n'avez pas beaucoup d'expérience, ce genre de problèmes n'est pas si important pour vous. Je me souviens qu'ils ne le seront pas pour moi :) J'étais concentré sur les problèmes techniques et sur la fin de mes tâches. Je ne pensais même pas pouvoir dire non au client, je n'avais pas beaucoup d'expérience et de confiance en moi, et c'est normal.

Lorsque vous êtes plus expérimenté (ex. Senior ou chef d'équipe), ce livre vous donnera plus de valeur.
Dans ce livre, vous reconnaîtrez beaucoup de situations que vous avez eues dans le passé et vous ne saviez pas comment y faire face. Ce livre vous donnera la confirmation que vous devez suivre vos meilleures pratiques et ne pas vous plier sous la pression. Vous êtes expérimenté, vous avez des compétences techniques pour prendre de bonnes décisions et vous ne devriez pas les changer parce que quelqu'un vous le dit - sans bons arguments.

Puis-je classer ce livre?
Eh bien, je dois lui donner deux estimations. Pour les développeurs ayant moins d'expérience, je leur donnerai 2/5. Désolé Robert :(
D'autre part, si vous êtes plus expérimenté et que vous recherchez un livre qui vous aidera à gérer
avec des compétences non techniques, ce livre est pour vous. Je suis sur cette position en ce moment, et pour moi, c'est 3.8 / 5.
05/12/2020
Afra Lichter

Avait acheté ce livre avec le code Clean comme pack combo sur Kindle. J'ai plus apprécié ce livre, car c'est vraiment un petit livre.

Ici, Oncle Bob ne vous apprend rien sur le code, mais il explique ou martèle le fait que, ce que cela signifie d'être un développeur professionnel.

Certains chapitres comme

1. Quand dire oui
2. Quand dire non

J'ai vraiment aimé ces chapitres de tout le livre.

Le reste du livre me manque un peu car, je ne pense pas que ce soit la responsabilité du développeur de tout faire en équipe, car si c'était le cas, alors pourquoi avons-nous différentes disciplines en génie logiciel comme

1. Essai
2. Devops

En comparant également les développeurs aux médecins, je ne suis pas entièrement d'accord avec cela, car les deux sont des professions différentes, avec leur propre ensemble de défis.

De plus, il est parfois impossible pour un développeur de convaincre les responsables de la gestion, pourquoi avons-nous besoin de tests unitaires? Oncle Bob, vous devez convaincre sinon vous ne faites pas votre travail. Je ne suis pas d'accord avec de telles hypothèses tenaces.

Dans l'ensemble, le livre est une lecture OK, mais beaucoup de contenu dans le livre est devenu obsolète.
05/12/2020
Osrock Rastegar

Définir le professionnalisme dans le développement de logiciels

Il s'agit d'un livre de programmation, mais pas sur les algorithmes, les structures de données ou les modèles. C'est une définition précise du professionnalisme dans le domaine du logiciel, un ensemble de pratiques et d'attitudes qui séparent un programmeur professionnel du plus grand bassin de «personnes qui codent». Dans la mode typique de l'Oncle Bob, c'est opiniâtre, résolu et, bien, propre. Il codifie un grand nombre des leçons et des intuitions que les programmeurs expérimentés ont acquises au cours de leur carrière, et plaide pour eux avec un langage clair et idéaliste qui est facile à communiquer lors de l'élaboration des normes de votre propre équipe. Le développement de logiciels a souvent été le domaine des primadonnas, des sorciers, des super-héros et des cow-boys. Mais c'est un domaine mature maintenant, et ce livre est une belle description de ce à quoi ressemble la programmation adulte.

Les comportements décrits par Martin sont ambitieux. Asymptotique. Mais l'image qu'il peint est une cible utile et digne de viser, en tant que professionnel individuel, et en tant que département technique forgeant sa culture.
05/12/2020
Portia Gorenflo

Je suis fortement en désaccord avec la suggestion selon laquelle l'employeur n'a absolument aucune responsabilité pour le développement professionnel de ses employés et qu'en tant que programmeur, vous devez passer au moins 20 heures par semaine à la maison à faire du perfectionnement professionnel. Un employeur qui n'investit pas dans son personnel est incroyablement myope et (en général) pas quelqu'un pour qui vous voulez travailler. S'il parlait de développement personnel, je pourrais être d'accord, mais pas de développement professionnel dont j'ai besoin pour faire mon travail et que mon employeur a besoin que je continue à être un employé précieux.

Par exemple, je passe personnellement plus de 20 heures par semaine à lire (ou à aller à l'université) pour des intérêts personnels tels que la philosophie, la sociologie, le féminisme, les études religieuses, les études sur les minorités, la psychologie, etc. Est-ce que je considère ce développement professionnel? Non. Est-ce que je pense qu'ils font de moi un meilleur employé et peut-être un meilleur programmeur? Oui, absolument et sans réserve.

Je me demande également si 20 heures sont vraiment aussi réalistes que ce que l'on prétend. Les programmeurs juniors dans les petites entreprises peuvent être incroyablement mal payés par rapport à ce qu'ils font réellement (j'ai dû occuper 2 emplois et travaillé 60 heures par semaine pendant une partie de ma carrière). Est-ce aussi réaliste pour les familles monoparentales avec enfants où vous avez tant d'autres obligations (cuisine, ménage, rendez-vous, clubs / sports, etc.)? Cela ne serait-il pas difficile, même pour une famille à deux revenus? Je dois me demander. Cela m'apparaît comme une recette de burn out.
05/12/2020
Socher Latislaw

Un autre bon livre d'oncle Bob. Fondamentalement, il s'agit de savoir comment être un professionnel. Il parle de sa carrière, de ses erreurs, des meilleures pratiques, de la gestion du temps, des estimations et du travail sous pression. Le Clean Coder n'est pas uniquement destiné aux développeurs, c'est un livre d'auto-assistance pour quiconque souhaite maîtriser son domaine dans le monde d'aujourd'hui où les entreprises sont motivées par la collaboration et les technologies.
05/12/2020
Felise Osisek

Cela m'a rappelé ce que signifie être un développeur professionnel, mais a également donné des conseils pratiques sur la gestion des projets, l'approche du codage, etc.
05/12/2020
Pelagias Shry

Un peu trop de peluches, mais un excellent livre sur le professionnalisme dans l'industrie du logiciel
05/12/2020
Riley Delfierro

Fortement recommandé pour tous les programmeurs (en particulier ceux qui souhaitent se dire "professionnels").
05/12/2020
Selinda Meny

- Travailler 60 heures par semaine est une idée pratique.
- Il faut du temps pour construire une bonne équipe, alors ne cassez pas l'équipe. Donnez des projets à l'équipe.
05/12/2020
Silsby Wisterman

Ce livre est une lecture incontournable pour tous ceux qui souhaitent faire carrière en tant qu'ingénieur logiciel.
05/12/2020
Daniele Schonfeld

Grand livre, facile à lire, grandes histoires. Donne un résumé de la vie de la programmation et vous fait réaliser que la plupart des problèmes que vous traitez quotidiennement sont plus courants que vous!
05/12/2020
Missi Olejarz

Belles recommandations et expérience d'auteur comment devenir maître, développeur professionnel.
05/12/2020
Guglielma Scheiblich

Ce livre donne quelques perspectives importantes sur la façon dont les programmeurs professionnels doivent se conduire ainsi que sur l'ensemble des valeurs dont ils ont besoin pour adhérer. Il fait un point fort pour le développement piloté par les tests. C'est une lecture rapide avec quelques points intéressants à retenir.
05/12/2020
Katlin Beeck

Remarques

Critique de livre - Le codeur propre
Uncle Bob
Robert C. Martin

Être professionnel, c'est prendre possession et responsabilité

Premièrement: ne pas nuire (au fonctionnement ou à la structure)

Des bogues dans votre code nuisent à la fonction. Ne donnez pas de code à qa avant de l'avoir déjà testé.

Vous devez vous efforcer d'obtenir une couverture de test à 100%. Si une fonction est difficile à tester, elle doit être réécrite pour être plus facile à tester. TDD

Automatisez les tests. Si c'est plus facile, vous le ferez.

Refactoring impitoyable ou règle du boy-scout: laissez chaque module mieux que vous ne l'avez trouvé. Chaque fois que vous passez en revue, recherchez des améliorations. Si ceux-ci finissent par être plus difficiles à mettre en œuvre que prévu, cela peut refléter un problème de conception.

Les professionnels apprennent et se développent continuellement (même sur leur propre temps). La règle 40 + 20 est de passer 20 heures par semaine à développer vos compétences pour votre carrière.

Le travail est performance. Un professionnel a besoin de pratiquer. Faites du code kata, apprenez de nouvelles langues, essayez de nouvelles choses, collaborez, jumelez et obtenez un mentor.

Connaissez votre domaine et vos clients: apprenez un peu ce que vous écrivez (comptabilité, voyages). Assurez-vous que ce que vous faites n'est pas seulement conforme aux spécifications mais utile pour cette industrie.

Être humble. Vous pourriez être la prochaine personne à commettre une erreur.

Chapitre 2 - Dites non

Les professionnels disent la vérité au pouvoir et disent non à leurs managers.

Le compromis peut être contradictoire lorsque les objectifs ne sont pas parfaitement alignés: le gestionnaire a besoin d'un produit prêt à être démo et l'ingénieur doit construire de la bonne façon. Si le gestionnaire demande de se précipiter et de sauter des étapes, le professionnel dit non et travaille sur un compromis (retard, maquette, une fois, suivi d'un congé supplémentaire pour le programmeur, etc.).

Dire non est le plus important lorsque les enjeux sont élevés.

Chapitre 3 - dites oui

L'engagement est: dites-le, pensez-le, faites-le.

Les professionnels ne sont pas tenus de dire oui à chaque demande. S'ils disent oui, ils doivent honorer cet engagement et ne pas sacrifier la qualité du travail ou de la vie.

Chapitre 4 - codage

La maîtrise vient du sentiment de confiance et d'erreur.

1. Votre code devrait fonctionner. 2. Votre code devrait résoudre le problème du client (tel qu'il est réellement, pas nécessairement comme décrit). 3. Votre code doit s'intégrer dans le système sans augmenter la rigidité, la fragilité ou l'opacité. 4. Votre code doit être lisible par d'autres ingénieurs.

Assurez-vous que votre sommeil, votre style de vie et votre santé sont réglés afin que vous puissiez passer de bonnes heures de travail.

Les développeurs professionnels allouent leur temps personnel afin de permettre à leur temps de travail d'être aussi productif que possible. Mettez de l'ordre dans votre vie de famille et la tête parce que le code distrait est un mauvais code.

Entrer dans «la zone» est utile pour la pratique, mais le travail de production est souvent à courte vue ou limité lorsqu'il est dans la zone, de sorte que le code écrit devra probablement être retourné et corrigé plus tard.

Le temps de débogage est tout aussi cher que le temps de codage.

N'acceptez pas de faire des heures supplémentaires ou de longues heures surtout pendant plus de deux semaines et sans plan de secours si l'effort supplémentaire ne termine pas le projet.

Définissez terminé et ne laissez pas cette définition glisser. Vous ne reviendrez pas plus tard.

Obtenez de l'aide et aidez d'autres programmeurs.

TDD
1. Vous n'écrivez aucun code de production avant d'avoir écrit un test unitaire ayant échoué.
2. Vous n'écrivez pas plus d'un test unitaire que ce qui est suffisant pour échouer.
3. Vous n'écrivez pas plus de code de production que nécessaire pour réussir le test unitaire ayant échoué.

Bénéfices: certitude, taux d'injection de défauts, courage (pour faire des changements), documentation, conception.

Pratique:

Coder les kata pour vous former à être prêt à utiliser efficacement le code de production.

Wasa: paire de kata. Écrivez un test unitaire, puis votre partenaire écrit le code de production pour le réussir et le prochain test unitaire ayant échoué. Passez d'avant en arrière.

Randori: round robin group Wasa.

Entraînez-vous à votre rythme et contribuez à des projets open source. Apprenez de nouveaux cadres, langages, paradigmes.

7 - test d'acceptation

Évitez:
Précision prématurée
Le principe d'incertitude des clients
Anxiété d'estimation
Ambiguïté tardive

Terminé est terminé. Réussit tous les tests. Approuvé par l'AQ. Intervenant testé et approuvé. Aucun professionnel ne permet de valider le code que partiellement.

Idéalement, les analystes commerciaux rédigeraient les tests de «chemin heureux», car ils fournissent une valeur de processus.
Idéalement, le contrôle qualité rédigerait les tests de «chemin malheureux» car ils se préoccupent de ce qui peut mal tourner avec un produit.

Si un développeur pense qu'un test tel qu'il est écrit est erroné, il doit parler à l'auteur avec des suggestions pour le corriger. Soyez direct pour ce qui est le mieux pour le projet. Écrire du code pour passer un test uniquement est passif agressif et non professionnel.

Les tests d'acceptation ne sont pas des tests unitaires.
Les tests unitaires sont écrits pour les programmeurs par les programmeurs.
Les tests d'acceptation sont rédigés par l'entreprise pour l'entreprise.

Les tests unitaires et d'acceptation sont principalement la documentation de la conception, de la structure et du comportement. Qu'ils vérifient ce qu'ils précisent est un effet secondaire.

Le principe de responsabilité unique stipule que vous devez séparer les éléments qui changent pour différentes raisons et regrouper ceux qui changent pour la même raison.

Ecrivez des tests de règles métier par rapport à la même API que l'interface graphique utilise. Gardez la présentation séparée de la logique.

CI - Faites en sorte que votre génération de source et vos tests s'exécutent automatiquement à tout archivage de code. Partagez les résultats.

Unité, composant, intégration (performances et débit), système et enfin tests exploratoires (humains) manuels.

8 - Réunions - ont un ordre du jour et un objectif. Partez si vous en avez besoin. Déclinez si vous en avez besoin. Perdre son temps n'est pas professionnel.

Stand-ups: qu'est-ce que j'ai fait hier, que vais-je faire aujourd'hui, qu'est-ce qui m'arrête? Moins d'une minute par personne

Inversion prioritaire pour les tâches difficiles, évitez-la. N'évitez pas les tâches difficiles simplement parce qu'elles sont difficiles.

9 - Estimations. Les entreprises les considèrent comme des engagements et les développeurs les considèrent comme des suppositions.

Technique d'évaluation et d'examen des programmes (PERT) US Navy 1957: l'analyse trivariée consistait en des estimations optimistes, nominales et pessimistes.

Mu = (O + 4N + P) / 6 = durée prévue de la tâche.

Q = (P - O) / 6 est l'écart type de la distribution de probabilité de la tâche.

"Wideband Delphi" - un groupe se réunit pour discuter et estimer une tâche, en répétant leur estimation jusqu'à ce qu'ils parviennent à un accord.

Le développeur professionnel est calme et décisif sous pression.

Alertez les parties prenantes si vous n'êtes pas certain de pouvoir respecter vos engagements.

Les professionnels ne succombent pas à la tentation de faire un gâchis pour se déplacer rapidement.

Choisissez des disciplines que vous vous sentez à l'aise en cas de crise, puis utilisez-les tout le temps.

Sous pression: ne paniquez pas. Communiquer. Fiez-vous à votre discipline. Obtenir de l'aide.

La première priorité d'un professionnel est de répondre aux besoins de son employeur.

Les équipes sont plus difficiles à construire que les projets. Créez une équipe capable de passer d'un projet à l'autre plutôt que de créer une nouvelle équipe pour chaque nouveau projet.

Annexe A. Outillage.

Utilisez le contrôle de source. De préférence open source car ceux-ci ont été écrits fubu. Git sur CVS / SVN.

Apprenez à utiliser les fonctionnalités IDE. vi <emacs <intellij / eclipse <quel que soit l'éditeur qui cible spécifiquement la langue de votre choix.

Suivi des problèmes: utilisez Pivotal Tracker, Lighthouse, un kanban. Quelle est la taille de votre équipe et du projet? Ne pas trop ingénieur / trop payer pour cela.

Construction continue: utilisez Jenkins ou similaire connecté à votre contrôle de version pour que chaque enregistrement exécute automatiquement des tests et informe l'équipe des changements de rupture. Tout commit qui rompt le programme doit être considéré comme un stop show et tous les programmeurs doivent collaborer jusqu'à ce qu'un commit fixe passe la construction / test.

Ne commettez jamais un changement de rupture. Exécutez la génération sur votre machine et assurez-vous qu'elle fonctionne avant de l'archiver.

Les tests unitaires doivent être rapides et faciles à exécuter, indiquer la réussite ou l'échec, indiquer la progression du test, faciles à écrire et décourager les tests individuels de communiquer entre eux.

Test des composants: devrait être écrit par l'entreprise + AQ si possible et décrire ce que l'entreprise considère que le programme fait ce qui était prévu. Test au niveau de l'API.

Les outils de test des composants sont le moyen par lequel nous spécifions qu'une tâche doit être effectuée. L'entreprise a convenu que c'est ce qu'elle devrait faire, lorsqu'elle réussit ce test, elle est terminée.

Outils de test de composants Bob aime: fitnesse, robotfx, poivron vert, concombre, jbehave.

Test d'intégration: les tests d'interface utilisateur sont fragiles, mais les tests d'existence (rendu) de l'interface utilisateur devraient l'être. Les tests de bout en bout doivent également tester l'interface utilisateur.

Bob aime le sélénium et waitr pour les tests d'interface utilisateur.

UML / Model Driven Architecture était censé faire de la programmation en texte une chose du passé. Les architectes concevraient un système à un niveau élevé via des diagrammes et le transmettraient à un interprète pour écrire le code réel.
Cela n'a pas fonctionné car tout est compliqué et les codeurs doivent savoir gérer les détails qui seraient très difficiles à utiliser avec MDA.

L'histoire de la nouvelle ligne et du retour chariot / n / r a été discutée et comment nous luttons toujours avec cela car il a été transféré des machines physiques au code informatique par les humains. Soit ne pas accepter ou oublier / se méprendre sur la spécification.

Les programmeurs doivent gérer ces détails.
05/12/2020
Ewall Tarrenis

for (int i = 0; i <Integer.MAX_VALUE; i ++) {
System.out.println ("Le meilleur livre de tous les temps!");
}
Pas vraiment. Vous avez lu ce livre après Clean Code, programmeur pragmatique. C'est exactement ce dont vous avez besoin lorsque vous vous conduisez dans le sens de l'artisanat.
05/12/2020
Oskar Kriner

Consultez également sur mon blog à: http://codependentcodr.blogspot.ca/20...

Ce livre est en grande partie un suivi de l'autre livre très connu de Martin "Clean Code". Alors que ce livre se concentre sur les artefacts (code) que nous développons, ce livre se concentre sur le développeur lui-même. Comment devons-nous agir en tant que développeurs professionnels? Quelle est la différence entre un engagement et une estimation? Quelles sont nos responsabilités? Quand pouvons-nous dire non et comment le faire? Quand sommes-nous obligés de dire oui? Comment pouvons-nous nous améliorer dans ce que nous faisons?

Martin essaie de distiller ses près de 40 ans d'expérience en quelques leçons durement disputées. Bien qu'il soit très apprécié d'entendre des «contes des tranchées», le livre a un ton assez «rigolo comme je dis». Ne fais pas TDD? Eh bien, vous n'êtes pas un professionnel. Créez-vous des estimations ambitieuses? Eh bien, vous n'êtes pas un professionnel. D'un point de vue rhétorique, le livre s'appuie sur cette approche de la «preuve par appel au professionnalisme», plutôt que de fournir des preuves et des données solides pour étayer bon nombre des arguments qu'il avance. Par exemple, le chapitre TDD a le passage:


Yes there have been lots of controversial blogs and articles written about TDD over the years and there still are. In the early days they were serious attempts at critique and understanding. Nowadays, however, they are just rants. The bottom line is that TDD works, and everybody needs to get over it.

Je pense que le paragraphe aurait dû se terminer par "QED". À peine un argument concluant en faveur de TDD, et le rejet direct de toute critique de la pratique nuit vraiment à son argumentation.

Cela dit, il est certainement clair qu'une grande partie de ce qu'il offre est de bons conseils et représente un défi ouvert pour que les développeurs soient meilleurs. Si vous mettez de côté la rhétorique «si vous ne faites pas cela, vous n'êtes pas professionnel», ce livre est fondamentalement un appel aux développeurs à assumer la responsabilité du travail pour lequel ils ont été embauchés. Souvent, en tant que développeurs, nous aimons nous cloisonner, nous concentrer sur nos tâches techniques étroitement définies, ce qui est tout simplement irréaliste. Une partie de la responsabilité d'être un développeur est de comprendre le contexte du travail que vous faites, pourquoi il est important et pourquoi il ajoute de la valeur au client / client / entreprise / etc. Et si cette valeur n'est pas là, c'est à vous de la trouver.

En tant que tel, j'ai trouvé ce livre à la fois rafraîchissant et terrifiant. Rafraîchissant d'entendre une voix de la communauté agile qui ne semble pas sentir que l'OP est la seule entité responsable d'identifier la valeur.
Terrifiant de penser qu'en tant que développeur de logiciels introverti, j'ai le devoir de faire plus que de simplement écrire du bon code propre.

En termes de structure, le livre est divisé en 14 chapitres différents couvrant chacun un sujet intéressant les développeurs professionnels. Bien qu'il y ait une discussion technique, elle est relativement rare, dans l'ensemble les sujets du chapitre se concentrent sur les compétences "non techniques" plutôt que techniques.

Dans l'ensemble, bien que brutal et parfois "moralisateur", c'est une lecture intéressante pour quiconque envisage ou mène une carrière dans le développement de logiciels.

Laisser un avis pour The Clean Coder: un code de conduite pour les programmeurs professionnels