Coder à la main c'est ringard ?

Bonjour,

je me pose cette question de plus en plus avec la charge de code à développer pour que les sites soient accessibles depuis n'importe quel support (supports qui se multiplient à une vitesse sans précédent). Je code à la main depuis 10 ans, j'avais bien commencé avec FrontPage (je suis vieille c'était dans mes années collège/lycée) et Dreamweaver quand il n'appartenait pas encore à Adobe. Aujourd'hui c'est Brackets avec les extensions qui vont bien avec...

En allant faire un tour sur Adobe CC qui me fait salement de l'oeil pour mon travail en UI/UX (gain de productivité décuplé !), j'ai pu voir que des logiciels ont émergés comme Muse, Edge, Dreamweaver toujours là. Je me souviens de Dreamweaver à l'époque où il inventait des codes originaux qui "salissait" l'ensemble. Je ne sais pas trop ce qu'il en est aujourd'hui...

Pour le responsive je m'aide bien des frameworks mais est-ce qu'on a pas encore loupé le coche avec d'autres outils aussi performants (lesquels?) que notre clavier et permettant de gagner en productivité ?

Ouala pour le p'tit débat du jour

Perso, si tu veux développer du code sur mesure, tu auras pas le choix de coder à la main.

Pour le responsive, j'utilise bootstrap, mais il faut coder manuellement.

Après, chacun à ses logiciels fétiches ...
Modifié par Tintin75 (27 Oct 2016 - 11:09)

Salut,

Je préfère personnellement développer front scratch, je trouve qu'on a beaucoup plus la mains sur l'enssemble de l'application qu'avec un CMS ou autres choses.

Bien sûr il existe différents framework permettant à nous les développeur d'aller "plus vite" (tout est relatif) et aux non développeur (comme ma copine) de faire un site vitrine ou e-commerce. Je pense pas que codé "à la main" soit ringard.

Par exemple, la majorité des templates wordpress d'aujourd'hui sont responsive, mais attention aux non développeur si il veut rajouter une colonne ou autres ! non, il ne pourrat pas, car il connait pas la programmation. Il devrat se contanter aux limites du template choisie (qui proposera j'en suis sûr un maximum de choses).

et .... le CSS3 et HTML5 sont tellement puissant que rien ne remplacera la qualité et la sécurité quand on fait les chose correctement et en se basant sur un modèle propre.

Bonjour,

coder à la main n'est certainement pas ringard. Réinventer la roue à chaque projet, peut-être bien... Mais c'est plus une question d'efficacité et de pertinence que de mode
On a simplifié le problème en préparant notre propre kit de départ à l'agence : Bretzel (node, gulp, sass, git sont utlisés mais il m'a fallu peu de modifs pour repasser à LESS pour un projet embarquant Bootstrap 3).

Des outils créant du code tout fait, je n'en utilise sans surprise pas (si ça convient à une équipe/entreprise, elle ne s'adressera probablement pas à alsacreations.fr pour une mission de ce type) mais par contre des outils j'en utilise de plus en plus : linter, compilateurs et optimiseurs de tous poils via PostCSS et gulp ou grunt, ah Autoprefixer s'il ne fallait en garder qu'un <3
Même une colorisation syntaxique correcte est un "outil" puisqu'il permet de détecter un problème immédiatement (ou aide à le détecter).
Par opposition non pas à "coder à la main" mais coder à l'arrache : on a de nombreuses conventions dans plein de domaines : je peux ouvrir un fichier Sass créé par ma collègue et je ne serai pas surpris par la forme et la manière de faire. Il faudra toujours que je comprenne le contexte du projet mais ça sera tout. Et avant ça, j'aurai su ce que signifient les branches git utilisées, laquelle choisir, dans quel répertoire X trouver les fichiers de type Y, etc

On est donc d'accord sur le fait que pour le moment les logiciels ne permettent pas de faire des sites efficaces sur-mesure Bon ça m'arrange j'aime bien le côté artisanat du développement en démarrant d'une feuille blanche ! Maintenant heureusement que Brackets ou Sublime Text offre des extensions qui améliorent notre prod. avec des raccourcis clavier idéaux. Personnellement, j'ai trouvé le bon compromis avec LiveReload qui m'offre en temps quasi-réel mon interface.

Ah mais quelle belle discussion que voilà

