Thinking in C: Foundations for Java & C++, de Chuck Allison (un séminaire sur CD-ROM de MindView, Inc., ©2000, attaché au dos de ce livre et également disponible sur www.BruceEckel.com). C'est un cours qui inclut leçons et transparents sur les bases du langage C pour vous préparer à apprendre le Java ou le C++. Ce n'est pas un cours de C exhaustif ; il ne contient que le strict nécessaire pour aller vers les autres langages. Des sections supplémentaires spécifiques à d'autres langages introduisent des caractéristiques pour le futur programmeur C++ ou Java. Pré-requis recommandés : de l'expérience dans un langage de programmation de haut niveau, comme Pascal, Basic, Fortran ou LISP (il est possible de tracer son chemin à travers les CD sans cette expérience, mais le cours n'est pas conçu comme une introduction aux bases de la programmation).

The C++ Programming Language, 3rd edition, de Bjarne Stroustrup (Addison-Wesley 1997). D'un certain point de vue, le livre que vous tenez en ce moment a pour but de vous permettre d'utiliser le livre de Bjarne comme référence. Comme ce livre contient la description du langage par l'auteur de ce langage, c'est typiquement l'endroit où vous irez pour résoudre n'importe quelle incertitude concernant ce que le C++ est supposé faire ou ne pas faire. Quand vous vous serez fait la main sur le langage et serez prêt pour passer aux choses sérieuses, vous en aurez besoin.

C++ Primer, 3rd Edition, de Stanley Lippman et Josee Lajoie (Addison-Wesley 1998). Plus vraiment un livre d'introduction ; il s'est tranformé en un livre épais rempli de beaucoup de détails, et c'est celui que j'utilise avec celui de Stroustrup quand j'essaye de résoudre un problème. Penser en C++ devrait fournir une base pour comprendre C++ Primer ainsi que le livre de Stroustrup.

C & C++ Code Capsules, de Chuck Allison (Prentice-Hall, 1998). Ce livre suppose que vous connaissiez déjà le C et le C++, et couvre certains problèmes sur lesquels vos pouvez être rouillés, ou que vous pouvez ne pas avoir bien compris au début. Ce livre bouche des trous en C comme en C++.

The C++ Standard. C'est le livre sur lequel le comité a travaillé si dur pendant toutes ces années. Il n'est pas gratuit, malheureusement. Au moins, vous pouvez acheter la version électronique en PDF pour seulement 18 dollars à www.cssinfo.com.

19.2.1. Ma propre liste de livres▲

Ces livres s'enfoncent plus profondément dans le langage, et vous aident à éviter les embûches habituelles inhérentes au développement de programmes C++.

Effective C++(2nd Edition, Addison-Wesley 1998) et More Effective C++(Addison-Wesley 1996), de Scott Meyers. Le classique à posséder absolument pour la résolution sérieuse de problèmes et la conception de code en C++. Je me suis efforcé de capturer et exprimer beaucoup des concepts de ces livres dans Penser en C++, mais je ne m'abuse pas à penser que j'y suis parvenu. Si vous passez un temps significatif avec le C++ vous finirez avec ces livres. Disponibles également sur CD-ROM.

Ruminations on C++, de Andrew Koenig et Barbara Moo (Addison-Wesley, 1996). Andrew a travaillé directement avec Stroustrup sur beaucoup d'aspects du C++ et est une autorité fiable en la matière. J'ai également trouvé rafraichissante sa perspicacité incisive, et j'ai beaucoup appris de lui, par écrit et en personne, au long des années.

Large-Scale C++ Software Design, de John Lakos (Addison-Wesley, 1996). Couvre des problèmes et répond à des questions que vous rencontrerez pendant la création de grands projets, mais souvent de plus petits aussi.

C++ Gems, Stan Lippman, editeur (SIGS publications, 1996). Une sélection d'articles de The C++ Report.

The Design & Evolution of C++, de Bjarne Stroustrup (Addison-Wesley 1994). Des explications de l'inventeur du C++ sur les raisons pour lesquelles il a pris certaines décisions. Pas essentiel, mais intéressant.

Extreme Programming Explained par Kent Beck (Addison-Wesley 2000). J' adore ce livre. Oui, j'ai tendance à avoir une approche des choses radicale, mais j'ai toujours senti qu'il pourrait y avoir un procédé de développement de programme très différent et bien meilleur, et je pense que XP s'en approche diablement. Le seul livre qui a eu un impact similaire sur moi fut PeopleWare(décrit ci-dessous), qui parle avant tout de l'environnement et traite de la culture d'entreprise. Extreme Programming Explained parle de programmation et bouleverse la plupart des choses, même les récentes “découvertes”. Ils vont même jusqu'à dire que les les images sont acceptables tant que vous ne passez pas trop de temps dessus et êtes prêts à vous en débarrasser. (Vous remarquerez que ce livre ne comporte pas“de logo de certification UML” sur sa couverture.) Je pourrais imaginer que l'on décide de travailler pour une société en fonction du seul fait qu'ils utilisent XP. Petit livre, petits chapitres, se lit sans effort, excitant d'y penser. Vous commencez à vous imaginer travailler dans une telle ambiance et cela fait naître les visions d'un monde complètement nouveau.

UML Distilled par Martin Fowler (2éme édition, Addison-Wesley, 2000). Quand vous rencontrez UML pour la première fois c'est d'abord intimidant à cause du nombre de diagrammes et de détails. D'après Fowler, la plupart de ces choses ne sont pas nécessaires donc il réduit à l'essentiel. Pour la plupart des projets, vous n'avez besoin de conaître que quelques outils de diagramme, et le but de Fowler est d'arriver à une bonne conception plutôt que de s'inquiéter de toutes les façons d'y arriver. Un petit livre agréable, fin et lisible ; le premier à vous procurer si vous avez besoin de comprendre UML.

The Unified Software Development Process par Ivar Jacobsen, Grady Booch, et James Rumbaugh (Addison-Wesley 1999). Je suis entré dans ce live en étant tout prêt à ne pas l'aimer. Il semblait avoir toutes les qualités d'un ennuyeux texte d'université. J'ai été heureusement surpris – seul l'emballage du livre contient des explications qui donnent l'impression que ces concepts ne sont pas clairs pour les auteurs. Le coeur du livre est non seulement clair, mais également agréable. Et le meilleur de tout, le procédé contient beaucoup de sens pratique. Ce n'est pas de l'"Extreme Programming" (et n'a pas leur clarté sur les tests) mais c'est aussi un élément de la force de frappe écrasante d'UML – même si vous ne pouvez pas faire adopter XP, la plupart des gens ont grimpé dans le train du mouvement “UML est bon” (indépendamment de leur réel niveau d'expérience en la matière) et vous pouvez donc probablement obtenir son adoption. Je pense que ce livre devrait être le livre phare d'UML, celui que vous pouvez lire après UML Distilled de Fowler, quand vous voulez plus de détails.

Avant que vous ne choisissiez une méthode, il est utile d'avoir le point de vue de ceux qui n'essayent pas d'en vendre une. Il est facile d'adopter une méthode sans vraiment comprendre ce que vous voulez en tirer ou ce qu'elle fera pour vous. D'autres l'utilisent, ce qui semble une raison suffisante. Toutefois, les humains ont un étrange petit caprice psychologique : s'ils veulent croire que quelque chose résoudra leurs problèmes, ils l'essaieront. (C'est l'expérimentation, ce qui est bon.) Mais si cela ne résout pas leurs problèmes, ils peuvent redoubler leurs efforts et commencer à annoncer haut et fort quelle grande chose ils ont découvert. (C'est du déni, ce qui n'est pas une bonne chose.) L'hypothèse ici pourrait être que si vous pouvez faire monter d'autres personnes dans le même navire, vous ne vous retrouverez pas seul, même si ça ne va nulle part (ou si ça coule).

Ce n'est pas pour insinuer que les méthodologies ne mènent nulle part, mais que vous devriez être armés jusqu'aux dents avec des outils mentaux qui vous aident à rester en mode expérimentation (“Ca ne fonctionne pas ; essayons autre chose”) et hors du mode déni (“Ce n'est pas vraiment un problème. Tout est merveilleux, nous n'avons pas besoin de changer”). Je pense que les livres suivants, lus avant de choisir une méthode, vous fourniront ces outils.

Software Creativity, par Robert Glass (Prentice-Hall, 1995). C'est le meilleur livre que j'ai vu qui discute du point de vue de toute la question de la méthodologie. C'est une collection de courts essais et de papiers que Glass a écrit et parfois acquis (P.J. Plauger est un contributeur), reflétant ses nombreuses années d'étude et de réflexion sur le sujet. Ils sont divertissants et juste assez longs pour dire ce qui est nécessaire ; il ne radote ni ne vous ennuie. Il ne fait pas simplement des effets de manches, non plus ; il y a des centaines de références à d'autres papiers et d'autres études. Tous les programmeurs et managers devraient lire ce livre avant de patauger dans le marais de la méthodologie.

Software Runaways: Monumental Software Disasters, par Robert Glass (Prentice-Hall 1997). La grande chose avec ce livre est qu'il met en avant ce dont on ne parle pas : combien de projets non seulement échouent, mais échouent spectaculairement. Il me semble que la plupart d'entre nous pense encore “Ca ne peut pas m'arriver” (ou “Ca ne peut encore se produire !”) et je pense que cela nous désavantage. En gardant à l'esprit que les choses peuvent toujours aller mal, vous êtes en bien meilleure position pour qu'elles aillent bien.

Object Lessons par Tom Love (SIGS Books, 1993). Un autre bon livre de point de vue.

Peopleware, par Tom Demarco et Timothy Lister (Dorset House, 2ème edition 1999). Bien qu'ils aient une expérience dans le développement de logiciels, ce livre traite des projets et des équipes en général. Mais l'accent est mis sur les personnes et leurs besoins plutôt que sur la technologie et ses besoins. Ils décrivent la création d'un environnement où les gens sont heureux et productifs, plutôt que de décider des règles que ces personnes devront suivre pour être les composants adéquats d'une machine. Je pense que cette dernière attitude est la grande responsable du comportement de certains programmeurs qui sourient et approuvent quand on adopte une méthode ou l'autre et continuent tranquillement à faire ce qu'ils ont toujours fait.

Complexity, par M. Mitchell Waldrop (Simon & Schuster, 1992). Ce sont les chroniques d'un groupe de scientifiques de différentes disciplines à Santa Fe, New Mexico, qui discutent de réels problèmes que les disciplines individuelles ne pouvaient pas résoudre (le marché boursier en économie, la formation initiale de la vie en biologie, pourquoi les gens font ce qu'ils font en sociologie, etc.). En croisant la physique, l'économie, la chimie, les mathématiques, l'informatique, la sociologie et autres, une approche multidisciplinaire de ces problèmes se développe. Mais plus important, une nouvelle manière d' aborder ces problèmes ultra-complexes émerge : loin du déterminisme mathématique et de l'illusion que vous pouvez écrire une équation qui prédit tous les comportements, il s'agit plutôt d' observer et de chercher un modèle et d'essayer d'émuler ce modèle par tous les moyens. (Le livre raconte, par exemple, la naissance des algorithmes génétiques.) Je crois que ce mode de pensée est utile quand nous observons des manières de gérer des projets de logiciels de plus en plus complexes.