Je commence à réaliser que le développement de logiciels est (entre autres) un processus consistant à se poser constamment des questions. Questions concernant la qualité du code, la séparation des préoccupations, la minimisation des dépendances, ...
Mais la question principale est: jusqu'où pouvez-vous aller sans vous retrouver dans un hôpital psychiatrique?
Je postule pour un nouvel emploi. Hier, j'étais avec un éventuel futur employeur qui voulait tester mes capacités de programmation. L'un des exercices était: expliquer ce que fait ce code. J'ai parcouru le code de l'application (winforms sur vb.net) qu'ils développent (c'est une application administrative pour un hôpital). Cela m'a donné l'occasion de voir comment ils abordent les choses et c'était plutôt décevant.
Quelques exemples:
- J'ai vu quelque part: Appeler [insérer le nom du sous-programme ici] -> J'ai été frappé: n'est-ce pas quelque chose de VB6?
- Ils ont une couche de données distincte, utilisant ado.net, mais une méthode que j'ai dû examiner renvoie un ensemble de données à la couche appelante. Donc, datalayer séparé ou non, l'application est liée à ado.net (qui pourrait également ne jamais être un problème si elle ne passe jamais à une autre approche d'accès aux données).
- Cet ensemble de données est lu tel quel, il s'agit donc toujours d'une approche centrée sur les données (bien sûr, on peut discuter de la quantité de logique / comportement que vous pouvez mettre dans des classes comme "Patient" ou "LabAnalysisRequest".
- Je pense également avoir vu la construction d'une requête SQL par concaténation de chaînes.
- Ils utilisent des procédures stockées (ce qui, pour moi, signifie: dispersion de la logique)
- aucune mention des vues / contrôleurs: tout est axé sur la forme
- La chose la plus moche que j'ai vue était:
Si TestEnvironment.IsTesting alors someVar = [une valeur codée en dur] autre someVar = [une valeur récupérée dynamiquement] fin si [reste de la fonction ici]
Tout est tellement différent de ce que j'ai appris à l'école: couche de domaine (agnostique de persistance), couche de persistance, couche de présentation, tests unitaires, ...
Je reformule donc ma question: à quel point doit-on être fondamental ou dogmatique? Dans quelle mesure un programmeur doit-il s'en tenir à ses principes ou simplement écrire du code qui fait le travail?