Surmonter la lenteur de la résolution de problèmes grâce à une meilleure connaissance de ce qui pourrait mal tourner [fermé]

450

Cela me trouble depuis quelque temps et j'apprécierais vraiment la contribution d'autres professionnels.

Contexte bref: j'ai commencé à programmer lorsque mes parents m'ont acheté mon premier ordinateur en 1988 (à 14 ans, j'ai 39 ans maintenant). J'ai suivi plusieurs autres carrières avant de devenir finalement programmeur professionnel en 1997. La floraison tardive peut-être, mais c'est comme ça. Je suis toujours satisfait de mon choix, j'adore programmer et je me considère bien dans ce que je fais.

Dernièrement, je me suis rendu compte que plus je gagnais d'expérience, plus je mettais de temps à terminer des projets ou certaines tâches d'un projet. Je ne vais pas encore sénile. C'est juste que j'ai vu tellement de façons différentes dont les choses peuvent mal se passer. Et les pièges potentiels et les pièges que je connais et dont je me souviens deviennent de plus en plus nombreux.

Exemple trivial: il était simplement "d'accord, écris un fichier ici". Maintenant, je m'inquiète des autorisations, du verrouillage, de la concurrence, des opérations atomiques, de l'indirection / des cadres, des systèmes de fichiers différents, du nombre de fichiers d'un répertoire, des noms de fichiers temporaires prévisibles, de la qualité du caractère aléatoire de mon PRNG, des coupures de courant au milieu de tout opération, une API compréhensible pour ce que je fais, une documentation appropriée, etc. etc. etc.

En bref, les problèmes sont depuis longtemps passés de "comment puis-je faire cela" à "quel est le meilleur moyen / le plus sûr de le faire".

Le résultat est qu'il me faut plus de temps pour terminer un projet qu'un novice. Ma version est peut-être aussi solide et impénétrable que je le sais, mais cela prend plus de temps.

L'exemple "créer un fichier" ci-dessus était juste un exemple. Les tâches réelles sont évidemment plus complexes, mais moins adaptées à une question générique comme celle-ci. J'espère que vous comprenez où je veux en venir. Je n'ai aucun problème à trouver des algorithmes efficaces, j'aime les mathématiques, j'apprécie les sujets complexes, je n'ai pas de problèmes de concentration. Je pense que j'ai un problème d'expérience, et par conséquent de peur des erreurs (intrinsèques ou extrinsèques).

Je passe presque deux heures par jour à découvrir les nouveaux développements, les nouvelles techniques, les langages, les plates-formes, les vulnérabilités en matière de sécurité, etc. Le casse-tête est que plus je gagne de connaissances, plus je suis lent dans la réalisation de projets.

Comment gérez-vous cela?

Zilk
la source
126
La leçon clé est la suivante: respectez les exigences, pas plus . De cette façon, vous n'essaierez pas d'implémenter des fonctionnalités inutiles.
mouviciel
19
Vous considérez la méthodologie de développement agile au lieu du modèle en cascade. Livrez les grandes choses en premier et livrez le reste de manière itérative. Ce nouveau concept aide à réduire les risques et les coûts.
Satish
23
Résumer les points de vue et ajouter le mien (au cas où vous l'auriez oublié): vous devriez envisager des projets plus critiques (du point de vue commercial, pas du point de vue de la sécurité), ou des exigences plus élevées en matière de qualité (faibles défauts) par rapport à la richesse des fonctionnalités. En d’autres termes, recherchez des projets dans lesquels vos meilleures compétences sont les plus recherchées.
rwong
13
Lorsque vous lisez l'un des livres sur la qualité du code, le thème qui vous résonne est qu'il peut coûter plus cher de créer un code de qualité. En premier lieu, il en coûtera moins à long terme une fois que vous aurez pris en compte la maintenance.
James Snell
6
"Fais la chose la plus simple qui puisse fonctionner." Une fois que vous avez fait cela, alors vous décidez si vous devez vous soucier de rien d'autre.
Wayne Werner

Réponses:

268

Vous n'êtes pas plus lent dans l'achèvement des projets. Auparavant, vous pensiez que vos projets novices étaient terminés alors qu’ils ne l’étaient pas. Vous devriez vendre cette qualité aux clients.

"Cette entreprise pourrait faire le travail plus vite et moins cher, mais est-ce vraiment fait? Ou allez-vous chasser les insectes pendant des années?"

Au-delà de cela, vous devez connaître et accepter le vieil adage: "Le parfait est l’ennemi du bien".

Telastyn
la source
112
ça me rappelle «bon, rapide, pas cher, choisissez deux» - lorsque vous en saviez moins que vous sacrifiez pour le «bon», et que maintenant que vous en savez plus, vous sacrifiez pour le «rapide».
Sevenseacat
10
@ Neil rien ne peut être sans bug. Il y aura toujours un problème, ils deviennent simplement plus petits ou plus complexes. Idéalement, le PO devrait trouver une marque où il termine assez rapidement et ne laisse que peu d' assez de bugs pour être satisfait de sa qualité, et
satisfera
10
@Neil "Dans les délais. Dans les limites du budget. Sur Mars. Choisissez-en deux."
Dan Neely
5
@ Leonardo: non, la forme de Telastyn est correcte (et c'est un dicton assez ancien . Voir aussi YAGNI et "si cela fonctionne, ne le
corrigez
3
Cette réponse est des conneries. Allez-y, essayez de dire à un client potentiel que vous le ferez pour 40K au lieu de 20K mais avec 10 fois plus de qualité et de fiabilité. Ils vous diront ceci: "Mon budget est de 20 000 $ et je n'ai pas besoin de cette qualité". À un moment donné, vous devez accepter le fait que 99% des clients ne se soucient pas vraiment de la qualité et que la qualité de votre travail représente votre investissement personnel.
Morg.
179

On dirait qu'il est temps pour vous de rejoindre le côté obscur: la gestion.

Je ne suggère pas que vous abandonniez la programmation et deveniez un gestionnaire. Mais il semble que toute l'expérience que vous avez citée jusqu'à présent soit de nature technique. Dans une simple opération d'écriture d'un fichier, vous pouvez imaginer 10 aspects différents qu'un développeur moins mature ne prendrait jamais en compte. Pas nécessairement une mauvaise chose, mais ...

Le côté obscur concerne la valeur actuelle. Il s’agit d’un investissement minimal pour un gain maximal (analyse coûts-avantages). En affaires, tout se résume à combien cela va me coûter, probabilité de succès, probabilité d'échec, probabilité d'échec spectaculaire et gain potentiel. Faire le calcul; agir en conséquence.

Cela fonctionne aussi bien lorsque vous êtes développeur: créez un fichier temporaire en ignorant les autorisations et les conflits de noms - 5 min. Gain net, le reste de l'équipe peut commencer à travailler sur n'importe quel code dépendant de la présence de ce fichier. Est-ce une solution parfaite? Absolument pas. Cela vous rapportera-t-il 99%, 95%, peut-être 90%? Oui, probablement.

Autre question à poser: que pensez-vous de la dette technique? Certaines personnes pensent qu'il faut l'éliminer. Je pense que ces gens ont tort. Comme dans le monde des affaires, la dette technique vous permet d’emprunter de l’argent ou du temps afin de livrer quelque chose plus tôt. Quoi de mieux: Une solution parfaite en 2 ans ou un hack complet qu'un client peut utiliser et acheter en 4 mois? Chaque situation est différente, mais dans certaines situations, si vous attendez 2 ans, votre client s'inscrira déjà avec votre concurrence.

L'essentiel est de gérer la dette technique de la même manière qu'une entreprise bien gérée gère la dette financière. Si vous n'en prenez pas assez, vous n'obtenez pas un retour sur investissement optimal. Si vous en prenez trop, les intérêts vont vous tuer.

Alors, mon conseil: Commencez par évaluer votre travail en fonction de l’optimisation de votre valeur plutôt que de votre minutie. Et si vous le pratiquez, vous développerez la même intuition que celle que vous avez déjà développée dans votre domaine technique.

En passant , j'ai récemment commencé à utiliser la technique du pomodoro et cela m'a beaucoup aidé. Au lieu de prendre la tangente d'une tangente, concentrez-vous sur de petits intervalles de temps, puis affectez des pomodoros à de futurs travaux / recherches. C’est étonnant de voir combien de fois j’ai pris note de faire une recherche sur un sujet, mais une heure plus tard, le moment venu, je me suis dit: «Il ya au moins trois autres choses que je pourrais faire avec mon temps aujourd’hui, qui ont toutes plus de valeur.»

DXM
la source
9
Donc, selon vous, créer délibérément des bugs est acceptable tant qu'ils se produisent assez rarement?
scai
87
@scai - vous choisissez vos batailles. Je suis dans l'industrie depuis 15 ans et je n'ai vu aucune publication dans 3 entreprises avec lesquelles j'ai travaillé à ce jour, livrées avec 0 bogue. Cela n'arrive pas dans le monde réel. Je ne dis pas que vous introduisez intentionnellement du code erroné, mais il existe un niveau de perfection et de protection contre les balles qui ne rapporte tout simplement pas ses fruits
DXM
25
Créer un bogue "délibérément" voudrait dire que le bogue lui-même était intentionnel - ce qui n’est pas la même chose que d’être conscient de la possibilité ou même de l’existence spécifique d’un bogue ou d’une incompatibilité. J'ai une application HTML5 qui ne fonctionne pas correctement dans IE6, j'en suis consciente, je pensais même que ce serait le cas lorsque je l'aurais créée - c'est juste que "ceux qui comptent importent peu ne compte pas ". Vous pouvez sciemment construire un pont qui ne résistera pas à une attaque nucléaire, et ce n'est pas grave.
BrianH
27
+100 pour votre prise sur la dette technique. À l'instar du PO, j'ai essayé d'éliminer toute dette technique. Je n'avais jamais envisagé l'idée d'une dette technique, c'est bien, jusqu'à ce que l'intérêt commence à vous tuer. Je constate maintenant que la gestion de la dette est beaucoup plus importante que son élimination. Je n'y avais jamais pensé auparavant. (d'ailleurs j'utilise aussi la technique pomodoro.)
adj7388
6
Cette réponse reflète étroitement ma propre expérience et prend en charge la dette technique. Plus que de le créer intentionnellement, simplement en confiant le travail à du personnel débutant, vous vous retrouvez naturellement avec une dette technique, qui doit être corrigée ultérieurement, ce qui les éduque dans le processus. En gros, une fois que vous atteignez cette étape, vous DEVEZ investir dans l’apprentissage des compromis et penser en termes d’emprunt qui doit être remboursé plus tard. Ceci parce que vous DEVEZ confier le travail à du personnel débutant simplement parce qu’il n’ya qu’un d’entre vous, et même si la qualité que vous obtenez est inférieure, vous pouvez obtenir ce qui serait impossible pour vous seul.
SplinterReality
94

J'ai eu le même problème (probable) il y a plusieurs années, cela a duré quelques années et je l'ai surmonté. Vous voudrez peut-être alors savoir comment j’ai atteint cet objectif, même si je ne suis pas sûr que ma façon de procéder s’appliquera également à vous.

Vous devriez également jeter un coup d'oeil ici: Les sept étapes de l'expertise en génie logiciel Cela montre que la productivité est en grande partie un effet secondaire du niveau de compétence. Il se peut que vous soyez encore à un moment donné entre les étapes 3 et 4 de la technologie que vous utilisez actuellement (la maîtrise des compétences dépend de la technologie, vous pouvez maîtriser certaines technologies tout en en apprenant d'autres).

Maintenant, je commence par un témoignage biographique.

Un peu de contexte. J'ai 47 ans. J'ai commencé à programmer à 12 ans dans les années 80. Au lycée, j'ai également travaillé comme programmeur professionnel de jeux vidéo à temps partiel. En gros, cela ne m'a pas rapporté beaucoup d'argent, juste assez pour acheter du matériel, mais je l'ai apprécié et j'ai beaucoup appris. À 18 ans, j'ai commencé un apprentissage formel en informatique.

En conséquence, à 20 ans, chaque fois que je commençais une tâche de programmation, je connaissais de nombreuses façons de résoudre les problèmes posés et j'étais très conscient des nombreux paramètres et pièges à résoudre, ainsi que des inconvénients et des limites de toute méthode.

À certains moments (par exemple environ 26 ans), il est devenu très difficile pour moi d'écrire un programme. Il y avait tellement de possibilités ouvertes que je ne pouvais plus choisir entre elles. Pendant quelques années (make it 6), j'ai même arrêté la programmation et je suis devenu rédacteur technique.

Je n'ai jamais totalement arrêté d'essayer de programmer quand même. Et à un moment donné, il est revenu. La clé pour moi était la programmation extrême, plus particulièrement le principe de simplicité: «écrivez la chose la plus simple qui pourrait fonctionner».

En gros, je me suis forcé de ne pas me soucier de l’efficacité du code (c’était mon principal obstacle, éviter les conceptions inefficaces), mais j’allais de la manière la plus simple. Je me suis aussi obligé de ne pas me soucier des erreurs et de reporter le traitement des erreurs à une date ultérieure, après avoir écrit des tests qui génèrent l'erreur (en réalité, il s'agit de TDD).

C'est quelque chose que j'ai appris en écrivant. Quand je ne sais pas quoi écrire, ou je savais que ce que j'écrivais était mauvais . Continue. En fait, écrivez les mauvaises choses. Je vais éventuellement le corriger plus tard. Ou si c'est vraiment si mauvais, effacez-le et réécrivez-le, mais il est plus rapide d'écrire des choses deux fois qui écrivent quelque chose de parfait la première fois.

En réalité, il est très probable qu'un code que vous croyez bon en première écriture nécessitera autant d'amélioration qu'un très mauvais code.

Si vous suivez le chemin de la simplicité, vous obtenez également un bonus supplémentaire. Vous acceptez facilement de supprimer / modifier la conception / le codage initial. Vous obtenez un esprit plus flexible.

J'ai également pris l'habitude de mettre un commentaire temporaire dans le code, expliquant ce que je ne faisais pas maintenant et que je voulais faire plus tard, lorsque le code serait fonctionnel dans le cas d'utilisation normale.

J'ai également assisté à un kata de code pratiqué par un dojo XP et pratiqué avec d'autres programmeurs pour internaliser les pratiques XP. Ça m'a aidé. Cela a rendu les méthodes formelles ci-dessus instinctives. La programmation en binôme a également aidé. Travailler avec de jeunes programmeurs donne un certain élan, mais avec l'expérience, vous voyez aussi ce qu'ils ne voient pas. Par exemple, dans mon cas, je les vois souvent s'engager dans des conceptions trop compliquées et je connais le cauchemar en matière de conception auquel elles peuvent donner lieu. Allé de cette façon. Fait ça. Eu des problèmes.

Le point primordial pour moi est de garder le cap. Être rapide, c'est vraiment réussir à garder le flux.

Maintenant, je suis de retour en tant que programmeur professionnel et je crois que je suis à la fois meilleur et plus rapide avec une compréhension plus profonde de ce que je fais. En pratiquant le TDD, je suis peut-être encore un peu plus lent que lorsque j'étais un jeune taureau (et je n’ai rien testé), mais je n’ai également pas de refactoring sur la peur et je passe certainement beaucoup moins de temps à déboguer (presque pas de temps, moins de 10% du temps) ).

En résumé: j'ai surmonté mon codeblock en utilisant des méthodes agiles (XP), en optant pour la simplicité, puis en le refacturant, et en pratiquant pour rendre cela instinctif. Cela a fonctionné pour moi. Pas sûr que cela puisse être généralisé à quelqu'un d'autre.

En ce qui concerne le niveau d’acquisition des compétences, j’ai surtout appris à accepter que chaque fois que je changerais de technologie (apprendre un nouveau langage, un nouveau cadre, etc.), je passerais par une étape de ralentissement. Ceci est normal et finira par surmonter cela. Je peux aussi compenser cela avec une bonne méthodologie et des compétences en programmation à usage général et ce ne sera pas un problème.

kriss
la source
22
+1 pour "c'est plus rapide d'écrire deux fois des choses qui écrivent quelque chose de parfait la première fois"
Brendan Long
2
+1 pour le partage d'une histoire personnelle, ce qui, à mon avis, sera reconnaissable et utile pour le questionneur.
R. Schreurs
Je suis d'accord, vous rencontrez peut-être un blocage de codeurs (comme le bloc de l'écrivain). Vous ne pouvez pas gérer la complexité, alors vous traînez. Le remède est le même que pour l'écrivain; écrire quelque chose . Dès que vous avez quelque chose à l'écran, il vous donnera des idées sur la façon de procéder. Ce conseil vous a probablement été donné sous une forme moins claire: "Ne vous inquiétez pas pour l'efficacité / les erreurs / peu importe, faites quelque chose rapidement." Eh bien, c'est la moitié de la réponse. L'autre moitié est qu'une fois que vous avez passé l'écran vide, en faisant la réelle gestion des erreurs, algo efficace ou tout ce qui est simple.
SeattleCplusplus
@SeattleCPlusPlus: Je conviens que c'est simple pour des problèmes simples, probablement pour la plupart des codes algorithmiques. Ce n'est pas si simple lorsque vous voulez obtenir de bonnes structures de classes. Les règles de refactoring ne sont pas totalement inutiles.
Kriss
41

Une partie importante de la programmation est la gestion et le contrôle de la complexité et, pour moi personnellement, c'est l'un des principaux problèmes. Si vous l'ignorez, la fréquence des défaillances augmente ou, comme dans votre cas, la ETA des logiciels finis augmente considérablement.

Soit une augmentation des déficiences ou une diminution de l'ETA

La complexité logicielle peut être contrôlée et gérée de nombreux niveaux et de différentes manières, mais une bonne règle générale est la suivante: "La priorité absolue de tout projet logiciel est la satisfaction du client, qui est fonction de ses attentes."

En d'autres termes, la complexité logicielle dépend en grande partie de votre capacité à maîtriser les attentes de votre client.

Quand on adopte ce point de vue, deux points importants deviennent évidents:

  1. les attentes des clients doivent être explicites (sous quelque forme que ce soit);
  2. Les attentes des clients peuvent toujours être modifiées et cela se fait à travers l'art de la négociation.

Votre exemple est très bon ", écrivez simplement" vs "myriade d'autres considérations". Pensez-y. Si quelqu'un devait écrire des exigences exhaustives pour les deux variantes, peut-il y avoir une équivalence dans les caractéristiques décrites ou non?

Construire un F16 est différent de construire un Cessna bien que les deux puissent voler.

Saul
la source
24

La réponse simple est: acceptez-le.

Dans tous les systèmes, il faut faire des compromis entre fiabilité, robustesse, sécurité, rapidité, coût du matériel, coût de développement, délai de commercialisation, par exemple. Vous ne serez pas toujours d'accord avec la façon dont le client fait ces compromis, mais ce n'est pas vous qui prenez ces décisions. Tout ce que vous pouvez faire est de donner un avis réfléchi. Le développement logiciel couvre toute la gamme, de "ma page Web personnelle" à "exécuter le réacteur nucléaire", et le code doit être écrit en conséquence. Si un crash signifie "recharger ma page Web personnelle", qui se soucie vraiment de cela? Mais si un crash signifie "Tchernobyl", votre préférence pour le code solide est un peu désinvolte à mon goût.

Certains clients acceptent volontiers le code de niveau "Proof of Concept" et l'exécutent dans leurs systèmes en direct. Ils ont souvent des administrateurs système très habitués à cela. IME leurs systèmes sont généralement indisponibles pendant une heure environ au milieu de la nuit, alors que de nombreux redémarrages programmés se produisent. Mais ils ont décidé que c’est comme ça qu’ils veulent rouler. Idéalement parce que leur domaine est si rapide que des codes de haute qualité ne seraient jamais prêts, mais souvent parce qu'ils ne peuvent pas en voir la valeur (si un système fonctionne "simplement", ils ne le remarquent jamais, donc ce système ne représente pas une valeur pour argent). Si cela vous dérange trop, essayez d'éviter ces clients.

Rester à jour est le temps que nous devons tous dépenser, ou du moins que nous devrions dépenser. Parfois, cela vous amène à travailler, d'autres fois, votre esprit reste en bonne santé. Quoi qu'il en soit, essayez d'en profiter.

Móż
la source
4
Ce peu "un peu décontracté à mon goût" dans votre comparaison de Tchernobyl a fait ma journée. En fait, j'ai ri aux éclats :)
Zilk
16

Il semble que vos compétences seraient très utiles pour le développement de systèmes critiques de très haute qualité, tels que les applications liées au secteur financier / commercial, la diffusion, l'aérospatiale, la défense ...

Les erreurs dans ce type d'applications sont très coûteuses et emploient des personnes qui pensent comme vous, car vous pouvez couvrir tous les cas.

utilisateur1037729
la source
15

La vérité est que les systèmes modernes deviennent de plus en plus complexes. L'ordinateur est maintenant similaire au jeu "Jenga" où toutes ces pièces sont basées sur de nombreuses autres. Sortez le mauvais morceau et vous avez une erreur, sortez un morceau correct / nécessaire et vous pouvez toujours produire une erreur. Plus le système est complexe, plus vous passerez de temps à réfléchir aux moyens de rendre votre code plus robuste et, espérons-le, plus sécurisé. Vitesse serait une bonne chose, mais je pense que la vitesse passe souvent au second plan quand on apprend aux nouvelles que la société "XYZ" a été piratée et que 6 millions de numéros de cartes de crédit ont été volés.

Vos clients ne voudront peut-être pas savoir que leur programme doit être sécurisé, robuste, etc. Mais vous pouvez leur dire que leur voiture n’a pas besoin de ceintures de sécurité et d’airbags, ni que leur maison a besoin de serrures et de portes ... car qui veut tout entendre cette?

Si vous réfléchissez trop, vous agissez de la bonne façon, sauf que vous devez choisir une stratégie qui semble "concrète" et la suivre.

David Betournay
la source
9

On dirait que vous êtes conscient de votre tendance à penser à tout ce qui peut mal se passer.

Expérimenté prudent Les développeurs apprennent souvent à suivre le mantra YAGNI, vous n'en aurez pas besoin quand ils essaieront de revenir à un flux de travail maigre, agile et productif après s'être trop étouffés sous les mauvaises herbes de l'analyse du mode d'échec.

Toutefois, si vous écrivez effectivement quelque chose dans un domaine où ce niveau de soin n’est pas inférieur à ce que demande le professionnalisme, vous devez alors réaliser que votre "vitesse", votre "productivité", en termes nets, se mesurent à combien de bien ( vous faites du mal à votre entreprise, à vos clients, à la suite logicielle ou à la famille de produits que vous construisez ou entretenez.

Se souvenir de:

  • Incluez le coût total de maintenance, le coût total de possession et le coût total de déploiement et de maintenance des solutions lorsque vous envisagez de modifier votre approche. Aller plus vite et faire plus d'erreurs peuvent ou non améliorer les choses.

  • Si vous travaillez dans une bonne entreprise, vous pouvez probablement en discuter au sein de votre propre équipe et avec votre propre superviseur, sans que cela soit un déménagement de limitation de carrière. Si vous ne le pouvez pas, le moment est venu de le découvrir et de trouver un nouvel emploi.

Warren P
la source
YAGNI m'a sauvé quand je traversais cette phase. Cette réponse nécessite plus de votes positifs. Le problème de "je suis trop lent" ne doit pas être simplement accepté; il est parfois acceptable de sacrifier une architecture parfaite pour la faire sortir rapidement.
Roman Starkov
7

La seule chose que je peux voir, c'est: "Vous devenez de plus en plus précieux".

Au fur et à mesure que vous accumulez de l'expérience, vous apprendrez des choses à éviter et c'est ce qui vous rend meilleur que les autres.

Une chose que vous auriez remarquée que votre code serait plus sûr et plus facile à maintenir maintenant.

  • La seule chose que vous devez faire est d'expliquer à votre client pourquoi cela a pris du temps et en quoi cela lui serait utile.
  • Vous devez leur montrer la profondeur de vos connaissances.
  • Vous devez leur dire pourquoi vous l'avez fait, ce que vous avez fait et en quoi cela importerait pour eux et pour leur entreprise.

Ma suggestion serait de se concentrer sur cette partie.

Falaque
la source
7

en cas de doute, citez mal Knuth ...

"L'optimisation prématurée est la racine de tout Mal."

Voici ce que je suggérerais, car il semble que vous ayez un problème que j'ai de temps en temps ...

Qu'est-ce qui fonctionne vraiment pour moi ...

  1. Ecrivez les tests unitaires, comme si tout le code était fait.
  2. documenter l'interface.
  3. implémenter l'interface.

ce que tu as vraiment fait:

  1. travailler à travers les exigences des couches de modèle
  2. vraiment mis en place la division du travail, quels objets sont responsables de ce
  3. Travaillez dans un environnement où vous pouvez parcourir le code de travail, ce qui rend les choses beaucoup plus rapides et plus précises ...

comptez également sur les assertions du développement initial ... puis déterminez les solutions à mettre en œuvre et vous n'écrirez pas de code inaccessible ou difficile à tester.

Grady Player
la source
Cela ressemble à Oncle Bob, le gars solide.
Warren P
6

Je pense que vous devriez vous en tenir à vos normes de codage, mais assurez-vous d'être franc avec vos clients. De nombreux clients ne savent pas ce qu'il faut / quels coûts pour construire un bon logiciel. Cela fait partie du travail du développeur professionnel de les éduquer.

Que vous soyez agile ou en cascade, vous obtenez une sorte d'accord du client sur ce qu'il attend de l'application. Trop de développeurs (OK peut-être plus de vendeurs) sont coupables de sacs de sable . "Ils n'ont pas dit vouloir un site Web hautement sécurisé." Dans la plupart des cas, c'est parce qu'on ne leur a pas demandé. "Cela vous dérange-t-il si votre site de commerce électronique se fait pirater?" Bien sûr, ils se soucient et pourquoi voudriez-vous le construire pour permettre à quiconque de pénétrer la sécurité? Vous devez les éduquer.

Assurez-vous simplement que vous ne faites que ce que le client vous paie. Votre expérience fait partie de votre service. Les clients s'attendent à ce que vous connaissiez les pièges sans avoir à demander. C'est à eux d'inclure l'exigence. Vous voudrez peut-être transmettre des clients qui veulent quelque chose de pas cher.

JeffO
la source
En fait, vous venez de prendre l’exemple du pire: un logiciel Web, où les noobs php sont officiellement en concurrence. Le prix est un facteur extrêmement important, et lorsque je fournis un logiciel de haute qualité, mes clients paient pour le logiciel et je paie pour la haute qualité.
Morg.
6

Réfléchissez aux conséquences pratiques d'un bogue par rapport à tous les autres problèmes à résoudre.

Considérez les conséquences suivantes de la création d’un morceau de code mal écrit:

  1. Toute la base de données est vidée tous les deux mois. 48 heures d'indisponibilité pendant la restauration des sauvegardes.
  2. Les enregistrements clients sont réticulés. Des commandes d'une valeur de 200 $ sont expédiées par mois aux mauvais clients.
  3. Une commande est bloquée dans un mauvais statut une fois par semaine. Commandez des navires mais l'entrepôt doit appeler le service d'assistance à chaque fois que cela se produit.
  4. Une fois toutes les deux semaines environ, l'application se bloque et l'utilisateur doit saisir à nouveau 2 minutes de données.
  5. Une fois par mois, l'application se bloque au démarrage. L'utilisateur doit tuer le processus et recommencer.

Le premier est évidemment inacceptable. N ° 2 - N ° 5 peut être ou ne pas être, en fonction de la nature de l'entreprise. N ° 2 - N ° 5 doivent être évalués dans le contexte d'autres problèmes auxquels l'entreprise est confrontée.

Idéalement, les numéros 2 - 5 ne se produiraient jamais. Dans la vraie vie, avec des priorités conflictuelles, les personnes qui signent votre chèque de règlement peuvent vouloir que vous travailliez sur autre chose que d'écrire un code parfait qui n'a jamais, jamais, rencontré de problème. Ils ne seront pas impressionnés si le n ° 5 est corrigé au détriment de la résolution d'un problème plus sérieux dans un autre programme.

poussée
la source
5

La solution consiste à créer une collection de bibliothèques avec des fonctions couramment utilisées que vous pouvez réutiliser dans des projets. Par exemple, j'ai une bibliothèque .NET StringFunctions.dll qui fait des choses comme l'encodage, le cryptage, le décryptage, l'évaluation des expressions régulières, etc. Ainsi, je n'ai pas à réécrire continuellement des choses qui ne changent pas.

Avoir un wrapper pour les tâches de création de fichier est également très utile. Votre bibliothèque pourrait exposer une méthode appelée GetFile () qui effectue toutes les vérifications à votre place et renvoie null ou un fichier (ou tout ce que vous jugez utile).

Capitaine Kenpachi
la source
4

Je pense que vous devez apprendre à décider combien il faut faire pour quel projet. Certains projets peuvent être triviaux et vous n'avez vraiment pas besoin de passer tout ce temps à le perfectionner. Tout n’aura pas besoin d’un cryptage solide, ni d’un million d’utilisateurs.

Écrire un programme capable de supporter plus d’un million d’utilisateurs prendra du temps et de l’expérience, mais si vous savez que votre application ne sera pas utilisée par plus de 1000 utilisateurs maximum, il ne sert à rien de tout dépenser. cette fois perfectionnant.

Je pense que ceci est une étape importante de votre carrière en programmation et vous devez maintenant passer au niveau suivant, qui concerne la maturité et non la programmation. Vous devez être capable de décider correctement du temps et du code nécessaires pour un projet donné.

Et comme tout le reste, vous pouvez y parvenir aussi avec la pratique. Essayez donc de décider cela avant de commencer un projet, parfois même pendant que vous y travaillez déjà, avec l'expérience, vous l'aurez également dépassé. Il peut y avoir quelques coups et des ratés au début, mais avec le temps, vous le perfectionnerez (prise de décision, pas de code).

Sachin Palewar
la source
3

@Zilk, je ne suis pas un grand programmeur et je le programme depuis 1998. Même moi, je suis confronté à ce problème maintenant. Mais ce que j’ai compris, c’est finalement la qualité qui compte. Si je meurs aujourd'hui, quelqu'un devrait pouvoir reprendre ce que je suis en train de faire là où il me reste. Telles devraient être les normes de programmation (universelles).

Je suis moi-même passé de développeur à architecte maintenant. Passer à la gestion change la ligne. Si vous voulez continuer avec votre passion, vous pouvez devenir architecte.

Initialement en tant qu'architecte technique -> Architecte de solution -> Architecte d'entreprise -> Architecte en chef, etc.

En tant qu'architecte, vous guiderez les gens vers le succès. Des gens comme vous programment depuis des décennies ces années d'expérience que vous pouvez utiliser pour guider les autres.

Comme un oiseau plus haut, il vole plus de terre qu'il peut voir, votre expérience aussi.

Laissez-moi également vous dire que programmer une bonne implémentation est important que de programmer une mauvaise implémentation plus rapidement. Récemment, un de mes juniors a programmé quelque chose de mal et cela a coûté beaucoup d'argent à une banque. Bien sûr, nous avions livré à l'heure plus tôt, mais cela ne servait à rien! Ai-je reçu le rôle de guide même si le même junior aurait codé ce problème ne serait pas arrivé. Je donne cet exemple pour souligner qu’il est également important de bien guider. Certains appellent ce travail comme consultant.

Satish
la source
3

Une autre option est: arrêtez d’écrire du code, vendez plutôt votre expertise en repérant les problèmes à l’avance.

En d'autres termes, devenez consultant .

De nombreuses organisations sont heureuses de payer des dollars chers (si ce n’est pas le prix fort) à une personne qui décèle les problèmes avant de passer des mois à créer le code qui crée ces problèmes. Il est bien connu que la résolution d'un bogue dans la conception est beaucoup moins onéreuse et moins coûteuse que de le réparer après qu'il a été codé, testé et déployé.

Vous n'écrirez pas autant de code et vous risquez de le rater, mais il semble que les lignes de code ne sont pas votre force principale, mais vous devez savoir quelles lignes de code doivent être écrites - et lesquelles ne le devraient pas.

Concentrez-vous sur vos forces.
(bon, si c'est ce que vous aimez ...)

Avide
la source
2

Ma meilleure recommandation pour vous est la suivante: des blocs de construction.

Créez un bloc de création de fichiers auquel vous pouvez toujours faire confiance, créez-en un pour votre API, arrêtez de perdre votre temps à écrire sans cesse la même chose. Pensez à chaque problème une fois et résolvez-le une fois pour toutes.

Personne ne le rattrapera, et certainement pas le novice qui passe 80% de son temps à déboguer du code qui échoue pour les cas critiques qu’il ne comprend pas.

Surtout, ne corrigez pas les problèmes qui ne peuvent pas se produire, tels que les autorisations erronées.

Si les autorisations sont erronées, quelque chose ne va déjà pas et vous devriez y remédier plutôt que de rendre votre programme infaillible.

À un moment donné, vous devez simplement ne pas vous tirer une balle dans le pied au lieu de toujours vérifier si vous l'avez ou non.

Au lieu de passer du temps à la documentation, prenez le temps de rendre votre code auto-documenté et aussi court que possible. Remplacez toutes ces fonctions dupliquées. Réduisez votre bibliothèque, renommez les choses avec précision.

Morg.
la source
1

Ne soyez pas trop dur avec vous-même. Vous travaillez dans un métier de plus en plus complexe, qui nécessite plus d'intelligence humaine, de connaissances et d'expérience que jamais auparavant.

La puissance de traitement de l’ordinateur ralentit - peut-être bientôt s’arrête -, ce qui entraîne la nécessité d’introduire des puces multicœurs, des données numériques alimentées par le gpu, du parallélisme, etc. Un nombre limité de transistors peut être placé sur une puce.

Par conséquent, les grandes avancées actuelles et futures proviendront des programmeurs: algorithmes avancés et code plus efficace.

Si vous regardez GTA 4 et GTA 5, les différences sont ahurissantes. Mais ils fonctionnent tous les deux sur le même matériel. Ceci est le résultat d'une pratique de programmation très intelligente et avancée qui n'était tout simplement pas nécessaire ou disponible il y a 10 ans.

Cela pourrait également signifier que les programmeurs expérimentés auront plus de valeur dans le futur - un peu comme d’autres professions, telles que l’ingénierie, où les pics de revenus sont généralement atteints en fin de carrière.

AsymLabs
la source
1

Tout comme vous, j’ai commencé à programmer à l’âge de 14 ans, même lorsque j’ai eu mon premier ordinateur (bien que j’ai étudié pendant quelques mois à ce moment-là). Cependant, je suis "seulement" 33 maintenant. :-)

Ma suggestion est que, lors du développement de quelque chose, vous preniez chacune de ces inquiétudes (autorisations de fichier, nombre de fichiers dans un répertoire, etc.) et utilisiez ensuite toute votre vaste expérience pour répondre à quelques questions à ce sujet, dans cet esprit:

  • Combien de temps faudrait-il pour traiter correctement ce problème dans votre code?
  • Si vous ne le manipulez pas correctement, quelle est la probabilité que cette chose vous morde plus tard?
  • Si cela vous pique, quelles sont les conséquences?

Armé de ces réponses, un homme aussi expérimenté n'aura pas de problèmes pour prendre une sage décision. ;-)

Les «anciens combattants» comme vous sont responsables de formuler ce type d’exigence, ce qui implique à la fois de déterminer ce qui ne va pas et de décider des problèmes potentiels auxquels vous devriez prêter attention.

igorrs
la source
1
La réaction du PO est que tous les problèmes potentiels observés doivent être prévenus. C’était peut-être vrai quand il a commencé comme programmeur junior (parce que les problèmes potentiels qu’il avait alors identifiés signifiaient généralement une amélioration considérable de la qualité), il est fort probable que ce n’est plus le cas: Comme l'explique @igorrs: le problème potentiel que vous voyez doit être évité - décidez consciemment si vous en avez besoin. C'est l' avantage que vous avez sur les programmeurs débutants: ils ne peuvent empêcher que ce qu'ils peuvent voir, alors que vous pouvez empêcher ce qu'il faut réellement empêcher.
Astrotrain
0

Connaître tous les critères possibles lors du développement d'une application est la chose la plus importante dans le développement d'un produit de qualité. Vous faites bien dans ce domaine. Une chose que vous pouvez faire est, vous pouvez classer l'exigence en niveau de qualité, puis mapper le niveau avec l'échéance donnée. De cette façon, vous pourrez facilement respecter la date limite du projet.

Jagz W
la source
0

Edsger Dijsktra a déclaré: «Si le débogage est le processus de suppression des bogues logiciels, alors la programmation doit être le processus de leur création. C'est juste une question d'apprendre à passer du temps à bien coder. Je suis encore un programmeur relativement jeune (20 ans) et j'aspire à pouvoir coder quelque chose de complètement correct une fois. Une heure de planification et 10 minutes de codage sont bien meilleurs que 10 minutes de planification, une heure de codage et trois de débogage.

ford prefet
la source