La proposition de nouvelle architecture est très intéressante mais elle saute l'étape du cahier des charges et décrit déjà une partie de l'implémentation.
Les buts mériteraient d'être regroupés dans un document séparé détaillant le but du projet, ses valeurs, les utilisateurs ciblés, les exigences minimum (matériel et OS, clients et serveurs, en test et production) et la stratégie de développement (contributeurs ciblés - individus ou entreprise => choix de la licence avec ou sans clause sur les brevets, CLA ou non - cf. problème qu'a rencontré VLC pour le relicensing -, critères pour le choix du langage de programmation, etc.). En gros, les choix techniques faits dans la proposition devraient répondre à une exigence dans le cahier des charges.
Le document décrivant l'architecture peut ensuite être complété avec les raisons pour lesquels le choix a été fait. Par exemple, pour le choix du langage de programmation, on voit dans le lien que Python et PHP sont plus populaires que Go. Le choix ne semble pas venir des compétences de l'équipe puisque sur les trois développeurs Go, un connais bien, un connais un peu et un est à recruter. Il serait intéressant de détailler. Est-ce parce que la réputation de Go monte et que c'est une solution d'avenir ? Est-ce pour cibler les développeurs Go puisqu'il n'y a pas de Cloud libre auxquels ils pourraient contribuer, contrairement aux développeurs PHP pour lesquels il existe plusieurs Clouds libres, mais pas en Python à ma connaissance.
Au premier abord, ça semble fastidieux d'écrire ce genre de documents (le pourquoi) mais ça permet de mettre en évidence beaucoup plus vite les lacunes de certains choix (mince, on a prévu d'avoir une interface CardDAV, il n'y a pas de bibliothèque Go qui fait ça, on va devoir l'écrire et c'est assez compliqué comme protocole... note : je n'ai aucune idée de si ça existe ou pas en Go, c'est juste pour l'exemple).
# Cahier des charges
Posté par Chuck #1 . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 4. Dernière modification le 01 septembre 2016 à 13:56.
La proposition de nouvelle architecture est très intéressante mais elle saute l'étape du cahier des charges et décrit déjà une partie de l'implémentation.
Les buts mériteraient d'être regroupés dans un document séparé détaillant le but du projet, ses valeurs, les utilisateurs ciblés, les exigences minimum (matériel et OS, clients et serveurs, en test et production) et la stratégie de développement (contributeurs ciblés - individus ou entreprise => choix de la licence avec ou sans clause sur les brevets, CLA ou non - cf. problème qu'a rencontré VLC pour le relicensing -, critères pour le choix du langage de programmation, etc.). En gros, les choix techniques faits dans la proposition devraient répondre à une exigence dans le cahier des charges.
Le document décrivant l'architecture peut ensuite être complété avec les raisons pour lesquels le choix a été fait. Par exemple, pour le choix du langage de programmation, on voit dans le lien que Python et PHP sont plus populaires que Go. Le choix ne semble pas venir des compétences de l'équipe puisque sur les trois développeurs Go, un connais bien, un connais un peu et un est à recruter. Il serait intéressant de détailler. Est-ce parce que la réputation de Go monte et que c'est une solution d'avenir ? Est-ce pour cibler les développeurs Go puisqu'il n'y a pas de Cloud libre auxquels ils pourraient contribuer, contrairement aux développeurs PHP pour lesquels il existe plusieurs Clouds libres, mais pas en Python à ma connaissance.
Au premier abord, ça semble fastidieux d'écrire ce genre de documents (le pourquoi) mais ça permet de mettre en évidence beaucoup plus vite les lacunes de certains choix (mince, on a prévu d'avoir une interface CardDAV, il n'y a pas de bibliothèque Go qui fait ça, on va devoir l'écrire et c'est assez compliqué comme protocole... note : je n'ai aucune idée de si ça existe ou pas en Go, c'est juste pour l'exemple).
Cette signature est publiée sous licence WTFPL