Je voudrais ajouter une réponse à cette question car j'ai parcouru récemment du bon, du mauvais mais surtout du laid Java et j'ai une toute nouvelle charge de sur-généralisations brutes sur les développeurs Java et Java par rapport à JS et Les développeurs JS qui pourraient en fait être basés sur quelque chose ressemblant vaguement à une vérité utile.
Il y a des IDE mais il peut être utile de comprendre pourquoi il n'y en a pas eu beaucoup
J'ai essayé Webstorm maintenant que je suis attiré par le développement de Node et ce n'est pas assez mal que je l'ai acheté, mais j'ai toujours tendance à ouvrir les fichiers js dans Scite plus souvent que WS. La raison en est que vous pouvez faire beaucoup plus avec beaucoup moins dans JS, mais aussi parce que le travail de l'interface utilisateur donne un retour immédiat, les outils de développement du navigateur (Chrome et Firebug en particulier) sont en fait assez excellents, et (tenant compte des contextes non-navigateur ) la réexécution du code modifié est rapide et facile sans étape de compilation.
Une autre chose dont je suis assez convaincu est que les IDE créent essentiellement leur propre demande en activant du code bâclé que vous ne pouvez vraiment pas vous permettre en JavaScript. Vous voulez savoir comment nous gérons dans JS? Il peut être utile de commencer par essayer d'écrire quelque chose de non trivial en Java sans IDE et de porter une attention particulière aux choses que vous devez commencer à faire et à penser afin de pouvoir réellement maintenir / modifier ce code sans qu'un IDE ne bouge. vers l'avant. OMI, ces mêmes choses sont toujours essentielles à l'écriture de code maintenable, que vous ayez un IDE ou non. Si je devais écrire un programme de programmation de 4 ans, cela ne vous laisserait pas toucher à un IDE pendant les deux premières années dans le but de ne pas tordre les outils et les dépendances.
Structure
Les développeurs JS expérimentés traitant des applications complexes peuvent et peuvent structurer leur code. En fait, c'est une chose que nous avons tendance à améliorer avec une histoire ancienne qui manquait d'IDE pour lire le code pour nous, mais aussi parce que les langages puissamment expressifs peuvent exprimer très rapidement des bases de code de catastrophe complètement ingérables très rapidement si vous ne codez pas de manière réfléchie.
J'ai en fait eu une courbe d'apprentissage assez abrupte dans la compréhension de notre base de code Java récemment jusqu'à ce que je réalise finalement que rien de tout cela n'était une bonne POO. Les classes n'étaient rien de plus que des ensembles de méthodes vaguement reliées modifiant les données disponibles à l'échelle mondiale dans des beans ou des DTO ou des getters / setters statiques. C'est essentiellement la même vieille bête que OOP était censée remplacer. J'ai donc arrêté de chercher et de penser au code en gros. Je viens d'apprendre les touches de raccourci et j'ai retracé les dégâts et tout s'est bien passé. Donc, si vous n'avez pas déjà l'habitude, pensez beaucoup plus à OOD.
Une application JS bien structurée au plus haut niveau aura tendance à se composer de fonctions complexes (par exemple jQuery) et d'objets interagissant les uns avec les autres. Je dirais que la marque d'une application bien structurée et facile à entretenir dans n'importe quelle langue est qu'elle est parfaitement lisible, que vous la regardiez avec un IDE ou Notepad ++. C'est l'une des principales raisons pour lesquelles je suis très critique à l'égard de l'injection de dépendances et du TDD test-first poussé à l'extrême.
Et enfin, abandonnez les cours. Apprenez l'héritage prototypique. Il est en fait assez élégant et facile à implémenter lorsque vous avez réellement besoin d'héritage. Cependant, je trouve que les approches de compositing fonctionnent beaucoup mieux dans JS, et je commence personnellement à tomber malade et à avoir des terreurs nocturnes EXTJS chaque fois que je vois plus d'un ou deux niveaux d'héritage en cours dans n'importe quelle langue.
Principes fondamentaux d'abord
Je parle des éléments essentiels dont devraient dériver toutes les autres bonnes pratiques: DRY, YAGNI, le principe du moindre étonnement, la séparation nette des domaines problématiques, l'écriture sur une interface et l'écriture de code lisible humain sont mon noyau personnel. Tout ce qui est un peu plus complexe et qui préconise l'abandon de ces pratiques devrait être considéré comme Kool Aid dans n'importe quel langage, mais surtout un langage comme JavaScript où il est très facile de laisser un héritage de code très déroutant pour le prochain. Le couplage lâche, par exemple, est une bonne chose jusqu'à ce que vous alliez si loin que vous ne pouvez même pas dire où se produit l'interaction entre les objets.
N'ayez pas peur de la frappe dynamique
Il n'y a pas beaucoup de types de base en JavaScript. Pour la plupart, les règles de casting dynamiques sont pratiques et simples, mais cela vaut la peine de les apprendre afin que vous puissiez mieux apprendre à gérer le flux de données sans conversions inutiles et routines de validation inutiles. Croyez-moi. Les types stricts sont parfaits pour les problèmes de performances et de repérage lors de la compilation, mais ils ne vous protègent de rien.
Découvrez les fonctions et fermetures de JS
Les fonctions de première classe de JS sont sans doute la principale raison pour laquelle JS a remporté le prix «Seule langue digne de toucher le Web côté client». Et oui, il y avait effectivement de la concurrence. Ils sont également une caractéristique centrale de JS. Nous construisons des objets avec eux. Tout est limité aux fonctions. Et ils ont des fonctionnalités pratiques. Nous pouvons examiner les paramètres via le mot-clé arguments. Nous pouvons temporairement les attacher et les tirer dans le contexte d'être des méthodes d'autres objets. Et ils rendent les approches événementielles des choses obscurément faciles à mettre en œuvre. En bref, ils ont fait de JS une bête absolue pour réduire la complexité et adapter différentes implémentations de JS lui-même (mais surtout l'API DOM) directement à la source.
Réévaluer les modèles / pratiques avant d'adopter
Les fonctions de première classe et les types dynamiques rendent beaucoup de modèles de conception plus complexes complètement inutiles et encombrants dans JS. Cependant, certains des modèles les plus simples sont incroyablement utiles et faciles à mettre en œuvre étant donné la nature très flexible de JS. Les adaptateurs et les décorateurs sont particulièrement utiles et j'ai trouvé les singletons utiles pour les usines de widgets d'interface utilisateur complexes qui agissent également comme gestionnaires d'événements pour les éléments d'interface utilisateur qu'ils construisent.
Suivez l'exemple de la langue et faites plus avec moins
Je crois que l'un des honneurs de Java fait valoir quelque part que la verbosité est en fait une caractéristique positive qui rend le code plus facile à comprendre pour toutes les parties. Poudlard. Si c'était vrai, le jargon juridique serait plus facile à lire. Seul l'auteur peut rendre ce qu'ils ont écrit plus facile à comprendre et vous ne pouvez le faire qu'en vous mettant à la place de l'autre gars de temps en temps. Adoptez donc ces deux règles. 1. Soyez aussi direct et clair que possible. 2. Arrivez au point putain déjà. La victoire est que le code propre et concis est des ordres de grandeur plus faciles à comprendre et à maintenir que quelque chose où vous devez parcourir vingt-cinq couches pour passer du déclencheur à l'action réelle souhaitée. La plupart des modèles qui préconisent ce genre de chose dans des langages plus stricts sont en fait des solutions de contournement pour les limitations que JavaScript n'a pas.
Tout est malléable et ça va
JS est probablement l'un des langages les moins protectionnistes couramment utilisés. Embrassez cela. Ça fonctionne bien. Par exemple, vous pouvez écrire des objets avec des variables persistantes "privées" inaccessibles en déclarant simplement des variables régulières dans une fonction constructeur et je le fais fréquemment. Mais ce n'est pas pour protéger mon code ou ses utilisateurs "d'eux-mêmes" (ils pourraient tout de même le remplacer par leur propre version pendant l'exécution). Mais c'est plutôt pour signaler l'intention parce que l'hypothèse est que l'autre gars est suffisamment compétent pour ne pas vouloir manipuler les dépendances et verra que vous n'êtes pas censé y accéder directement, peut-être pour une bonne raison.
Il n'y a pas de limites de taille, seuls les domaines problématiques
Le plus gros problème que j'ai avec toutes les bases de code Java que j'ai vues est une surabondance de fichiers de classe. Tout d'abord, SOLID n'est qu'une réitération déroutante de ce que vous devez déjà savoir sur la POO. Une classe doit gérer un ensemble spécifique de problèmes connexes. Pas un problème avec une seule méthode. Cela ne prend que du mauvais vieux code de func-spaghetti C en chaîne uniquement avec l'ajout de toute la syntaxe de classe inutile pour démarrer. Il n'y a pas de limite de taille ou de méthode. S'il est logique d'ajouter quelque chose à une fonction ou une classe ou un constructeur déjà long, cela a du sens. Prenez jQuery. C'est un ensemble d'outils complet de la longueur d'une bibliothèque dans une seule fonction et il n'y a rien de mal à cela. Que nous ayons encore besoin de jQuery est à un débat raisonnable, mais en termes de conception,
Si Java est tout ce que vous savez, essayez quelque chose avec une syntaxe non basée sur C
Quand j'ai commencé à jouer avec Python parce que j'aimais ce que j'entendais sur Django, j'ai appris à séparer la syntaxe de la conception du langage. En conséquence, il est devenu plus facile de comprendre Java et C comme une somme de leurs parties de conception de langage plutôt que comme une somme de choses qu'ils font différemment avec la même syntaxe. Un bon effet secondaire est que plus vous comprenez les autres langues en termes de conception, mieux vous comprendrez les forces / faiblesses de celle que vous connaissez le mieux grâce au contraste.
Conclusion
Maintenant, compte tenu de tout cela, nous allons toucher tous vos problèmes:
- Aucun moyen immédiat de trouver le point d'entrée d'une fonction (autre qu'une recherche en texte brut, qui peut ensuite entraîner des recherches ultérieures de méthodes plus haut dans la hiérarchie des appels, après deux ou trois dont vous avez oublié où vous avez commencé)
Chrome et Firebug ont en fait un suivi des appels. Mais voyez aussi mes points sur la structure et la concision et la directivité. Plus vous pouvez considérer votre application comme de plus grandes constructions bien encapsulées interagissant les unes avec les autres, plus il est facile de déterminer à qui revient la faute lorsque les choses tournent mal. Je dirais que c'est vrai aussi pour Java. Nous avons des constructeurs de fonctions de classe qui sont parfaitement utilisables pour les problèmes de POO traditionnels.
function ObjectConstructor(){
//No need for an init method.
//Just pass in params and do stuff inside for instantiation behavior
var privateAndPersistent = true;
//I like to take advantage of function hoisting for a nice concise interface listing
this.publicAndPointlessEncapsulationMurderingGetterSetter
= publicAndPointlessEncapsulationMurderingGetterSetter;
//Seriously though Java/C# folks, stop with the pointless getter/setters already
function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
if(arg === undefined){
return privateAndPersistent;
}
privateAndPersistent = arg;
}
}
ObjectConstructor.staticLikeNonInstanceProperty = true;
var instance = new ObjectConstructor();//Convention is to capitalize constructors
Dans mon code, je n'utilise presque jamais les littéraux d'objet {}comme composants d'application structurelle car ils ne peuvent pas avoir de variables internes (privées) et préfèrent plutôt les réserver pour une utilisation en tant que structures de données. Cela permet de définir une attente qui maintient la clarté de l'intention. (si vous voyez des curlies, ce sont des données, pas un composant de l'architecture de l'application).
- Les paramètres sont transmis aux fonctions, sans aucun moyen de savoir quelles propriétés et fonctions sont disponibles sur ce paramètre (autre que l'exécution du programme, la navigation jusqu'au point auquel la fonction est appelée et l'utilisation de console.logs pour afficher toutes les propriétés disponible)
Encore une fois, consultez les outils de navigation modernes. Mais aussi, pourquoi est-il si difficile de réexécuter le programme? Le rechargement est quelque chose qu'un développeur Web côté client frappe généralement toutes les quelques minutes, car cela ne vous coûte absolument rien pour le faire. C'est encore une fois, un autre point avec lequel la structure de l'application peut être utile, mais c'est un compromis de JS que vous devez exécuter votre propre validation lorsque l'application des contrats est critique (quelque chose que je fais uniquement aux points de terminaison exposés à d'autres choses que ma base de code ne fait pas). 't contrôle). OMI, le compromis vaut bien les avantages.
- Utilisation courante de fonctions anonymes comme rappels, ce qui conduit souvent à un spaghetti de chemins de code déroutants, que vous ne pouvez pas parcourir rapidement.
Ouais, c'est mauvais pour tout ce qui n'est pas trivial. Ne fais pas ça. Nommez vos fonctions enfants. Il est également plus facile de retracer les choses. Vous pouvez définir, évaluer (requis pour attribuer) et attribuer une fonction triviale simple en ligne avec:
doSomethingWithCallback( (function callBack(){}) );
Désormais, Chrome aura un nom pour vous lorsque vous effectuez le suivi des appels. Pour les fonctions non triviales, je les définirais en dehors de l'appel. Notez également que les fonctions anonoymées affectées à une variable sont toujours anonymes.
- Et bien sûr, JSLint détecte quelques erreurs avant l'exécution, mais même ce n'est pas aussi pratique que d'avoir des lignes ondulées rouges sous votre code directement dans le navigateur.
Je ne touche jamais à ça. Crockford a donné de bonnes choses à la communauté, mais JSLint franchit la ligne dans les préférences stylistiques et suggérant que certains éléments de JavaScript sont de mauvaises parties sans raison particulière, IMO. Ignorez définitivement une chose à propos des classes regEx et négation suivies de * ou +. Les caractères génériques fonctionnent moins bien et vous pouvez facilement limiter la répétition avec {}. Ignorez également tout ce qu'il dit sur les constructeurs de fonctions. Vous pouvez facilement les envelopper dans une fonction d'usine si le nouveau mot clé vous dérange. CSSLint (pas Crockford) est encore pire sur le mauvais conseil. Prenez toujours des gens qui font beaucoup de discours avec un grain de sel. Parfois, je jure qu'ils cherchent simplement à établir une autorité ou à générer de nouveaux éléments.
Et encore une fois, vous devez désapprendre ce que vous avez appris avec cette préoccupation d'exécution que vous avez. (c'est un problème courant que j'ai vu avec beaucoup de développeurs Java / C #) Si voir des erreurs au moment de l'exécution vous dérange encore 2 ans plus tard, je veux que vous vous asseyiez et que le spam se recharge dans un navigateur jusqu'à ce qu'il s'enfonce. il n'y a pas de division à la compilation / à l'exécution (enfin pas visible de toute façon - JS est exécuté sur un JIT maintenant). Il n'est pas seulement correct de découvrir des bogues au moment de l'exécution, il est extrêmement avantageux de recharger le spam aussi facilement et à moindre coût et de découvrir des bogues à chaque point d'arrêt auquel vous vous rendez.
Et lancez-vous sur ces outils de développement Chrome. Ils sont intégrés directement dans le webkit. Faites un clic droit dans Chrome. Inspecter l'élément. Explorez les onglets. Beaucoup de puissance de débogage avec la possibilité de modifier le code dans la console pendant l'exécution étant l'une des options les plus puissantes mais moins évidentes. Idéal pour les tests aussi.
Sur une note connexe, les erreurs sont vos amis. N'écrivez jamais une déclaration catch vide. Dans JS, nous ne cachons ni n'enterrons les erreurs (ou du moins nous ne devons pas tousser YUI / toux ). Nous nous occupons d'eux. Rien de moins entraînera une douleur de débogage. Et si vous écrivez une instruction catch pour masquer les erreurs potentielles dans la production, enregistrez au moins silencieusement l'erreur et documentez comment accéder au journal.