Low-code (2/2) : des technologies qui s'adaptent à cette tendance
Outre les plateformes low-code à proprement parler que nous avons évoquées, la plupart des technologies actuelles sont plutôt adaptées à une logique que l'on pourrait qualifier de low-code, en particulier les plus récentes.
Swift et SwiftUI
Le langage Swift permet de facilement transformer des objets JSON provenant des services web (et donc d’une plate-forme low-code) en objets exploitables dans le code, notamment grâce au protocole Codable arrivé avec Swift 4.
Certains se sont même amusés à contrôler leur interface à distance en utilisant du JSON côté serveur et SwiftUI (disponible depuis iOS 13) + Codable côté app. Parmi ceux-ci on trouve le célèbre développeur John Sundell, également connu pour être le contributeur principal de l’ancienne plate-forme low-code HubFramework de Spotify.
Want to see something *really cool*? ?
Since SwiftUI views are just plain old structs, they can easily be made Codable, which means that a view hierarchy can be decoded directly from JSON! ?
This is backend-driven UIs in <100 lines of code. Will publish all of it very soon ? pic.twitter.com/oEdA3ilnTb
Pleines d’avenir et, dans le même temps, promesses d’obsolescence accélérée. Je m’explique: toute application dépend d’une proportion toujours plus grande de composants logiciels externes, non maîtrisés localement, eux-mêmes dépendants d’autres composants et d’infrastructures colossales. Le nombre de maillons nécessaires à faire fonctionner la moindre application ne cessant d’augmenter, les causes de rupture potentielle augmentent de même.
J’ai connu quelques évolutions conceptuelles dans le logiciel (l’orienté-objet, les design patterns, de multiples frameworks, les L4G, les progiciels, etc.). Tous promettaient de diminuer la quantité de code à écrire, par une combinaison de réutilisation (d’architecture et de code) et/ou de génération de code. Les promesses étaient plus ou moins bien tenues mais, dans tous les cas, la fragilité a augmenté, le savoir s’est fragmenté (au lieu de maîtriser un langage, il fait en maîtriser 10 et autant de bibliothèques, d’API, de protocoles) — et surtout, beaucoup ont disparu (alors que j’ai encore des clients qui doivent maintenir du Fortran ou du Cobol).
Ces technologies sont en effet pleines d’avenir, mais surtout pour les applications qui en ont peu. On produit beaucoup, on jette presque autant. Je le vois même avec ma nouvelle chaudière, toute neuve, mais dont il a déjà fallu changer le thermostat connecté, plus maintenu un an après l’installation.
Tout à fait d'accord avec vous. on en arrive à des blocages d'application après un certain temps car tel module/composant extérieur n'est plus mis à jour/n'existe plus/a été vendu à une autre boite qui en a fait autre chose... et on arrive à voir des sociétés qui du jour au lendemain se retrouve 'bec dans l'eau' coincées et qui 'gueulent' contre leurs programmeurs que ca marche plus... Bien sur le programmeur ne sais pas quoi répondre/faire car il a perdu depuis longtemps la maitrise du projet à force d'utiliser des composants externes (et bien sur la perte de competances/savoir)... 'A oui ça a couté moins cher au départ.. mais bonjour le boomerang... Expérience vécue...
@Diamondsoftware
Entièrement d'accord avec votre commentaire.
Et le coût est immense si les développeurs doivent malgré tout trouver une solution/alternative dans des fonctionnalités qu'ils n'ont pas codées.
Non, je ne suis pas certain du bénéfice à long terme de ces solutions low-code. Pour une petite app de courte durée certainement, mais pas dans d'autres contextes plus professionnels (b2b).
@sigmanet15
merci.
le coût et le stress, la perte de temps qui pourrait être utilisé pour d'autres choses de plus utile...
Bien sur ça depend du projet... Si c'est pour faire une 'bricole' qui aura une durée de vie courte...
Dans mon cas je développe des softwares qui doivent fonctionner des années sans soucis... (industrie) et donc les derniers frameworks/composants on s'en (je vais plus tot dire je m'en) fou. Ca doit marcher avec le maximum de fiabilité sur de longues années... Mes premiers projets dans le secteur fonctionnent encore après 20ans et le client n'est pas pres de changer car ça correspond à son besoin et non à la mode du moment. Bien sur on améliore l'ergonomie et les fonctionnalités régulièrement mais on ne prend pas de technos à la mode et on essaye de faire le maxi en interne... C'est vital pour assurer un fonctionnement et une compatibilité à très très long terme.
@DahuLArthropode
Complètement.
L’important n’est pas tant la capacité à construire que la capacité à « démanteler » la solution logicielle tout en limitant les effets de bord.
Mais, en général, Apple fait bien les choses : la migration Objective-C vers Swift se fait sans douleur, idem pour la migration UIKit vers SwiftUI.
Par contre, quand on commence à intégrer des frameworks tiers, ça peut rapidement devenir difficile à maintenir. L’avantage, avec l’open-source, c’est qu’on peut maintenir soi-même le framework. Si on a les ressources à disposition, évidemment.
@DahuLArthropode
Expérience similaire. Constat parfaitement exposé🧠... y compris pour la chaudière.
Ben oui ... les couches basses, ça demande des compétences qui ne sont pas à la portée de n'importe qui, et ça coute beaucoup trop cher. Ce qui est fascinant avec le codage, c'est qu'après des dizaines d'années d'expérience, cette activité reste finalement mal comprise, et es processus pour la décrire ne font pas l'unanimité.
Je donne une anecdote (réelle). dans une vie antérieure, j'essayais de vendre des services d'amélioration du processus logiciel. Je tombe sur un patron qui me dit : mais moi c'est très simple, je vire les mauvais programmeurs ! (et effectivement, quand on connaît l'incroyable variabilité des performances des programmeurs ...).
Pour compléter votre super article je vous recommande de tester bubble.io, une plateforme no-code permettant de créer des web app complex sans code. L’outil est vraiment puissant.
@jeffapplefan
Merci !