Je voudrais aussi dire par expérience venant du monde industriel ayant fait de la gestion d’entreprise et du system pendant plus de 40ans. et remercier l'auteur de l'article qui m'a donnée l'idée de vous écrire ce petit mot.
Je voudrais seulement signaler que pour faire du code lisible......
Prenons un exemple , la gestion de stock
c’est quelque chose de connue les grands principes sont dans les livres par exemple chez Gilbert jeunes….
Il faut commencer pas réfléchir comment articuler votre base de données, la granulé et ne pas penser à faire un record qui comprend toutes les zones pour géré votre stock
mais:
une entête qui comprendra par exemple
les zones fabrication appro-fournisseur , stock réel, stock dispos, stock encours , stock livraison , stock facturer , stock rebus , stock demande de livraison …...
des lignes article détail , qui vous permettrons d’avoir pour un même article des conditionnements différent, une liaison avec la commande de fabrication , la date de fabrication pour la traçabilité, le numéro de fabrication pour la traçabilité …..
on voit bien que ce n’est pas possible et pas bon de raisonner sur une ligne.
(dans tout ça je n’ai pas abordé le faite qu’il y a un M. BD qui gère le dictionnaire de référence pour faire les fichiers afin d’avoir la même nomenclature pour le n° de client dans tous les fichiers ou il sera question du n° de client par exemple et non comme j’ai vue une fois le n° numérique des fois alpha et pas de la même longueur un truc immonde dans la même application )
Maintenant j’en vient aux mouvements et là, ça devient important pour le développement.
Dans les suivit de mouvement une sorte de log (MVT)
le n° de mouvement la quantité (sortie / entée etc ) la clef complète qui permet de relier le fichier entête et le fichier détail ect…
dans mon expérience*:
j’ai pris l’option de faire des modules qui converse entre eux et indépendant un peu comme la théorie des ensembles ou l’on verrait chaque module résoudre sont problème et indépendant des autres tout en étant articulé par une base de données qui définit le programme a exécuter en fonction des opérations fonctionnel à faire ce qui donne:
entrée de commande
a) création = un mvt demande de fabrication (dans l’imprimerie une commande est égale a une fabrication l’article appartenant au client est unique)
b) modification = un mvt annulation demande de fabrication , et un mvt = nouvelle demande de fabrication (bien entendu qu’il est impossible de modifier la commande alors qu’elle est pointer comme étant en phase de production etc.… je ne rentre dans le pourquoi mais pour appuyer la modularité )
ces 3 mvt donne lieu a une modification dans l’entête de l’article zone demande de fabrication
et je ne parle pas des prévisions de matière de la réalisation des demandes de livraison des livraisons retour client etc.
tout cela pour dire que l’on peut faire des programmes de 10 000 lignes mais oui il y a un MAIS la MAINTENANCE, et l’ÉVOLUTION et de la SÉCURITÉ (journaliser commit rollback ) ces 10 000 lignes qui font tout et qui dans le temps font que ce n’est pas gérable dans l’industrie ou c’est toujours pour hier …. Alors la solution est de granuler vos programmes pour si il y a lieu( ça peu arriver) corriger un bug , modifier le comportement , ajouter un ou des modules, on voit par là toutes les perspectives…..
on comprends tout de suite l’indépendance entre la vie de la commande et la vie du stock etc...
et de par là on ce voit et on ce doit de penser comment articuler ce projet qui comporteras des modules qui communique entre eux et cela fait parti du développement même si ça ne gère pas le stock….
ceci n’est qu’un exemple pour vous dire qu’il faut mettre aplat votre projet pour le faire coller à la réalité et encore je n’ai pas parlé des normes que vous initialiseriez afin que votre apparence soit la même dans toutes les interfaces qui seront dans l’entreprise ( ex la même touche de fonction qui fait exit idem pour update ou creat etc. les couleurs etc... ) . Et qui de plus devront être intuitive pour l’utilisateur afin que l’outil informatique (traitement de l’information mécanique) soit réellement un outil et non pas un casse tête intellectuel mais qui colle à la peau de l’entreprise et là vous verrez votre patron prendre beaucoup d’intérêt à vous avoir …..
ps( théorie des ensembles la base de données est gérer par les programmes modulaire qui eux mêmes sont articulé par la base de données et les données doivent circuler entre elles et la boucle est faite je n'ai fait ni référence à Merise ni OO mais plutôt la Méthode AXIAL rodp "relationnel-objet-data-path" qui comprend les deux précédentes faite pour faire du L4G )
voilà ce n’est pas possible en si peu de lignes de tout résumer mais je souhaite que çà vous aiguille.
Bien penser son projet c’est 50% de bien écrire son projet le reste relisez les précautions , je ne rajouterais qu’une seule chose à la présentation faite relire vos programmes et tester par d'autre et dialoguer …. ce tenir a jour dans l'évolution du langage et ne pas hésiter a remettre son tablier pour réactualiser les applications.
3 |
0 |
Chers membres du club,
Retrouvez les meilleurs cours et tutoriels pour apprendre la programmation 
Envoyé par JPLAROCHE
