Débat sur le développement

Mouai, je suis plutôt perplex, moi je dirais que ça dépend des projets

Pourquoi pas les deux ? De toute manière tu généreras de la dette technique car le seul moyen de ne pas en générer, c'est de ne pas faire de code. Ca peut faire partie d'un principe qui revient à ne pas coder ce qui n'est pas essentiel dans un premier temps.

Surtout que si tu pars sur du code "pas très propre" comme tu dis, il y a une théorie, celle de la vitre brisée qui te donnera moins envie de mettre du code "pas très propre" dans du beau code (Même si c'est subjectif), un peu comme dans des toilettes publiques (Si vous voyez de quoi je parle).

Si l'on applique quelques principes de design comme SOLID, DRY et KISS, on peut arriver à avoir du code propre, concis, qui fait ce qu'il doit faire et uniquement cela et qui du coup arrive à être propre, testable, etc ou peut le devenir plus facilement lors d'un sprint visant à rembourser une partie de la dette technique. Cela fait certainement perdre du temps à l'apprentissage, mais qui sera très vite remboursé, car vous pourrez l'appliquer à vos autres projets mais également quand vous devrez modifier votre code.

Je ne pense pas que ça soit soit l'un sois l'autre.
Ceci étant dit :

Un code pas propre mais fait rapidement, permettra peut être d'avoir un projet rapidement en place. Mais le code n'est pas maintenanble et le temps que tu as peut être gagné sera complètement anéanti. Si le code est vraiment sale une simple mise à jour entrainera peut être une refonte total du site

Un code propre mais plus long, le code sera plus facilement à maintenable du coup évoluera mieux dans le long terme. Le code propre te permettra de gagner un temps considérable lors du debug aussi.

Enfin, j'insiste sur ce point, développer plus proprement n'est pas forcément plus long. C'est plutôt le contraire je pense, pour moi code pas propre = plus lent à dev ^^

Si tu veux coder quelque chose rapidement, fais le bien : comme avec le prototyping ou la production de MVP (minimal viable product).
Y'a un moment, tu vas devoir faire un choix :

A. Je code comme une m##de toute ma vie et finalement je ne suis pas un développeur professionnel mais bien un bricoleur.
B. Je code comme un grand c'est à dire créer des scripts informatiques de haut niveau qui sont fonctionnels, compréhensibles, testés et réutilisables.

Après ce n'est pas toujours ton choix. Je prends l'exemple de mon ancienne boite : toujours coder dans l'urgence, jamais rien tester et limite ne pas utiliser de système de versionning... Quand je vois mon premier projet qui n'est toujours pas terminé après un an et demi alors qu'il a été vendu pour deux mois. Niveau rentabilité, on a déjà vu mieux ;-)

Et pour ceux qui ne documentent jamais leurs code, et je ne parle pas QUE de commentaires, les noms de variables c'est pas pour les chiens, arrêtez par pitier ou reconvertissez vous :(

Si vous vous reconnaissez dans ce post, je m'en excuse par avance. Ce n'est pas méchant, mais renseignez-vous sur les techniques actuelles. Sérieusement.

Ca fait du bien de se lâcher après deux ans de supplice :'D

C'est vrai que les variables $data et $array ont souvent bon dos haha ^^

$data tu peux t'en servir, mais à condition de bien t'en servir, par exemple uniquement dans le cas d'insertion dans la base de donnée. Au moins ça reste compréhensible :)

Bonjour.
Un code pas très propre mais fonctionnelle rapidement ou un code très clean mais qui prend du temps à la production
Pour ma part, je dirais un code plutôt clean, car dans le cas où un autre développeur doit intervenir dans le code, il sera plus facilement lisible et compréhensible, que ce soit au niveau de l'indentation du code, que du choix des noms de variables ou autre (je ne veux pas dire d'une manière précise pour le nom des variables, mais au niveau général, que leurs noms aient un minimum de rapport avec leur utilisation).
Je ne sais pas si vous voyez ce que je veux dire exactement, mais bon, nous ferons comme-ci c'était le cas.
Et comme l'a conseillé Jonathan dans plusieurs de ces tutoriels vidéos, penser à commenter un minimum certaines fonctions ou parties de codes qui pourraient le nécessiter.
Et tout ça, ce n'est pas spécialement long, donc autant coder "proprement". :)