J'essaie aussi de faire ça ; malheureusement, mes bonnes résolutions sont vites périmées et il faut ensuite que j'attende un sursaut de courage pour recommencer :(.
Non en fait mon père est formateur en management de projets et il m'a toujours dit de faire ça, jusqu'au jour où j'ai décidé d'arrêter de penser que c'était un vieux qui radote et que j'ai décidé de l'appliquer réellement.
Quand j'ai appris qu'évidemment c'était une méthode connue et reconnue (bah oui…), il m'a dit "ah merde ils m'ont volé mes idées dit donc", je soupçonne un tantinet de malice…
Mais quand on voit les résultats que ça donne je ne suis pas surpris du tout que ce soit aussi célèbre. Et Get Things Done englobe bien plus que ça, mais c'est vrai que c'est le point le plus marquant, le plus simple, et peut-être le plus efficace de tous.
@lethom : prend le pour "principe", c'est aussi simple que ça. Ou vois ça comme un petit jeu avec toi-même. C'est pas "une bonne résolution" c'est un réflexe qui devient presque conditionné. Tu penses à quelque chose, tu vois quelque chose, tu te poses immédiatement la question "est-ce-que ça prend moins de deux minutes ?" ça devient très très vite un réflexe dans la vie de tous les jours. Et plus encore : ça s'entretient tout seul. Moins t'as de trucs qui traînent, plus vite tu repères les trucs qui traînent, et moins de temps tu mets pour les traiter. Du coup, de plus en plus de choses rentrent dans la case "moins de deux minutes", etc. Un espèce de cercle vertueux.
@lethom : prend le pour "principe", c'est aussi simple que ça. Ou vois ça comme un petit jeu avec toi-même. C'est pas "une bonne résolution" c'est un réflexe qui devient presque conditionné. Tu penses à quelque chose, tu vois quelque chose, tu te poses immédiatement la question "est-ce-que ça prend moins de deux minutes ?" ça devient très très vite un réflexe dans la vie de tous les jours. Et plus encore : ça s'entretient tout seul. Moins t'as de trucs qui traînent, plus vite tu repères les trucs qui traînent, et moins de temps tu mets pour les traiter. Du coup, de plus en plus de choses rentrent dans la case "moins de deux minutes", etc. Un espèce de cercle vertueux.
Exactement. Perso j'ai lu un peu de ce bouquin, j'ai principalement retenu ce concept que j'essaie d'appliquer et Javier ne ment pas, c'est redoutable !
Ah pour mon côté maniaque de la doc j'ai également la chance d'avoir un directeur technique militaire qui relit tout ce qui passe dans les tickets. Mon bureau est en bordel mais mes docs sont à la virgule près.
D'ailleurs c'est le même genre de cercle vertueux qui se produit quand on commence à utiliser pylint. D'abord c'est un jeu (chercher la note de 10/10, donc TOUT documenter, tout bien nommer, tout présenter correctement, ne pas prendre de raccourcis dégueus), puis ca finit en réflexe. Si je tape def spam(), mes doigts sont conditionnés pour terminer la séquence par deux-points/entrée/3x simplequote/entrée/entrée/3x simplequote/haut.
Le pire c'est qu'un beau jour je me suis dit que je ferais mieux de configurer mon éditeur pour qu'il le fasse à ma place, mais j'ai jamais réussi à m'y faire : impossible de désapprendre la séquence à mes doigts.
Ça dépend. On peut également mettre un point à chaque ligne et commencer par une majuscule sur l'entrée suivante. Cela sert notamment pour les listes où chaque élément est une phrase complète ou plusieurs phrases.
Puisqu'on en est aux déformations professionnelles, voici les miennes :
Quand j'utilise quelque chose qui possède des automatismes (métro lillois entre autres), je m'imagine l'algorithme qui est utilisé pour le faire fonctionner… et je m'imagine la cause d'un bug lorsqu'il a lieu !
Quand je lis une feuille et que je dois y trouver une information précise, j'ai envie de faire un Ctrl+F (classique, je sais)
J'ai toujours ZdS ouvert en arrière plan, même si il ne s'y passe absolument rien. Je le rafraîchit de temps en temps pour voir si l n'y a pas de nouveaux tutos ou articles.
Je peut pas blairer Git. Enfin, sur le principe je trouve ça génial, mais j'y comprends rien et je galère complet avec.
Je mets de la musique, sinon je parle tout seul (oui, je suis bizarre …)
Quand il y a une exception dans mon programme je mets des points d'arrêt à chaque (ou presque) pour bien voir d'où viens le problème.
de la musique, selon l'humeur, mais en général c'est mieux quand ça motive ;
il arrive que je passe plus de temps à changer de musique qu'à coder, pour remédier à ça : playlist ;
je suis très à cheval sur la propreté de mon code et de mon indentation, même si :
je n'ai pas de règle définie pour tout, particulièrement sur les lambdas où je me cherche encore ;
ma lecture reste confortable même quand plusieurs styles se mélangent, je m'en accommode très bien car c'est une perte de temps de vouloir faire coder tout monde dans le même style, mieux vaut apprendre à lire tous les styles (j'étais limite maniaque là dessus avant, mais ça va beaucoup mieux ) ;
une règle d'or : ce qui est important doit être visible, ça implique :
pas de commentaire - doc comprise - quand le code s'exprime tout seul ;
quand je mets un commentaire - doc comprise -, faut le vouloir pour le zapper ;
quand je fais une lib publique, soit j'applique cette règle, soit je fais une documentation quasi-normative - et là la doc devient plus importante que le code ;
plus le code est expressif, mieux je me porte ;
du code générique, oui, du code template seulement quand c'est nécessaire, using jamais ;
je déteste git, mais comme mon VCS préféré (bazaar) est en train de mourir, j'ai pas bien le choix. Smartgit sous Windows, beaucoup de jurons dans un terminal (c'est le pire vcs que j'aie jamais vu dans un terminal). Un jour je coderai un autre VCS. Un jour.
même si je suis un aficionado de Code::Blocks, je l'utilise à défaut de mieux, un jour je coderai un nouvel IDE, un jour ;
le C++ c'est aussi faute de mieux, un jour je créerai un nouveau langage, un jour ;
je hais Cmake, jamais je coderai un truc pareil !
Ma petite manie la plus récurrente : ne pas être satisfait des outils disponible (mais les choisir avec soin quand même).
Pardon, ce n'est pas très clair, jamais de using whatever; ou using namespace whatever;.
Pour le using namespace parce que ça ne fait que cacher les éléments extérieurs au module, alors que je trouve que ça a un vrai intérêt de distinguer ce qui fait partie intrinsèquement du module actuel et ce qui est une dépendance. Il m'arrive de l'employer de façon très spécifique, par exemple pour les std::placeholder::_N;
Pour le using whatever;, parce que je n'aime pas la nouvelle tendance qui vise à écrire dix lignes de plus pour économiser 3 caractères. C'est pas "plus générique", c'est un mauvais design.
Par contre beaucoup de using Truc = Chouette; parce que ça fait du générique pour pas cher, très facilement substituable.
Bière ou café. Si c'est vide depuis 20 minutes, je termine mon algo et je vais faire le plein.
Si une erreur survient et que je ne la comprends pas, je me passe la main dans les cheveux. Systématiquement.
Si une erreur survient et que je n'arrive pas à la corriger, je vais éclater du zombie.
J'engueule copieusement la personne qui travaille à côté de moi et qui fait du bruit pendant que je me prends la tête sur un algo.
Quand je suis à fond dans mon travail, j'oublie de manger. Il arrive que je sois totalement affamé et de ne m'en rendre compte qu'à cause du bruit de mon estomac mécontent.
Je laisse des références culturelles dans mes commentaires (style répliques de film).
Je m'arrête de taper quand quelqu'un se place dans mon dos et j'attends qu'il parte avant de reprendre.
Et toutes les autres petites habitudes du développeur maniaque (indentation, rangement des dossiers, formatage du code, git status avant de commit, etc).
Marrant ce topic sinon, on voit que finalement on n'est pas le seul à avoir des manies parfois un peu étranges ahah.
Quand je suis à fond dans mon travail, j'oublie de manger. Il arrive que je sois totalement affamé et de ne m'en rendre compte qu'à cause du bruit de mon estomac mécontent.
La vache, moi aussi! Je le remarque quand mes collègues reviennent de manger. Ou alors j'oublie de partir et je m'en rends compte quand la femme de ménage passe.
Je fait git status, git commit, git status à chaque fois (enfin y a une variante : git status, 'tin quel con, cd path/to/rep, git status, git commit, git status).
Tout ce qui est mal indenté, je le vois tout de suite. 2 espaces partout et surtout pas de tabulations.
Pourquoi mettre les accolades en fin de ligne façon Java ? C'est moche.
Les IDE c'est mal, vim+compilo c'est mieux.
Mon bureau est relativement simple, en tiling : à droite firefox (doc, stackoverflow…) et à gauche c'est en haut vim et en bas le shell (compilation/exécution).
Toujours de la musique, peu importe quoi.
Quand je code en C++ et que g++ me parle de template, je lance le fameux colorscheme.sh avant chaque compilation pour savoir où commencent les insultes.
Je connais l'architecture de tous mes projets par coeur, au détail près. Par contre j'ai pas encore dépassé le main en terme de code.
Je ne supporte pas qu'on se poste derrière moi pour me regarder coder sans mon autorisation, surtout si c'est un prof… au point de faire un malaise.
Un jour je troquerai mes compile.pl/compile.sh pour des Makefile, un jour…
Un jour j'arrêterai de créer des fonctionnalités révolutionnaires venues du froid à coup de template et de #define pour obtenir un C++ fait maison.
Avoir "_system" en fin de nom de classe c'est bien.
J'aime tellement pas créer un dépôt git pour rien qu'au final je le crée qu'à la première release du projet (excepté si on est plusieurs dessus).
Il y a 2 sortes de programmeurs… Et il y a les conventions de codage (par langages, par projet, par société…).
En php je mets les deux accolades seules sur leur ligne, au niveau du if/for/function/whatever,
en javascript, j'ouvre sur la même ligne et je ferme au niveau du if/while/whatever, avec les parenthèse et point virgule sur la même ligne s'il y a lieu.
En python, muhahaha (les accolades ne servent que pour les dictionnaires, souvent, tout sur la même ligne)
En python, muhahaha (les accolades ne servent que pour les dictionnaires, souvent, tout sur la même ligne)
1
2
3
4
5
6
7
8
$ python3
Python 3.4.0 (default, Apr 11 2014, 13:05:11)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
>>>
Je ne suis pas dev de profession, (je vais me faire taper pour mes propos)
par le passé j'avais des mauvaises manies : pas de commentaires, des noms de variables a la con pour tester (avec parfois des jeu de mot de merde) sauf qu'une fois que mes tests étaient fini, le nom a la con restait souvent en place.
Des messages d'erreurs ou de réussites non explicites : dans un si j'affichais OK si ca fonctionnait ou KO si ca ne fonctionnait pas, ou des messages d'erreurs avec insultes envers moi même quand je galérais trop longtemps sur un truc. En général j'oubliais de corriger ça et je me retrouvais avec plusieurs si sinon avec des Ok et Ko qui s affiche donc quand je lançais le script ça m'affichait OK puis OK puis ko puis ok puis ko et parfois ça crash sans que je sache trop ou j'étais rendu …
Pas d'indentation …
Depuis j'essaies de faire ça bien mais les mauvaises manies ont la vie dure …
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
) ;
