Les bons développeurs savent qu'ils passeront plus de temps à relire leur code et à le modifier qu'ils n'en ont mis à l'écrire. Ce livre vous explique les principes et les bonnes pratiques du refactoring, en indiquant où et comment commencer à analyser son code pour l'améliorer de façon efficace quel que soit le langage utilisé. Depuis plus de vingt ans les développeurs confirmés du monde entier font confiance à ce livre de Martin Fowler pour améliorer leur code, en faciliter la maintenance et rendre leur programme plus facile à comprendre par autrui. Cette nouvelle édition très attendue a été entièrement actualisée pour tenir compte des évolutions du domaine de la programmation. Elle dresse un catalogue àjour des refactorings et comporte des exemples de code en Javascript. La version française de cette 2e édition inclut un accès gratuit aux ressources complémentaires en ligne (en anglais) de ce livre de référence.

Refactoring - Comment améliorer le code existant

UML apporte la garantie d'un langage universel compris par tous les informations et leurs clients.
Cet ouvrage est un guide clair et concis qui aborde les aspects essentiels d'UML. Il débute par un résumé de l'histoire d'UML, de son développement et de sa logique, puis analyse la façon dont il peut être intégré au processus de développement orienté objet. A l'aide de nombreux exemples, il vous présente également les grandes lignes des différentes techniques de modélisation - cas d'utilisation, diagrammes de classe, diagrammes d'interaction, etc. - et décrit leur sémantique.

Maintenant adopté comme standard de facto de l'industrie, et cautionné par l'OMG (Object Management Group), UML est une notation que tous les développeurs se doivent de connaître et de comprendre. Il apporte la garantie d'un langage universel, compris par tous les informaticiens et leurs clients. Cet ouvrage est un guide clair et concis qui aborde les aspects les plus essentiels d'UML. Il débute par un résumé de l'histoire d'UML, de son développement et de sa logique, puis analyse la façon dont il peut être intégré au processus de développement orienté objet. A l'aide de nombreux exemples, il vous présente également les grandes lignes des différentes techniques de modélisation - cas d'utilisation, diagrammes de classe, diagrammes d'interaction, etc. - et décrit leur sémantique.

Je ne peux pas choisir si quelqu'un est offensé par mes actions. Je peux choisir si je m'en soucie.

Tout imbécile peut écrire du code qu'un ordinateur peut comprendre. Les bons programmeurs écrivent du code que les humains peuvent comprendre.

Je ne peux penser qu'à tant de bonnes idées en une semaine. Avoir d'autres personnes contribue à ma vie plus facile.

Jamais dans les annales de l'ingénierie logicielle n'a été tant due à tant de gens à si peu de lignes de code

L'une des choses que j'ai essayé de faire est de rechercher des règles plus simples ou des règles qui sous-tendent une bonne ou une mauvaise conception. Je pense que l'une des règles les plus précieuses est d'éviter la duplication. "Une fois et une seule fois" est la phrase de programmation extrême.

L'un des grands dangers est de prétendre que vous pouvez suivre un processus prévisible lorsque vous ne pouvez pas.

Dans presque tous les cas, je suis opposé à réserver du temps pour refactoriser. À mon avis, le refactorisation n'est pas une activité que vous avez mis de côté. Le refactorisation est quelque chose que vous faites tout le temps dans de petites rafales.

Il est impossible de ne pas remarquer Ruby sur les rails. Il a eu un effet énorme à la fois en dehors de la communauté Ruby ... Rails est devenu une norme à laquelle les outils à bien-être, même à bien, se comparent.

Quand utiliser le développement itératif? Vous devez utiliser le développement itératif uniquement sur les projets que vous souhaitez réussir.

Pourquoi la composition des symphonies est-elle difficile? Je ne sais pas. C'est juste que très peu de gens dans le monde peuvent bien le faire. Et je pense que c'est le cas avec le design initial. C'est très difficile de bien faire.

J'espère donc que j'ai clairement indiqué que l'imposition de méthodes agiles est un drapeau très rouge.

Le plus gros problème des équipes logicielles est de s'assurer que tout le monde comprend ce que tout le monde fait.

J'ai appris à toujours éviter de dire "toujours"

Lorsque vous vous asseyez réellement pour écrire du code, vous apprenez des choses que vous n'avez pas obtenues en pensant à eux en termes de modélisation ... il y a un processus de rétroaction là-bas que vous ne pouvez vraiment que de l'exécution de certaines choses et de voir ce qui fonctionne

L'intégration continue est une pratique de développement de logiciels où les membres d'une équipe intègrent fréquemment leur travail, généralement chaque personne intègre au moins quotidiennement - conduisant à de multiples intégrations par jour. Chaque intégration est vérifiée par une version automatisée (y compris le test) pour détecter les erreurs d'intégration le plus rapidement possible. De nombreuses équipes constatent que cette approche entraîne une réduction considérablement de problèmes d'intégration et permet à une équipe de développer plus rapidement des logiciels cohérents.

Maintenant, je suis une personne assez paresseuse et je suis prêt à travailler assez dur pour éviter le travail.

Je trouve que les tests d'unité d'écriture augmentent en fait ma vitesse de programmation

En comparaison avec une autre activité, il est utile si cela vous aide à formuler des questions, c'est dangereux lorsque vous l'utilisez pour justifier les réponses.

Ses oeuvres

Ses derniers livres