Suivez le chemin de ce que je sais, puis essayez de mettre en œuvre des pratiques de codage correctes, ou commencez par de bonnes pratiques de codage et essayez de me frayer un chemin?

Tout d'abord, je tiens à dire que j'ai l'habitude de faire de la programmation procédurale comme passe-temps - j'essaie d'apprendre la POO dans quelques langues et de comprendre la théorie , mais pas la pratique.

J'ai un projet pour animaux de compagnie que je voulais construire, spécifiquement en PHP avec un backend de base de données (peu importe celui-là). Ma principale raison était que l'application devait être utilisée sur n'importe quel appareil, donc une WebApp semblait être le choix logique.

Je comprends que pour construire des WebApp PHP maintenables, il doit utiliser la POO, les classes, les frameworks, les bibliothèques, etc. Cela semble logique, alors je décide d'essayer quelques-unes des plus populaires. Cependant, après un week-end entier de simplement les essayer et d'essayer de passer à travers les tutoriels, je suis à la fois confus et frustré d'essayer d'adapter les tutoriels à mon petit projet.

J'ai décidé, principalement pour une preuve de concept, de créer l'application dans un autre programme (Microsoft Access), et j'ai atteint mes principaux objectifs en seulement quelques heures - à l'exception de la partie Web.

Ma question est, dois-je suivre le chemin de ce que je sais, puis essayer de mettre en œuvre des pratiques de codage correctes, ou devrais-je commencer par les bonnes pratiques de codage et essayer de me faufiler? Pour ce projet, j'aimerais qu'il soit Open Source sur GitHub, donc je serais ouvert à d'autres personnes utilisant et modifiant mon code, mais je sais aussi que si le code est mal écrit, il serait difficile de rassembler des codeurs pour aider.

Les meilleures pratiques sont principalement des suggestions et des propositions tirées de l'expérience pour faciliter la * réalisation des projets.

Les aspects clés de cette IMHO est la partie expérience. Bien que ces meilleures pratiques soient de bons moyens pour les personnes ayant plus d'expérience de les partager avec les débutants, je pense que l'on a encore besoin d'un niveau minimum d'expérience pour vraiment comprendre ce qui en fait une meilleure pratique. Faire autrement équivaut à les suivre aveuglément comme la règle de droit qui, à la fin, je pense, ralentira votre apprentissage tandis que vous laissez lentement les autres réfléchir à votre place.

Dans tous les cas, la chose la plus importante et la plus importante à faire dans un projet logiciel pour moi est ... eh bien ... finissez-le, expédiez-le ... bref faites-le fonctionner!

Tout ce qui précède est du vaporware, un fruit de votre imagination. Ce n'est qu'une fois que vous avez quelque chose qui fonctionne que vous pouvez vraiment évaluer s'il est lent, difficile à entretenir, difficile à tester, etc. Le processus de le faire fonctionner exposera des choses pour lesquelles, peut-être, il existe une meilleure pratique qui pourrait vous aider à repenser ce d'une manière qui facilite l'atteinte de cet objectif.

Alors oui, commencez par ce que vous savez d'abord, prenez note des choses que vous faites qui sont difficiles. Lorsque vous frappez un mur, reculez et regardez ce mur, apprenez de quoi il est fait. Dans de nombreux cas, vous vous rendrez compte que VOUS êtes à l'origine du problème. Votre manque de compréhension d'une partie du problème que vous essayez de résoudre, votre manque de connaissances sur la façon de mieux tirer parti des outils dont vous disposez ou votre ignorance des autres outils qui se trouvent sous votre nez tout le temps mais n'étaient pas prêts à commencer leur maîtrise.

En même temps, continuez à lire sur de nouvelles façons de faire les choses. Lisez ces meilleures pratiques et essayez de voir si elles s'appliquent à tout ce que vous trouvez difficile dans votre projet. Sinon, souvenez-vous de leur existence et revoyez-les de temps en temps. Reste curieux. Avec le temps, vous verrez que les observations faites ci-dessus ne font que cliquer naturellement avec les connaissances acquises ici.

Enfin, essayez ce que vous avez appris et voyez si cela simplifie les choses. continuez et finalement vous lirez les meilleures pratiques pour ce qu'elles sont. Juste de simples conseils de personnes qui ont souffert et ont appris un moyen de le rendre plus facile. Heck vous pouvez même être en désaccord avec certains d'entre eux et voir que votre chemin fonctionne réellement mieux pour vous. Mais sans le savoir, vous marchez simplement aveugle.

bonne chance

TL; DR

