Un retour d'expérience sur le développement d'un jeu, 1 an et demi après.

Voici le retour:

Microservices vs. Monolithe n'est pas la question: dans tous les cas, votre soucis le plus immédiat est d’isoler les composants chacun derrière des interfaces publiques clairement définies. Avoir un binaire par tâche ou plusieurs dépend en réalité du nombre de personnes et d'équipes qui travaillent sur le projet.

À voir le projet gRPC afin de faire communiquer les différentes interfaces. Pourquoi gRPC ? Pour générer automatiquement le code d'un service lorsque celui-ci se content d'exposer des méthodes CRUD sur une simple entité dans une base de données SQL.
Qui finalement s'est révélé moins pratique à la longue lorsque les requêtes se sont complexifiées.

Contrairement au dicton qu'il ne faut pas réinventer la roue, certaines valent mieux être réinventée. Ici:

• l'ORM gorm par une bibliothèque plus bas niveau: sqlx
• testify remplacé par rien

Finalement, ce n'est pas une réinvention, mais un débarras de surcouche en complexité.

Le mantra d'E.W. Djikstra:

Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?

la maîtrise du problème est beaucoup plus importante que la solution qu’on lui apporte

Concernant les tests: l'auteur recommande le TDD pour développer ce qui est utile uniquement.

Enfin il s'agit surtout de maîtriser le problème afin de parvenir à une excellente solution.

Guidelines:

• make small changes in each PR
• precommit hooks
• pair programming

Guidelines:

• don't make it personal
• don't fall in love with your code
• reviewer is not alwyas right
• Do make sure the why
• Do make your own comments

The first rule of thumb:

If you’re stuck for over an hour, seek help.

with

When you seek advice, first write down everything you’ve tried.

that as 3 benefits:

1. act as a rubber duck debugging
2. evidence that there is some kind of structured thought process that has been carried out, and what it was
3. saving time explaining the context to someone else

If this is not useful enough, the author recommends to use his formula.

Why this post ?

The software industry is filled with a chaotic mess of a developer experience. Everything and anything can break.

🤣😭

If you figure out something fun, and integration that otherwise wasted an hour or two. Find ways to document it. On StackOverflow or on your blog or what have you. Just do that. Many developers including your future self will thank you for that.

So does this implies writing question and posting your own answer ?

About data structures, immutable and mutable data, programming model, public interface, distributed system, always having a limit for everything and trust your gut.

Je veux être fier de mon travail. Je veux fournir des choses qui fonctionnent, qui sont stables. Pour faire ça, il faut que l’on comprenne ce que nous faisons, à l’entrée et à la sortie, et ça ne peut pas se faire dans un système fourre-tout avec autant de surcouches.

👍‍ pour tout ce qui est énoncé dans ce billet de blog

1. De quoi parle-t-on ?

l’architecture micro frontend c’est faire d’une application web front-end un ensemble d’applications indépendantes (cycle de vie, complexité, technologie) cohabitant et communiquant sur le même site.

2. Concrètement, pourquoi faire ?

3. front + front = front ?
   Technologies pour les construire:

   1. Web Components
   2. Node.js / Express / EJS
   3. Framework Single SPA

4. Comment les applications communiquent entre elles ?

   1. Attributes et properties
   2. DOM / Custom Events
   3. Solution de state management
   4. sessionStorage / localStorage / cookies

5. Quelle stratégie de tests utiliser ?

6. Ai-je vraiment besoin des micro frontends ?

Hey, on m'a assigné des bugs à corriger sur ton dernier projet, mais j'ai l'impression qu'il n'y a pas de documentation ?
Hein ?
Bien sûr qu'il y a de la doc. Il y a des infos dans des readme, et des éléments sur le Jira. Ou alors c'est dans le Trello. En plus, on a mis des infos sur des Google Docs dans un dossier partagé, regarde si t'as les droits. Même si c'est pas à jour c'est utile. Et, au pire, il y a plein de commentaires contextuels dans le code...
Bref, c'est bien ce que je disais... y a pas de doc

in-house expertise is needed at some point.

Advices for open source projects:

• don't make promises
• don't try to compete on anything
• just describe what it does now and have fun with it

An not ending mess as we know it. This may improve in the future though...

Tout peut s'écrire sous forme de fonction quoi !

with examples

With software development, though, mistakes are free! If we make a mistake, we can tab back to our editor, change the code, and try again. We even have helpful error messages that can (sometimes) point us in the right direction. This is an incredible luxury, and not one that we take advantage of enough.

I should the "learn in public" philosophy as it could fit what I want to do :)

Il fallait le faire 🤣

Every time I learned a new PC programming language, the industry changed. It made it impossible to keep up wit hthese changes.

Tips:

• While you should keep up with the computer language changes, it is nearly impossible to do so. [...] go onto the major job sites and search for a current language and see how many jobs are out there. This would be a barometer to see what languages are current.

(or if you want to learn a language for fun, do it.)

• The second piece of advice is to find a few people in the companies you work for and keep in touch with them even if they leave the company.

Outside of technology, the world prefers stability

Similarly, the engine controller in cars, and medical devices like pacemakers and insulin pumps, are running on C. They don’t run on C because C is a good language with all the latest features, they run on C because the risks and mitigations for issues in C programs are well-understood and documented as part of MISRA C.

Comis about IT topics

A dev / hacker community and platform