Salut la commu,

Je sors d'un BTS SIO et j'aimerais dans l'absolu décrocher un poste en tant que dev mobile Android.
Je me suis donc récemment mis à Kotlin, n'ayant qu'un peu touché Java durant ma formation, et afin d'étoffer mon portfolio, ai développé une simple TodoList utilisant les APIs incontournables (coroutines, viewModel, LiveData, Room, etc...).
L'appli permet de crééer, modifier, consulter, supprimer des "Todos" ainsi que de leur attribuer une catégorie, un ordre de priorité. Il est aussi possible de programmer un rappel s'effectuant via une notification.

Du coup si quelques bonnes âmes (si dev Android ça serait magnifique) avaient 5mn à tuer, j'aimerais beaucoup avoir un feedback sur l'appli (architecture, code, présentation), toutes les critiques sont bonnes à prendre si elles sont constructives.

Le projet est accessible ici https://github.com/Florian-Martin/todos-list

Merci d'avance !

J'ai jamais vraiment fait de Kotlin mais je fais du Java professionnellement.

• Du snake_case dans le package name, on voit direct que tu viens du Python
• Structure des dossiers pourrie. T'as un dossier debug, et un dossier src/debug. T'as deux dossiers avec des tests, mais l'un est vide, etc.
• Un seul viewmodel avec en gros toute la logique de ton application. Autant tout mettre dans le main à ce niveau là.
• Les models qui n'ont pas le moindre sens, tu as Todo, Category et TodoCategory à la place d'avoir une variable Category dans ton Todo et une List<Todo> dans ta Category. C'est supporté par Room mais c'est pas l'approche recommandée (évidemment).
• Des valeurs random hardcodées: Color.parseColor("#D32F2F")
• Aucune gestion des exceptions à part e.printStackTrace()

Je vais même pas parler du fait que l'appli todo-list est clairement le projet le plus surfait et le plus pourri du monde.

Merci pour le coup de hache !

Structure des dossiers pourrie. T'as un dossier debug, et un dossier src/debug. T'as deux dossiers avec des tests, mais l'un est vide, etc.

J'avoue que je sais pas d'où sortent ces dossiers debug de merde, ça a dû être créé lorsque j'ai généré l'apk, mais jamais eu le cas auparavant, du coup j'ai tout viré. My bad de pas y avoir vu. Pareil pour l'un des dossier de tests vide. Fixed.

Un seul viewmodel avec en gros toute la logique de ton application. Autant tout mettre dans le main à ce niveau là.

En fait je pensais qu'un viewModel partagé par les 4 fragments de l'activity serait plus pertinent en me basant sur le codelab que j'ai suivi ici https://developer.android.com/codelabs/basic-android-kotlin-training-shared-viewmodel#3, plutôt que d'utiliser un viewModel par fragment. Un par fragment aurait été plus approprié si je comprends bien. Le MVVM est encore tout récent pour moi.

Les models qui n'ont pas le moindre sens, tu as Todo, Category et TodoCategory à la place d'avoir une variable Category dans ton Todo et une List<Todo> dans ta Category. C'est supporté par Room mais c'est pas l'approche recommandée (évidemment).

Effectivement je pensais faire comme tu le suggères à la base puis j'ai opté pour cette solution après avoir consulté la doc afin de gérer clés primaires / étrangères avec Room https://developer.android.com/training/data-storage/room/relationships#one-to-one

Des valeurs random hardcodées: Color.parseColor("#D32F2F")

Je vais check ça.

Aucune gestion des exceptions à part e.printStackTrace()

Effectivement, faut que je m'occupe sérieusement de ça.

Je vais même pas parler du fait que l'appli todo-list est clairement le projet le plus surfait et le plus pourri du monde.

On est bien d'accord, c'était juste l'occasion de faire un premier projet pour mettre en pratique ce que j'avais vu dans les codelabs fournis par Google. Chaque chose en son temps.

En tout cas merci pour le feedback, ça a le mérite d'être objectif.

J'ai sûrement manqué des trucs parce que j'ai pas fais d'Android depuis 7 ou 8 ans et jamais fais de Kotlin, mais en tout cas ce genre de trucs est la base.

Juste l'absence de gestion des exceptions serait suffisant pour moi pour ne pas t'embaucher.

Je comprend que t'as fais ce projet pour te mettre dans le bain, mais vu que tu comptes l'utiliser pour trouver un travail, t'as pas vraiment le droit à l'erreur.

Pas grand chose à ajouter, si tu veux que ce soit professionnel, fais les choses bien. Les tests unitaires, la gestion d'exceptions, l'organisation du projet, c'est plein d'aspects auxquels les employeurs accordent de plus en plus d'importance. Pourquoi ? Parce qu'à force de payer le prix fort pour effacer ce genre de dettes techniques, les entreprises commencent à comprendre qu'il vaut mieux faire correctement dès le départ, ça coûte beaucoup moins cher. Là ton projet, c'est un truc tout neuf, très petit, mais on y trouve déjà énormément de mauvaises pratiques et de "je m'en foutisme". Si tu veux que ce soit ton portfolio, prends-en soin. Travaille avec des outils d'audit de code (SonarLint p.ex.). Comme l'a dit Grand__Smurf, déjà que le projet est bateau, au moins sois irréprochable sur la qualité. Si ton projet montrait un peu plus d'ambition en termes de recherche (le R de R&D donc ), j'aurai été un poil plus indulgent sur la forme (après on ne pardonne pas tout, mais la créativité ça ne s'apprend pas, alors que les best practices oui).

J'ajouterai quand même une remarque concernant ta gestion de commits GIT. T'as seulement deux branches, du coup évite de te brouter sur la façon de faire. Ta branche DEV est 4 commits en retard par rapport à ta master. Ca ne devrait pas arriver (ou mise à part cas spéciaux avec hotfix prod non rapatriés sur DEV, par contre pas si tu bosses en gitflow). Ca montre des lacunes sur l'utilisation correcte d'un repository GIT. Si tu montres via ton repo une compréhension dans la gestion d'une software factory (avec gestion des versions et publications, feature branch, tag des branches, release branch, etc etc. ce serait un gros plus. Mais avec un petit projet comme ça, t'arrives vite au bout.

Bref ca se corrige vite ces mauvaises habitudes mais si tu dis sur ton CV que tu comprends ces outils et langages, l'employeur s'attendra à ce que tu les comprennes réellement. Mais y en aura tout un tas qui en aura rien à secouer aussi