Est-ce que le conseil d'un programmeur expérimenté d'utiliser toujours des livres est une bonne idée? [fermé]


53

Je suis un développeur junior et je ne suis dans l'industrie que depuis 5 ans. Dans mon entreprise actuelle, il y a une personne âgée, appelons-la Infestus. Parfois, on me donne l'occasion de briller et de faire quelque chose de complètement neuf à partir de zéro.

L'un des exemples les plus récents est que j'ai dû créer un singleton dans l'application multithread. J'ai décidé d'utiliser cette méthode. Dès qu'Infestus l'a vu, il a rapidement commencé à me traiter de stupide et m'a dit d'utiliser cette approche . Quand il lui a demandé pourquoi il l’avait simplement effacé, c’est mieux et c’est comme cela que ce livre sur Java dit que c’est mieux.

Et c’est un schéma habituel: chaque fois que j’ai la possibilité de faire quelque chose de nouveau, Infestus me rabaisse rapidement et la seule raison pour laquelle sa méthode est meilleure, c’est que ces livres ont été écrits par des programmeurs célèbres. Il essaie toujours de me donner des livres à lire pour que je puisse "apprendre" les manières de programmer.

Je ne programme que de l'argent depuis 5 ans, mais est-ce toujours une bonne idée de simplement suivre aveuglément le livre sur les meilleurs moyens de résoudre un problème, ou dois-je essayer de faire des expériences de temps en temps? Le flot incessant de plaintes de l'Infestus commence à m'obliger à ne jamais essayer quoi que ce soit de nouveau et à suivre des exemples dans des livres.

EDIT : Je suis complètement perdu. Oui, je sais que suivre quelque chose à l'aveuglette est une mauvaise idée. Mais ce dieu programmeur Infestus qui semble en savoir beaucoup, me dit que la seule façon de programmer correctement est de lire des livres et de tout suivre jusqu’à un T. Toutes les règles qu’il impose sont celles qui sont écrites, alors je me demande si si les livres sont le seul moyen correct.

EDIT2 : Infestus n'est pas mon patron. Il n’est que l’un des développeurs principaux en charge de la révision du code. Et la plupart de ses commentaires après critiques consistent en des noms de livres où telle ou telle méthode est fausse.


100
Suivre quelque chose à l' aveuglette est-il une bonne idée?
FrustratedWithFormsDesigner

16
Suivre quelque chose à l'aveuglette est une mauvaise idée, mais ne laissez pas "Infestus" vous en vouloir à des livres. La lecture de livres est l’un des meilleurs moyens de sortir de votre zone de confort et de développer vos compétences en programmation.
Kyralessa

21
Il semble que le supérieur sache peut-être pourquoi il suit ces méthodes particulières de résolution de problèmes - mais ne veut peut-être pas prendre le temps de vous expliquer pourquoi, et vous indique simplement les ressources qui l'expliquent. Avez-vous lu les ressources qu'il vous a dirigées? Expliquent-ils pourquoi la solution choisie a été choisie?
Joris Timmermans

28
5 ans après, tu n'es plus junior, tu le sais? Infestus le sait?
Iluxa

