Téléchargé parHenri Tremblay
Confoo 2018: Être pragmatique
La présentation de Henri Tremblay aborde des règles pragmatiques pour le développement logiciel, notamment l'utilisation judicieuse des interfaces et les mises en garde contre les architectes, consultants et gestionnaires considérés comme dangereux. Il insiste sur l'importance de se concentrer sur les objectifs et d'être pragmatique dans les décisions techniques. Des exemples concrets et des suggestions de lecture sont également fournis pour illustrer ses points.
Confoo 2018: Être pragmatique
- 1. © Henri Tremblay2015 Henri Tremblay Développeur Sénior Terracotta, une filiale de Software AG Être pragmatique @henri_tremblay
- 2. 2 Les histoires racontéesdurant cette présentation sont vraiment arrivées TOUTEFOIS Toute ressemblance avec une quelconque compagnie que vous connaissez est fortuite Avertissement
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. 11 Tu pourrais en avoirbesoin plus tard
- 12.
- 13. 13 Tu pourrais en avoirbesoin plus tard
- 14.
- 15.
- 16.
- 17.
- 18. 18 Il faut une interfacepour “mocker”
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. 24 Si ça al’air trop compliqué pour rien, utilise-le pas Règle #2
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33. 33 Pourquoi? (en prenant commepostulat que l’autre n’est pas un imbécile) Règle #4
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48. 48 Brie,"Mild soft cheese" Oka,"VenerableQuébec cheese" Camembert,Strong soft cheese Cheddar,"Hard cheese, taste nothing if not aged" Maroilles,"Classified as ""chemical weapon"" in the USA" Cheese.csv
- 49.
- 50. 50 Tu en asbesoin plus vite que tu penses Règle #7
- 51.
- 52. 52 1 500 000000 000 instructions
- 53.
- 54.
- 55.
- 56. 56 Qu’est-ce que ça coûted’essayer? Règle #8
- 57.
- 58. 58 Saut parachute sans parachute Peux mourrir
- 59.
- 60. 60 Migrer à Log4j2 3 JH
- 61.
- 62. 62 Convertir à JUnit5 20 JH
- 63.
- 64. 64 Henri Tremblay • Apopulariser les mock et proxy de classes • A inventer le terme “partial mocking”
- 65. 65 Qui a apprisquelque chose aujourd’hui? ?
- 66.
- 67.
Notes de l'éditeur
- #2 Hello everyone and welcome to a session that may change your life. Today you will learn to be pragmatic. But first, who think he is pragmatic? Great, I dearly hope you are right. Because I am not presenting this session for you. I am selfishly presenting this session for me! I would love to be surrounded by pragmatic people! But first, let me get started with one disclaimer.
- #3 Read the slide After all we are in the United States, land of the lawyer and I don’t want to get sued for telling war stories. Now, let’s get started
- #4 True wisdom is knowing what you don’t know. And they actually both said pretty much the same thing. For real. And when Socrates and Confucius are saying the same thing, you can only humbly agree. And yes of course they both never said that. Those are English quotes made up by some marketing guy to sound punchy. But yes, the spirit of what they said is more or less preserved here. Anyway. True wisdom is really knowing what you don’t know. So there is everything you do know, and for everything else there is….. ?
- #5 GUT FEELING! Yes sir. Gut feeling. What else can you do? If I don’t know, if just don’t know. So I just use my gut feeling. But not everybody was born equal. Some have better guts than others. So today, I will teach you how to train your gut. “Hey! Wait a minute! Who’s this guy telling me I’m not pragmatic. Who does he thing he is?” You are right. Let me step back a bit.
- #6 I’m Henri Tremblay. I currently work for Terracotta, which is owned by Software AG and I develop Ehcache and some other stuff that surrounds it
- #7 I’m also Java Champion.
- #8 Mainly because of things that I did when I was young. Let me tell you about it. A long time ago, when I was young, I was asked by some analysts to retrieve some cheese from a database. I wasn’t actually cheese but let’s just assume it was.
- #9 So here is my simple Cheese class, nothing worth of mention here
- #10 And here is my DAO. See? I’m so awesome that I was already using Java 8 20 years ago. Anyway, I was quite happy with that so I went back to the analyst to show him what I did. And of course he wasn’t as happy as I was. He told me:
- #11 God voice: Only depends on interfaces. Huh? Why? I have only one implementation. Today you have (grand architects tend to speak like Yoda), but
- #12 “You might need it later” What? “You might need it later!” Ok. I got it right the first time. Let me rephrase that.
- #13 You want to do modify my nice design to add all these interfaces? That’s will just make me loose tons of time swimming in uselessness! Why?
- #14 “You might need it later” What? “You might need it later!” Ok. I got it right the first time. Let me rephrase that.
- #15 Look let’s say I have a CheeseService that uses my CheeseDao
- #16 And I then decide that I need another implementation of the CheeseDao so I extract an interface from it. What does it change for CheeseService?
- #17 Nothing! Absolutely nothing! Now, two things can happen. One is that the analyst was in fact a vampire who never test his code and he turn into ashes
- #18 Or, 2, he says:
- #19 “You need an interface to mock it” And he’s right. In these old days, EasyMock, and all other mocking frameworks, were only mocking interfaces. So if you wanted to inject a mock, you need an interface. So I was doing it like everyone else, but it felt so wrong, so artificial. And one day, a guy named Bob Lee gave me an idea. “Hey, we could use this class proxying framework, cglib to mock classes” So that’s how pragmatic I am. Because it felt so wrong to have interfaces exclusively for unit testing, I got involved in open source and developed class mocking.
- #20 Now, back to be pragmatic. During your developer’s life you have encounter multiple methodologies which have for sole goal to help you stay pragmatic
- #21 Extreme programming in one
- #22 Agile methodologies are one
- #23 Lean is one. All these ideas where created only to help being pragmatic. If you apply them with respecting their purpose, if you forget what they are for, if you are just doing your scrum without thinking if anything you do make sense, all these methodologies will they fail. This will lead me to my first advise.
- #24 Don’t lose the purpose What is your purpose? Do you want a product loved by your users? Or you want to play with Apache Spark? I need to choose and whenever there is a decision to make, always think about the purpose. What do you want to achieve? Once you know that, we can go to the second rule
- #25 If it feels useless or overly complicated, it probably is. I mean it. You are not here to win a fight against a tool. I know developers. They have their pride, they wants to win against the machine. Ah ah! This damn framework is unusable! But it won’t beat me. I will use it! Whatever it takes! Ah ah! It should beat you. If it’s unusable, it’s not worth your time. Just drop it. Now. My rule is: If I can’t get it to work. By that I mean just the basic stuff. Like a getting started. In about 30 minutes, it should rot in hell because I have much better things to do. There is only one exception to this rule. Sometimes there are no alternative. When you are forced to use it.
- #26 OAuth2 for instance. Have you ever noticed that most cryptic and unusable framework are for security? I’m starting to think that there’s a sect of overly paid security consultants that is behind this. But yes, I deeply have OAuth2 but it is all over the place so I got to use it. Sadly. But trust me, if I could do otherwise, I would. Anyway. Rule #2
- #27 Yes. That sounds silly but I think it is really helpful. Because it gets automatic. As soon as you are in front of something that doesn’t feel like God would have wanted it, you can express yourself. Some examples
- #28 “It smells” A classical one. Wildly used in extreme programming
- #29 Huh? That’s not rights
- #30 AAAAAAAAAAAAA!!!!!!! But not appropriate for an open space And of course my favorite
- #31 WTF which stands for
- #32 AAAAAAAAAAAAA!!!!!!! But not appropriate for an open space And of course my favorite
- #33 Voyons donc! Kossé ça! Now you get it. It’s bad. Now put on your boy scout suit and go clean that mess. BTW, this was actual Ehcache code that I’ve refactored a bit since. Ok. Great. Now we have our quote. Let’s go to the next rule
- #35 Voyons donc! Kossé ça! Now you get it. It’s bad. Now put on your boy scout suit and go clean that mess. BTW, this was actual Ehcache code that I’ve refactored a bit since. Ok. Great. Now we have our quote. Let’s go to the next rule
- #36 Crazy architects are the most dangerous thing that can happen to a project. They can singlehandedly cost years of work. An example was a client who called us some years ago. They had multiple problems. One of them was the ORM. It was slow and hard to maintain. Their architects explained that he didn’t like hibernate. It was too slow and not doing stuff that I don’t remember. So instead he decided to code a homemade ORM
- #37 And not only that. The process was also really wise. The grand architect was the only one allowed to modify the model. So you had to ask him for a new field, he would then add it when he has time, launch the generator and TADA, you have a new field. How long is it to run the generator? About 2 hours. WTF!!!!! Can I please have a hammer?
- #38 And not only that. The process was also really wise. The grand architect was the only one allowed to modify the model. So you had to ask him for a new field, he would then add it when he has time, launch the generator and TADA, you have a new field. How long is it to run the generator? About 2 hours. WTF!!!!! Can I please have a hammer?
- #39 And you can see why quotes are useful. They help externalize the problem. In the end, the architect left the company, afraid by my sledgehammer and we just replaced everything by Hibernate Next rule
- #40 I’m talking about crazy consultant. Not good ones like myself. Or Venkat. Good ones are really useful. Consultants are paid by the company who hired them but frequently have their own agenda. So sometime there are not actually crazy. It’s just that their goals are not aligned with yours Here some real stories. A consulting firm is hired to tell us the best fit for a workflow engine. The verdict was: This one is bad, this other one is worst and this final one is awful. We recommend you to use the awful one because you have already started using it and we have some expertise with it so you could send you some consultant to help you I’m the performance expert from this big company selling application server. Ok, let’s work together. I will launch a benchmark and we can then do some tuning. Sure, meanwhile I will sneakily change your server configuration to use “well-known to improve performance” parameters You don’t need to look at the source code. We will send you the final binaries We are much more efficient when the entire team is made of our consultants And so on and so on A hammer is not enough. They require an halberd to get rid of.
- #42 You might see a pattern here. I could just squash the two rules together to call it “Beware crazy people” but in fact, both tend to be dangerous in different ways. Note that crazy developers are also dangerous but in general in a more limited way. So, beware crazy managers. They want to be useful. Like. Hey Henri. Your app looks like a workflow. So here, I bought this workflow engine for you. Please use it.
- #43 Aaaaaaaaa. I told you Aaaaaaa was useful as well. Anyway, cool down and be pragmatic
- #44 What can you do to counter craziness. Sometimes means discussing the issue and find a pragmatic solution. Sometimes it means to get external help. But sometimes it’s nastier. It means ignoring the workflow engine for the sake of sanity. Or just to plainly leave the company because I have no time to loose. Yes, it happened. I told them to talk me back when they are ready to listen because otherwise they will crash. They crashed. Back to the rules
- #45 Never use something you don’t need until you do. All parts of this rules are important. Especially the until. Which is why it is in bold. Never use something you don’t need UNTIL you do. And when is until is left to you to decide. Let me show you an example.
- #46 My boss comes and tell me: “Hey Henri, people love your cheese app” “Cool” “We need to add more cheese. I have this CSV. Can you please load it in your DB” “Sure” And I went coding.
- #47 Easy as pie. Then my boss comes back. “Hey Henri. We would now like won’t to add a description field in the csv”. “Ok, why not, let me change the parser”
- #48 Hurray. Job done. Then, the actual file arrives.
- #49 Oh dear Lord. That’s not what I expected. Double-quotes. Not all the time. Comma in the text. Escaped double-quotes. So now, you’re at a crossroad. You can go left and code and entire CSV parser by yourself, or go right and drop everything you did so far to use an off-the-shelf open source parser. So I take me code, delete it and use OpenCSV.
- #50 That is the most efficient way. Too bad for the existing code. That’s the UNTIL. Before, I was fine with my simple code. After, I really need something else. I don’t want to maintain a full-fledge CSV parser. Of course, in this example it was easy to pick a side. In real life, it can mean to delete 10 000 lines of code. Or months of work. So keep in mind the purpose, do the right thing. Next rule.
- #51 Yes. Now I’m just messing with you. I was just saying you should wait until and now I’m saying “You need it earlier than you thought” Some things are needed really early in a project. An example is performance testing. One day, I was asked by junior consultant to help him on a mission. He said he was swimming in so much insanity that he could bear with it anymore. He’s quite a muscular guy so he doesn’t need an axe to be damaging. So I went. “Hi, what’s up? I was told you have performance issues.” “Yes, we do.” “What kind?” “You know, usual stuff, like you know, this call here takes 15 minutes” “What?!?!?!” That’s not a batch. It is a normal interactive call. 15 minutes.
- #52 When I see a number like that, I like to put it in perspective.
- #53 15 minutes is about 1.5 Trillion CPU instructions. There a lot of things that can be done by 1.5 Trillion instructions. 15 minutes. It is the equivalent of calling the guy down there in the archive room. Hi buddy, can you bring me up the file A21 please. Sure it will be right on your desk in 15 minutes, I just need to pee first. Great thanks! People need to understand how ridiculous this number is for an interactive call. And the manager I was talking too wasn’t getting it. “And so, you’ve just started performance testing heh?” “Yes, we are going in production in a month” “Humkay. How long has this project been going on” “Oh About two years”
- #54 Two years. It means that during 2 years, no one ever ever had the idea to test only a tiny bit of performance of the system on a real dataset. 2 years. When I code an app, it tends to look like this.
- #55 One service to retrieve cheese. Followed by
- #56 One Gatling test to its performance. Because applications are never magically optimizing themselves by adding functionalities. If this single rest service is too slow, I can guarantee you that in 2 years it won’t be faster. So just test it right away. Our time together is almost over and I have one last rule for you. It is actually a question to ask yourself when making a decision
- #57 How harmful is it to try? How harmful is it to try all these I just gave you? And in general, when making a decision, if you take the wrong one, how harmful will it be? Let’s see
- #58 Skydiving without a parachute.
- #59 Can die. Not willing to try that
- #60 Can die. Not willing to try that
- #61 Ok. That I can afford
- #62 Convert to Junit 5
- #63 Oh gosh. That’s a lot. Can’t do that right now. Maybe later
- #64 Use Scala. Ok, this one is special. I don’t like scala. I don’t want to use it. But some developers on my team wants to. And I might be wrong. Maybe it will have some benefits. So I let them try and see. Being pragmatic is not about being right all the time. It’s about looking at the constraint, cost and benefits and do the most meaningful thing. Hey, you know what, I forgot finishing presenting myself.
- #65 I’m Henri Tremblay, I’m also the founder of the PerfUG in Paris. I am now one of the Montreal Jug leaders, so if you ever pass by, come say hello and present something. Finally, I’m also involved in Devoxx4kids Québec. Thank you very much for attending, I hope it was useful and I hope you had fun. My favourite question after a talk so I can know if I should keep doing it, is
- #66 By a raise of hand, who has learned something today? Thank you very much. To put on your nightstand, two books that are really good for the mindset.
- #67 The Goal, which is about theory of constraints. This is not at all an IT book and it is written as a noveli. The other, the Phoenix Project, is the same thing but move to an IT/Ops world. They are both must read books
- #68 About Ehcache, version 3 has been out for a while now. It is obviously faster, safer, nicer. Please have a look and give us feedback. This is the end, do you have any question?
- #69 Stories: CAE image generator The hashmap to generate mipmap Reading a linux book to answer questions Tibco staffware Benchmarking How the hell do I put that in production? To minutes rule to trying a framework and Hibernate String 5000 15 minutes performance