je plussois le codage "à la main" il est évident que c'est plsu souple...

Pour autant à force de coder à la main on a beaucoup de code "déjà fait" et avec un peu de méthode on gagne du temps

pour ma part pour aller dans le bon sens, et parceque je code à la main depuis plus de 15 ans, je suis enfin arrivé à une solution "efficace"

le modèle MVC, si tu ne concerve que le concept est un gain de temps précieux

donc des classes (largement réutilisable en l'état) le modèle
des cores php qui sont là pour prendre les infos et les coller dans le template : le controller
et des templates (avec un moteur de templates) les vues.

Au final on modifie un chouilla les cores parceque chaque site affiche ce qu'il a besoin et on modifie bien évidemment les templates (sinon on ferait toujours le même site avec le même look)
les classes elles ne sont que rarement modifiées au mieux compléter ou améliorées mais jamais de changement fondamental

du coup on gagne beaucoup de temps.

vive le codage à la main

Je rejoins les commentaires précédents... coder à la main n'a rien de ringard et c'est, à mon sens, le meilleur moyen de maîtriser HTML / CSS / Javascript.
Ceci dit, cette forme de développement se heurte vite à la dure réalité des projets, dès lors que le nombre de pages à produire dépasse l'unité et qu'on souhaite adopter une présentation graphique identique pour l'ensemble du site web à générer.
Le recours à un atelier logiciel externe est alors quasi incontournable, pour d'évidentes raisons de productivité :
- Jekyll ou autre, pour la production de sites statiques
- PHP / Wordpress, Joomla, etc. pour des sites dynamiques
le tout assis sur des librairies diverses et variées telles que JQuery, etc.
Il existe toutefois une voie médiane consistant à dire :
- je veux garder la maîtrise totale de mon code HTML / CSS / javascript
- capitalisons sur le savoir faire acquis
- automatisons la production du code à partir de classes C#, Java, Python ou autre langage de programmation
Cette dernière approche est plutôt celle de programmeurs stricto sensu, aptes à concevoir / développer dans un / des langages de programmation orientés objet autres que PHP.
Très puissant... mais ardu et nécessitant un large panel de compétences.
Par contre, c'est "le pied"

Pour ce qui est du front je suis d'accord que ça peut se faire à la main. Mais tout ce qui est développement serveur c'est pas très pérenne pour les clients. Demain si vous fermez boutique personne ne voudra retravailler à partir du code que vous avez fait car il y aura trop d'incertitude quant au temps à passer ou trop d'investissement de compétences à faire.

«Coder à la main» n'a pas beaucoup de sens. Rédiger une page en HTML sur un editeur de code et la poser sur un serveur Apache pré-configuré est-ce coder à la main? On est tellement habitué à nos outils de base qu'on oublie qu'ils sont là.

Dans les métiers qui touchent à l'informatique on travaille par couche. Personne aujourd'hui ne crée de site web avec des couches bas niveau (en C par exemple) sans librairie et en créant eux-même leur serveur de fichiers (en cherchant bien on doit trouver un ou deux illuminés dans le monde). On utilise principalement des languages de script (php, javascript) et de description (HTML) qui se trouvent en quasi fin de chaîne. Dès lors il est difficile de parler de «à la main».

Après il est évident qu'on a de la marge de manœuvre sur la possibilité d'ajouter une ou deux couches. Cependant sur ce site, on réunit des gens qui vont de celui qui crée son petit site en dilettante à des professionnels qui gèrent des parcs de centaines de sites au sein de grandes équipes. Il est évident que les besoins et les solutions sont radicalement différentes. Je ne conseillerai jamais à un amateur qui fait son petit site vitrine pour son activité d'utiliser moults frameworks et librairies, versioning, déploiement auto et systèmes de builds. Tout simplement parce que comprendre, configurer et maintenir tout ce bazar lui prendra dix fois plus de temps que de s'occuper de son site à proprement parler. À l'inverse, dans une boîte et en équipe, certains éléments de ces workflows sont une évidence et ne se discutent même pas.

Chaque couche ajoutée a des avantages (rapidité de codage, uniformisation des pratiques, alertes/logging, travail d'équipe, etc.) mais toujours un coût: maintenance, apprentissages, ressources machines, compatibilité, etc. La réelle question est donc de définir ses besoins et de placer le curseur selon.