25
...brushed it off as this is better and that's how this and this book about java says it is better. Cela devrait déclencher des sonneries d'alarme immédiates. Si Infestus ne peut vous donner une explication autonome, il risque de ne pas le comprendre lui-même. (Ou il a besoin d'une copie du livre illustré de mauvais arguments .)
Blrfl

Réponses:


87

Vous allez rencontrer des programmeurs comme celui-ci toute votre carrière. Il n'y a rien de mal à expérimenter et à apprendre par soi-même. Bien sûr, les livres sont excellents. Bien souvent, les exemples fonctionnent dans un environnement propre, mais si vous êtes développeur pour une autre entreprise, il n’existe pas d’environnement propre (sans ingérence des autres).

C'est toujours agréable de savoir comment faire les choses "correctement", mais les opinions changent d'année en année. Alors, apprenez ce que vous pouvez. Prenez ce que vous pouvez du développeur principal, mélangez-le avec les connaissances que vous apprenez par vous-même. Finalement, vous serez un développeur senior et tirerez profit de ces expériences pour enseigner aux développeurs juniors.

Juste ne soyez pas un imbécile à ce sujet.


65

Est-ce qu'il appelle vraiment vous stupide, ou est -il juste dénigrent le code? Appeler quelque chose de stupide n’est pas délicat, mais cela n’annule pas la suggestion. Je pense qu'Infestus a fait une suggestion précieuse et qu'à l'avenir vous devriez considérer ses suggestions sérieusement. Il semble lire beaucoup, et au moins dans ce cas son opinion est bien informée. La synchronisation est à la fois coûteuse et délicate. Son implémentation recommandée est plus efficace et plus simple que la vôtre, et son fonctionnement est garanti.

Il essaie toujours de me donner des livres à lire pour que je puisse "apprendre" les manières de programmer.

C'est gentil de sa part. Il essaie activement de vous aider, mais vous semblez laisser votre ego faire obstacle. Ne prenez pas la critique de votre code personnellement. Le code est peu coûteux à produire et facile à changer. Si quelqu'un vous montre une façon plus simple de faire quelque chose, remerciez-le.

Et oui, la lecture fera de vous un meilleur programmeur. Tous les experts que j'ai connus ont lu beaucoup. Si vous ne lisez pas beaucoup, vous êtes au mieux médiocre et, dans cinq ans, vous constaterez peut-être que vous n'êtes plus commercialisable.


6
Vous faites valoir un très bon point, et l'article auquel vous créez un lien est très intéressant, mais il est clairement indiqué à la fin que le verrouillage par double contrôle ne fonctionne pas avec JDK version 1.4 ou antérieure (avec ces modèles de mémoire du JDK). À partir de JDK 1.5 et au-delà, cela fonctionne aussi longtemps que le champ contenant l'instance est déclaré volatile (ce qui est le cas dans l'exemple lié par l'OP).
Shivan Dragon

4
Merci pour le conseil :) et oui, il m'appelle effectivement stupide (parfois aliéné) dès qu'il se met vraiment en colère à propos du code. Ce n'est pas tellement mon ego qui m'empêche d'accepter ses réponses, mais plutôt la façon dont il essaie de me l'enfoncer dans la gorge et les noms qu'il utilise pour moi et mon code, mais c'est une histoire différente. Cependant, il est bon de savoir que les livres fournissent des informations :)
Quillion

6
@ Quillion - personnellement, je n'accepterais pas son appel. On dirait que vous en avez assez de tout. J'envisagerais sérieusement d'en discuter avec votre responsable, peut-être même des ressources humaines. La vie est trop courte pour supporter les abus de quelqu'un.
webdad3

2
@Quillion - Personne ne devrait te traiter comme ça. Je me fiche de qui ils sont. Et rappelez-vous toujours que tout le monde est remplaçable. J'envisagerais sérieusement de parler à Infestus d'abord, ensuite à votre responsable, puis aux RH. Si vous n'obtenez pas de satisfaction, passez à autre chose. Croyez-moi, vous trouverez un autre grand groupe de personnes.
webdad3

1
Infestus a une réaction émotionnelle face à ce qu’il considère comme une profonde laideur. Il pourrait peut-être bénéficier de quelqu'un lui demandant de se contrôler.
kevin cline

22

Lire un livre ne devrait pas être aveugle: l'auteur devrait essayer de vous convaincre des mérites de son approche au moment de la présenter. Il est raisonnable que votre aîné vous indique un livre expliquant son approche préférée plutôt que de lui demander de l'expliquer lui-même: bien qu'il devrait être en mesure d'expliquer les avantages de ses préférences sans s'appuyer sur le livre, il s'agit également d'une duplication d'effort. l'auteur du livre a déjà fait.

Alors, lisez le livre, voyez ce que dit l'auteur du livre, et si cela vous confond ou si vous souhaitez confirmer votre compréhension, ou si vous n'êtes pas d'accord, parlez-en à votre doyen, mais maintenant vous serez capable d'avoir une discussion plus productive.


