Discussion :

[cinemania]

héhé la question qui tue...

j'ai un profil équivalent, et c'est pour cette raison que j'ai été recruté là où je suis

à part pour de gros projets, en général, on fait des projets de petites ou moyenne ampleur, qui ont donc en moyenne guère plus de 3 développeurs en temps plein.
Souvent l'architecte fait parti de ces développeurs.

En général, contrairement à ses petites camarades cependant, il sera convié à faire toute la partie préliminaire, étude de faisabilité, spécifications techniques, et bien entendu l'architecture.
A ce titre, une fois qu'il a conçut l'architecture, défini les différents modèles, les pattern, les technologies à utiliser, le projet devient un projet d'équipe et habituellement il va en faire partie, et on va lui confier la partie la plus complexe de la bête qui est en général le noyau dur de l'application.
quand je dit "on" généralement c'est lui même qui va se confier cette tâche... et également une tâche plus coordinatrice, surtout si il n'y a pas de chef de projet désigné.

Là en plus de mes projets, on m'a confié de revoir certains des projets, pour voir ce qui allait de ce qui n'allait pas (attention... certaines parties m'ont clairement été cachées, de peur que je fasse une crise cardiaque... ce qui en dit long...)
Et au fur et à mesure des projets que je revois et développes j'étoffe, un framework spécifique pour cette société, que je réutilise à chaque fois et complète au fur et à mesure.
C'est d'ailleurs une de mes grosses tâches en plus de définir les architectures et les différentes spécifications techniques, et de participer au développement.

Ce n'est pas pour rien qu'un architecte logiciel doit savoir développer... comment pourrait-il en être autrement ? lol
En effet, la théorie (UML) c'est bien, mais on apprend également que parfois, il faut revoir le modèle parce que la réalité... est toute autre. Un architecte qui ne développe pas ne peut pas l'appréhender.

A mon humble avis, le fait que soit développeur "expert" signifie que tu es donc plus à même d'être un bon architecte.
Soyons pragmatique... Même chez Microsoft, on ne créé pas suffisamment de projets pour avoir des architectes payés à ne faire que cela...
C'est pour cela que tu ne trouve aucune offre, et ne trouvera à mon avis jamais, ne visant qu'à faire que de l'architecture.

C'est d'ailleurs tout l'intérêt d'une société... recruter un architecte, c'est quelque part être sure d'avoir recruté un développeur à peu près correct, voir très bon, mais surtout qui soit autonome, et qui puisse concevoir lui mêmes les architectures et guider les autres développeurs, et relever le niveau parfois déplorable...
Mon employeur a été franc, le jour où il m'a embauché... il m'a clairement dit pourquoi... autonomie, compétences et connaissances, et relever le niveau...
Je fait pas mal d'architecture, c'est vrai, mais ca ne représente qu'environ 40% de mon travail.

[B.AF]

Moi je ne crois pas à la para-informatique. Si tu veux faire de l'architecture logicielle, il faut savoir concevoir un logiciel.
La plupart des gens en recyclage de la période des années 80 ont réussi à faire une illusion de "MOA", "Q&A" mais sont d'une inutilité flagrante, au mieux des passes plats, au pire d'énormes boulets à trainer.

[OsoNet]

Tu me rassures, je vois que l'on a approximativement le même genre de travail.

La question avait l'air bête, mais j'ai déjà vu des cas où l'architecte ne développait pas du tout (et ne voulait pas en faire).

Pis comme j'ai souvent l'impression d'être pris pour un martien parmi les développeurs, bien content de voir que mon profil n'est pas si original que çà.

Merci pour ta réponse. Je repars, content d'être "normal".

B.AF, pas mieux, tout est dit.

[cinemania]

c'est clair... belle conclusion B.AF

[pseudocode]

Moi je ne crois pas à la para-informatique. Si tu veux faire de l'architecture logicielle, il faut savoir concevoir un logiciel.
La plupart des gens en recyclage de la période des années 80 ont réussi à faire une illusion de "MOA", "Q&A" mais sont d'une inutilité flagrante, au mieux des passes plats, au pire d'énormes boulets à trainer.

Complétez la phrase suivante.

1. L'architecte logiciel doit être également un développeur __________ .

A. métier
B. technique
C. système
D. graphique
E. dans tous les domaines (aka GOD)


2. L'architecte logiciel doit s'y connaitre en développement autant que _________

A. un architecte en bâtiment s'y connait en maçonnerie
B. un développeur s'y connait en architecture
C. un pigeon s'y connait en aéronautique
D. Mme michu s'y connait en reverse engineering de chiffrage asymétrique
E. Albert Einstein s'y connait en physique relativiste

[B.AF]

1. L'architecte logiciel doit être également un développeur __________ .

A. métier OBLIGATOIREMENT
B. technique Comment faire des algorithmes métiers cohérent sans bonnes bases techniques ????? C'est une utopie ?
L'incongruité de base "La programmation paralléle, c'est génial ! Ah bon pour faire quoi ? Ben des choses métier en paralléle ? Donc j'implémente au cas où !!!!!!!".
C. système Dans la limite de la plateforme de développement, sans être un expert
D. graphique Non, ça c'est un métier à part, qui requiert d'autres compêtences. Il doit cependant connaitre techniquement les faisables pour donner une environnement de contraintes aux designers
E. dans tous les domaines (aka GOD) Ca n'existe pas


2. L'architecte logiciel doit s'y connaitre en développement autant que _________

F. Autant qu'il est nécessaire de l'être pour s'assurer que son projet est viable, cohérent et utile. Après, on peut être technocrate, à priori ça donne aussi droit à un salaire. C'est juste moins marrant pour l'ego.


Un architecte est un homme de choix. Cela veut dire qu'il doit savoir déléguer et faire confiance car il ne peut pas être omniscient, mais il doit aussi tracer une voie et être fiable. Sinon, tout le monde serait architecte. "JE veux un logiciel qui fasse aussi le café" serait une architecture redoutable alors !

[B.AF]

Tu me rassures, je vois que l'on a approximativement le même genre de travail.

La question avait l'air bête, mais j'ai déjà vu des cas où l'architecte ne développait pas du tout (et ne voulait pas en faire).

C'est juste un incompétent égotique qui finira par perdre pied parce qu'à se faire distancer et à rester dans sa tour d'ivoire, il vieillira mal.

[cinemania]

c'est malheureusement le cas de nombre de ceux que j'ai pu rencontrer
c'est triste et donne un piètre constat.

[tomlev]

Merci pour ta réponse. Je repars, content d'être "normal".

Hum... si tu considères l'audience de cette discussion comme des gens "normaux", tu es effectivement normal... mais honnêtement, je pense qu'ici on est tous un peu azimuthés (moi compris, et je l'assume )

[B.AF]

Hum... si tu considères l'audience de cette discussion comme des gens "normaux", tu es effectivement normal... mais honnêtement, je pense qu'ici on est tous un peu azimuthés (moi compris, et je l'assume )

Oui normaux, tout à fait !!!!

[davcha]

Hum... si tu considères l'audience de cette discussion comme des gens "normaux", tu es effectivement normal... mais honnêtement, je pense qu'ici on est tous un peu azimuthés (moi compris, et je l'assume )

J'allais dire "Ben, pas forcément non", puis parler de mon cas. Mais après y avoir réfléchi environ 3 fractions de secondes, je vais m'abstenir.

Pour le reste de la discussion, quelques trucs que j'ai noté :

Les pointeurs dans un langage de haut niveau... En fait pourquoi pas. Mais le souci est de trouver un sens à l'utilisation d'un pointeur. J'entends un sens "sémantique" et non une raison technique.
Or un pointeur, ça me parait quand même clairement technique : un moyen de se balader dans la mémoire d'un système ?... Pas très abstrait, tout ça.

Les templates C++, je les regrette en .NET. Ceci dit... Ils peuvent être plus ou moins remplacés plus ou moins facilement via des expressions Linq compilées, CodeDom ou au pire Emit.

Pour le reste, je commenterais (peut-être) plus tard. Là, je rentre chez moi.

[tomlev]

Les templates C++, je les regrette en .NET. Ceci dit... Ils peuvent être plus ou moins remplacés plus ou moins facilement via des expressions Linq compilées, CodeDom ou au pire Emit.

C'est vrai que les templates C++ offrent des possibilités intéressantes, qui n'ont pas d'équivalent en .NET. D'un autre côté, vu qu'en C++ l'instanciation des templates se fait à la compilation, tu ne peux pas utiliser un template dynamiquement à l'exécution, alors que c'est possible avec les génériques en .NET via la réflexion. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
object MakeList(Type elementType)
{
    Type openType = typeof(List<>);
    Type closedType = openType.MakeGenericType(new[] { elementType });
    return Activator.CreateInstance(closedType);
}

(mais c'est vrai qu'il est rarement utile de faire ce genre de choses...)

Par contre je ne vois pas trop ce que tu veux dire concernant les expressions Linq...

[cinemania]

effectivement tomlev... un bon exemple, dont on ne se sert que rarement...
note: les activateurs c'est pas bien... c'est lent ces sales bêtes... la LCG par contre, mais bon j'avoue pour un exemple, ca ne le ferait pas

davcha euh oui là j'avoue que pour les expressions Linq ou les lambda expressions, je vois pas bien le rapport avec les templates...

[tomlev]

note: les activateurs c'est pas bien... c'est lent ces sales bêtes... la LCG par contre, mais bon j'avoue pour un exemple, ca ne le ferait pas

En quoi c'est lent ? ça va juste créer l'objet avec le constructeur par défaut, non ? en tout cas je vois pas de moyen plus simple de créer un objet à partir de son type...

Sinon je vois pas bien comment ça pourrait être plus rapide avec la LCG ? Enfin en même temps j'ai jamais utilisé ça...

[B.AF]

En quoi c'est lent ? ça va juste créer l'objet avec le constructeur par défaut, non ? en tout cas je vois pas de moyen plus simple de créer un objet à partir de son type...

Sinon je vois pas bien comment ça pourrait être plus rapide avec la LCG ? Enfin en même temps j'ai jamais utilisé ça...

En passant un coup de Reflector sur l'utilisation d'un activator tu devrais comprendre. Ca provoque une succession de casts et surtout la réflection donne un niveau d'abstraction, ce qui n'arrange pas la choucroute.

LCG te permet de gérer de la IL directement, donc un niveau de contrôle supérieur plus "close to the metal".

Codedom lui émet du code, donc nécessite une compilation et une invocation.

Quant aux génériques, il suffit de voir ce que donne le new T() pour avoir froid dans le dos ....Il passe par un Activator..Ce qui se chunte par..L'utilisation des lambdas...Comme quoi, tous les sujets se recoupent !

[davcha]

On peut obtenir plus ou moins le même comportement avec des expressions linq qu'avec les templates C++. Au même titre que de l'emit et/ou du LCG, en fait.

La différence est qu'avec des expressions Linq, tu n'auras pas à t'embêter avec le code msil.

Typiquement, je m'en sers pour remplacer les appels à Activator et à la reflection lors de l'initialisation de types dont je ne connais pas les membres à la compilation.

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Expression p = Expression.Parameter(typeof(InputData));
Func<InputData,T> ctor = Expression.Lambda(Expression.MemberInit(Expression.New(typeof(T).GetConstructor(...).... blablabla...

En très très gros et de très loin, hein. Je me rappelle pas précisément des signatures de ces méthodes. :p

Mais c'est assez agréable à utiliser, ça permet de faire beaucoup de choses très facilement.

[tomlev]

Quant aux génériques, il suffit de voir ce que donne le new T() pour avoir froid dans le dos ....Il passe par un Activator..

Effectivement, je viens de vérifier, c'est dingue ça

Mais bon, après faut voir ce qu'on appelle "lent"... je viens de faire un petit test : pour créer 1000000 instances de List<int>, ça prend entre 100 et 300ms. Donc bon, a priori c'est pas ça qui va foutre par terre les performances de toute une appli...

Sinon je viens de tester la LCM, c'est vrai que ça marche bien... à condition de générer la méthode une seule fois et de la réutiliser à chaque fois ! Donc si c'est pour créer plein d'instances en boucle, la LCM c'est bien, mais si c'est pour en créer une seule, ça va plus vite avec Activator.CreateInstance.

[cinemania]

c'est sure tomlev... la LCG c'est un peu l'artillerie lourde... c'est sure que c'est pas fait pour une instanciation, mais quand tu instancie en masse... les temps économisés sont plutôt sympa. bien qu'il faut admettre que l'activateur ne soit pas le plus long des process de la reflexion...
le Invoke sur une méthode, là c'est chaud... alors une méthode de temps en temps ca passe inaperçu, des appels dynamiques partout... c'est plus du tout la même histoire... je te parle même pas des accès aux propriétés...
faudrait que je fasse un ptit reflector sur un serialiseur pour voir ce qu'il fait mais je serait pas surpris qu'il utilise la reflexion lol...

effectivement davcha passer par les lambda-expressions et tout particulièrement par leur compilation permet de s'affranchir les migraines nécessaires quand on n'a pas l'habitude de msil et qu'on souhaite faire un truc simple.
perso je me suis fait mon lot de classes et de process qui passe par la LCG, mais bon ils ont été écrits avant que je ne découvre les arbres de construction des lambda, et puis je viens du monde assembleur, alors le MSIL me dérange pas trop
Les lambda, c'est très sympa dans certains cas, comme obtenir le nom d'une propriété pour faire de la reflexion ... (voir les exemples qui sont dans le code de la DvP pour cela)
Une autre alternative aux lambda et la LCG c'est d'utiliser le célèbre CreateDelegate quand le besoin est très simple... un appel à un delegate sera toujours plus rapide qu'une invocation par reflexion, mais le createdelegate n'est pas possible pour une "activation".

effectivement, je viens de regarder aussi, le new T(), c'est une horreur