Les contractants, comment réussissent-ils à écrit des programmes biodégradables ?

En apparence leur code est propre, bien structuré et d'apparence professionnelle. Mais au bout d'un certain temps, leurs systèmes se mettent à mal fonctionner ... Vous rechercher une date incluse dans le code source de leur programme, ou simplement une minuterie pour comprendre comment est-ce possible qu'un programme fonctionne de façon impeccable, puis fonctionne mal ou plus du tout au bout d'un certain temps et surtout le plus inexplicable, vous tester leur système sur un serveur de test et tout fonctionne sans problème !

La première astuce, c'est de créer plus de structure que nécessaire, c'est-à-dire qu'il faut souvent consulter plusieurs fichiers différents pour comprendre un seul algorithme ! Il faut que le code soit clair sans être claire !

La deuxième astuce, faire en sorte qu'il faut se baser sur le temps pour provoquer des erreurs inexplicables. Ainsi, par exemple, vous créer un fichier d'image avec une date, l'heure et les secondes. Vous vous arrangez pour que des traitements soit longs immédiatement après la création du fichier, mais pas trop au début, comme consulter une liste de données de base de données allant augmenter au fil du temps. Plus la liste s'agrandira, plus les chances que la seconde soit dépassée surviendront ! De plus, vous vous arrangez pour qu'il ne soit pas possible de récupérer directement le nom de fichiers dans l'autre objet allant l'utiliser ! Si un jour, on se rencontre de la supercherie, ce genre de code malicieux est toujours un accident, ou l'oeuvre d'un sous-traitant inexpérimenté dont on trouve plus la trace !

La troisième astuce, c'est de mettre un nombre abusif de systèmes de cache. Un système de cache accéléra un système, mais plein de systèmes de cache ensemble avec plusieurs noeuds de serveurs, peut facilement créer des bogues inexplicables pour celui n'étant pas au courant de ce genre de détail. Grâce au système de caches déployer sur de multiples serveurs, une bogue pourrait se manifester uniquement en production, mais jamais sur un poste en local, lorsque quelqu'un tentera de le déboguer. Ne trouvant pas d'explication, le contractant sera nécessairement appelé.

Quatrième astuce. C'est une astuce un peu plus subtile, laquelle consiste a utiliser un champ avec une limite un peu basse, mais pas trop. Par exemple, si vous avez des enregistrements allant éventuellement dépasser la limite de 65535, vous mettez un type «short» afin que la valeur dépasse la limite. Le système fonctionnera pendant un certain nombre de semaines ou des mois sans problèmes et tout à coup : Il ne fonctionne plus, sans prévenir ! De plus, ce genre de comportement est souvent très difficile à déterminer, puisque si le système fonctionne en mode 16 bits, 32 bits ou 64 bits, il n'aura pas la même réaction.

Conclusion

En conclusion, une personne que vous payez pour une courte période, se trouvera toujours à coûter plus cher, puisqu'il cherche continuellement a se faire rappeler. Tandis qu'un permanent, lui cherchera a régler les problèmes pour qu'ils ne reviennent plus, car il a intérêt à montrer qu'il amène la stabilité. Expliquer cela maintenant à du monde prenant les décisions ...

Voir également

Comment les «DevOps» sont en train de faire disparaitre les développeurs ?
Articles - L'entreprise amateur !
Articles - Les bonnes pratiques