T'es au courant que la polygamie est légale dans une cinquantaine de pays, pour la plupart de culture musulmane ?
Cela n'a pas d'importance si ton application est destinée uniquement à la France, à l'Europe ou à l'Occident. Mais dans le contexte actuel de mondialisation des ventes, il faut penser aux différences culturelles.
J'aimerai bien voir ça un jour (on peut toujours rêver) : le mariage pour tous dans les pays "musulmans". Un mélange de polygamie et de polyandrie, ou que des mecs ou que des nanas (je ne sais pas comment ça s'appelle).
Ce que tu appelles factoriser, je l'appelle aussi comme ça, c'est faire du rangement. Tout le monde le fait ou devrait le faire.
Ma règle pour décider de ranger c'est : quand je tape la même chose pour la troisième fois, je me pose la question de factoriser (pas besoin d'acronyme).
Généraliser, c'est autre chose : c'est trouver l'essence des objets.
Donner plus de potentiel à une conception. Cela a un prix : réduire la lisibilité du concept et du code.
Ce n'est cependant pas à bannir d'emblée même s'il y a un danger à explorer la généralisation.
Dire ça c'est ignorer les chapitres 11 et 12 du "Refactoring" de Fowler précédemment cité. On peut généraliser en refactorisant.
Et les Design Patterns tu évites aussi de les employer du coup ?
J'utilise les design patterns en tant que catalogue d'idée pas en tant que dogme. Comme beaucoup, j'ai eu la chance d'en trouver tout seul avant de connaà®tre le livre design patterns. J' en ai découvert d'autres (le pattern Command).
La généralisation n'a aucun rapport avec de quelconques contraintes d'UI. Ton architecture interne d'application ne va pas plus que ça imposer de contraintes UI. Ou alors c'est que tu ne respectes pas le MVC et les Design Patterns usuels.
Je te trouve très optimiste. Un exemple simple auquel j'ai été confronté : je classe des lieux par ordre alphabétique et je les affiche dans une table view. Je peux en afficher 20000 par ordre alphabétique sur le nom du lieu de manière transparente car derrière Core Data utilise une requête SQLLite ORDER BY. Par contre si je veux classer ces lieux par distance par rapport à la position de l'utilisateur, ça devient tout de suite beaucoup plus compliqué. Il n 'y a pas de requête pour ça donc je dois charger en mémoire tous les lieux pour les trier. Je ne peux donc pas faire un tri par distance brut, je dois demander une distance max à l'utilisateur.
Mes choix de conceptions et ceux de SQLLite se traduisent bien en contrainte sur l'UI.
La généralisation ici consiste à traiter une position comme deux "double" séparés. Dans CloudKit en revanche on peut créer un champ de Location qui va permettre un tri par distance.
Plus simple : la généralisation qui consiste à traiter un caractère comme un nombre sur 7 bits (ASCII).
Je trouve ton exemple très bon, il illustre parfaitement ta manière de penser. Je comprends bien que tu n'offre pas la possibilité par plaisir mais parce que tu penses que le client a des besoins sous-jacents non exprimés. Alors tu extrapoles un peu, parce que tu sens qu'il n'a pas saisi toute la teneur du problème et que si tu te contentes d'implémenter son besoin exprimé, alors tu devras casser ton modèle par la suite, alors que ce changement était prévisible.
J'ai personnellement un exemple récent, que je ne peux malheureusement pas partager ici, mais qui va dans ton sens.
Peut-être qu'effectivement, il ne fera jamais de mariage pour tous dans sa cité, dans ce cas, ce n'est pas grave je n'ai rien perdu.
Je pense que c'est sur cet aspect que nous ne sommes pas d'accord: si, tu as peut-être perdu du temps et complexifié ton code inutilement. Par ailleurs, en adoptant dès le départ la solution compliquée, tu te prives du gain de connaissance qu'apporte l'implémentation de la solution simple.
Un exemple simple auquel j'ai été confronté : je classe des lieux par ordre alphabétique et je les affiche dans une table view. Je peux en afficher 20000 par ordre alphabétique sur le nom du lieu de manière transparente car derrière Core Data utilise une requête SQLLite ORDER BY. Par contre si je veux classer ces lieux par distance par rapport à la position de l'utilisateur, ça devient tout de suite beaucoup plus compliqué. Il n 'y a pas de requête pour ça donc je dois charger en mémoire tous les lieux pour les trier. Je ne peux donc pas faire un tri par distance brut, je dois demander une distance max à l'utilisateur.
Mes choix de conceptions et ceux de SQLLite se traduisent bien en contrainte sur l'UI.
La généralisation ici consiste à traiter une position comme deux "double" séparés. Dans CloudKit en revanche on peut créer un champ de Location qui va permettre un tri par distance.
Dans mon métier on n'a pas du tout la même approche. Ce n'est pas l'architecture qui drive l'UI, mais l'UI et surtout le fonctionnel qui drive l'architecture.
Aujourd'hui tu n'as pas besoin de tri par distance, mais tu as besoin de gérer un grand nombre de données et d'avoir du tri alphabétique. Donc tu vas choisir une solution technique qui répond juste à tes besoins.
Si demain tes utilisateurs disent "ça serait vraiment bien de trier par distance", et que ça devient un nouveau besoin, alors dans ce cas tu vas te poser la question de comment faire ton refactoring pour le supporter. Mais si les tu pensais que les utilisateurs te demanderaient ça plus tard et que tu choisis dès le début une solution complexe, avec un moteur de BDD qui sait gérer les coordonnées géographiques nativement, etc, en te disant "en prévision", tu vas sortir l'artillerie lourde juste pour un "au cas où, si je rajoute ça plus tard".
Sauf que là , imagine, tes utilisateurs te demandent non pas d'afficher "tous les résultats, triés par distance", mais "on serait intéressés pour avoir les résultats les plus proches". Là tu vas creuser auprès de tes utilisateurs pour savoir si par cela ils entendent "les lieux à moins de 10km", ou "les 20 lieux les plus proches" ou autre.
-> S'ils te demandent les lieux à moins de 10km, il te suffit de rajouter dans ta requête CoreData (ou tout autre SGBD que tu aurais choisi initialement) pour filtrer les résultats qui ont "ici.x-10km < position.x < ici.x+10km" et pareil pour "y" (enfin, ou latitude/longitude si tu préfères). Tu auras les résultats dans un carré de 20km de côté, et après tu peux parcourir ces résultats pour éliminer ceux qui ne sont pas dans le cercle de rayon 10km. Le fait de filtrer dans un carré avec ta requête te permet un pré-filtrage pour pas avoir à charger TOUS tes lieux, et le post-filtrage à la main pour ne garder que ceux dans le cercle est du coup peu consommateur en comparaison à si tu avais eu à le faire pour tous tes lieux.
Bilan : tu gardes ta solution et ton architecture d'origine (CoreData, SQLite), et tu implémentes bien la nouvelle fonctionnalité demandée, sans avoir à tout migrer vers CloudKit et à sortir l'artillerie lourde et à dropper des anciennes versions d'iOS juste pour ça.
-> S'ils te demandent que les 20 lieux les plus proches, tu peux aussi faire un algo similaire (les lieux à moins de 10km, et s'il y en a moins de 20, tu augmentes ta distance jusqu'à en avoir assez), c'est + efficace que de charger TOUT en mémoire et de TOUT filtrer à la main ensuite
Bilan : là encore, tu gardes ta solution CoreData, tout en implémentant bien ce que les utilisateurs attendent comme comportement.
Au final, tu gardes une architecture simple et qui te suffit pour ton besoin, plutôt que de te dire dès le départ "il faut absolument que je parte sur CloudKit ou sur un SBDG qui gère la SIG (= requêtes Géoloc)... au cas où j'en ai besoin un jour" alors qu'en fait le jour où tu en as besoin tu te rends compte que vu la demande des utilisateurs, c'est même pas nécessaire de migrer vers une telle solution.
Je pense que c'est sur cet aspect que nous ne sommes pas d'accord: si, tu as peut-être perdu du temps et complexifié ton code inutilement.
Peut-être, mais c'était une sorte de pari et de compromis, parfois ça paye, parfois non.
Mais bien souvent la démarche de généralisation en amont vise à simplifier le problème et non pas à faire l'application ultime qui va tout faire. Pour pouvoir estimer une charge de travail et réduire le coût sur un cahier des charges métiers de 200 pages en 3 jours, tu dois nécessairement simplifier le problème. Le but n'est donc pas de faire une usine à gaz mais au contraire de ramener un problème complexe à quelque chose de simple, quitte à faire quelques généralisations hâtives qui se verront au niveau de l'UI.
Après c'est une négo. commerciale. Par exemple, si j'ai vendu un catalogue de produit avec un titre et un auteur pour chaque produit et des features annexes type "recherche par auteur", etc.
Maintenant le client me dit qu'en fait quand le produit est un disque, ça peut-être une compilation et donc il peut y avoir plusieurs "auteurs". Du coup si on veut rester dans le budget initial, on décide de mettre tous les auteurs dans le même champ séparé par un séparateur texte. C'est pas terrible, j'ai trop généralisé en supposant un seul auteur par produit, mais j'ai un budget à tenir.
Si j'avais travaillé en Agile, j'aurais peut-être pas fait cette généralisation parce qu'on aurait eu plus de temps, mais je n'aurais jamais été capable de donner un prix/délais à l'avance.
Donc le but de ma généralisation n'était pas de faire une app qui gère tous les produits mais bien de faire une app que je puisse envisager dans son ensemble pour la chiffrer à l'avance.
Heu là dans ton dernier message tu décris justement YAGNI...
T'as fait un produit simplifié, qui gère des produits ayant un titre et un auteur. Parce qu'à l'origine c'est le seul besoin qu'il y avait. Donc tu n'as pas fait un truc générique qui prend tout avec une base relationnelle et tout, tu as fait au plus simple pour te cantonner au besoin.
Demain tu as un autre besoin, tu développes spécifiquement pour le besoin.
Si tu avais dès le début fait un truc qui support tous les artistes, tu aurais peut-être développé un truc pour rien, car ton client aurait peut-être plutôt dit "un album, c'est un groupement de produits, chaque produit est une chanson", et tu aurais alors plutôt organisé ton modèle sous forme hiérarchique et fait autrement, selon les besoin du client.
Tu ne peux pas savoir à l'avance et surtout de façon bien spécifiée dès le début quel nouveau besoin tu auras dans le futur. C'est justement ça YAGNI. Ne pas essayer d'imaginer des fonctionnalités non encore spécifiées, car quand demain tu auras les spécifications précises expliquant tous les cas, tu te rends compte des impacts techniques que tu n'aurais pas pu voir en avance de phase sans les specs.
S'il s'agit la conception d'un groupe de classes parmi lesquelles on pourrait trouver une hiérarchie, je commence en créant toutes les classes sans héritage, même si je le prévois.
Seulement après j'ai vérifié leurs fonctionnalités, là je cherche les points communes et je commence à créer une super-classe.
J'aimerai bien voir ça un jour (on peut toujours rêver) : le mariage pour tous dans les pays "musulmans". Un mélange de polygamie et de polyandrie, ou que des mecs ou que des nanas (je ne sais pas comment ça s'appelle).
Pour le moment, ça s'appelle "séance de lapidation collective" ! Et ça se pratiquait encore dans les campagnes françaises, il n'y a pas très longtemps.
S'il s'agit la conception d'un groupe de classes parmi lesquelles on pourrait trouver une hiérarchie, je commence en créant toutes les classes sans héritage, même si je le prévois.
Seulement après j'ai vérifié leurs fonctionnalités, là je cherche les points communes et je commence à créer une super-classe.
Je fais ça aussi qund les classes ne correspondent pas à quelque chose de réel. Par exemple des vues. Si les classes correspondent à du réel, exemple véhicule/voiture/vamion. Je pars des le depart sur une hierarchie, ne serait que pour pouvoir traiter les objets en collection.
Dans mon métier on n'a pas du tout la même approche. Ce n'est pas l'architecture qui drive l'UI, mais l'UI et surtout le fonctionnel qui drive l'architecture.
Ce n'est pas mon cas car il n'y a pas assez d'efforts mis sur la définition de l'UI.
Donc en général, je fais en sorte que les deux se rencontrent, c'est la partie la plus interessante d'ailleurs de la conception.
Là tu vas creuser auprès de tes utilisateurs pour savoir si par cela ils entendent "les lieux à moins de 10km", ou "les 20 lieux les plus proches" ou autre.-> S'ils te demandent les lieux à moins de 10km, il te suffit de rajouter dans ta requête CoreData (ou tout autre SGBD que tu aurais choisi initialement) pour filtrer les résultats qui ont "ici.x-10km < position.x < ici.x+10km" et pareil pour "y" (enfin, ou latitude/longitude si tu préfères). Tu auras les résultats dans un carré de 20km de côté, et après tu peux parcourir ces résultats pour éliminer ceux qui ne sont pas dans le cercle de rayon 10km.
C'est exactement ce que j'ai fait, sauf que la distance max est réglable.
J'ai pris cette exemple pour démontrer que l'architecture finit souvent par avoir une influence sur l'UI, qu'on le veuille ou non.
D'ailleurs quand on ne travaille pas en mode agile et sans designer, on a tendance à calquer l'UI sur l'architecture, ou en tous cas, on est biaisé parce qu'on sait quelle est l'architecture et on peut avoir envie de choisir la solution d'UI qui va être la plus facile à développer en fonction de la conception.
Finalement FKDEV, je me demande si ta démarche n'est pas tout simplement ce que l'on appelle maintenant l'Analyse Métier (Business Analysis) dans laquelle on s'intéresse à la modélisation du Métier indépendamment de tout système d'information et de toute application informatique.
T'es tu intéressé au BPMN (Business Process Modeling Notation), aux extensions métier d'UML, à l'excellent livre de Fowler (le même que la factorisation) Analysis Patterns ?
La démarche est de modéliser le métier afin :
- d'avoir des architectures informatiques plus pérennes (c'est ton intention me semble-t-il)
- des applications plus proches du 'réel' besoin
- éventuellement automatiser plus simplement les processus métier en utilisant des systèmes qui 'exécutent' directement le BPMN
J'ai de nombreux exemples de 'bug' chez les clients, mal vécus par les informaticiens car ils trouvent injuste qu'on leur reproche d'avoir respecté la Spécification. Par exemple on énonce une règle de gestion "un contrat est toujours associé à un prescripteur", et une fois l'application en production le système est inutilisable. Les services utilisateurs informent la direction générale que le business s'arrête parce que ces crétins d'informaticiens au cerveau binaire mono-neuronique n'ont pas compris qu'un contrat pouvait ne pas avoir de prescripteur ou qu'il pouvait en avoir plusieurs.
Les principes YAGNI, KISS, le TDD s'appliquent à la conception et à la réalisation de logiciel, lorsqu'on est dans le système d'information. Une fois que le besoin a été spécifié.
Ils ne s'appliquent pas à l'analyse métier, étape intermédiaire indispensable pour obtenir les 'bonnes' spécifications.
Le problème cest que FKDEV tu évoques le cas où c'est la même personne qui fait le technique et le fonctionnel.
Là forcément du coup c'est biaisé, car quand tu conseilles du fonctionnel au client, comme tu dis, tu te contraint toi-même inconsciemment (ou consciemment d'ailleurs), t'as pas envie de proposer telle ou telle feature parce que du coup tu te dis "ouais je vais pas proposer ça, car ça va être le border à implémenter vu mon architecture, va falloir que je réfléchisse à faire un refactoring, c'est la merde" et du coup bah tu proposes pas la feature.
Alors qu'en général, c'est plutôt "chacun son métier". Comme dit jpimbert, tout comme le développement est un métier à part entière, et l'architecture aussi, le design en est un autre, l'ergonomie en est un autre, et la spécification fonctionnelle en est un autre. Savoir ce que veut le client, ce qui sera + ergonomique, ou plus profitable (call-to-action vers un achat, etc) pour ton Business Model, en fonction des besoins, des profils des utilisateurs, etc... c'est un métier à part entière, qui n'est pas le même que le métier de développeur, ça ne nécessite juste pas les mêmes connaissances et compétences.
Alors certes la plupart de ceux qui s'installent en Auto-Entrepreneur ont tendance à tout faire (je suis passé par là ), et du coup ça se comprend, on essaye de concilier, et là forcémentsi on fonctionne comme ça, on s'auto-restreint, les choix d'architecture qu'on fait vont restraindre l'UI car on voudra pas changer l'archi donc on va pas proposer une certaine UI. Mais normalement, quand on a une personne dont c'est le métier pour chaque discipline, chacun apporte ses propres arguments et propose des idées SANS être biaisé par les limitations des autres. Et du coup on trouve des compromis, pour peser le pour et le contre, mais au moins il n'y a pas de restriction dans les idées. Ce n'est pas à l'architecture de limiter les possibilités du design et de l'ergo, mais plutôt l'inverse.
Ce n'est pas à l'architecture de limiter les possibilités du design et de l'ergo, mais plutôt l'inverse.
Je ne suis pas trop d'accord. Ce qui compte c'est la valeur pour le client. S'il existe une manière de faire 80% du boulot avec 20% de l'effort, il faut faire de cette manière ! Bien sûr que ce n'est pas idéal, mais d'une part la perfection est quelque chose de subjectif, d'autre part c'est mieux pour le client d'avoir quelque chose de très bien aujourd'hui que quelque chose de parfait dans longtemps. Et ça permet à l'idée de mûrir.
Là forcément du coup c'est biaisé, car quand tu conseilles du fonctionnel au client, comme tu dis, tu te contraint toi-même inconsciemment (ou consciemment d'ailleurs), t'as pas envie de proposer telle ou telle feature parce que du coup tu te dis "ouais je vais pas proposer ça, car ça va être le border à implémenter vu mon architecture, va falloir que je réfléchisse à faire un refactoring, c'est la merde" et du coup bah tu proposes pas la feature.
Clairement. Le problème étant quand c'est inconscient et pour des raisons qui ne sont pas forcément purement technique. Parfois on se limite aussi parce qu'on a un coût et un délai à tenir, ou une équipe qui ne veut pas suivre derrière si on prend une architecture qui n'est pas simple.
Mais normalement, quand on a une personne dont c'est le métier pour chaque discipline, chacun apporte ses propres arguments et propose des idées SANS être biaisé par les limitations des autres. Et du coup on trouve des compromis, pour peser le pour et le contre, mais au moins il n'y a pas de restriction dans les idées. Ce n'est pas à l'architecture de limiter les possibilités du design et de l'ergo, mais plutôt l'inverse.
Je suis d'accord. Après, si on est conscient de son biais et objectif sur ses propres motivations, on peut endosser plusieurs rôles à la fois.
C'est juste du bon sens, connaà®tre avec précision les besoins du client.
Oui et pourtant c'est loin d'être évident en pratique. Entre ceux qui sont timides, ceux qui disent oui à tout, ceux qui n'écoutent pas, ceux qui ne comprennent pas et ceux qui pensent que le client est un con, on n'est pas toujours bien capable de connaà®tre avec précision les besoins du client.
Deuxième point : quelle est l'importance du papier ? Vous servez-vous du papier ? En particulier pour certains mécanismes complexes, je ressens le besoin pour documenter mon programme de faire un schéma (et de le scanner et de le mettre dans mon projet xcode). ça peut être en particulier le cas pour le démarrage de l'appli (qui init qui ? quels sont les viewDidLoad et viewDidAppear importants, etc.). Ressentez-vous aussi ce besoin et si oui que faites-vous ?
De façon générale, y a-t-il des bons livres (ou post de blogs/vidéos, etc.) qui parlent de ces aspects "philosophiques" du métier ?
Merci !
Colas
Oui le papier pour le fonctionnement général, le moteur du programme, pour faire des schémas.... Déjà c'est léger, transportable, reposant pour les yeux (quoi que avec le rétina..) et trés peu de code couché sur papier.
Le tableau 'véléda' quand tu travaille a plusieurs c'est pas mal aussi.
Le sujet est intéressant mais pouvez vous traduire les termes : YAGNI, KISS, TDD
Sinon, côté réflexion le crayon de papier, la gomme et la feuille sont les meilleurs alliés de la réflexion en général. Une notion que j'ai du apprendre à mes filles lorsqu'en 4ème et 3ème leur collège ´ numérique ´ leur imposait de travailler directement sur le PC mis à leur disposition. J'ai a ce moment constaté un manque croissant de compréhension de leur cours. Le soir on devait reprendre ensemble sur papier les notions apprise n'y en classe. Quel catastrophe quand je les voyais faire un devoir maison de math, d'histoire etc directement sur le PC.
Réponses
J'aimerai bien voir ça un jour (on peut toujours rêver) : le mariage pour tous dans les pays "musulmans". Un mélange de polygamie et de polyandrie, ou que des mecs ou que des nanas (je ne sais pas comment ça s'appelle).
Dire ça c'est ignorer les chapitres 11 et 12 du "Refactoring" de Fowler précédemment cité. On peut généraliser en refactorisant.
Comme beaucoup, j'ai eu la chance d'en trouver tout seul avant de connaà®tre le livre design patterns.
J' en ai découvert d'autres (le pattern Command).
Je te trouve très optimiste.
Un exemple simple auquel j'ai été confronté : je classe des lieux par ordre alphabétique et je les affiche dans une table view. Je peux en afficher 20000 par ordre alphabétique sur le nom du lieu de manière transparente car derrière Core Data utilise une requête SQLLite ORDER BY.
Par contre si je veux classer ces lieux par distance par rapport à la position de l'utilisateur, ça devient tout de suite beaucoup plus compliqué. Il n 'y a pas de requête pour ça donc je dois charger en mémoire tous les lieux pour les trier.
Je ne peux donc pas faire un tri par distance brut, je dois demander une distance max à l'utilisateur.
Mes choix de conceptions et ceux de SQLLite se traduisent bien en contrainte sur l'UI.
La généralisation ici consiste à traiter une position comme deux "double" séparés.
Dans CloudKit en revanche on peut créer un champ de Location qui va permettre un tri par distance.
Plus simple : la généralisation qui consiste à traiter un caractère comme un nombre sur 7 bits (ASCII).
Je comprends bien que tu n'offre pas la possibilité par plaisir mais parce que tu penses que le client a des besoins sous-jacents non exprimés. Alors tu extrapoles un peu, parce que tu sens qu'il n'a pas saisi toute la teneur du problème et que si tu te contentes d'implémenter son besoin exprimé, alors tu devras casser ton modèle par la suite, alors que ce changement était prévisible.
J'ai personnellement un exemple récent, que je ne peux malheureusement pas partager ici, mais qui va dans ton sens.
Je pense que c'est sur cet aspect que nous ne sommes pas d'accord: si, tu as peut-être perdu du temps et complexifié ton code inutilement. Par ailleurs, en adoptant dès le départ la solution compliquée, tu te prives du gain de connaissance qu'apporte l'implémentation de la solution simple.
Aujourd'hui tu n'as pas besoin de tri par distance, mais tu as besoin de gérer un grand nombre de données et d'avoir du tri alphabétique. Donc tu vas choisir une solution technique qui répond juste à tes besoins.
Si demain tes utilisateurs disent "ça serait vraiment bien de trier par distance", et que ça devient un nouveau besoin, alors dans ce cas tu vas te poser la question de comment faire ton refactoring pour le supporter.
Mais si les tu pensais que les utilisateurs te demanderaient ça plus tard et que tu choisis dès le début une solution complexe, avec un moteur de BDD qui sait gérer les coordonnées géographiques nativement, etc, en te disant "en prévision", tu vas sortir l'artillerie lourde juste pour un "au cas où, si je rajoute ça plus tard".
Sauf que là , imagine, tes utilisateurs te demandent non pas d'afficher "tous les résultats, triés par distance", mais "on serait intéressés pour avoir les résultats les plus proches". Là tu vas creuser auprès de tes utilisateurs pour savoir si par cela ils entendent "les lieux à moins de 10km", ou "les 20 lieux les plus proches" ou autre.
-> S'ils te demandent les lieux à moins de 10km, il te suffit de rajouter dans ta requête CoreData (ou tout autre SGBD que tu aurais choisi initialement) pour filtrer les résultats qui ont "ici.x-10km < position.x < ici.x+10km" et pareil pour "y" (enfin, ou latitude/longitude si tu préfères). Tu auras les résultats dans un carré de 20km de côté, et après tu peux parcourir ces résultats pour éliminer ceux qui ne sont pas dans le cercle de rayon 10km. Le fait de filtrer dans un carré avec ta requête te permet un pré-filtrage pour pas avoir à charger TOUS tes lieux, et le post-filtrage à la main pour ne garder que ceux dans le cercle est du coup peu consommateur en comparaison à si tu avais eu à le faire pour tous tes lieux.
Bilan : tu gardes ta solution et ton architecture d'origine (CoreData, SQLite), et tu implémentes bien la nouvelle fonctionnalité demandée, sans avoir à tout migrer vers CloudKit et à sortir l'artillerie lourde et à dropper des anciennes versions d'iOS juste pour ça.
-> S'ils te demandent que les 20 lieux les plus proches, tu peux aussi faire un algo similaire (les lieux à moins de 10km, et s'il y en a moins de 20, tu augmentes ta distance jusqu'à en avoir assez), c'est + efficace que de charger TOUT en mémoire et de TOUT filtrer à la main ensuite
Bilan : là encore, tu gardes ta solution CoreData, tout en implémentant bien ce que les utilisateurs attendent comme comportement.
Au final, tu gardes une architecture simple et qui te suffit pour ton besoin, plutôt que de te dire dès le départ "il faut absolument que je parte sur CloudKit ou sur un SBDG qui gère la SIG (= requêtes Géoloc)... au cas où j'en ai besoin un jour" alors qu'en fait le jour où tu en as besoin tu te rends compte que vu la demande des utilisateurs, c'est même pas nécessaire de migrer vers une telle solution.
Peut-être, mais c'était une sorte de pari et de compromis, parfois ça paye, parfois non.
Mais bien souvent la démarche de généralisation en amont vise à simplifier le problème et non pas à faire l'application ultime qui va tout faire.
Pour pouvoir estimer une charge de travail et réduire le coût sur un cahier des charges métiers de 200 pages en 3 jours, tu dois nécessairement simplifier le problème.
Le but n'est donc pas de faire une usine à gaz mais au contraire de ramener un problème complexe à quelque chose de simple, quitte à faire quelques généralisations hâtives qui se verront au niveau de l'UI.
Après c'est une négo. commerciale.
Par exemple, si j'ai vendu un catalogue de produit avec un titre et un auteur pour chaque produit et des features annexes type "recherche par auteur", etc.
Maintenant le client me dit qu'en fait quand le produit est un disque, ça peut-être une compilation et donc il peut y avoir plusieurs "auteurs". Du coup si on veut rester dans le budget initial, on décide de mettre tous les auteurs dans le même champ séparé par un séparateur texte.
C'est pas terrible, j'ai trop généralisé en supposant un seul auteur par produit, mais j'ai un budget à tenir.
Si j'avais travaillé en Agile, j'aurais peut-être pas fait cette généralisation parce qu'on aurait eu plus de temps, mais je n'aurais jamais été capable de donner un prix/délais à l'avance.
Donc le but de ma généralisation n'était pas de faire une app qui gère tous les produits mais bien de faire une app que je puisse envisager dans son ensemble pour la chiffrer à l'avance.
T'as fait un produit simplifié, qui gère des produits ayant un titre et un auteur. Parce qu'à l'origine c'est le seul besoin qu'il y avait. Donc tu n'as pas fait un truc générique qui prend tout avec une base relationnelle et tout, tu as fait au plus simple pour te cantonner au besoin.
Demain tu as un autre besoin, tu développes spécifiquement pour le besoin.
Si tu avais dès le début fait un truc qui support tous les artistes, tu aurais peut-être développé un truc pour rien, car ton client aurait peut-être plutôt dit "un album, c'est un groupement de produits, chaque produit est une chanson", et tu aurais alors plutôt organisé ton modèle sous forme hiérarchique et fait autrement, selon les besoin du client.
Tu ne peux pas savoir à l'avance et surtout de façon bien spécifiée dès le début quel nouveau besoin tu auras dans le futur. C'est justement ça YAGNI. Ne pas essayer d'imaginer des fonctionnalités non encore spécifiées, car quand demain tu auras les spécifications précises expliquant tous les cas, tu te rends compte des impacts techniques que tu n'aurais pas pu voir en avance de phase sans les specs.
S'il s'agit la conception d'un groupe de classes parmi lesquelles on pourrait trouver une hiérarchie, je commence en créant toutes les classes sans héritage, même si je le prévois.
Seulement après j'ai vérifié leurs fonctionnalités, là je cherche les points communes et je commence à créer une super-classe.
Pour le moment, ça s'appelle "séance de lapidation collective" ! Et ça se pratiquait encore dans les campagnes françaises, il n'y a pas très longtemps.
Je fais ça aussi qund les classes ne correspondent pas à quelque chose de réel. Par exemple des vues. Si les classes correspondent à du réel, exemple véhicule/voiture/vamion. Je pars des le depart sur une hierarchie, ne serait que pour pouvoir traiter les objets en collection.
Ce n'est pas mon cas car il n'y a pas assez d'efforts mis sur la définition de l'UI.
Donc en général, je fais en sorte que les deux se rencontrent, c'est la partie la plus interessante d'ailleurs de la conception.
C'est exactement ce que j'ai fait, sauf que la distance max est réglable.
J'ai pris cette exemple pour démontrer que l'architecture finit souvent par avoir une influence sur l'UI, qu'on le veuille ou non.
D'ailleurs quand on ne travaille pas en mode agile et sans designer, on a tendance à calquer l'UI sur l'architecture, ou en tous cas, on est biaisé parce qu'on sait quelle est l'architecture et on peut avoir envie de choisir la solution d'UI qui va être la plus facile à développer en fonction de la conception.
Finalement FKDEV, je me demande si ta démarche n'est pas tout simplement ce que l'on appelle maintenant l'Analyse Métier (Business Analysis) dans laquelle on s'intéresse à la modélisation du Métier indépendamment de tout système d'information et de toute application informatique.
T'es tu intéressé au BPMN (Business Process Modeling Notation), aux extensions métier d'UML, à l'excellent livre de Fowler (le même que la factorisation) Analysis Patterns ?
La démarche est de modéliser le métier afin :
- d'avoir des architectures informatiques plus pérennes (c'est ton intention me semble-t-il)
- des applications plus proches du 'réel' besoin
- éventuellement automatiser plus simplement les processus métier en utilisant des systèmes qui 'exécutent' directement le BPMN
J'ai de nombreux exemples de 'bug' chez les clients, mal vécus par les informaticiens car ils trouvent injuste qu'on leur reproche d'avoir respecté la Spécification. Par exemple on énonce une règle de gestion "un contrat est toujours associé à un prescripteur", et une fois l'application en production le système est inutilisable. Les services utilisateurs informent la direction générale que le business s'arrête parce que ces crétins d'informaticiens au cerveau binaire mono-neuronique n'ont pas compris qu'un contrat pouvait ne pas avoir de prescripteur ou qu'il pouvait en avoir plusieurs.
Les principes YAGNI, KISS, le TDD s'appliquent à la conception et à la réalisation de logiciel, lorsqu'on est dans le système d'information. Une fois que le besoin a été spécifié.
Ils ne s'appliquent pas à l'analyse métier, étape intermédiaire indispensable pour obtenir les 'bonnes' spécifications.
C'est juste du bon sens, connaà®tre avec précision les besoins du client.
C'est aussi un métier à part entière
Là forcément du coup c'est biaisé, car quand tu conseilles du fonctionnel au client, comme tu dis, tu te contraint toi-même inconsciemment (ou consciemment d'ailleurs), t'as pas envie de proposer telle ou telle feature parce que du coup tu te dis "ouais je vais pas proposer ça, car ça va être le border à implémenter vu mon architecture, va falloir que je réfléchisse à faire un refactoring, c'est la merde" et du coup bah tu proposes pas la feature.
Alors qu'en général, c'est plutôt "chacun son métier". Comme dit jpimbert, tout comme le développement est un métier à part entière, et l'architecture aussi, le design en est un autre, l'ergonomie en est un autre, et la spécification fonctionnelle en est un autre. Savoir ce que veut le client, ce qui sera + ergonomique, ou plus profitable (call-to-action vers un achat, etc) pour ton Business Model, en fonction des besoins, des profils des utilisateurs, etc... c'est un métier à part entière, qui n'est pas le même que le métier de développeur, ça ne nécessite juste pas les mêmes connaissances et compétences.
Alors certes la plupart de ceux qui s'installent en Auto-Entrepreneur ont tendance à tout faire (je suis passé par là ), et du coup ça se comprend, on essaye de concilier, et là forcémentsi on fonctionne comme ça, on s'auto-restreint, les choix d'architecture qu'on fait vont restraindre l'UI car on voudra pas changer l'archi donc on va pas proposer une certaine UI.
Mais normalement, quand on a une personne dont c'est le métier pour chaque discipline, chacun apporte ses propres arguments et propose des idées SANS être biaisé par les limitations des autres. Et du coup on trouve des compromis, pour peser le pour et le contre, mais au moins il n'y a pas de restriction dans les idées. Ce n'est pas à l'architecture de limiter les possibilités du design et de l'ergo, mais plutôt l'inverse.
"Less is More".
S'il existe une manière de faire 80% du boulot avec 20% de l'effort, il faut faire de cette manière ! Bien sûr que ce n'est pas idéal, mais d'une part la perfection est quelque chose de subjectif, d'autre part c'est mieux pour le client d'avoir quelque chose de très bien aujourd'hui que quelque chose de parfait dans longtemps. Et ça permet à l'idée de mûrir.
Clairement. Le problème étant quand c'est inconscient et pour des raisons qui ne sont pas forcément purement technique.
Parfois on se limite aussi parce qu'on a un coût et un délai à tenir, ou une équipe qui ne veut pas suivre derrière si on prend une architecture qui n'est pas simple.
Je suis d'accord.
Après, si on est conscient de son biais et objectif sur ses propres motivations, on peut endosser plusieurs rôles à la fois.
Oui et pourtant c'est loin d'être évident en pratique.
Entre ceux qui sont timides, ceux qui disent oui à tout, ceux qui n'écoutent pas, ceux qui ne comprennent pas et ceux qui pensent que le client est un con, on n'est pas toujours bien capable de connaà®tre avec précision les besoins du client.
Oui le papier pour le fonctionnement général, le moteur du programme, pour faire des schémas.... Déjà c'est léger, transportable, reposant pour les yeux (quoi que avec le rétina..) et trés peu de code couché sur papier.
Le tableau 'véléda' quand tu travaille a plusieurs c'est pas mal aussi.
Bref le papier quand ça coince uniquement.
Sinon, côté réflexion le crayon de papier, la gomme et la feuille sont les meilleurs alliés de la réflexion en général. Une notion que j'ai du apprendre à mes filles lorsqu'en 4ème et 3ème leur collège ´ numérique ´ leur imposait de travailler directement sur le PC mis à leur disposition. J'ai a ce moment constaté un manque croissant de compréhension de leur cours. Le soir on devait reprendre ensemble sur papier les notions apprise n'y en classe. Quel catastrophe quand je les voyais faire un devoir maison de math, d'histoire etc directement sur le PC.
KISS - garde ça simple, stupide
TDD - développement piloté par les tests
à‰galement, tu pourrais voir les définitions plus complètes sur Wikipédia