Charte de responsabilité des programmeurs [fermée]

Nous avons donc tous entendu parler de la Charte des droits des programmeurs et XP a un concept similaire.

C'est une plainte commune de nos jours que nous entendons beaucoup parler des droits des personnes, mais pas tant de leurs responsabilités, alors que devrait être le cahier des charges des programmeurs. Ce sont des choses qu’ils devraient faire, qu’ils pourraient trouver désagréables, mais qui séparent les programmeurs agissant de manière professionnelle et responsable de ceux qui ne le font pas.

Je m'intéresse principalement aux désagréables et à ceux qui ont tendance à ne pas se produire. Ce sont ceux que les programmeurs ont tendance à éviter et à éviter, plutôt que ceux que 90% des programmeurs veulent réellement faire (comme toujours refactoriser et utiliser le contrôle de source).

Alors, que devrait figurer sur la charte de responsabilité des programmeurs?

• Un programmeur a la responsabilité de repousser les exigences peu élevées au lieu de les appliquer aveuglément. Cela implique de dire aux clients que ce qu'ils veulent coûte plus cher que les autres options ou comporte un ensemble de risques particulier. Cela implique également de communiquer de manière professionnelle les mauvaises nouvelles - ne pas crier, appeler des gens stupides, ce qui implique qu'ils sont stupides ou présentent un autre comportement enfantin. S'il repousse, il devrait avoir un ensemble de raisons (plus que "Je n'aime pas SQL Server et je ne l'utilise pas") et un plan alternatif à présenter.

• Cependant, le programmeur a également la responsabilité d'accepter les décisions et d'utiliser des outils ou des conceptions qui ne lui plaisent peut-être pas si leur refoulement n'était pas accepté. Si un rapport a été demandé dans SSRS, son envoi dans Crystal Reports (ce que le client n'a peut-être pas) est inacceptable. Si une solution .net était nécessaire, sa livraison en Haskell est inacceptable. Si personne d'autre dans l'équipe n'utilise un outil ou un langage que vous souhaitez utiliser, il est peu professionnel de l'utiliser si la direction n'est pas d'accord pour dire qu'il s'agit du meilleur outil pour un travail donné.

• Un programmeur a la responsabilité de tester son travail. (Cela ne devrait pas être le seul test, mais aucun programmeur professionnel ne devrait envoyer du code qu'il n'a pas encore testé.) Cela inclut de tester même les branches du code que vous ne vous attendez pas à frapper très souvent. Si vous avez un jeu de FI imbriqués, testez tous les itinéraires possibles.

• Un programmeur a la responsabilité de gérer les erreurs et les exceptions avec élégance et d'écrire des messages d'erreur que l'utilisateur verra professionnels et neutres, pas de blagues ni d'insultes.

• Un programmeur a la responsabilité de protéger les données privées, le code propriétaire qu'il écrit pour l'entreprise et de protéger les utilisateurs contre les catastrophes (même les catastrophes auto-infligées) de leur utilisation de l'application.

• Un programmeur a la responsabilité de s’assurer que son code est maintenable et qu’il est en contrôle de source.

• Un programmeur a la responsabilité de se coordonner avec les autres pour s’assurer que ses modifications n’affectent pas ce qu’ils font.

• Un programmeur a la responsabilité de recommander au client le meilleur choix d'outils ou de langues en phase de conception, et non de l'outil / de la langue avec lequel il souhaite jouer et apprendre.

• Un programmeur a la responsabilité de travailler avec tout le personnel approprié pour un projet, y compris ceux qu'il n'aime pas. Ce n’est pas votre travail d’aimer les gens, c’est votre travail de travailler avec eux et d’être poli.

• Un programmeur a la responsabilité de produire un produit qui respecte ce qui a été spécifié dans un délai raisonnable. Si le délai ne sera pas respecté, il lui incombera d’en informer la direction dès que celle-ci sera connue.

• Un programmeur a la responsabilité d'informer les gestionnaires de projet des obstacles à la réalisation du travail. Ils ne peuvent pas réparer ce qu'ils ne savent pas.

• Un programmeur a la responsabilité de s’acquitter de l’ensemble de la tâche et pas seulement des parties amusantes et intéressantes. Chaque travail a des parties ennuyeuses, il reste encore à faire. Cela inclut des choses comme les feuilles de temps et l'ajout d'éléments de discussion au logiciel de gestion de projet. Cela inclut des choses comme la documentation, la révision de code, etc.

• Un programmeur a la responsabilité d’apprendre le domaine commercial qu’il prend en charge, et pas seulement les concepts de programmation.

• Un programmeur a la responsabilité de maintenir ses compétences à jour.

• Lorsqu'un programmeur se trompe, il a la responsabilité de faire tout ce qui est en son pouvoir pour régler les problèmes le plus rapidement possible. Cela peut impliquer de porter les mauvaises nouvelles à la direction plutôt que d'essayer de cacher que vous venez de supprimer une table critique dans la base de données de production.

