Qui a dit que le DDD et le logiciel en général ne pouvait être composé que de classes, d’héritage, et qu’une modélisation sans comportement était forcément un modèle anémique, un anti-pattern par définition ?
Aujourd'hui, je vais te montrer les pires bouts de code que j’ai jamais vus. Des sataneries qu'il ne faut surtout pas produire !
Par personnellement, mais j'ai vu ça en coaching d'équipes.
Fuir est une option rapide.
Défendre sa cause est plus long et plus impactant sur à terme. Mais il faut en avoir la patience et l'envie.
Si tu aimes le côté évangéliste, c'est intéressant à faire. Si tu veux juste coder dans de bonnes conditions, tu as probablement plus vite fait de changer d'environnement.
Je n'ai pas pris la peine de défendre mon point de vue car je suis le principal développeur. Les personnes opposées étaient les chefs de projet, qui ne touchent que très ponctuellement au code... et qui étaient beaucoup intéressées à définir la place de l'accolade pour le "if" (retour à la ligne ou pas ?! ça c'est un grand débat !)
C'est quoi la modélisation d'une architecture logicielle à l'aide du modèle C4 ? Je connaissais bien UML et l'outil qui va avec Enterprise ...
Cela permet d'avoir une méthode de communication claire et lisible, facile à lire même pour les développeurs débutants !
UML est un outil qui peut se révéler complexe, mal maitrisé cela peu apporter de la confusion.
Rien n'empêche de mixer les deux par ex: utiliser C4 Model et réserver UML aux cas les plus avancés :)
Être efficace en télétravail passe par une modification de la culture d'entreprise. Dans cet article nous étudierions les outils de communication
Une organisation tellement a contre courant qu’elle vaut le coup de s’y intéresser de près !
GitLab aussi a une organisation assez atypique.
Un retour d’expérience riche d’un CTO dans une startup en pleine croissance.
A lire pour tous ceux qui sont attirés par un rôle de lead, que ce soit tech lead ou CTO.
Est-ce que c’est une carrière qui attire ?
Disponible pour en discuter avec plaisir !
Les 3 conseils à mettre en place pour passer d'un travail classique à un job en remote
C'est un talk que j'ai découvert de Codeur en Sein qui parle de comment passer d'une architecture MVC vers une architecture clean/hexagonale.
Pour approfondir, je pense que tu trouveras des gens intéressés par ces questions sur le slack de Wealcome de Michaël Azerhad.
join.slack.com/...
Salut à tous,
Ton site est intéressant. Je trouve aussi que c'est compliqué de trouver du travail en remote. Les catégories (js, ruby...) sont-elles prédéfinies ?
Par exemple, je suis intéressé par du C++ et il n'y a pas cette catégorie.
Prévois-tu de rajouter une boîte de recherche pour filtrer les résultats en fonction de mots-clefs ?
@Marc: Oui c'est prédéfini, j'ai mis les langages sur lesquels j'ai des offres pour l'instant. Mais ça rejoins le com' de Damien, un champ recherche!
Je ne suis pas forcément fan des entretiens techniques dans lesquels on pose des questions d'algorithmiques surtout lorsque celles-ci n'ont aucun rapport avec le poste en question. Malheureusement, c'est une réalité, de plus en plus d'entreprises font passer ce genre d'entretiens aux candidats et ce n'est plus exclusivement réservé aux FAANG. J'ai donc décidé pour cette année de commencer une série d'articles concernant les questions d'algorithmiques les plus fréquemment posées en entretien. C'est également une bonne occasion de (re)découvrir les bases de notre métier qu'est l'algorithmique et la résolution de problème. Pour ce premier article, j'ai décidé de commencer avec les listes chaînées qui sont l’une des structures de données linéaires les moins maîtrisées par les candidats contrairement aux tableaux.
De là en découle une complexité en temps et ou mémoire.
Cela permet de prévoir et prendre les bonnes décisions quand la volumétrie et/ou le nombre d'utilisateurs augmente.
Et quand ca déborde sur une architecture simple malgré les bonnes optimisations, on repense une archi plus complexe qui puisse répondre aux nouvelles contraintes.
C'est donc la base à maitriser pour aller plus loin.
EDIT: le temps que j'écrive, d'autres réponses ont popé ^^ Je répondais exactement à la même phrase que Benoît "il vaudrait mieux faire gagner du temps à tout le monde et poser des questions pertinentes pour le poste"
Je partage votre point de vue. Je n'ai rien contre poser une question d'algorithmie, de complexité... si la question sert à un échange. Ce qui me gène plus c'est refuser des candidats sur le seul principe d'échouer à répondre à ces questions.
Bon pour la liste chaînée ayant été formé sur le C je suis biaisé et considère que ça fait parti du minimum culturel pour un dev. Mais mettons que ce ne soit pas le cas. Refuser un candidat parce qu’il ne réussi pas à implémenté une liste chaînée parce qu’il ne sait pas ce que c'est et n'en a jamais vu de telle implémentation c'est dommage. Discuter avec lui, l'aiguiller sur une piste et ce rendre compte qu'en reformulant le problème il arrive à implémenter une solution par liste chaînée, c'est mieux.
Après ça dépend de l'objectif de l'entretien aussi. Si on veut des gens très pointus sur tout ça fait un bon filtre.
Pourquoi devrais-je l'étudier selon toi ?
En plus d'être très bon dans son domaine (no pun intended !), c'est un super pédagogue qui sait expliquer simplement des concepts compliqués sans les vulgariser/dénaturer.