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

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?

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".

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.»

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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).

@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.

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 ...)

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.

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.

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.

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.

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.