Les programmeurs testent s'ils ont surmonté ces obstacles

La tâche la plus difficile d'un programmeur n'a pas grand-chose à voir avec l'écriture de code. Le codage est la pratique de la pensée logique, qui est relativement simple par rapport aux autres tâches du travail quotidien d'un programmeur. Si vous pensez que vous êtes encore un programmeur moyen, assurez-vous d'avoir surmonté les obstacles suivants à l'avancement avant de pouvoir véritablement entrer dans les rangs des experts.

1. Expliquez ce que vous faites

Expliquer le processus de développement logiciel est une chose difficile. Les personnes qui ne sont pas programmeurs en savent peut-être beaucoup sur la programmation, mais elles ne savent évidemment pas comment programmer. Pour eux, notre vie consiste à être assis devant un clavier dans une pièce sombre et à consommer du café.

Vous rencontrerez des personnes parmi vos amis, votre famille et vos collègues qui penseront que le codage n'est pas la bonne carrière.

2. Visualisez la solution logicielle

Sur la base de quelques brèves exigences - généralement avec peu de connaissances, vous devez concevoir des structures de données, une architecture logicielle, des algorithmes de code, des protocoles de communication et tous les autres composants de solutions aux problèmes des entreprises. Ensuite, vous devez les exprimer dans des termes qu’un profane peut comprendre et vous devez les soumettre au client dans un délai spécifié.

Peu de programmeurs peuvent bien faire cela.

3. Estimer la durée

C'est la source de douleur pour les programmeurs. Avant que la tâche de développement ne soit terminée, il vous est absolument impossible de déterminer le temps nécessaire pour terminer la tâche. Peut-être que le programme est très similaire à ce que j'ai écrit auparavant, mais l'environnement a changé, les problèmes ont changé et les contraintes ont changé.

L'expérience fournira un certain degré de jugement, mais la plupart des programmeurs ont l'habitude de sous-estimer la difficulté des problèmes. La raison en est qu’ils ne prennent en compte que l’aspect codage et ignorent les autres éléments de la liste de tâches.

4. Conserver le code des autres

Il peut y avoir 10 000 solutions et 10 000 façons d'écrire un problème. Reprendre du code écrit par d'autres signifie que vous devez passer d'innombrables heures à explorer des milliers de lignes de code pour comprendre les idées de l'auteur original. Et s'il s'agit d'un demi-projet laissé par un programmeur qui ne croit pas aux commentaires et à la documentation, le problème est encore plus grand.

5. La propagation floue des frontières logicielles et des exigences fonctionnelles étranges qui font vomir du sang

Bien que les méthodes de développement agiles offrent un certain espace de préparation pour l'expansion de la portée des logiciels, cela ne signifie pas n'ont aucun effet - surtout lorsque vous rencontrez des exigences fonctionnelles qui découlent d'un caprice. Vous savez que cela est voué à l'échec. Votre équipe sait que cela est voué à l’échec. Mais le client pense que c'est génial, et lorsque l'échec se produit inévitablement, c'est entièrement de votre faute si vous ne comprenez pas ses véritables intentions.

6. Trouvez un équilibre entre le manque d'optimisation et la sur-optimisation

Un logiciel complexe ne sera jamais parfait ; il y aura toujours une meilleure solution. Vous pouvez continuer à optimiser à l’infini, c’est pourquoi les projets logiciels ne sont jamais terminés plus tôt que prévu.

D’un autre côté, la mentalité du « ça suffit, je l’optimiserai plus tard » est également courante. Un code qui fonctionne bien aujourd'hui, mais vous savez qu'il pourrait rencontrer des problèmes ou ne pas fonctionner demain. Bien sûr, vous n'avez pas besoin de le modifier, cela sera laissé au prochain programmeur malchanceux.

7. Testez votre code

Vous avez également écrit des tests unitaires, et le logiciel a été soumis au groupe de test, mais les bugs existent toujours...

Logiciel est complexe et peut contenir des milliers de lignes de code. Il peut y avoir des millions d'interactions et de chemins logiques différents dans le système ; vous ne pouvez pas tous les tester.

De même, les logiciels interagiront avec différents logiciels sur différentes plates-formes dans différentes conditions. Vous ne pouvez pas tous les mesurer.

Écrire de bons tests unitaires est un travail ennuyeux et difficile. Idéalement, les tests devraient être écrits avant le début du développement - mais comment expliquer au client pourquoi quatre semaines se sont écoulées et qu'il n'y a toujours pas de logiciel utilisable

Les tests unitaires ne couvrent pas tous les points problématiques ? Dans un monde idéal, il y aurait une équipe indépendante rédigeant des tests et identifiant activement les problèmes. Malheureusement, pour la plupart des projets, cela est trop coûteux et prend trop de temps, c'est donc à l'équipe de développement qu'il revient d'écrire les tests. L’équipe de développement évite inconsciemment de nombreux cas extrêmes.

Les programmeurs aiment traiter tous les problèmes de manière logique. Mais les utilisateurs sont rarement comme ça. Ils découvriront des problèmes auxquels vous ne vous attendriez jamais.

8. Rédiger la documentation du logiciel

Rédiger la documentation du code est une tâche laborieuse et chronophage. Peu de programmeurs sont bons dans ce domaine, peu de programmeurs aiment ça, et peu de programmeurs prennent le temps de les lire.

9. Gérer les problèmes informatiques

Vous étudiez la technologie tous les jours. Vous êtes peut-être un programmeur HTML ou PHP, mais vous risquez de rencontrer des problèmes tels qu'une corruption du disque dur, des conflits de pilotes ou des pannes logicielles. Ce n'est pas votre responsabilité principale de résoudre ces problèmes, mais à moins que vous ne les répariez, vous ne pourrez pas continuer votre travail de développement.

Malheureusement pour les personnes extérieures au cercle informatique, les programmeurs sont censés être des personnes maîtrisant à la fois les logiciels et le matériel. Lorsqu’ils rencontrent un problème, ils le résolvent eux-mêmes sans perdre de temps et s’adressent directement à vous. Quel que soit le problème : vous êtes un informaticien, vous savez comment importer un budget dans Sage, comment configurer Oracle ou pourquoi ils ne peuvent pas envoyer d'e-mail sur leur BlackBerry.

Bien sûr, ces interruptions ne peuvent pas être la raison pour laquelle vous ne pouvez pas terminer votre travail, et il n'y a pas de récompense, n'est-ce pas ?

10. Gérer les problèmes des gens

Les problèmes ci-dessus peuvent tous être résumés comme des « problèmes humains ». Peu de profanes conseilleraient un pilote sur la façon de piloter un avion ou un ingénieur électricien sur la façon de câbler un avion. Mais de nombreuses personnes suggéreront avec enthousiasme et courage comment développer des logiciels.

Je crois qu’il n’y a pas de bonne solution pour ces personnes. Vous devez accepter le fait que la moitié des habitants de la planète ont une intelligence inférieure à la moyenne !