Vous ne saurez jamais tout. Il y a à peu près toujours plus de profondeur et d'étendue autour de chaque «chose» individuelle que vous pouvez savoir. Apprenez au fur et à mesure. Appliquez maintenant les "meilleures pratiques" que vous jugez pertinentes . Faire des erreurs. Essayez simplement d'éviter de faire des erreurs très coûteuses . Trouvez des mentors si votre projet peut entraîner des erreurs coûteuses.

Et maintenant, la réponse longue ...

1. "Un logiciel fonctionnel est la principale mesure du progrès." ( Manifeste Agile )

Si vous pouvez voir les limites de vos connaissances, c'est génial! Poursuivez les bords! Continue d'apprendre! Mais gardez à l'esprit que vous pourriez apprendre et analyser pour toujours .

Construisez quelque chose.

2. Apprenez et faites des erreurs; mais n'en faites pas de "mauvais". *

Continuez à repousser les limites de vos connaissances / compétences. Vous ferez des erreurs. Vous pouvez apprendre d'eux. Mais, vous n'avez pas besoin d'être téméraire .

Le temps que vous passez à trouver et à travailler avec des développeurs et des mentors plus expérimentés devrait augmenter proportionnellement à la valeur commerciale et au profil de risque du projet.

Si vous faites un peu CLI pour vous - même : faire fonctionner comme vous le souhaitez.

Si vous écrivez le portail Web d'une banque: entourez-vous de développeurs très expérimentés.

3. Les «meilleures pratiques» doivent être écrites entre guillemets et prononcées avec un clin d'œil.

Les «pratiques» sont promues aux «meilleures pratiques» quand on constate qu'elles réussissent à accomplir X dans au moins certains cas. Quelqu'un reconnaît les avantages de la pratique A pour la réalisation de l' avantage X et déclare que cette pratique est une "meilleure pratique" sur Internet. D'autres sont d'accord - souvent pour une bonne raison. Mais, à partir de ce moment-là, nous perdons généralement de vue pourquoi certaines pratiques sont des "meilleures pratiques" et d'autres sont soit "contre-modèles" ou "puantes".

Le problème est qu'une «meilleure pratique» n'est jamais égoïste. Les "antipatterns" ne sont pas réellement diaboliques en eux-mêmes. Et, même une "puanteur" ne vient que parfois de la pourriture. Parfois, cette puanteur n'est qu'un délicieux fromage de fantaisie ...

Vous ne pratiquez pas des choses comme «l'injection de dépendance» (DI) parce que «l'injection de dépendance» est intrinsèquement précieuse pour l'entreprise. Ce n'est même pas essentiel à distance pour construire un produit fonctionnel. Il accomplit quelque chose que vous souhaitez peut-être dans votre produit final. Mais, cela pourrait aussi rendre votre travail plus long sans aucun avantage ...

Hmm ...

Alors, devez-vous suivre les "meilleures pratiques"? Même si vous ne les comprenez pas? ... Euh ... oui. Je veux dire non. Mais oui. Mais, seuls ceux qui s'appliquent vraiment à vous et à votre logiciel et à son objectif.

Invoquez le POAP ! ^{(Ouaip. Mon blog.)}

Les principes, les modèles et les pratiques ne sont pas des finalités.

La bonne et correcte application de chacun est donc inspirée et limitée par un objectif supérieur et plus final. Vous devez comprendre pourquoi vous faites ce que vous faites!