Je serais d'accord. Si l'auteur d'un livre est incapable d'expliquer le bien-fondé de l'approche dont il parle, comment peut-on lire le livre de l'auteur, alors l'une des deux choses doit être vraie. Soit il y a une explication cela existe, et le lecteur ne comprend tout simplement pas, ou une explication n'existe pas et le lecteur devrait essayer de trouver une explication pour cette méthode. Puisque nous parlons d'un sujet spécifique, celui où il n'y a que deux façons valables de le faire, une explication doit sûrement exister. En d'autres termes, je suis d'accord avec votre réponse.
Ramhound

17

Toute relation saine comporte trois éléments clés. Communication, honnêteté et confiance. Cela compte pour toutes les relations, même les relations de travail. Vous devriez parler à votre superviseur de ces préoccupations.

Si vous ne comprenez pas les raisons pour lesquelles il préconise un certain design, dites-le-lui . Dites-lui que vous n'avez pas lu le livre et que vous voudriez comprendre pourquoi sa façon de le faire est meilleure. La clé est que vous devriez essayer de comprendre sa façon de faire les choses.

Je pense que vous devriez également traiter cette personne avec plus de respect. Dans votre tête, vous l'appelez des noms péjoratifs et vous critiquez son approche de ce que vous appelez «apprendre». Attention à ça. D'autre part, vous avez dit qu'il vous a appelé stupide. Ce n'est pas cool, et tu devrais lui dire que ce n'est pas cool d'appeler quelqu'un de stupide.

Les idées peuvent être stupides. Nous faisons tous des erreurs et nous passons à côté de choses, même les plus expérimentés. Quand il y a un défaut dans un design, la meilleure question à poser est "Pourquoi le faites-vous de cette façon? Ne sera-t-il pas cassé dans la situation X, Y, Z? Le design B ne sera-t-il pas meilleur?"

N'oubliez pas que vous travaillez sur ce logiciel avec d'autres personnes. C'est une compétence difficile à apprendre. Peu importe que vous n'écriviez rien à partir de zéro, il y a toujours de la place pour briller en faisant de votre code le meilleur code possible.

Et «le mieux» signifie très souvent lisible et compréhensible . Nous, les programmeurs, passons beaucoup de temps à lire le code des autres. Si ce code est clair et lisible, cela le rend vraiment précieux. L’un des moyens d’apprendre à écrire un bon code consiste à lire beaucoup de bons codes. Vous trouvez très souvent un très bon code dans les livres. Donc, lire un ou deux bons livres de programmation fera probablement de vous un meilleur programmeur.


En fait, je pense que ses compétences sont pieuses et que je respecte. Cependant, les critiques sévères concernant tout ce qui est nouveau commencent à me démotiver, même d'essayer de nouvelles choses et de rester fidèle aux livres, et oui, il est très vulgaire.
Quillion

6
Le neuf n’est pas toujours bon et le vieux n’est pas toujours mauvais. S'il critique une idée, demandez à savoir pourquoi. Toujours demander pourquoi. "Parce que le livre le dit" n'est pas assez bon. D'autre part, après avoir lu le livre, il a très probablement une perspective beaucoup plus large. Vous devriez également chercher à élargir votre propre perspective, au point de pouvoir justifier votre conception sur ses propres mérites.
Gustav Bertram

2
Ne pensez à personne comme divin. Vous ne pouvez pas toujours compter sur lui. Traitez-le comme un pair qui a plus d'expérience. Si vous le traitez comme un dieu, vous vous vendez à découvert et vous ne serez jamais respecté.
webdad3

7

Dans l'entreprise où vous travaillez, c'est probablement le cas. C'est ce qu'ils vous demandent de faire.

Cet ingénieur Infestus fait un très mauvais travail en éduquant les développeurs débutants en leur disant "c'est écrit dans le livre, et c'est pourquoi". Ce n’est pas un prédicateur, c’est un ingénieur, et il devrait être capable de le décomposer et de présenter les concepts afin que les plus jeunes puissent apprendre de son expérience.

