Architecte logiciel pour un audit de notre application

Message

Nous recherchons un architecte logiciel pour un audit de notre application en vue d'une refonte complète de la structure. L'architecte devra réaliser un audit puis faire un rapport de recommandation en mode cahier des charges en indiquant chaque étape d'actions à réaliser ainsi que le temps jour pour chaque action.
Actuellement le code de notre application mélange le front et le back, et plusieurs mauvaises pratiques. Il s'agit pour nous de refondre le projet pour qu'il soit conforme aux bonnes pratiques. Notre objetif est la suppression des codes morts et dupliqué, la restructuration du projet sur Vuejs avec une séparation entre le front et le back + webpack.
Vous trouverez ci-après une liste d'une partie des problèmes identifiés et des recommandations pour les régler.
L'architecte logiciel devra confirmer ou non ces problèmes, auditer l'intégralité de l'application, rédiger un cahier des charges détaillé avec une chronologie (indiquant l'ordre de traitement des problématiques) et une évaluation en jour homme pour chaque action
1. BackgroundVideo dans chaque Resizable ?
Impact faible: Mount inutile si composant non utilisé (impact sur performance: à mesurer)

2. L'utilisation de “!important” et de "magic numbers"

Impact moyen:
● “!important” override les spécificités de CSS. C’est une mauvaise pratique.
● Les magic numbers dans le style montrent un problème de factorisation du style, rendant difficile toute modification.

3. L'utilisation de `setTimeout` (28 occurences) avec une valeur hardcodée est périlleuse
Impact moyen: Peut engendrer des comportements non voulus, si la connexion d'un utilisateur est mauvaise par exemple.

4. Il n'y a pas de tests front.
Impact fort:
● Onboarding difficile d'un nouveau développeur: les tests sont un bon moyen de comprendre le fonctionnement attendu d'un composant.
● Évolutions difficiles car il n'y a pas de protection contre les régressions.

5. Il faut faire un choix entre l'utilisation de Vanilla JS, jQuery et Vue.js et entre Twig et Vue.js
Il serait judicieux d'exploiter au maximum ce qu'offre un framework moderne comme Vue.js et éviter les instructions globales, comme par exemple “document.querySelectorAll” (50 occurrences)
Idéalement, il faudrait également se passer de Twig: écrire du code Vue.js dans des fichiers Twig empêche tout linter de détecter des erreurs et demande de jongler entre les fichiers pour comprendre le comportement d’un même composant.
Impact fort:
● Effets de bord non maîtrisés, rendant difficiles les évolutions/résolutions de bug. <br />● jQuery et Vue.js sont 2 frameworks, avec leurs spécificités. En choisir un permet de faire progresser les développeurs du projet.

6. Beaucoup de duplication de code
Ex: 34 occurrences de la classe “can-drop” dans les fichiers JS.
Le principe DRY n’est pas respecté.
Impact fort: Évolutions difficiles.

7. Pas d'image claire de la structure des données pour une page.
C’est le point le plus important qu’il faut revoir en priorité.
Impact fort: On ne peut pas facilement savoir ce qui a changé, où et pourquoi. La plupart des
transactions passent par le DOM en modifiant l’objet style directement.
## Recommandations
- [outils] Ajout de ESLint / Prettier
- [outils] Ajout de typage statique pour éviter pleins d'erreurs avec une démarche progressive:
- Setup de TS
- Choix d'un fichier qui pose problème
- Typage progressif des méthodes
- [outils] Automatiser l'analyse de qualité de code (ex: SonarQube ou Codacy)
- [architecture] Unifier le modèle de données (todo: ajouter un schéma):
- 1 json par template
- on crée un objet JS qui contient toutes les infos (sections, blocs, images, texte) avec les positionnements
- stockage de l'objet dans le store
- une app Vue.js qui interprete cet objet
- les différentes opérations (resize, drag, contribution texte/image) updatent l'objet
- stockage du json en DB pour chaque site grâce à l’API Symfony

Voici également une plusieurs autres consignes qui nous ont été transmise :

Assets : tous les fichiers images etc
components: les micro briques réutilisables (et non des mixins comme chez vous) par exemple ca peut etre une base des spawners
db: les fichiers d'appels au backend, segmentés par type (auth, profile, ..)
fonts: mes fonts
js: un dossier avec des fichiers pur js qui me servent un peu partout
locales: mes fichiers de traductions (fr et en au minimum)
router: utilisation obligatoire de vue-router ([URL visible pour les membres Pro])
store: utilisation obligatoire de vuex ([URL visible pour les membres Pro])
styles: tous mes fichiers sass, à importer dans les components
utils: divers fichiers js
views; mes vues vuejs i.e. la page de création de site, la page admin, la page profile, .. dans lesquels viendront les components
app.vue et main.js : les deux fichiers de base d'une application vuejs
components.png
Il n’y a pas assez de variables crées avec la méthode data de vuejs ce qui empêche souvent la réactivité
il y a trop de variables de meme nom dans les mixins, ce qui cause des effets de bords, les mixins écrasant ces valeurs au fur et à mesure
Il faudrait créer de véritables fichier vuejs pour une meilleure compréhension
Les mixins ne sont pas utilisées comme il faut, on gagne on complexité, on perd en stabilité
Avoir des tests front end est indispensable dans un projet avec beaucoup d’intervenants
Il faudrait se passer de twig et utiliser les composants de vuejs à la place
Il faut séparer le front du back avec vuejs d’un coté qui fait des calls au backend symfony de l’autre
Debug : pas d’accès au chrome début vuejs. Le code étant dockerisé on n’a pas la possibilité de mettre des break points et on doit travailler en console.log
Mettre un linter pour un homogénéité et propreté du code
Beaucoup de code jamais utilisé
Ne pas faire des fichiers de 2 000 lignes
Ne pas chercher les div avec des noms de classes car on est sensé pouvoir utiliser les class où on veut. Il vaut mieux utiliser des id et encore mieux des composants vuejs
Le travail du CTO consiste à donner au code une cohérence malgré les différents intervenants
il faut du https meme en dev
environment preprod et de dev en ligne obligatoire ! On ne doit pas s’inquiéter des mises à jours
embetant d’avoir tout dockérisé en local : comment on suit les évolutions backend ou bdd ?
Impossibilité d’utiliser les outils de débug de chrome et de visual studio (a cause du docker)
Pour tout ce qui est manipulation des sections, blocks, box, etc.. Ne pas manipuler le dom mais manipuler un json avec le store de vuex qui réinterpretera automatiquement ce json dans le dom

Début: Le mois prochain
Durée: Entre 1 et 3 mois
Nombre de jours travaillés par semaine: 3 jours
À distance: Oui