• Un programmeur a les mêmes responsabilités que tout autre travailleur - se présenter à l'heure, travailler les heures contractées, demander des vacances à l'avance, répondre à des messages téléphoniques et des courriels (enfin, lire leurs courriels), remplir les formulaires requis RH, etc.

Chaque programmeur devrait rendre son code lisible par d’autres.

Le programmeur est responsable de la confidentialité et de la sécurité de toutes les données fournies par l'utilisateur. Surtout les mots de passe, numéros de carte de crédit, adresses e-mail et emplacement physique.

Ne faites pas perdre le travail à l'utilisateur.

C'est plus difficile que ça en a l'air ... le travail ne consiste pas seulement en "données dans un fichier" ... c'est tout le temps que l'utilisateur a consacré à votre logiciel.

Par exemple, si l'utilisateur remplit votre formulaire de 30 champs avec 29 éléments valides et un élément invalide, n'effacez pas toutes ses données valides pour se plaindre du 1 invalide (heck, n'effacez même pas l'invalide. peut-être est-il long et nécessite-t-il une correction mineure, ou l'utilisateur ne se souviendra plus de ce qu'il était avant si vous l'effacez)

Un exemple non évident mais important est ce que Windows et pratiquement tous les autres logiciels de "gestionnaire de fichiers" se trompent ... si je passais une demi-heure avec soin à appuyer sur Ctrl-clic pour sélectionner un ensemble de fichiers et que je cliquais accidentellement au lieu de Ctrl-Click, il ne devrait pas effacer tous mes fichiers précédemment sélectionnés, ce qui me fait recommencer.

Un autre problème auquel ils se sont trompés ... si je frappe accidentellement sur Ctrl-A (au lieu de Ctrl-S juste à côté), cela ne devrait pas perdre ma place dans le fichier et mettre le curseur au début ... j'appelle trouver le bon endroit dans le fichier "travail" que le programme a "perdu".

Encore un autre: le dialogue "commit" de TortoiseSVN a une longue liste de fichiers. Avant de cliquer sur "Commit", vous pouvez descendre dans la liste des fichiers, en double-cliquant sur chacun d'eux pour voir ses modifications dans une 2ème boîte de dialogue. Pour faire cela rapidement, j'utilise parfois uniquement le clavier, en appuyant sur <Esc>pour fermer le deuxième dialogue et revenir au premier. Si je frappe accidentellement <Esc> deux fois, la première boîte de dialogue se ferme, ce qui me fait oublier le fichier que je préparais.

Un programmeur a la responsabilité de respecter le système sur lequel son programme sera exécuté. Une fois le développement et les tests terminés, le programme sera déployé pour être utilisé conformément à son objectif, ce qui implique généralement que d'autres personnes l'exécutent sur leur ordinateur. Le programmeur doit garder cela à l'esprit: son programme fonctionne sur la propriété de quelqu'un d'autre , et non sur la leur, et doit se comporter comme un invité chez eux au lieu de se faufiler comme s'il était propriétaire.

Par exemple, son programme ne devrait pas:

• modifier les paramètres globaux sans le consentement de l'utilisateur. (Y compris les problèmes de gestion de bibliothèque partagée .)
• supprimer ou modifier des données appartenant à l'utilisateur ou à un autre programme sans le consentement de l'utilisateur.
• se mettre à jour sans le consentement de l'utilisateur.
• se rendre difficile à désinstaller.
• se rendre difficile à fermer.
• désactiver lui-même ou interférer de quelque manière que ce soit avec le bon fonctionnement de l'ordinateur si le programme est incapable de passer une vérification de licence faillible .
• Supposons qu’il s’agit du seul programme important fonctionnant sur le système et de gérer les ressources système en conséquence. (Des exceptions peuvent être faites pour les machines à tâche unique réelles, bien sûr, ou pour les programmes que l'utilisateur pourrait normalement exécuter seul, tels que les jeux lourds en plein écran.)
• sauter devant l'utilisateur avec une fenêtre contextuelle pendant que l'utilisateur fait autre chose dans d'autres programmes. (Je te regarde, Yahoo Messenger!)

Extrait du Manifeste pour les artisans logiciels :

En tant que futurs artisans du logiciel, nous élevons la barre du développement logiciel professionnel en le pratiquant et en aidant les autres à apprendre le métier. Grâce à ce travail, nous avons pu valoriser:

• Logiciel non seulement fonctionnel, mais aussi bien conçu

• Non seulement réagir aux changements, mais aussi apporter une valeur constante

• Non seulement les individus et les interactions, mais aussi une communauté de professionnels

• Non seulement la collaboration client, mais aussi des partenariats productifs

C'est-à-dire qu'à la recherche des objets de gauche, nous avons trouvé que les objets de droite étaient indispensables.

Regardez dans le miroir et reconnaissez éventuellement les pires qualités d'un programmeur en lui-même. Ensuite, travaillez à les éliminer chaque jour.

1. N'apprends rien de nouveau
2. Ne cherche pas à développer tes compétences
3. Ne pas être ouvert au nouveau, s'en tenir aux vieilles habitudes
4. Ne pas se soucier de la qualité de votre travail
5. Ne pas chercher à améliorer la qualité de votre travail
6. Être un travailleur de 9 à 5 sans passion
7. Ne pas avoir sa propre opinion sur les choses
8. Accepter l'opinion des autres sans se poser de questions
9. Croire que vous avez tout appris
10. Ne tolérer aucune critique
11. N'écoute pas d'entrée externe
12. Être égocentrique, savoir-tout-individuel
13. Avoir une personnalité négative et critiquer les autres

• La responsabilité du programmeur est de créer un logiciel qui réponde aux besoins des exigences, de l'analyse, de la conception et des spécifications, tels qu'ils sont définis dans tous les contrats passés entre le programmeur et le client.
• La responsabilité du programmeur est de créer un logiciel économique, fiable et efficace sur de vraies machines.
• La responsabilité du programmeur est de travailler de manière aussi efficace, éthique et intègre que possible et de se conduire avec le plus grand professionnalisme.

Cela s’applique en partie aux responsabilités de «Une société de programmation ».

• Le programmeur doit connaître et utiliser les bibliothèques de base et la plate-forme utilisées.

Particulièrement quand le programmeur vient d'une autre plate-forme / langue. C’est terrible de trouver le programmeur qui se bat pour quelque chose que fournit la bibliothèque principale ou d’utiliser à mauvais escient l’avantage de la plate-forme en raison de son ignorance.

• Le programmeur doit créer du code auto-documentant

Il est très important que le code soit documenté pour que d'autres puissent l'utiliser, mais en ce qui concerne la facilité de maintenance, le code auto-documenté peut littéralement économiser des heures et des heures de frustration.

Par exemple, comparez:

// validates if is leap year
if(  year % 4 == 0 && (year % 100 != 0 || year % 400 == 0) ) { 
     doSomethingWithFebruary();
}

à

if( isLeapYear( year ) ) { 
    doSomethingWithFebruary();
}

La programmation est un métier, pas une compétence. Cela signifie qu'un programmeur a la responsabilité de rester au courant des derniers outils, techniques et technologies dans son domaine.

Cela peut impliquer de demander aux gestionnaires de donner du temps pour permettre un apprentissage et une formation continus, ou de le faire pendant votre temps libre.

1) Expliquez clairement qu'une solution à tout problème entraînera des compromis entre performance, coût, délai et qualité.

2) Compléter la documentation pertinente, qu’elle publie des notes ou des plans de test. (la documentation varie selon le type et la taille de l'entreprise)

3) Demander les bons outils pour leur travail (tant de gens se plaignent de cela mais ne contactent jamais leur patron avec des arguments raisonnables pour obtenir ce dont ils ont besoin)

