• [^] # Re: Usine

    Posté par . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 4.

    Tu peux développer ? Notamment au niveau de ce que tu appelles "outils de base" ?

    Ca va être extrêment grossier donc pas très intéressant et sujet à dérive.

    Pour le SE basiquement le langage, entre Java 5 et Java 7, est mort. Il y a eu d'énorme loupés dans le design de lib standard et des collections qui ne sont pas corrigés par soucis de backward compatibilité et qui forcent à mélanger 100 bibliothèques qui font la même chose (bonjour commons, guava & les amis). C'est assez pauvre en ADT. L'interaction avec les systèmes hôtes est ridicule. Pour prendre l'exemple le plus grossier il a fallut attendre fin 2011 pour avoir un accès basique aux fichiers.

    Note que je ne dis pas "Java c'est nul". Je dis que c'est un langage moyen qui n'évolue plus mais qui est sauvé par d'excellentes boîtes logicielle et son outillage. J'ai certainement une vision biaisée par rapport à pas mal de dev Java qui font majoritairement de la webapp ou du webservice sans "gros code métier" hormis jouer avec une DB. On en revient à l'usine logicielle.

    Pour un langage compilé qui a une longue histoire, je trouve que Java évolue plutôt vite et dans le bon sens.

    Sur le langage il ne s'est absolument rien passé de notable entre Java 5 et Java 7. A voir si Oracle relance la machine…

    Ce n'est pas parce qu'on peut en faire mauvais usage que c'est un mauvais outil.

    Je n'en ai encore jamais vu un bon cas d'utilisation.

    Les outils peuvent être pratique. Mais les balancer dans une webapp ca n'a que peu d'interet. Les gens qui sont dans le code seront beaucoup plus productif à intégrer les outils dans leur environnement de dev. Les gens qui ne sont pas dans le code c'est pas leur soucis. Si ils en arrivent à trouver des problèmes avec Sonar ca à dérapé depuis bien trop longtemps. Ce n'est pas un outil qu'il te faut c'est revoir complètement ton équipe et son organisation.

    il se passe quand on n'est pas dans le code au quotidien.

    Si tu n'es pas dans le code c'est le rôle de ton tech lead de faire ce genre de chose. Tu cherches à faire quoi en regardant le Sonar ?

    C'est une bonne idée, ça. Tant qu'à faire, le mieux est de bloquer le build sur chaque problème, comme ça, chaque build devient une aventure.

    C'est juste le principe de l'intégration continue: détecter et fixer les problèmes au plus tôt. Si le code est mauvais (c'est bien le but de Sonar non ? ) il ne passerait pas une code review et ne serait jamais intégré à la branche de dev. Là il a déjà été intégré donc tu échoues ton build comme tu le ferais pour un test qui ne passe pas et tu corriges maintenant. Pas dans 9 mois. Si ce n'est pas si important que ca à quoi servent les mesures et les règles mises en place ?

    Si tu fonctionnes par patch et par code review tu peux même le faire en avance. C'est ce que font la plupart des projets Apache par exemple. Quand tu attaches un patch au bugtracker le robot fait passer un build et compare son résultat par rapport au dernier build. Il donne un +1 ou -1 pour chaque mesure. Le code n'est pas intégré tant que c'est pas vert ou que quelqu'un décide manuellement que c'est ok quand même.

    Dire que c'est "la dernière chose dont tu as besoin" est volontairement provocateur qui vient contrebalancer le "Sonar youhou c'est super". Mais je pense vraiment que si tu cherches à produire du soft de qualité c'est effectivement très très très loin sur ta liste de priorité que tu
    sois dev, development manager ou project manager. Il y a tellement d'autres choses qui paient 1000x plus avant.