Je vous encourage à parler à des développeurs compétents de votre entreprise, à leur poser des questions sur les avantages et les inconvénients de différentes techniques de programmation, etc., tout en lisant des livres et des blogs (je recommanderais Joel on Software - il suffit de le rechercher sur Google, c'est indispensable) devrait vous donner une meilleure compréhension.


4

IMHO, il y a 2 aspects ici, que vous devriez traiter séparément:

  • Le fait que ce type soit un imbécile, vous appelle et vous donne des noms simplement parce qu'il le peut comportement intimidant, et tout simplement mauvais.

Essayez de ne pas vous baisser à ce niveau. N'essayez pas de l'intimider en retour ou de "le raconter" au patron ou quoi que ce soit. Faites de votre mieux pour ignorer cet aspect de son comportement, en gardant à l'esprit qu'il devient trop extrême (c'est-à-dire que si cela affecte votre productivité, etc.), vous devez agir.

  • Le fait qu'il vous dise que votre code est mauvais (et comment le faire correctement). Honnêtement, d'après ce que vous décrivez, en ignorant le ton du gars, cet aspect de son comportement n'est pas si grave. Vous apprenez les choses beaucoup plus rapidement et vous les voyez dans le contexte approprié lorsque vous avez quelqu'un de plus expérimenté qui vous corrige et vous dit non seulement ce que vous avez mal fait, mais aussi comment le faire correctement (par rapport à un simple apprentissage par vous-même d’essais personnels / expériences sur erreurs, etc.).

Plusieurs fois, j'ai eu quelqu'un qui corrige ce que je pensais au départ comme étant "mon code parfait" et je me suis énervé que le gars me dise quoi faire avant de réaliser plus tard qu'il avait raison tout le temps, ma version était mauvaise, la sienne était bien, et dieu merci, il a vu ça! :) J'ai donc appris à atténuer mes impulsions initiales de "hé, tu ne me dis pas quoi faire, mista!" et au lieu de cela, chaque fois que quelqu'un me corrige, je vérifie tout d'abord, objectivement, mon code, puis le sien et m'assure qu'il n'a pas vraiment raison et que c'est moi qui fais la gaffe. Si c'était de ma faute, je le remercie pour son aide et m'assure de bien comprendre le fonctionnement de sa solution (plutôt que de simplement copier / coller).

Et hé, parfois, je trouve que la correction proposée est en fait pire que ce que j’avais fait au début, à quel point j’essaie de parler de tout cela avec l’autre type. Honnêtement, j'ai remarqué que rien ne gagnait le respect des autres plus vite que quand ils voyaient que tu pouvais accepter d'être corrigé quand tu avais fait une erreur, mais en même temps, tu n'as pas peur de dire que c'est toi qui a raison quand vous le pensez, étant donné que vous pouvez immédiatement prouver que vous basez votre affirmation sur des recherches concrètes, et pas seulement sur l'ego

Sur ce point, je pense que vous devriez vraiment essayer de parler au gars de ce qu'il propose, de ce que vous proposez et ainsi de suite. Montrez-lui ce que vous pensez, comment vous êtes arrivé à une solution particulière et pourquoi vous pensez que c'est mieux que le sien (quand vous pensez honnêtement et objectivement que c'est le cas). Ou, si vous découvrez que sa proposition est meilleure que la vôtre, dites-le-lui, exprimez votre reconnaissance pour l'aide apportée. Cela peut reconstruire certains ponts brûlés.


1
Je suis tout à fait d’accord avec vous :) et j’essaie d’ignorer son ton et d’essayer de me rabaisser car je suppose que c’est son caractère. Mais ce qui m’inquiète le plus, c’est qu’il me dirait que mon code est faux (ce qui me convient le moins du monde) et que, au lieu d’essayer de m’expliquer de manière erronée, il me donnerait un livre et me dirait de le faire. lisez-le avant d’essayer d’écrire du code stupide. C'est ce qui me fait me demander si les livres ont toutes les réponses, car la moitié du temps lorsque je lisais le livre, cela ne s'appliquait pas parfaitement au scénario en question.
Quillion

Oui, je vois ce que vous voulez dire, mais tout cela dépend vraiment du livre et de la façon dont il le recommande. C'est-à-dire que s'il dit des choses comme "tu as mal fait, va lire quelques livres de programmation", c'est évidemment mauvais, mais s'il dit "Regarde, Effective Java 2nd edition donne un exemple plus simple et meilleur de la façon de faire Singletons, vérifie ici ma. safaribooksonline.com/book/programming/java/9780137150021/… "alors je dirais que c'est une chose utile pour vous (encore une fois, laissant de côté la discussion sur le ton de la livraison)
Shivan Dragon

Je ne "ignorerais" jamais ce comportement. Il y aurait soit un siège avec son patron, soit un skip pour parler à son patron si je lui avais déjà dit que l'appel du nom ne volerait pas.
Rig

3

Expérimentez vous-même et apprenez tout ce que vous pouvez. Après avoir lu suffisamment de livres, vous allez découvrir qu'il existe plusieurs livres sur des sujets particuliers et qu'ils peuvent se contredire. Essayez celui qui vous convient le mieux et essayez les deux si vous avez le temps ou si vous voulez comparer / contraster.

Traiter avec votre patron est un sujet et une approche totalement différents. Si je voulais que quelqu'un fasse quelque chose exactement comme dans un livre, je le leur dirais. C'est juste moi parce que je ne m'associe pas avec les lecteurs d'esprit. Votre patron en prend l'habitude. Demandez-lui s'il recommande des livres ou des références lorsque vous recevez un nouveau projet.

Quoi que vous fassiez, n'arrêtez pas de travailler sur de nouveaux projets. Je sais qu'il est facile pour nous tous de donner des conseils sur la façon de gérer cette situation. Ils peuvent ou non fonctionner, mais vous êtes celui qui doit vivre avec et subir la négativité. Vous allez vous améliorer, mais cela vient généralement d'écrire plus de code sur de nouvelles choses, d'apprendre des succès et des échecs.


3

Suivre des livres à l'aveuglette est une mauvaise idée, mais il y a une différence entre suivre un livre à la lettre et le suivre à l' aveuglette .

Lorsque vous essayez de comprendre des éléments d'un livre, il est généralement approprié de les suivre exactement au début, pendant que vous avez une idée de ce qu'ils essaient de vous apprendre. Il y a de fortes chances que vous ne compreniez toujours pas tout lorsque vous avez terminé (c'est ainsi que les choses se passent habituellement ainsi), mais si vous suivez le livre au début avec exactitude, vous pourrez expérimenter quelque chose lorsque vous essayez de comprendre vos questions. Les chances sont bonnes que vous trouviez un moyen de ne pas être d'accord avec le contenu du livre, mais vous aurez une bonne compréhension des problèmes que le livre essayait de résoudre, de sorte que lorsque le moment est venu d'écrire votre propre code, vous pouvez Abordez-les à votre manière (ou peut-être à leur manière, du moins en partie) plutôt que de laisser ces problèmes vous mordre plus tard.

Une autre chose qui n'est pas intrinsèquement spécifique à Java, mais qui est néanmoins particulièrement courante dans cette communauté. Je pense que je peux deviner de quels livres vous parlez, et ils constituent une partie importante du lexique de la communauté Java. Les comprendre et la façon dont ils décrivent les choses vous seront très utiles lorsque vous aurez besoin de comprendre d’autres codes Java que vous trouverez. C'est une compétence précieuse en soi.


3

La lecture de livres et de billets de blog est très utile pour la programmation. Il existe des livres que tous les développeurs devraient lire.

Cependant, les livres ne sont pas la seule source pour apprendre différents concepts et technologies de programmation. De nos jours, la formation vidéo à la demande devient très populaire. Vous pouvez consulter Pluralsight , qui offre une formation de haute qualité aux professionnels.

En fait, si vous ne lisez que des livres, cela ne vous aidera pas non plus. Outre la lecture, nous devons également faire autre chose. Vous pouvez trouver plus de détails ici .


Formation basée sur la vidéo, la formation en salle de classe ou simplement la lecture de sources. En fin de compte, ils partagent tous une chose, vous lisez (ou écoutez) un nouveau code et vous entendez / lisez une explication de la raison pour laquelle cette approche a été adoptée.
Ramhound

2

Vous devriez lui demander ce qui ne va pas avec votre méthode. S'il est incapable de répondre clairement à cette question, vous êtes peut-être presque certain que c'est un type ordinaire qui aime se sentir supérieur.


1
Ses compétences et les programmes qu'il écrit indiquent clairement sa supériorité en programmation. Cependant, la plupart des raisons pour lesquelles il fait quelque chose de spécifique sont toujours liées aux livres d'auteurs célèbres. Cependant, peu m'importe ce qu'il ressent envers moi, je veux plutôt savoir si les livres sont vraiment le meilleur moyen de devenir un bon programme et s'il faut leur faire confiance comme si un religieux croyait en la Bible.
Quillion

Vous devez absolument être conscient des raisons pour lesquelles choisir une approche plutôt qu'une autre. Aller vers une autre solution que celle que vous avez imaginée doit être justifiée par des raisons que vous comprenez. Sinon, vos compétences (de type senior) ne s'amélioreront pas. Vous pouvez obtenir les idées de livres mais les idées sont ce qui est important, pas où ou par qui elles sont présentées. La programmation n'est pas une religion :).
Clime

1
Et ne soyez pas trop intimidé par lui. On dirait qu'il est peut-être un très bon programmeur, mais pas très bon pour diriger et enseigner aux gens.
Clime

@Quillion - La seule façon de devenir un bon programmeur est de le faire une tonne, en lisant des livres (ou toute autre source), vous pouvez compléter l'écriture de code par la lecture. Avez-vous même lu le livre en question? Vous devez décider si l'auteur du code vaut la peine d'être écouté, un auteur qui prétend avoir eu 20 ans en Java, est une bonne personne à écouter. Cela signifie qu'il a de bonnes chances, il a parlé avec les développeurs Java actuels, de certains sujets. Si j'écrivais un livre sur Java, j'irais à la source de mes recherches et utiliserais mon expérience pour expliquer le sujet.
Ramhound

@Ramhound Oui, j'ai dû lire les livres qu'il m'a donnés. Et oui je suis d'accord avec ses livres sur certains sujets. Cependant, le problème que j'ai trouvé avec les livres qu'il a recommandés est qu'ils décrivent un monde parfait où tout le code est écrit correctement et l'autre moitié du temps, ils se sont sentis légèrement dépassés. Mais son flot incessant de spams de livres pour me permettre de lire et de défendre tous ses arguments avec des livres plutôt que d'essayer de m'expliquer, m'a fait penser que les livres ne sont peut-être pas la meilleure source. Cependant, il semble que ce soit le cas et je les étudierai plus avant.
Quillion

2

Le problème avec les livres, c’est qu’ils - la plupart du temps - passent par des révisions, qui ont une meilleure chance de repérer les mauvaises pratiques et les idées fausses. En outre, les «grands noms» sont des personnes expérimentées qui comptent sur leur capacité à gagner de l'argent en vendant des livres. Il existe donc des garanties de qualité minimale sur ce qu'elles disent.

Cela dit, lire des livres, des journaux et d’autres sources est un bon moyen de se développer en tant que professionnel, bien sûr, lorsque la pratique le confirme. Vous avez donc intérêt à lire ces livres (même ceux recommandés par Infestus). Cependant, les livres doivent surtout élargir votre compréhension sur le sujet, car il y aura presque toujours d'autres moyens de résoudre le même problème.

En ce qui concerne votre approche "allez-y moi-même", le but est de: maintenir votre point de vue Comment pouvez-vous prouver que votre solution est meilleure que les autres? Parfois, vous pouvez concevoir vous-même des solutions brillantes, mais si vous les comparez à d'autres solutions connues, vous devez pouvoir expliquer pourquoi votre solution est meilleure, car les autres ont au moins l'avantage des cas d'utilisation. Ensuite, soyez créatif et réfléchi, mais surtout, soyez efficace.

Si je l'étais, je lirais ces livres. Cela vous aidera en vous donnant plus d'arguments et, en même temps, vous constaterez peut-être qu'Infestus prend peut-être à tort ces livres comme argument, et il n'a pas encore été repéré parce que personne ne connaît le contenu de ces livres. Ou vous pouvez trouver qu'il k


1

D'après mon expérience, lorsque l'on se préoccupe de la programmation, la qualité et la présentation des informations, accompagnées d'explications adéquates dans les livres, sont d'une magnitude supérieure à celles obtenues lors de la recherche d'informations sur le même sujet sur Internet. Internet manque souvent d'explication, de contexte et de qualité.

La quantité d'informations sur Internet est plus élevée.

Donc, ma stratégie générale est d’apprendre des livres pour mieux comprendre, puis d’Internet pour être exposé à différentes applications et élargir mon expérience (et souvent voir comment ne pas faire des choses).


1

Je rechercherais les mérites de chaque approche et viendrais à votre propre jugement. Si vous pensez que votre approche est meilleure, discutez-en avec Infestus jusqu'à ce que l'un de vous convaince l'autre. Si vous ne parvenez pas à un accord, vous pouvez demander un deuxième avis ou simplement accepter l'approche d'Infestus, en fonction de votre conviction.

Dans le cas des singletons, un argument que vous pourriez faire valoir contre l'approche enum est que les enums ne peuvent pas étendre les classes. J'écris souvent un code comme celui-ci:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Cela ne peut pas être fait avec des enums. Étant donné que l'approche enum ne fonctionne pas dans tous les cas, vous pouvez faire valoir que, par souci de cohérence, elle devrait être évitée même lorsqu'il n'est pas nécessaire de recourir à une extendsclause.

Quelques autres arguments contre l'utilisation d'énums:

  • c'est un hack - il utilise des enums pour quelque chose pour lequel ils ne sont pas destinés
  • c'est déroutant pour les lecteurs qui ne l'ont pas encore vu

Umm ... pourquoi voudriez-vous implémenter un sérialiseur de date en tant que singleton? S'il s'agit d'apatridie, vous pouvez vous attendre à ce qu'elle soit peu coûteuse à instancier et avoir plusieurs instances ne devrait pas être une préoccupation majeure. Si ce n'est pas apatride, alors vous devez le rendre synchronisé, et il est possible que cela devienne un goulet d'étranglement ...
Stephen C

@StephenC pour les classes sans état, il semble simplement étrange d'autoriser plusieurs instances lorsque cela suffirait, et quel est l'avantage? Un singleton avec état qui me vient à l’esprit est un analyseur packrat - vous pouvez avoir plusieurs classes de singleton qui étendent un AbstractParser. Certes, la synchronisation est nécessaire si vous analysez en parallèle, mais le partage de l'état mémo est important.
Daniel Lubarov

Au contraire, il me semble étrange que vous vous occupiez des singletons et des complexités qui en découlent si vous n'en avez pas besoin. À mon sens, l’approche la plus simple consiste à créer, utiliser et jeter des objets "transformateurs" ... sauf s’il existe une raison / une incitation forte à les réutiliser.
Stephen C

1

Je compte énormément sur les livres comme source de connaissances - ce sont d'excellentes bases et je pense qu'Infestus a raison, vous devriez en consommer des quantités importantes pendant votre temps libre, car ils accélèrent réellement vos compétences. Les livres ne sont pas la seule source d’informations, mais je pense que vous devriez en consommer. Consultez votre groupe d’utilisateurs local, recevez les bulletins technologiques pertinents dans votre boîte de réception, lisez des blogs.

Je ne suis cependant pas d'accord avec l'affirmation selon laquelle, comme c'est écrit d'une certaine manière dans un livre, c'est comme cela que cela doit être fait. Oui, les livres fournissent d'excellents conseils. Ils sont écrits par des experts et examinés par des experts. Cependant, après avoir été impliqué dans un livre relativement simple, je peux vous dire qu'il faut généralement au moins deux ans pour terminer, rédiger et publier un livre. . Le rythme des changements technologiques est rapide et les conseils d’il ya deux ans pourraient ne plus être corrects pour aujourd’hui. Les principes génériques résistent souvent à l'épreuve du temps, mais l'optimisation d'une activité spécifique peut être invalidée avec un nouveau composant matériel ou une nouvelle version du logiciel.

Il est excellent de demander à Infestus d’examiner vos suggestions: partez, lisez tout et revenez avec un tas de questions réfléchies auxquelles vous avez déjà essayé de répondre / résoudre vous-même, ainsi que les preuves que vous étiez en train de soutenir. méthode.

Il y avait des questions à savoir si après 5 ans pourquoi vous étiez encore junior. Pour moi, la principale mesure permettant de déterminer si une personne est une junior ne réside pas dans sa longue expérience, mais dans quelle mesure elle nécessite une alimentation à la cuillère. Je m'attends à ce qu'un développeur de niveau intermédiaire soit relativement autonome, un consommateur réfléchi de sources de connaissances qui puissent agir en conséquence et l'étendre à leur situation. Ils devraient également être au stade où ils peuvent commencer à enseigner aux juniors car ils comprennent bien leur sujet pour pouvoir expliquer les choses clairement. L’autre compétence essentielle est la confiance: si vous avez fait le travail, lu le texte et produit quelque chose de décent, n’ayez pas peur de le défendre devant un tribunal pour débattre, car un subalterne nécessite une validation, un développeur demande le consensus.


1

Mettre de côté les habitudes de travail, mettre de côté la réalité du rôle de mentor que jouent les développeurs seniors, mettre de côté votre propre désir d'explorer, mettre de côté les comportements insultants et mettre de côté les fétiches pour les livres ...

Les objectifs d'une révision de code dans une équipe sont 1) de valider le code et 2) de s'assurer que la personne qui écrit le code comprend la signification de l'amélioration du code. Ce n'est pas l'endroit pour dire "changez cela parce que Martin Fowler l'a dit dans le livre du GoF". Cependant, c'est l'endroit pour dire "changez cela parce que [brève explication]; il y a plus de détails à ce sujet dans le livre du GoF".

Si votre développeur principal n’explique pas, du moins simplement et de façon subtile, un changement, et insiste pour utiliser le verbiage de "à cause de [livre]", il est un peu malin et sournois. Comment gères-tu cela? Mentionnez-le verbalement lors d'une réunion d'équipe et demandez à vos coéquipiers de fournir une déclaration ou deux expliquant brièvement l'avantage ou la nécessité du changement, ainsi que la référence utile de ce livre. Assurez-vous de le remercier pour la référence du livre.

Face à cela, votre objectif est d’apprécier la suggestion de changement et de ne pas être démotivé pour votre tâche ou votre travail. Dis lui ça. "J'apprécierais davantage la suggestion de changement si vous pouviez décrire brièvement l'avantage ou la nécessité du changement lorsque vous révisez mon code; car je trouve que les références de votre livre sont un peu démotivantes."

S'il continue à refuser de fournir une explication simple avec ses références de livre, si vous pouvez fournir un autre livre ou une ressource de notoriété égale ou plus grande dans l'industrie avec un avis différent et si cela correspond à votre scénario, vous pourrez peut-être ajouter votre propre livre. référence dans votre commentaire commentaire en envisageant de conserver le code original. Faites cela assez souvent, il pourrait reculer. Veillez à ce que le contre-argument soit juste et nettement plus important; c'est bien de laisser un développeur senior se tromper et de continuer à agir, c'est quelque chose que j'ai appris et que je continue à apprendre.


1

Je dirais que l'apprentissage de la programmation à partir de livres seulement est impossible, mais que les bonnes vous donneront un énorme coup de pouce. C'est comme du karaté - vous n'obtiendrez pas la ceinture noire;), je crois que dans ce cas particulier M. Infestus faisait référence à "Effective Java" de Joshua Bloch. C'est vraiment un excellent livre sur le développement Java et vous devriez absolument le lire si vous ne l'avez pas déjà fait.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.