... D'autres sans doute à suivre.

Question n'importe quoi - Un programmeur devrait avoir la responsabilité de s'informer de tout ce qu'un système peut être appelé à faire ou à gérer. Cela peut inclure de demander ce que les utilisateurs peuvent considérer comme des questions idiotes, car différents sites sont consacrés à montrer ce que les utilisateurs peuvent être capables de faire. Daily WTF et SharkTank sont quelques exemples, mais je suis sûr qu’il en existe d’autres.

Un programmeur est responsable de la conversion des user stories du backlog du produit en incréments logiciels opérationnels et livrables.

C'est pourquoi les gestionnaires doivent s'assurer qu'ils ont tout pour leur but.

Voici ma proposition.

1. Un programmeur doit exiger les conditions de travail exposées dans la déclaration de droit du programmeur, afin de ne pas abaisser les normes du poste.

(Pour "programmeur", je veux dire "programmeur", pas "pirate de week-end", donc toutes les choses habituelles qu'un programmeur devrait faire sont implicites.)

5 préceptes de la guilde du programmeur

1.) vérifier son code hebdomadaire et les jours fériés.

2.) répondre aux besoins de la communauté de programmation.

3.) lire au moins un livre de programmation par an.

4.) assistez à au moins une conférence de programmation par an.

5.) reconnaissez vos erreurs.

Je vais ajouter "toujours documenter toutes les hypothèses faites" à la liste. :-)

Un programmeur ne doit pas faire ou mettre en œuvre quoi que ce soit qui soit contraire à l'éthique ou illégal, comme écrire des virus ou pirater les systèmes d'autrui (à moins que ce soit pour découvrir des failles de sécurité et ensuite en informer la victime et ce qu'elle peut faire pour éviter que cela ne se produise. exploité par des pirates informatiques malveillants).