(pour les non-tech, un LOCK c'est un mécanisme qui limite l'accès à une zone critique. Un seul accès à la fois, pour éviter de corrompre les données. A l'inverse des fichiers, les serveurs de DB gèrent cela automatiquement dans 99.9% des cas, sans intervention du développeur)
Alors qu'on discutait sous mon post "La base de données, un détail 🤔", quelqu'un indique qu'en startup on a peu d'utilisateurs, qu'une DB c'est donc overkilled, et qu'on peut utiliser un bête fichier... sans lock.
Si l'on aborde cela sous l'angle des risques, il a sans doute raison. La probabilité est faible que 2 utilisateurs parmi 10 touchent exactement la même zone critique exactement au même moment. L'impact est faible aussi : au pire on a mélangé ou corrompu les données de 10 beta testeurs, on cherche 10 nouveaux pigeons si les premiers n'acceptent pas nos plus plates excuses.
Sur le plan systémique c'est une autre histoire. Tout porte à croire qu'il s'agit d'une culture dev :
- Tu vas quand même pas mettre des backups pour 10 utilisateurs ?
- Tu vas quand même pas sécuriser l'API pour 10 utilisateurs ?
- Tu vas quand même pas gérer les cas d'erreurs pour 10 utilisateurs ?
- Tu vas quand même pas documenter ton code pour 10 utilisateurs ?
- Tu vas quand même pas respecter le GDPR pour 10 utilisateurs ?
Se cache ici l’un des angles morts du développement logiciel dans le sillage du Manifeste Agile depuis deux décennies. On peut chercher à y mettre des mots.
Le driver d'Agile c'est "fait vite". La recherche légitime sous-jacente, à savoir combattre l'incertitude par des itérations courtes et une confrontation avec le réel, se transforme en recherche effrénée de performance.
L'observation récente du vivant par le biologiste Olivier Hamant nous invite à réfléchir aujourd'hui : performance est surtout amie avec fragilité.
- Tu vas quand même pas être robuste ?
L'ironie du sort, c'est que les grands penseurs Agile comme Uncle Bob ou Allen Holub visent plus de qualité. Ils ont une culture systémique, une culture des risques, une connaissance et l'expérience de l'histoire (la majorité a 60 ans ou plus, ils ont tous connu l'assembleur, C, et COBOL). Les petites phrases cash qu'ils utilisent ("la base de données, un détail", "right first time, ça n'existe pas") se retournent contre les jeunes développeurs et créent dans bien des cas le manque de qualité contre lequel ces auteurs se battent initialement.
Dit autrement : si les itérations rapides d'Agile visent à découvrir les besoins utilisateurs, elles ne visent pas à redécouvrir qu'un manque de qualité se retourne toujours contre nous et nous ralentit. Ca on le savait déjà.
Comme aime à rappeler C.J. Date: "those who don't know history are doomed to repeat it". Parfois je me demande si ces autres auteurs prennent conscience que les jeunes développeurs n'ont simplement pas leur culture historique.
#SoftwareEngineering #Agile