Hé bien peut-être commences-tu à comprendre pourquoi rien de bien grandiose n'a été programmé en s'appuyant uniquement sur le savoir transmis au sein des grandes écoles d'ingénieurs françaises. Notamment parce qu'en école on apprend pas à programmer, mais à devenir un programmeur, ce qui n'est pas tout à fait la même chose.
Les universitaires aiment bien considérer, pour d'évidentes raisons pratiques, qu'un developpeur sait ce qu'il fait avant de commencer à travailler. En théorie, des gens vachement intelkligents sont apssés avant, ont posé le bon problème, trouvé la meilleure solution au problème posé, une architecture de solution a été définie et un processus de developpement déterminé. C'est très rassurant pour le manager qui ne saurait envisager d'autre approche pour un projet que linéaire (des étapes à franchir et des cases à cocher sur la todolist).
Malheuresement, il s'avère que certains programmeurs ne souhaitent pas procéder ainsi. Par exemple, parce qu'ils n'ont pas pris le temps de rédgier l'énoncé du problème et n'ont qu'une vague idée d'une classe de solutions, et que leur performance (appréciée par eux mêmes ou leurs proches) leur tient lieu de méthode. Cela arrive quand, par exemple, faute d'avoir reçu les bons conseils du génie logiciel universitaire, ils admettent tout simplement qu'ils vont commencer à programmer avant de savoir ce à quoi le fait de programmer va les mener.
Et notamment, il arrive que, bien qu'on essaie de bosser un peu sérieusement, publier des spécification d'interface publique, toussa, on se rende compte au bout d'un certain temps que le design qu'on avait choisi était foireux.
Quand on a le source des deux côtés de l'interface, ça ne pose normalement aucun problème. Donc, ne pas disposer d'interfaces publiques stables et documentées n'est pas forcément bloquant pour qui que ce soit, à condition d'exposer non seulement l'interface, mais aussi les mécanismes d'interfaçage, ce qui se fait suffisamment efficacement en exposant le source (car source==doc, n'est-ce pas ?). D'ailleurs, on peut aussi publier en annexe un fichier surdétaillant l'interface destiné à être intégré compile-time ou runtime avec tout produit se greffant.
Et une chose est certaine : c'est que quand on a pas besoin de béquilles pour avancer, il arrive qu'on aille plus vite, même si on se casse plus souvent la gueule, entrainant parfois avec soi quelques voisins ou compagnons d'aventure. Pour les premiers, programmer devient prévisible, en un mot, professionnel : ce peut donc être devenir un métier, une profession, pour les seconds, c'est une passion. Quand à savoir lequel est le plus efficace des deux, c'est un autre débat... les moyens dont disposent les uns et les autres ne sont nullmement comparbales?.
# Meuh powah
Posté par Grumbl . En réponse au journal Linux et les pilotes binaires.... Évalué à 10.
Les universitaires aiment bien considérer, pour d'évidentes raisons pratiques, qu'un developpeur sait ce qu'il fait avant de commencer à travailler. En théorie, des gens vachement intelkligents sont apssés avant, ont posé le bon problème, trouvé la meilleure solution au problème posé, une architecture de solution a été définie et un processus de developpement déterminé. C'est très rassurant pour le manager qui ne saurait envisager d'autre approche pour un projet que linéaire (des étapes à franchir et des cases à cocher sur la todolist).
Malheuresement, il s'avère que certains programmeurs ne souhaitent pas procéder ainsi. Par exemple, parce qu'ils n'ont pas pris le temps de rédgier l'énoncé du problème et n'ont qu'une vague idée d'une classe de solutions, et que leur performance (appréciée par eux mêmes ou leurs proches) leur tient lieu de méthode. Cela arrive quand, par exemple, faute d'avoir reçu les bons conseils du génie logiciel universitaire, ils admettent tout simplement qu'ils vont commencer à programmer avant de savoir ce à quoi le fait de programmer va les mener.
Et notamment, il arrive que, bien qu'on essaie de bosser un peu sérieusement, publier des spécification d'interface publique, toussa, on se rende compte au bout d'un certain temps que le design qu'on avait choisi était foireux.
Quand on a le source des deux côtés de l'interface, ça ne pose normalement aucun problème. Donc, ne pas disposer d'interfaces publiques stables et documentées n'est pas forcément bloquant pour qui que ce soit, à condition d'exposer non seulement l'interface, mais aussi les mécanismes d'interfaçage, ce qui se fait suffisamment efficacement en exposant le source (car source==doc, n'est-ce pas ?). D'ailleurs, on peut aussi publier en annexe un fichier surdétaillant l'interface destiné à être intégré compile-time ou runtime avec tout produit se greffant.
Et une chose est certaine : c'est que quand on a pas besoin de béquilles pour avancer, il arrive qu'on aille plus vite, même si on se casse plus souvent la gueule, entrainant parfois avec soi quelques voisins ou compagnons d'aventure. Pour les premiers, programmer devient prévisible, en un mot, professionnel : ce peut donc être devenir un métier, une profession, pour les seconds, c'est une passion. Quand à savoir lequel est le plus efficace des deux, c'est un autre débat... les moyens dont disposent les uns et les autres ne sont nullmement comparbales?.