Observations sur le développement et le déploiement chez StackOverflow

Article surprenant sur le développement et le déploiement chez stackoverlfow. Quelques points que j’ai relevé :

Garbage collection driven programming

Ceci inclut de se dispenser de TDD (on peut comprendre), d’éviter des couches d’abstraction (cette manie de la programmation en lasagnes doit cesser), et d’utiliser… des méthodes statiques, même si cela n’est pas très catholique ou orthodoxe O.O. Pour des raisons de performance.

Ce dernier point me fait froncer les sourcils. Le langage utilisé, C#, est-il un bon choix si son mode d’écriture usuel pose des soucis de performance? Passer systématiquement par des méthodes statiques ressemble à forme d’optimisation prématurée. Mais on peut s’imaginer que cela renforce au moins la cohérence de style (tout est statique plutôt qu’un mix).

Do only what needs to be done

Très peu de tests unitaires et autres parce qu’ils déploient fréquemment et préalablement sur meta.stackexchange, qui leur sert de site de tests d’acceptance et que leur communauté leur remonte rapidement les bugs, avant de déployer sur SO à proprement parler.

Étrange postulat. Bien sûr, une éventuelle erreur sera rapidement détectée par leur communauté, mais pq la laisser se propager aussi loin? Comment avoir une grande confiance dans le code écrit si la couverture en tests est lacunaire? Juste en le relisant? Quid en cas de modification majeure? Cela semble marcher pour eux. “You Aint Gone Need It really works” disent-ils, poussé à l’extrême, rejetant non seulement le “TDD” mais carrément les “T”.

No bureaucracy

“There’s always some tools your team needs.” Quand je pense aux entreprises qui choisissent Eclipse “parce que IJ est payant” ou dans lesquelles la moindre licence à 50€ exige de suivre une procédure d’approbation dont le coût interne réel excède celui de ladite licence, quand ce n’est tout simplement refusé parce que “ce n’est pas standard” dans l’entreprise, je me dis que je ne délire pas en me tenant à l’écart.

Go down to the bare metal

Ils descendent au niveau “IL”, en quelque sorte le bytecode en .Net. Conséquence logique d’une focalisation extrême sur les performances. Pas le genre de chose qu’on rencontre sur un projet usuel en entreprise.

Lire aussi : les morceaux des powerscripts utilisés lors du build (ça vous change de maven), les machines surdimensionnées avec pour conséquence l’inadéquation d’Amazon EC2 qui serait hors de prix, le culte du SSD, …