(Le POAP n'est pas exempté du POAP.)

Ainsi, vous ne comprendrez peut-être pas toutes les nuances de DI, par exemple. Mais, si vous comprenez l'intention, vous saurez si vous "devriez" utiliser DI, et vous comprendrez implicitement mieux la DI.

Et, une fois que vous avez sorti le produit, vous pouvez vous demander si DI (ou quoi que ce soit) était vraiment bénéfique. Si oui, expliquez pourquoi par écrit. Sinon, expliquez pourquoi par écrit ...

Lecture bonus / Assez pertinent:

La paralysie de l'analyse est une chose. Vous devez analyser et apprendre; mais, vous devez également faire avancer les choses. Équilibre.

Vous pourriez toujours vous sentir comme un codeur de cow-boy .

^{* Vous ferez réellement de grosses erreurs si vous faites quelque chose de remarquable. Mais vous êtes humain, je suppose. Donc, nous vous pardonnons à l'avance ... Ou, du moins, je le fais. Peut être. ... Eh bien ... nous verrons.}

Ma question est, dois-je suivre le chemin de ce que je sais, puis essayer de mettre en œuvre des pratiques de codage correctes, ou devrais-je commencer par les bonnes pratiques de codage et essayer de me faufiler?

Peut-être faites de votre mieux mais expédiez toujours quelque chose? Il existe deux forces différentes entre la façon dont les utilisateurs évaluent la qualité et l'attrait d'un produit et la façon dont les développeurs derrière lui évaluent la qualité du code. Essayez de rendre ces deux forces aussi harmonieuses que possible. Se concentrer trop sur l'un au détriment de l'autre est généralement la façon dont vous vous retrouvez avec les itinéraires les plus contre-productifs.

Eh bien, tout d'abord, je dirais que l'adoption de bonnes pratiques de codage n'est pas fausse ... L'astuce consiste à comprendre le but de chaque pratique et comment la mettre en œuvre correctement.

Les environnements de développement d'applications rapides sont séduisants, car vous pouvez faire beaucoup de choses en très peu de temps. J'ai créé un système comptable complet dans Access une fois. Mais vous l'avez dit vous-même: vous ne pouvez pas mettre une application comme celle-ci sur le Web sans réécrire, et les outils dont vous avez besoin sont vraiment différents.

Il y a des raisons pour lesquelles personne n'utilise plus d'outils de conception visuelle comme Access ou Visual Basic. Ils ont tendance à vous isoler du code qui accomplit vraiment quelque chose. L'accès est un excellent outil, mais il nécessite précisément que les applications Web soient spécifiquement conçues pour éviter: l' installation. La personnalisation de son apparence peut être difficile; même si vous n'en avez pas besoin sur le Web, une application Access ressemblera toujours beaucoup à n'importe quelle autre application Access. La plupart des gens qui écrivent leur première application Access n'en savent pas assez pour écrire une bonne application, et Access facilite l'écriture d'une mauvaise application.

Alors maintenant, vous vous résignez à apprendre une nouvelle technologie pour obtenir votre application sur le Web. Devriez-vous le construire correctement dès le départ? Bien sûr. Mais apprendre un nouvel environnement de développement et une nouvelle philosophie, c'est comme apprendre toute autre chose; vous devez l'incliner pendant un certain temps pour bien faire les choses.

C'est pourquoi je pense que vous avez posé une fausse dichotomie. Personne n'apprend toutes les "meilleures pratiques" en premier. Ils les apprennent au fur et à mesure. Mais pour être productif dans n'importe quel langage de POO, je pense que vous aurez besoin de connaître un peu de POO, ou au moins comment les cours fonctionnent fondamentalement.

Pour ce que ça vaut, je ne pense pas que PHP soit votre meilleur choix. PHP est attrayant car il est "superficiel", ce qui signifie que vous n'avez pas besoin d'en savoir beaucoup pour écrire un programme de travail. Les meilleures pratiques sont laissées en grande partie au développeur, ce qui signifie que PHP ne va pas vous aider à écrire de "bons" programmes. Ce n'est pas nécessairement une mauvaise chose, mais cela signifie que, comme Access, vous pouvez éventuellement abandonner PHP pour une plate-forme plus robuste.

Considérez la POO comme un autre modèle que vous pouvez appliquer au bon moment. La POO n'est pas un cadre capable de résoudre méthodiquement chaque tâche. Une telle chose n'existe pas en génie logiciel.

Notez également que ce que les gens prétendent être de bonnes pratiques est parfois discutable. J'ai souvent vu des développeurs inexpérimentés adopter des modèles de programmation très compliqués qui n'étaient pas nécessaires pour le problème donné. La complexité du code doit être adaptée à la complexité du problème. La simplicité est une valeur importante.

Les articles sur le Web, les déclarations d'experts de l'industrie et les conseils de collègues seniors peuvent être faux. J'ai beaucoup vu ça.

Par conséquent, je vous recommande d'appliquer la solution la plus simple qui résout votre problème. Probablement, cela englobera l'utilisation de l'un des cadres populaires de votre espace. Dans cette contrainte, vous pouvez choisir librement le type de code que vous aimez. Ne pensez pas simplement que leur façon de procéder est appropriée pour votre cas.

Comprenez également pourquoi certaines techniques sont recommandées. Par exemple, la POO concerne l'encapsulation. Vous pouvez encapsuler d'autres manières (les procédures concernent également l'encapsulation).

Un exemple négatif: Parfois, les gens écrivent une couche d'accès aux données pour résumer la base de données. Ici, l'essence de ce modèle est de devenir indépendant du magasin de données concret et d'exposer une interface plus simple à des couches de code supérieures. Mais si vous n'avez pas besoin de ces avantages, vous n'avez pas besoin d'une couche d'accès aux données et vous pouvez enregistrer le travail. Pourtant, de nombreux experts recommandent de toujours faire un DAL qui est une recommandation incorrecte.

Je trouve que le bon code est souvent amusant à travailler. C'est amusant parce que vous travaillez sur les besoins réels au lieu de vous préoccuper des problèmes d'infrastructure. Si vous trouvez que ce que vous faites est trop de travail de grognement, alors vous avez probablement choisi le mauvais ensemble de modèles.