Je viens d'un milieu OO solide et j'ai récemment commencé à travailler dans une organisation qui, bien que le code soit écrit en Java, met beaucoup moins l'accent sur une bonne conception OO que ce à quoi je suis habitué. On m'a dit que j'introduisais "trop d'abstraction" et que je devrais plutôt coder comme cela a toujours été fait, qui est un style procédural en Java.
TDD n'est pas non plus très pratiqué ici, mais je veux avoir du code testable. Enterrer la logique métier dans les méthodes privées statiques dans les grandes "classes divines" (qui semble être la norme pour cette équipe) n'est pas très testable.
J'ai du mal à communiquer clairement ma motivation à mes collègues. Quelqu'un a-t-il des conseils sur la façon de convaincre mes collègues que l'utilisation d'OO et de TDD permet de gérer plus facilement le code?
Cette question sur la dette technique est liée à ma question. Cependant, j'essaie d' éviter de contracter la dette en premier lieu, plutôt que de la rembourser après coup, ce que recouvre l'autre question.