déplace les idées en dehors du contenu
This commit is contained in:
Yannick Francois
@@ -0,0 +1,71 @@
|
||||
---
|
||||
layout: post
|
||||
title: Principe de bonne programmation
|
||||
---
|
||||
|
||||
Il y a quelques temps, j'avais mis de coté un article de l'Artima Developer Community : "The Principles of Good Programming"
|
||||
*source : http://www.artima.com/weblogs/viewpost.jsp?thread=331531*
|
||||
|
||||
The Artima Developer Community
|
||||
Heron-Centric: Ruminations of a Language Designer
|
||||
The Principles of Good Programming
|
||||
by Christopher Diggins
|
||||
July 24, 2011
|
||||
|
||||
L'idée était d'en faire une simple traduction, mais finalement, je préfère me baser sur les points abordé dans cette article, et les expliquer en quoi ces principes sont, à ma avis, indispensable à tout bon développeur.
|
||||
|
||||
|
||||
DRY - Don’t repeat yourself - This is probably the single most fundamental tenet in programming is to avoid repetition. Many programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more). As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction. http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
|
||||
|
||||
Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.” http://en.wikipedia.org/wiki/Abstraction_principle_(programming)
|
||||
|
||||
KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal. Simple code takes less time to write, has fewer bugs, and is easier to modify. http://en.wikipedia.org/wiki/KISS_principle
|
||||
|
||||
Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it. http://en.wikipedia.org/wiki/YAGNI
|
||||
|
||||
Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design. http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
|
||||
|
||||
Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplified http://www.sensible.com/dmmt.html
|
||||
|
||||
Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend. http://en.wikipedia.org/wiki/Open_Closed_Principle
|
||||
|
||||
Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else. A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” http://c2.com/cgi/wiki?CodeForTheMaintainer
|
||||
|
||||
Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible. http://en.wikipedia.org/wiki/Principle_of_least_astonishment
|
||||
|
||||
Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task. http://en.wikipedia.org/wiki/Single_responsibility_principle
|
||||
|
||||
Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability” http://en.wikipedia.org/wiki/Coupling_(computer_programming)
|
||||
|
||||
Maximize Cohesion - Code that has similar functionality should be found within the same component. http://en.wikipedia.org/wiki/Cohesion_(computer_science)
|
||||
|
||||
Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component. http://en.wikipedia.org/wiki/Information_Hiding
|
||||
|
||||
Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.) http://en.wikipedia.org/wiki/Law_of_Demeter
|
||||
|
||||
Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth. http://en.wikipedia.org/wiki/Program_optimization
|
||||
|
||||
Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time. http://en.wikipedia.org/wiki/Code_reuse
|
||||
|
||||
Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code. http://en.wikipedia.org/wiki/Separation_of_concerns
|
||||
|
||||
Embrace Change - This is the subtitle of a book by Kent Beck, and is also considered a tenet of extreme programming and the agile methodology in general. Many other principles are based on the concept that you should expect and welcome change. In fact very old software engineering principles like minimizing coupling are related directly to the requirement of making code easier to change. Whether or not you are an extreme programming practitioner, this approach to writing code just makes sense. http://www.amazon.com/gp/product/0321278658
|
||||
Talk Back!
|
||||
|
||||
Have an opinion? Readers have already posted 18 comments about this weblog entry. Why not add yours?
|
||||
RSS Feed
|
||||
|
||||
If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.
|
||||
DiggDigg | del.icio.usdel.icio.us | RedditReddit
|
||||
About the Blogger
|
||||
|
||||
Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.
|
||||
|
||||
This weblog entry is Copyright © 2011 Christopher Diggins. All rights reserved.
|
||||
Sponsored Links
|
||||
Sign up for Applied and Advanced Scala Workshop: Dec 5-9, Boston, MA
|
||||
Learn how to "get higher" with ScalaTest in this one-hour free video at Parleys.com
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
|
||||
|
||||
quote:
|
||||
|
||||
En dehors de ça, un seul conseil : ne fait pas d'administration système !
|
||||
Fait du devops à la place, en utilisant Chef http://www.opscode.com/chef/ ou Puppet https://puppetlabs.com/
|
||||
Ca te facilitera fortement la tâche d'administration de ta machine, et te permettra par exemple de tester aisément des modifications sur celle-ci dans une machine virtuelle tout en étant à peu près sur que ça fonctionnera après en vrai.
|
||||
|
||||
|
||||
...
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
|
||||
Kanban, basé sur un système à flux tiré, encourage également unengagement au plus tard, à la fois sur la priorisation du travail et lalivraison du travail en cours. Typiquement, les équipes vont convenird'une fréquence pour rencontrer les parties prenantes et décider sur quoitravailler dans la suite. Ces réunions peuvent être tenues régulièrementparce qu'elles sont généralement très courtes. On peut y aborder une question très simple, quelque chose comme : "Depuis notre dernièreréunion, deux créneaux de travail se sont libérés. Notre temps de cycleactuel jusqu'à la livraison est de 6 semaines. Quelles sont les 2 choses quevous aimeriez voir livrées dans 6 semaines ?". Cela a une doubleincidence. Poser une question simple se traduit généralement par uneréponse de bonne qualité obtenue rapidement et permettant de maintenirune réunion courte. La nature de cette question signifie que l'engagementde sur quoi travailler est retardé jusqu'au dernier instant. Cela améliorel'agilité en gérant les exigences, en raccourcissant les temps de cycle entrel'engagement et la livraison, et en éliminant le travail de remise à niveaupuisque le risque d'un changement dans les priorités sera minimisé.
|
||||
|
||||
|
||||
A ETUDIER !
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
SOLID Principe, le détail
|
||||
@@ -0,0 +1,82 @@
|
||||
http://www.infoq.com/news/2011/10/Time_to_Stop_Estimating_Stories
|
||||
|
||||
|
||||
Is it Time to Stop Estimating User Stories?
|
||||
|
||||
Posted by Todd Charron on Oct 01, 2011
|
||||
|
||||
Sections
|
||||
Process & Practices,
|
||||
Architecture & Design,
|
||||
Development
|
||||
Topics
|
||||
Team Collaboration ,
|
||||
Process ,
|
||||
Agile Techniques ,
|
||||
Agile
|
||||
Tags
|
||||
Scrum ,
|
||||
User Stories ,
|
||||
Kanban
|
||||
|
||||
Share Share |
|
||||
|
||||
Most new Agile teams transition from hours based estimates to relative estimation using story points, but do we even need estimates at all?
|
||||
|
||||
Michael Dubakov suggests the following reasons why you should stop estimating user stories:
|
||||
|
||||
You don’t waste time on estimation
|
||||
You shouldn’t explain to higher managers why it took soooo loooooooong
|
||||
You don’t give promises that are hard to keep
|
||||
You don’t put additional pressure on development team
|
||||
You focus on really important things
|
||||
|
||||
Stephan Schwab, worries about how estimation can result in silos and prevent team based solutions:
|
||||
|
||||
Imagine an organization where teams are expected to have a fully estimated backlog in order to determine the cost for the project. At first glance such an approach seems to be a good idea. The people who will do the work will provide the estimate and thus based on what they say the true cost of the work will be known.
|
||||
|
||||
But then is the true cost of the project really known? What about all the discoveries that will be made once a team of smart people starts solving a problem? It seems unlikely that a few analysts will be able to analyze a problem and create a good solution expressed in small story cards for a 6 months project within a few weeks. They may be able to create 500 story cards over a few weeks but I think that will be all based on early assumptions. If the problem can be solved in a few weeks, then there is no need to pay the whole team over 6 months.
|
||||
|
||||
So to me it seems more like the attempt of predict the future, create a plan and then manage to the plan.
|
||||
|
||||
The fact that a team is asked to provide a fully estimated backlog – and a detailed one! – creates the prescriptive behavior and discourages the technical team members from developing a solution using the input from analysts, user experience person and product owner. In the end it should be no surprise, if the quality of the resulting “solution” is lower than expected. The team has been prevented from doing a good job.
|
||||
|
||||
Quality has been traded for false predictability and it is likely that this happened based on requests from the very same stakeholders who expect a high quality product.
|
||||
|
||||
What is much more important than to “calculate” cost is to build something of value. Something that can be used and in the end makes the stakeholders to want come back to the same people for extensions or with new ideas.
|
||||
|
||||
Mike Cottmeyer comes to the defence of estimates:
|
||||
|
||||
Since we don’t like managers and we don’t like death marches, we conclude the creation of software is an unpredictable process, that estimates are bad, and we should never estimate at all. Is it possible that we don’t really have an estimating problem? Is it possible that we have a bad management problem?
|
||||
|
||||
I don’t see any reason to stop estimating. In fact, unless your business model supports totally emergent outcomes, chances are you have some sort of goal, some sort of business outcome you are tracking toward that is tied to a hard, somewhat pre-defined deliverable. Chances are you’ve sold something to some customer and now you have to make good on that commitment.
|
||||
|
||||
We can debate this business model all day long, but if that’s your reality, you need estimates.
|
||||
|
||||
Estimates have to have ranges and probabilities. Assumptions have to be managed and risks have to be mitigated. We have to be able to measure how wrong our estimates are so that we can start to forecast that error forward.
|
||||
|
||||
We ignore what the data is telling us. We ignore the team’s actual performance against the estimate. There is so much competitive pressure to deliver, so much pressure to add those extra features by the end of next month so we can make the sale, so much pressure to deliver those features our sales team committed to win that big deal. So much pressure that we ignore reality.
|
||||
|
||||
The real problem is that, far too often, we oversell the organizations ability to deliver. The real problem lies in creating a ‘you have to deliver at all costs’ culture that doesn’t respect the teams established capacity to build working tested software.
|
||||
|
||||
Bad estimates become a problem, bad management becomes a problem, in the face of unyielding pressure to deliver against unreasonable expectations and inflexible project schedules and commitments.
|
||||
|
||||
Bob Marshall in the same article adds his comments:
|
||||
|
||||
Further, I regularly feel compelled to ask “why estimate?”. Until folks grok the requirements for which estimation is (most often) an implicit solution, how can anyone say with any certainty that estimation has any value?
|
||||
|
||||
Many believe Kanban has done away with estimates, Karl Scotland clarifies the situation:
|
||||
|
||||
Kanban teams do not eschew estimation simply because it is hard. Some teams choose not to estimate because they can realise the same benefits that estimation gives with a lower cost. The old joke does still apply (“Doctor, Doctor it hurts when I do this”, “Don’t do that then”). If it hurts to estimate, then find other ways to encourage whole team interaction and collaboration, learn about past capability and forecast future capability. On the other hand, if estimation doesn’t hurt, or costs too much, then it may be the right thing to do in your context.
|
||||
|
||||
When we are planning, we should decompose work for understanding, rather than sizing.
|
||||
|
||||
Jeff Anderson gives another take on estimating in Kanban:
|
||||
|
||||
As teams progress, work accepted will typically become categorized into better understood work types that have less variability. i.e. team A might typically work on java enhancements, emergency defects, and canned reports.
|
||||
|
||||
The most important part of estimating is breaking up the work into small pieces, once you've done that, the only reason to care about differences in the small range is to provoke discussion.
|
||||
|
||||
While it seems the value of the output of estimation may be in doubt, it seems the real benefit of estimation comes from the whole team conversations that occur along the way. What have your experiences been?
|
||||
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
<slainer68> J'ai eu une discussion avec lui par mail totalement hallucinante y a quelques mois
|
||||
<slainer68> nan mais le gars il voulait qu'on lui refasse tout pour 3 cacahuètes. j'ai laissé tombé.
|
||||
<slainer68> http://www.numerama.com/magazine/25240-arnaud-montebourg-veut-la-demondialisation-des-donnees-personnelles.html > SafeHarbor 2 le retour !
|
||||
<Shine-neko> slainer68: bah tu sais tu en as plein comme ça :)
|
||||
<pimpin> mais à force de discuter avec des freelance, ne croyez vous pas qu'ils puissent évoluer dans leurs exigences ?
|
||||
<slainer68> Shine-neko: a chaque fois je fais mister nice guy avec les clients en leur expliquant les bases de la méthodoligie Agile. Mais le truc fou c'est qu'il semblait ne pas comprendre.
|
||||
<Shine-neko> pimpin: dépends quand on est con hein !
|
||||
<pimpin> slainer68: tu lui a fait tout le topo maximisastion de la VA et tou ?
|
||||
<pimpin> (mais partage de la responsabilité) et obligation d'implication
|
||||
<slainer68> nan meme pas. les trucs encore plus basiques.
|
||||
<slainer68> itération, prototype rapide et tout.
|
||||
<slainer68> enfin bon.
|
||||
<pimpin> ouia, là est la question : la connerie est-elle une fatalité ? à force de rabacher ... peut etre que ça peut changer ?
|
||||
<slainer68> là c'est pire encore car le gus il a un existant en rails 2, sans test et tout.
|
||||
<Shine-neko> slainer68: moi perso si un client n'est pas un minimum impliqué c"est que c'est un mauvais payeur
|
||||
<pimpin> tu as vu le code slainer?
|
||||
<pimpin> tu dis que c'est sans test... est-ce homogène et propre ?
|
||||
Reference in New Issue
Block a user