Surmonter la résolution lente des problèmes grâce à une meilleure connaissance de ce qui pourrait mal se passer
Cela me préoccupe depuis un certain temps et j'apprécierais vraiment la contribution d'autres professionnels.
Bref historique: J'ai commencé la programmation lorsque mes parents m'ont acheté mon premier ordinateur en 1988 (à 14 ans, j'ai 39 ans maintenant). J'ai suivi quelques autres cheminements de carrière avant de finalement devenir programmeur professionnel en 1997. Floraison tardive, peut-être, mais c'est comme ça. Je suis toujours satisfait de mon choix, j'adore la programmation et je me considère bon dans ce que je fais.
Dernièrement, j'ai remarqué que plus je gagne en expérience, plus il me faut pour terminer des projets ou certaines tâches dans un projet. Je ne suis pas encore sénile. C'est juste que j'ai vu tant de façons différentes dont les choses peuvent mal tourner. Et les pièges et pièges potentiels que je connais et dont je me souviens sont de plus en plus nombreux.
Exemple trivial: c'était juste "okay, écrivez un fichier ici". Maintenant, je m'inquiète des autorisations, du verrouillage, de la concurrence, des opérations atomiques, des indirection/frameworks, des différents systèmes de fichiers, du nombre de fichiers dans un répertoire, des noms de fichiers temporaires prévisibles, de la qualité 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 faire cela" à "quelle est la meilleure façon/la plus sûre 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 solide comme le roc et aussi impénétrable que je sais comment la fabriquer, mais elle prend plus de temps.
L'exemple de "création de fichier" ci-dessus n'était qu'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'adore les mathématiques, j'aime les sujets complexes, je n'ai aucun problème de concentration. Je pense que j'ai un problème avec l'expérience, et par conséquent avec la peur des erreurs (intrinsèques ou extrinsèques).
Je passe près de deux heures par jour à lire les nouveaux développements, les nouvelles techniques, les langages, les plateformes, les failles de sécurité, etc. L'énigme est que plus je gagne en connaissances, plus je suis lent à réaliser des projets.
Comment gérez-vous cela?
Vous n'êtes pas plus lent à terminer vos projets. Auparavant, vous pensiez que vos projets novices étaient terminés alors qu'ils ne l'étaient vraiment pas. Vous devez vendre cette qualité aux clients.
"Cette entreprise pourrait le faire plus rapidement et à moindre coût, mais est-ce vraiment le cas? Ou allez-vous chasser des insectes pendant des années?"
Au-delà de cela, vous devez connaître et accepter l'ancien idiome: "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 vous suggère pas d'abandonner la programmation et de devenir gestionnaire. Mais il semble que toute l'expérience que vous avez citée jusqu'à présent soit de nature technique. En écrivant simplement un fichier, vous pouvez penser à 10 aspects différents qu'un développeur moins mature ne considérerait jamais. Pas forcément une mauvaise chose, mais ...
Le côté obscur est tout au sujet de la valeur actuelle. Il s'agit de faire un investissement minimal pour un gain maximum (analyse coûts-avantages). En affaires, tout se résume à combien cela me coûtera, 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 collisions de noms - 5 min. Gain net, le reste de l'équipe peut commencer à travailler sur le code qui dépend de la présence de ce fichier. Est-ce une solution parfaite? Absolument pas. Cela vous rapportera-t-il à 99%, 95%, voire 90%? Oui, probablement.
Une autre question à se poser: comment vous sentez-vous face à la dette technique? Certaines personnes pensent qu'il doit être éliminé. Je pense que ces gens ont tort. Tout comme en affaires, la dette technique vous permet d'emprunter de l'argent ou du temps pour 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 vos concurrents.
La clé 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, l'intérêt vous tuera.
Alors mon conseil: commencez à évaluer votre travail selon que vous maximisez votre valeur au lieu de maximiser votre rigueur. Et si vous pratiquez cela, vous développerez la même intuition que vous avez déjà développée dans votre domaine technique.
En remarque, j'ai récemment commencé à faire la technique pomodoro et cela a beaucoup aidé. Au lieu d'aller sur une tangente d'une tangente, concentrez-vous sur de petits intervalles de temps, puis allouez des pomodoros pour de futurs travaux/recherches. C'est étonnant combien de fois j'ai pris une note pour faire des recherches sur un sujet, mais une heure plus tard, le moment venu, je me suis dit "il y a au moins 3 autres choses que je pourrais faire avec mon temps d'aujourd'hui qui sont toutes plus précieuses".
J'ai eu le même problème (probablement) il y a plusieurs années, il a duré quelques années et je l'ai surmonté. Il serait donc peut-être intéressant pour vous de savoir comment j'y suis parvenu, même si je ne suis pas sûr que ma voie s'applique également à vous.
Vous devriez également jeter un œil 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 certain stade entre le stade 3 et le stade 4 sur la technologie que vous utilisez actuellement (la compétence dépend de la technologie, vous pouvez être maître de 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é la programmation à 12 ans dans les années 80. Pendant mes études secondaires, j'ai également travaillé comme programmeur de jeux professionnel à temps partiel. Fondamentalement, 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 de l'informatique.
Par conséquent, lorsque j'ai eu 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 donné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 (disons environ 26 ans), il m'est devenu vraiment difficile d'écrire n'importe quel programme. Il y avait tellement de possibilités ouvertes que je ne pouvais plus choisir entre elles. Pendant quelques années (faites-en 6), j'ai même arrêté de programmer 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 précisément le principe de simplicité: "Écrivez la chose la plus simple qui pourrait éventuellement fonctionner".
Fondamentalement, je me suis forcé à ne pas me soucier de l'efficacité du code (c'était mon principal barrage routier, éviter les conceptions inefficaces), mais à suivre la voie la plus simple. Je me suis également forcé à me soucier moins des erreurs et à retarder la gestion des erreurs à une date ultérieure, après avoir écrit des tests augmentant l'erreur (c'est vraiment TDD).
C'est quelque chose que j'ai appris lorsque j'écrivais. Quand je ne sais pas quoi écrire, ou que je savais 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 mauvais, effacez-le et réécrivez-le, mais il est plus rapide d'écrire deux fois des choses qui écrivent quoi que ce soit de parfait la première fois.
Vraiment, il est très probable qu'un code que vous croyez bon à la première écriture ait besoin d'autant d'améliorations que de très mauvais.
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 j'avais l'intention de faire plus tard lorsque le code serait fonctionnel dans le cas d'utilisation normal.
J'ai également assisté à un XP Dojo un katas de code pratiqué avec d'autres programmeurs pour internaliser les XP pratiques. Cela a aidé. Cela a rendu les méthodes formelles ci-dessus instinctives. Programmation de paires 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 de conception qui peut conduire à. J'ai fait ça, eu des problèmes.
Le point primordial pour moi est de garder le flux. Être rapide réussit vraiment à maintenir 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 approfondie de ce que je fais. Pratiquer 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 pas peur de refactoriser et je passe certainement beaucoup moins de temps à déboguer (presque pas de temps du tout, soit moins de 10% du temps) ).
En résumé: j'ai surmonté mon bloc de code en utilisant des méthodes agiles (XP), en optant pour la simplicité puis en refactorisant et en m'exerçant à rendre cela instinctif. Ça a marché pour moi. Pas sûr qu'il puisse être généralisé à quelqu'un d'autre.
En termes de niveau d'acquisition de compétences, j'ai surtout appris à accepter que chaque fois que je change de technologie (apprendre un nouveau langage, un nouveau cadre, etc.) je passe par une étape où je ralentis. C'est normal et cela finira par surmonter cela. Je peux également compenser cela avec une bonne méthodologie et des compétences en programmation à usage général et ce ne sera pas autant un problème.
Une partie importante de la programmation est gérer et contrôler la complexité et pour moi personnellement, c'est l'un des principaux problèmes. S'il est ignoré, la fréquence des défaillances augmente ou, comme dans votre cas, l'ETA du logiciel fini augmente considérablement.
La complexité des logiciels peut être contrôlée et gérée à partir de nombreux niveaux et de différentes manières, mais une bonne règle empirique pour obtenir une certaine perspective est la suivante: "La priorité absolue de tout projet logiciel est la satisfaction du client qui est fonction de leurs attentes."
En d'autres termes, la complexité du logiciel dépend en grande partie de votre compétence à maîtriser les attentes de votre client.
Quand on adopte ce point de vue, alors deux points importants deviennent évidents:
- les attentes des clients doivent être explicitées (sous quelque forme que ce soit);
- les attentes des clients peuvent toujours être modifiées et cela se fait grâce à l'art de la négociation.
Votre exemple est très bon, "écrivez-le simplement" contre "une 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 fonctionnalités 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-la.
Dans tous les systèmes, il y a des compromis à faire entre la fiabilité, la robustesse, la sécurité, la vitesse, le coût du matériel, le coût de développement, le délai de commercialisation, vous l'appelez. 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 fournir une opinion réfléchie. Le développement de logiciels 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 plantage signifie "recharger ma page Web personnelle", qui s'en soucie vraiment si cela se produit? Mais si un crash signifie "Tchernobyl", alors votre préférence pour le code solide est si quelque chose d'un peu décontracté à mon goût.
Certains clients acceptent volontiers le code de niveau "Proof of Concept" et l'exécutent dans leurs systèmes en direct, et ils ont souvent des administrateurs système qui sont bien habitués à cela. IME, leurs systèmes sont généralement indisponibles pendant environ une heure au milieu de la nuit pendant qu'un tas de redémarrages planifiés se produisent. Mais ils ont pris la décision commerciale que c'est ainsi qu'ils veulent rouler. Idéalement parce que leur champ évolue si rapidement qu'un code de haute qualité ne serait jamais prêt, mais souvent parce qu'ils ne peuvent pas voir la valeur (si un système "fonctionne juste", ils ne le remarquent jamais, donc ce système ne représente pas la valeur de argent). Si cela vous dérange trop, essayez d'éviter ces clients.
Rester à jour est le temps que nous devons tous passer, ou du moins devrions-nous dépenser. Parfois, cela vous permettra de travailler, d'autres fois, cela gardera votre esprit en bonne forme. 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é, comme les applications liées à la finance/au commerce, la radiodiffusion, 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 à ce jeu "Jenga" où vous avez toutes ces pièces qui dépendent de beaucoup d'autres. Retirez la mauvaise pièce et vous avez une erreur, retirez une pièce correcte/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ûr également. La vitesse serait agréable, mais je pense que la vitesse prend beaucoup de retard ces jours-ci lorsque vous apprenez dans les nouvelles que la société "XYZ" a été piratée et que 6 millions de numéros de cartes de crédit de clients ont été volés.
Vos clients ne voudront peut-être pas entendre que leur programme doit être sécurisé, robuste, etc. Mais vous pourriez leur dire que leur voiture n'a pas besoin de ceintures de sécurité et d'airbags ni que leur maison n'a besoin de serrures et de portes ... car qui veut tout entendre cette?
Si vous pensez trop, vous allez sur les choses dans le bon sens, sauf que vous devez choisir une stratégie qui semble "concrète" et aller de pair avec elle.
Il semble que vous soyez conscient de votre tendance à penser à tout ce qui peut mal tourner.
Les développeurs prudents expérimentés 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 avoir été trop étouffé par les mauvaises herbes du mode de défaillance - l'analyse est devenue folle.
Cependant, si vous écrivez effectivement quelque chose dans un domaine où ce niveau de soins n'est pas inférieur à ce qu'exige le professionnalisme, alors vous devez vous rendre compte que votre "vitesse", votre "productivité", en termes nets, est mesurable par la quantité de bien ( ou nuire) que vous faites à votre entreprise, à vos clients et à la suite logicielle ou à la famille de produits que vous créez ou maintenez.
Se souvenir de:
Incluez le coût total de la maintenance, le coût total de possession et le coût total du déploiement et de la maintenance des solutions lorsque vous envisagez des changements dans votre approche. Aller plus vite et faire plus d'erreurs peut ou non améliorer les choses.
Si vous travaillez dans une bonne entreprise, vous pouvez probablement en discuter dans votre propre équipe et avec votre propre superviseur, sans qu'il s'agisse d'un mouvement limitant la carrière. Si vous ne pouvez pas, c'est le bon moment pour le découvrir et trouver un nouvel emploi.
La seule chose que je peux voir est: "Vous devenez de plus en plus précieux".
Au fur et à mesure que vous obtenez plus d'expérience, vous apprenez des choses que vous devriez éviter, et c'est ce qui vous rend meilleur que les autres.
Une chose que vous auriez remarqué que votre code serait plus sûr et plus maintenable maintenant.
- La seule chose que vous devez faire est d'expliquer à votre client pourquoi cela a pris du temps et comment cela pourrait lui être utile.
- Vous devez leur montrer la profondeur de vos connaissances.
- Vous devez leur dire pourquoi vous avez fait, ce que vous avez fait et comment cela importerait pour eux et leur entreprise.
Ma suggestion serait de me concentrer sur cette partie.
Je pense que vous devriez vous en tenir à vos normes de codage, mais assurez-vous que vous êtes franc avec vos clients. De nombreux clients ne savent pas ce qu'il faut/coûte 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 sandbagging . "Ils n'ont pas dit qu'ils voulaient 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 si votre site de commerce électronique est piraté?" Bien sûr, ils s'en soucient et pourquoi voudriez-vous le construire pour laisser quelqu'un pénétrer la sécurité? Vous devez les éduquer.
Assurez-vous simplement que vous ne faites que ce que le client vous paie. Une partie de votre service est votre expérience. Les clients s'attendent à ce que vous connaissiez les pièges sans qu'ils aient à demander. C'est à eux d'inclure l'exigence. Vous voudrez peut-être transmettre des clients qui veulent quelque chose de bon marché.
en cas de doute par défaut à mal citer 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 ...
Ce qui fonctionne vraiment pour moi ...
- Écrivez les tests unitaires, comme si tout le code avait été fait.
- documenter l'interface.
- implémenter l'interface.
ce que vous avez vraiment fait:
- travailler à travers les exigences des couches de modèle
- vraiment mis en place la division du travail, quels objets sont responsables de ce
- se mettre au travail dans un environnement où vous pouvez réellement parcourir le code de travail, ce qui rend les choses beaucoup plus rapides et plus précises ...
comptez également sur les assertions au début du développement ... puis déterminez quels remèdes doivent être implémentés et vous n'écrirez pas de code inaccessible ou difficile à tester.
Réfléchissez aux conséquences pratiques d'un bogue par rapport à tous les autres problèmes qui doivent être résolus.
Considérez les conséquences suivantes de la création d'un morceau de code mal écrit:
- La base de données entière est vidée tous les deux mois. 48 heures d'indisponibilité pendant la restauration des sauvegardes.
- Les dossiers clients sont réticulés. Des commandes d'une valeur de 200 $ sont expédiées aux mauvais clients par mois.
- Une commande est bloquée dans un mauvais état une fois par semaine. Commandez les navires mais l'entrepôt doit appeler le service d'assistance chaque fois que cela se produit.
- Une fois toutes les deux semaines environ, l'application se bloque et l'utilisateur doit saisir à nouveau 2 minutes de données.
- Une fois par mois, l'application se bloque au démarrage. L'utilisateur doit tuer le processus et recommencer.
Le premier est évidemment inacceptable. # 2 - # 5 peut l'être ou non, selon la nature de l'entreprise. # 2 - # 5 doivent être évalués dans le contexte d'autres problèmes auxquels l'entreprise est confrontée.
Idéalement, # 2 - # 5 ne se produirait jamais, jamais. Dans la vraie vie, avec des priorités contradictoires, les personnes qui signent votre chèque de paie pourraient vouloir que vous travailliez sur d'autres choses plutôt que d'écrire du code parfait qui n'a jamais, jamais de problème. Ils ne seront pas impressionnés si # 5 est corrigé au détriment de la correction d'un bug plus grave 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 sur plusieurs projets. Par exemple. J'ai une bibliothèque .NET StringFunctions.dll qui fait des choses comme l'encodage, le chiffrement, le déchiffrement, l'évaluation des expressions régulières, etc. De cette façon, je n'ai pas à réécrire continuellement des choses qui ne changent pas.
Avoir un wrapper pour les tâches de création de fichiers est également très logique. Votre bibliothèque pourrait exposer une méthode appelée GetFile () qui effectue toutes les vérifications pour vous et retourne soit null soit un fichier (ou tout ce que vous jugez utile).
Je pense que vous devez apprendre à décider de ce qui doit être fait pour quel projet. Certains projets peuvent être triviaux et vous n'avez vraiment pas besoin de passer tout ce temps à les perfectionner. Tout ne nécessitera pas un cryptage solide comme le roc ni tout sera mis à l'échelle pour un million d'utilisateurs.
Écrire un programme qui peut bien évoluer pour plus d'un million d'utilisateurs prendra du temps et de l'expérience que vous avez maintenant, mais si vous savez que votre application ne sera pas utilisée par plus de 1000 utilisateurs maximum, il est inutile de tout dépenser cette fois le perfectionnant.
Je pense que c'est une étape importante dans votre carrière en programmation et maintenant vous devez passer au niveau supérieur, qui a à voir avec la maturité et non avec la programmation. Vous devez être en mesure de décider correctement du temps et du code qui devraient être suffisants pour un projet particulier.
Et comme tout le reste, vous pouvez également y parvenir avec de la pratique. Essayez donc de décider de cela avant de commencer un projet, parfois même lorsque vous y travaillez déjà, avec de l'expérience, vous passerez aussi cela. Il peut y avoir quelques coups sûrs et manqués au début, mais avec le temps, vous le perfectionnerez (prise de décision, pas de code).
Une autre option est: arrêtez d'écrire du code, vendez plutôt votre expertise pour repérer les problèmes à l'avance.
En d'autres termes, devenez Consultant.
De nombreuses organisations sont heureuses de payer cher (sinon le gros dollar) à quelqu'un pour repérer les problèmes avant de passer des mois à créer le code à l'origine des problèmes . Il est bien connu que la correction d'un bogue dans la conception est beaucoup moins chère/plus facile que de le réparer une fois qu'il a été codé, testé et déployé.
Vous n'écrirez pas autant de code, et vous risquez de le manquer, mais il semble que les lignes de code ne soient pas votre force principale, mais de savoir qui les lignes de code doivent être écrites - et ce ne doit pas l'être.
Concentrez-vous sur vos points forts.
(eh bien, si c'est ce que vous aimez ...)
@Zilk, je ne suis pas un grand programmeur et je programme depuis 1998. Même moi, je suis confronté à ce problème maintenant. Mais ce que j'ai réalisé, c'est finalement la qualité qui compte. Si je meurs aujourd'hui, quelqu'un devrait pouvoir ramasser ce que je fais maintenant d'où je suis parti. Telles devraient être les normes de programmation (universelles).
Je suis maintenant passé de développeur à architecte. Passer à la gestion change la ligne. Si vous voulez continuer votre passion, vous pouvez passer à 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 qui 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 terres qu'il peut voir, tout comme votre expérience.
Permettez-moi également de vous dire que la programmation d'une implémentation correcte est importante que la programmation d'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é à temps plus tôt, mais cela ne servait à rien! M'a-t-on donné le rôle de guider même si le même junior aurait codé ce problème ne se serait pas produit. Je donne cet exemple pour souligner qu'il est également important de bien guider. Certains appellent ce travail comme conseil.
Ma meilleure recommandation pour vous est: les 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 la même chose encore et encore. Pensez à chaque problème une fois et résolvez-le une fois pour toutes.
Personne ne le rattrapera, certainement pas le novice qui passe 80% de son temps à déboguer du code qui échoue pour les cas d'angle qu'ils ne comprennent pas.
Surtout, ne résolvez pas les problèmes qui ne peuvent pas se produire, tels que les mauvaises autorisations.
Si les autorisations sont incorrectes, quelque chose ne fonctionne pas déjà et vous devriez corriger cela plutôt que de rendre votre programme à l'épreuve des balles.
À un moment donné, vous ne devez tout simplement pas vous tirer une balle dans le pied au lieu de toujours vérifier si vous l'avez fait ou non.
Au lieu de passer du temps sur la documentation, passez du temps à rendre votre code auto-documenté et aussi court que possible. Remplacez toutes ces fonctions en double. Rétrécissez votre bibliothèque, renommez les choses avec précision.
Tout comme vous, j'ai commencé la programmation à l'âge de 14 ans, également lorsque j'ai eu mon premier ordinateur (même si j'étudiais depuis quelques mois à ce moment-là). Cependant, je n'ai "que" 33 ans maintenant. :-)
Ma suggestion est que, lors du développement de quelque chose, vous prenez chacun de ces soucis (autorisations de fichiers, nombre de fichiers dans un répertoire, etc.) puis utilisez toute votre vaste expérience pour répondre à quelques questions à ce sujet, dans cet esprit:
- Combien de temps faudrait-il pour gérer correctement ce problème dans votre code?
- Si vous ne le manipulez pas correctement, est-il probable que cette chose vous mordra plus tard?
- Si cela vous mord, quelles en sont les conséquences?
Armé de ces réponses, un gars aussi expérimenté n'aura pas de problème pour prendre une sage décision. ;-)
Il est de la responsabilité des "vétérans" comme vous de proposer ce type d'exigence, et cela implique à la fois d'identifier ce qui peut mal tourner et de décider quels problèmes potentiels vous devez prêter attention.
Ne soyez pas trop dur avec vous-même. Vous travaillez dans un métier d'une complexité croissante, qui nécessite plus d'intelligence humaine, de connaissances et d'expérience que jamais.
La puissance de traitement informatique ralentit - peut-être bientôt au point mort - ce qui conduit à la nécessité d'introduire des puces multicœurs, du numérique alimenté par un processeur graphique, du parallélisme, etc. Il n'y a que peu de transistors pouvant être placés sur une puce.
Par conséquent, les grandes avancées actuelles et futures proviendront des programmeurs - des algorithmes avancés et un code plus efficace.
Si vous regardez GTA 4 et GTA 5, les différences sont étonnantes. Mais ils fonctionnent tous les deux sur le même matériel. C'est le résultat d'une pratique de programmation très intelligente et avancée qui n'était tout simplement pas requise ou disponible il y a 10 ans.
Cela pourrait également signifier que les programmeurs expérimentés pourraient devenir plus précieux à l'avenir - un peu comme d'autres professions telles que l'ingénierie où les gains de pointe se produisent généralement en fin de carrière.
Selon les mots d'Edsger Dijsktra: "Si le débogage est le processus de suppression des bogues logiciels, la programmation doit être le processus de leur mise en place." C'est juste une question d'apprendre à passer du temps à le coder correctement. Je suis encore un programmeur relativement jeune (lire 20ish) et j'aspire à pouvoir coder quelque chose de bien une fois. Une heure de planification et 10 minutes de codage sont bien meilleures que 10 minutes de planification, une heure de codage et trois de débogage.
Connaître tous les critères possibles lors du développement d'une application est la chose la plus importante pour développer un produit de qualité. Vous vous en sortez bien. Une chose que vous pouvez faire est de catégoriser l'exigence en niveau de qualité, puis de cartographier le niveau avec l'échéance donnée. De cette façon, vous pouvez facilement respecter l'échéance du projet.