Comment coder plus rapidement (sans sacrifier la qualité)
Je suis codeur professionnel depuis plusieurs années. Les commentaires sur mon code sont généralement les mêmes: écrit du bon code, bien testé, mais pourrait être plus rapide .
Alors comment devenir un codeur plus rapide, sans sacrifier la qualité? Pour cette question, je vais limiter la portée à C #, car c'est principalement ce que je code (pour le plaisir) - ou Java, qui est suffisamment similaire à bien des égards.
Choses que je fais déjà:
- Écrivez la solution minimale qui fera le travail
- Écrivez une multitude de tests automatisés (empêche les régressions)
- Écrire (et utiliser) des bibliothèques réutilisables pour toutes sortes de choses
- Utilisez des technologies bien connues là où elles fonctionnent bien (par exemple Hibernate)
- Utilisez des modèles de conception là où ils se mettent en place (par exemple, Singleton)
Ce sont tous excellents, mais je n'ai pas l'impression que ma vitesse augmente avec le temps. Je fais attention , car si je peux faire quelque chose pour augmenter ma productivité (même de 10%), c'est 10% plus rapide que mes concurrents. (Pas que j'en ai.)
En plus de cela, j'ai toujours obtenu ce retour de mes gestionnaires - que ce soit le développement Flash à petite échelle ou le développement Java/C++ d'entreprise.
Edit: Il semble y avoir beaucoup de questions sur ce que je veux dire par rapide, et comment je sais que je suis lent. Permettez-moi de clarifier avec plus de détails.
J'ai travaillé au sein d'équipes petites et moyennes (5-50 personnes) dans différentes entreprises sur différents projets et différentes technologies (Flash, ASP.NET, Java, C++). L'observation de mes managers (qu'ils m'ont dit directement) est que je suis "lent".
Cela est dû en partie au fait qu'un nombre important de mes pairs ont sacrifié la qualité pour la vitesse; ils ont écrit du code bogué, difficile à lire, difficile à maintenir et difficile à écrire pour les tests automatisés. Mon code est généralement bien documenté, lisible et testable.
Chez Oracle, je résolvais systématiquement les bogues plus lentement que les autres membres de l'équipe. Je le sais, car j'obtiendrais des commentaires à cet effet; cela signifie que d'autres développeurs (oui, plus expérimentés et plus expérimentés) pourraient faire mon travail en moins de temps qu'il ne me l'a fallu, à peu près de la même qualité (lisibilité, maintenabilité et testabilité).
Pourquoi? Qu'est-ce que je rate? Comment puis-je m'améliorer?
Mon objectif final est simple: si je peux fabriquer le produit X en 40 heures aujourd'hui, et que je peux m'améliorer d'une manière ou d'une autre pour pouvoir créer le même produit à 20, 30, voire 38 heures demain, c'est ce que je veux savoir - Comment puis-je y arriver? Quel processus puis-je utiliser pour m'améliorer continuellement? J'avais pensé qu'il s'agissait de réutiliser du code, mais cela ne semble pas suffisant.
J'aime l'approche de Jeff Atwood à ce sujet qui peut être trouvée ici http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .
Fondamentalement, dans l'article, il fait référence à un passage du livre Art & Fear de David Bayles et Ted Orland. Le passage va:
Le professeur de céramique a annoncé le jour de l'ouverture qu'il divisait la classe en deux groupes. Tous ceux du côté gauche du studio, a-t-il dit, seraient notés uniquement sur la quantité de travail qu'ils produiraient, tous ceux de droite uniquement sur sa qualité. Sa procédure était simple: le dernier jour de classe, il apportait sa balance de salle de bain et pesait le travail du groupe "quantité": cinquante livres de pots classés "A", quarante livres un "B", etc. Ceux qui étaient notés sur la "qualité", cependant, devaient produire un seul pot - bien que parfait - pour obtenir un "A". Eh bien, est venu le moment du classement et un fait curieux est apparu: les œuvres de la plus haute qualité ont toutes été produites par le groupe en cours de classement en quantité. Il semble que, tandis que le groupe "quantité" produisait des tas de travail - et apprenait de ses erreurs - le groupe "qualité" avait réfléchi à la perfection et, finalement, n'avait guère plus à montrer pour ses efforts que des théories grandioses et un tas d'argile morte.
Essentiellement, vous salir les mains plus rapidement et plus souvent améliore mieux vos compétences que de passer votre temps à étudier et à théoriser sur la façon "parfaite" de le faire. Mes conseils, continuez à pratiquer, suivez la technologie et étudiez la conception.
Une possibilité que personne d'autre ne semble avoir mentionnée est que vous vous débrouillez très bien et que vos gestionnaires ne sont pas très bons. Comment mesurent-ils la productivité? Peuvent-ils vous donner des exemples précis ou s'agit-il simplement d'une perception générale? Ont-ils pris en compte le temps passé à réparer le travail des autres par rapport au vôtre?
J'ai vu beaucoup de gens obtenir du crédit pour avoir fait des choses, tandis que le reste de leur équipe corrige le désordre qu'ils ont laissé.
La plupart de ce que les gens pensez est important n'est pas important. La vitesse de frappe n'est pas importante. Des machines ou des outils plus rapides ne sont pas importants. Nous ne sommes ni dactylographes ni opérateurs de machines. Nous sommes des travailleurs pensés. Nous sommes des décideurs .
Ce qui est important est d'utiliser les commentaires pour améliorer continuellement votre processus de prise de décision. La seule façon de le faire, comme l'acquisition d'une autre compétence, est par l'expérience, utile la pratique et la rétroaction continue.
- Travailler sur des projets annexes.
- Travail sur des projets open source.
- Travaillez avec des développeurs meilleurs que vous. Programme de jumelage!
- Exposez-vous à de nouveaux outils et techniques. Gardez ce qui fonctionne.
- Faites des exercices de programmation conçus pour entraîner votre appareil de prise de décision *.
- Surveillez votre amélioration en fonction de mesures objectives telles que le taux et la vitesse des défauts, et de mesures subjectives comme la qualité et la forme physique du code.
Enfin: rappelez-vous que la vitesse sans qualité est inutile, et vice versa. Pour maximiser votre utilité, trouvez un équilibre entre ces tensions.
Il est fort possible qu'en fait, on vous demande de sacrifier la qualité , pour une plus grande vitesse.
Dans certains environnements de développement1, cela ne vaut tout simplement pas le temps supplémentaire de produire quelque chose de poli, quand "juste assez bien" fera l'affaire.
1 - Je pense notamment à "l'outilleur interne", mais il y en a probablement d'autres.
Il semble que vous fassiez toutes les bonnes choses - à moyen terme, vous serez plus rapide, il n'est donc pas évident si vous êtes réellement lent. Vous seul le savez vraiment. (mais c'est une possibilité très réelle - PeopleWare revendique une différence de productivité jusqu'à 10X entre les développeurs pour la même tâche).
J'ai donc quelques suggestions pour vous:
Le temps est une chose relative, donc peut-être que le problème n'est pas votre vitesse réelle, mais plutôt la perception du temps que vous donnez. Vous pourriez laisser entendre que cela prendra une semaine, mais finirez par passer deux semaines, tandis que d'autres pourraient passer 3 semaines ... mais vous semblez juste 1 semaine lente.
Étant donné que vous recevez souvent ces commentaires, il est peut-être temps de parler à votre responsable et à vos pairs pour voir ce qu'ils disent - il doit y avoir beaucoup à apprendre d'eux.
Faites de la programmation en binôme avec un développeur de "qualité rapide" pour voir si vous pouvez voir la différence.
Tout ce que les gens ont demandé si vous êtes vraiment lent est idiot. Devenir un programmeur plus rapide sans sacrifier la qualité est toujours un bon objectif, même si vous êtes déjà lent ou rapide. C'est mon objectif numéro 1 en tant que programmeur et je n'aurai jamais fini. J'essaie toujours d'aller plus vite sans sacrifier la qualité, je suis obsédée par ça. Voici ce qui a fonctionné jusqu'à présent dans l'ordre de l'aide, avec quelques idées expérimentales à la fin:
1) N'arrêtez jamais d'apprendre: apprenez tout ce que vous pouvez sur la programmation et l'utilisation des ordinateurs en général. Trouvez les domaines dans lesquels vous êtes faible et apprenez-les. Même si cela semble complètement sans rapport avec votre travail et C #, je vous garantis que si vous le recherchez, vous trouverez souvent des moyens de l'appliquer à ce que vous faites. L'apprentissage est également une question d'expérience, alors ne lisez pas seulement des trucs, mais essayez-les et développez vos compétences. Si vous avez l'habitude d'utiliser Windows, essayez Unix ou vice versa. Si vous aimez normalement utiliser les outils de ligne de commande IDE et les éditeurs de texte ou vice versa. Si vous entendez parler d'un outil ou d'une technologie dont vous n'avez jamais entendu parler auparavant ou que vous ne connaissez pas beaucoup, ne cédez pas à la tentation de passer à autre chose. Cherchez-le! N'ayez pas peur de sortir des sentiers battus et d'apprendre de nouvelles technologies expérimentales qui, selon d'autres, ne sont pas pratiques; Nous commençons à peine à gratter la surface de la programmation productive.
2) Divisez les projets: essayez de diviser vos projets en mini-projets. Essayez de faire une nouvelle version tous les jours ou une fois tous les quelques jours au maximum. Demandez-vous "Quelle est la quantité minimale de fonctionnalités que je peux libérer, et toujours publier quelque chose qui est utile à l'utilisateur." C'est une compétence que vous apprendrez en la faisant. Vous devrez peut-être convaincre vos gestionnaires de vous laisser faire, mais ils seront généralement satisfaits des résultats assez rapidement. En faisant cela, vous commencerez à remarquer que les choses que vous pensiez essentielles à votre fonctionnalité sont en fait des fonctionnalités supplémentaires qui peuvent être développées plus tard. Cela vous permet, ainsi qu'à vos responsables, de hiérarchiser uniquement les fonctionnalités les plus importantes au lieu de toutes les fonctionnalités liées à celle sur laquelle vous travaillez. Cela vous permet de penser plus rapidement en gardant votre esprit clair et concentré. Vous pourrez à son tour légitimement programmer plus rapidement. Vos managers ou au moins les managers de votre manager sont également susceptibles de percevoir que vous programmez maintenant encore plus vite que vous ne l'êtes vraiment parce que vous obtenez plus de versions. Un autre avantage énorme de ceci est que vous serez beaucoup mieux à estimer le temps nécessaire pour terminer les versions, et vos gestionnaires vous adoreront pour cela. Comme vous effectuez déjà de nombreux tests automatisés, vous ne devriez avoir aucun problème à effectuer des versions fréquentes et stables. Vous devrez peut-être renforcer votre système de construction automatisé. Je recommande fortement de lire le livre Continuous Delivery de la série Martin Fowler. C'est une lecture difficile et parce que c'est extrêmement répétitif, mais toujours très utile.
3) Utilisez la technique du pomodoro et adaptez/changez ce qui ne fonctionne pas pour vous. Si vous combinez cela avec le numéro 2 de cette liste, vous obtiendrez un énorme gain de productivité.
4) Apprenez Vim. Même si vous finissez par utiliser ces commandes dans Visual Studio via ViEmu, ou depuis Eclipse via un plugin, ou depuis Emacs, vous gagnerez en productivité. La meilleure façon d'apprendre Vim est de commencer à l'utiliser et de vous forcer à ne jamais le désactiver (revenir à vos anciens outils) jusqu'à ce que vous l'ayez maîtrisé. C'est douloureux au début, mais vous ne voudrez jamais reculer, et même grincer des dents lorsque vous devez travailler sans. Certains diront que cela n'augmentera pas beaucoup votre vitesse. Mais plus rapide est plus rapide, en particulier lorsque la lecture et la modification de code sont CE QUI WE DO, et je me suis retrouvé gagner beaucoup de temps avec cela à l'occasion.
5) Ce dernier n'est pas nécessairement recommandé car je ne suis pas sûr que ce soit une bonne idée, et cela peut en fait diminuer votre productivité, mais je le ferai quand même. Vous pouvez essayer de faire plus de tests d'acceptation et moins de tests unitaires, ou peut-être au moins assurez-vous de faire des tests d'acceptation. J'ai eu du succès avec SpecFlow, mais je pense qu'il y a quelque chose de mieux là-bas. Même la rédaction des spécifications peut être assez technique, donc vous voudrez peut-être simplement que votre manager/client rédige d'abord une ébauche de version que vous modifiez de manière significative, ou vous pouvez écrire le tout vous-même et simplement le lire et le valider. Cela vous aidera avec le numéro 2 de cette liste. Les tests d'acceptation peuvent également être plus pratiques et nécessitent moins de code que les tests unitaires. Cela ne veut pas dire qu'ils les remplacent, différents outils pour différentes choses. Mais vous pourrez peut-être vous en sortir avec moins de tests unitaires si vous faites beaucoup de tests d'acceptation.
6) Celui-ci est encore plus expérimental et controversé. Je ne l'ai pas fait moi-même, donc je ne peux pas exactement le recommander. Apprenez et utilisez le système de programmation Meta de JetBrains. Utilisez-le pour créer des outils que votre gestionnaire/client utilise pour créer lui-même le logiciel souhaité. Vous pourriez même être en mesure d'arrêter de faire des tests unitaires et d'acceptation si vous pouvez l'utiliser pour créer des outils que votre responsable/client utilise pour spécifier le comportement de manière très simple et non compliquée. L'idée n'est pas de se débarrasser du programmeur. Les programmeurs devraient encore ajouter de nouvelles fonctionnalités à ces outils utilisés par le client/gestionnaire chaque fois qu'ils (les personnes, pas les outils) ne peuvent pas facilement créer la fonctionnalité souhaitée. Je crois que le MPS ou d'autres outils similaires sont la voie de l'avenir.
En fait, cela se résume à expérience. Pour être plus rapide dans ce que vous faites, c'est comme conduire une voiture, au départ, vous avez peur car les autres sont des conducteurs rapides (ou ivres) (ou les deux) et vous voulez arriver à la maison en toute sécurité (en termes de logiciel, vous voulez vous assurer que votre code fonctionne comme développé et il fonctionne bien).
Au fil des ans/des mois, une fois que vous maîtrisez la conduite et les autoroutes, vous apprenez quelques trucs en cours de route qui rendent votre conduite amusante. C'est ce que nous appelons l'expérience. Ces "astuces" (que j'appelle des traits) sont ce qui aide.
Dans mon cas, j'ai appris l'utilisation réelle des modèles de conception en codant (même @ home) et en apprenant les utilisations de certains. Ainsi, lorsque je rencontre un problème qui nécessite un modèle de conception, j'utilise l'expérience passée pour voir ceux qui ont fonctionné et pourquoi cela fonctionnerait/ne fonctionnerait pas pour ma situation.
En résumé:
- Expérience crée des traits qui renforcent la confiance et de meilleurs logiciels.
PS: L'expérience vient aussi de l'apprentissage des autres. Par exemple. Aide de SO, programmation en binôme, évaluations par les pairs, etc. Vous ne pouvez pas avoir d'expérience si vous ne pouvez pas regarder en arrière et apprendre des erreurs (ou si quelqu'un ne remet jamais en question vos efforts).
La question est de savoir si vous êtes moins cher si vous regardez le coût total à long terme.
En d'autres termes, vos corrections de bogues soigneusement conçues sont-elles de si haute qualité (y compris les cas de test et la documentation) qu'elles l'emportent sur les coûts liés à la maintenance des corrections de bogues effectuées par vos collègues les plus rapides?
Si oui, alors vous devez en informer vos supérieurs. Il peut être difficile d'argumenter s'ils ne mesurent pas et ne disposent pas des données nécessaires pour confirmer votre évaluation.
Si non, alors vous devez fortement considérer pourquoi c'est le cas:
- Êtes-vous trop inexpérimenté?
- Passez-vous beaucoup de temps à faire des choses non demandées qui, selon vous, devraient être là?
- Avez-vous du mal à déterminer quand le correctif est terminé?
- Votre code est-il de moindre qualité après tout que vous ne le pensez?
- Devriez-vous aborder le développement de code d'une manière différente, car il vous faut trop de temps pour vous mettre à niveau comme vous le faites actuellement?
- Avez-vous passé trop de temps sur des choses comme ce site?
Réfléchissez et modifiez votre question avec vos résultats.
Utilisez plus votre cerveau et faites moins de tests. Pour être honnête, le test a sa place, mais c'est cher.
Lisez aussi The Art of Unix Programming (gratuit en ligne, livre qui vaut le prix)
Enfin, vous n'êtes peut-être pas au bon endroit. Cheville ronde dans un travail carré, etc.
En fin de compte, c'est comme l'école: "Produire ce que l'enseignant veut" devient "produire ce que la direction demande et paie".
Si vous prenez un projet volumineux et terminé et obtenez le nombre de lignes de code "finales" par heure de travail, vous constaterez que les programmeurs codent BEAUCOUP plus lentement que vous ne l'auriez imaginé.
Nous ne parlons que de quelques lignes de code par jour. Le reste du temps, vous passez le débogage, la réécriture et les tâches générales de programmation.
Vous avez peut-être entendu le vieil adage - si vous détectez une erreur pendant que vous la tapez, cela vous fera gagner 10 fois plus de temps si vous l'avez détectée au moment de la construction, ce qui est 10 fois mieux que de l'attraper pendant l'AQ, qui est 10 fois mieux. que de l'attraper après la libération ..
Alors, comment l'accélérez-vous? Je ne me concentrerais sur aucune forme de vitesse de frappe - la réduction des erreurs et l'amélioration d'autres "futures interactions" avec votre code devraient être un bien meilleur investissement de votre temps.
Un code clair et lisible est essentiel. Vous écrivez votre code une fois, mais il sera lu des dizaines de fois. Écrire pour la lisibilité vous fera économiser BEAUCOUP de problèmes sur toute la ligne (ce qui vous fera également gagner beaucoup de temps). Si vous retournez JAMAIS en arrière et lisez votre code et que vous devez y penser même une seconde, vous vous trompez.
La programmation par paire peut réduire le temps d'AQ et, si vous considérez qu'un programmeur ne produit que quelques lignes par jour, si deux peuvent coder au même rythme qu'une, mais avec moins d'erreurs, vous avez une longueur d'avance.
Le codage défensif (par exemple, la vérification des paramètres) peut réduire les problèmes ... Si vous avez un très bon analyste/architecte dans votre équipe, vous pouvez gagner du temps avec une bonne conception de départ.
Sinon, continuez à améliorer vos compétences en conception. Au fur et à mesure que vous acquérez de l'expérience, vous serez plus en mesure de reconnaître les modèles qui ne fonctionneront pas et de les éviter, vous pourrez identifier les puits de temps plus tôt, etc.
Pour autant que je sache, c'est:
- bien
- vite
- pas cher
En tant que manager, vous pouvez en choisir 2.
Ne vous inquiétez pas des commentaires que vous avez reçus sur la vitesse. En tant que codeur, je préfère maintenir un code bien pensé et bien écrit que quelque chose qui a été giflé ensemble.
Avez-vous envisagé de faire un audit détaillé de vous-même pendant que vous travaillez? Soit un stylo et un suivi papier de la façon dont vous passez votre temps ou utilisez quelque chose comme Rescue Time pour vous suivre.
Une fois que vous savez plus exactement COMMENT vous passez votre temps, vous pouvez avoir une meilleure idée de ce qui doit être amélioré et concentrer vos efforts là-bas.
Idéalement, vous pouvez mettre au défi certains de vos collègues de le faire également, comparer vos résultats et obtenir des idées les uns des autres. Vous avez probablement des avantages dont ils pourraient également bénéficier.
Peut-être que vous découvrez que vous passez trop de temps sur une partie de votre processus qui pourrait être automatisée ou simplement que vous avez beaucoup de distractions pendant une certaine partie de la journée et qu'une autre partie de la journée est calme, alors vous pouvez planifier vos tâches autour cela, etc.
Ou peut-être que vous découvrez que les tests prennent plus de temps que vous ne le pensiez et que vous devez repenser votre perception que cela vous rend plus rapide.
À tout le moins, cela vous donne des repères sur lesquels vous pouvez travailler.
De votre liste, vous allez bien.
Si vos collègues font du code avec un numéro CRAP plus élevé, ils iront plus vite. CRAP est une métrique comiquement nommée combinant complexité cyclomatique et couverture de test.
N'écrivez pas de code plus CRAP que nécessaire. ;)
Mon seul changement à vous suggérer est d'utiliser des bibliothèques, ne les écrivez que si:
- Votre entreprise vend des bibliothèques
- Vous avez refactorisé le code récurrent dans une bibliothèque
Vous lisez et faites et c'est super. Mais vous pourriez être bloqué en pensant à procuedural ou OO, vous êtes-vous exposé à la programmation fonctionnelle (disons Haskell?) Et Prolog?
Pour affiner votre technique de programmation OO, avez-vous joué avec Smalltalk/Squeak?
Et enfin, la théorie. Avez-vous au moins une compréhension rudimentaire de la théorie des graphes? (Certains programmes fonctionnent avec des arbres, des DAG ou simplement des graphiques simples à un moment donné. Les réseaux sont des graphiques)
Je vais citer Oncle Bob :
La seule façon d'aller vite est de bien aller.
Chaque fois que vous ressentez la tentation d'échanger la qualité contre de la vitesse, vous ralentissez. À chaque fois.
J'ai une objection à la vue de la "qualité sacrifiée pour la vitesse" d'OP.
Les codeurs professionnels (programmeurs) doivent satisfaire 3 objets:
1) Le code doit fonctionner comme prévu
2) La livraison doit être à temps
3) Avoir une bonne qualité, une documentation, etc.
4) Autre etc.
Je pense que OP a été blâmé comme lent, probablement parce que OP n'a pas été fait à temps.
C'est un hic 22 qui est difficile à contourner. Bien que vous manquiez encore d'expérience et qu'une certaine quantité de connaissances dans de nombreux aspects soient déjà plus rapides que la plupart, le hic, c'est que c'est plus difficile à mesurer .
Personnellement, le mieux que vous puissiez faire à ce stade est de vous mesurer. Donnez-vous des commentaires sur votre façon de travailler, peut-être que de simples changements dans vos habitudes de travail peuvent vous rendre plus productif.
J'ai trouvé que les mails rongeaient beaucoup plus que je ne le pensais simplement à cause de l'interruption. Maintenant, je ne réponds aux mails que deux fois par jour et j'ai gagné près d'une heure de productivité certains jours. Essayez des méthodes comme pomodoro , je l'ai utilisé comme moyen de mesure. À intervalles réguliers (15 minutes), je notais ce que je faisais à ce moment-là. Cela m'a permis de voir comment mes journées étaient structurées et ce que je pouvais faire pour maximiser l'efficacité.
Les principales choses auxquelles je peux penser sont les suivantes
- Augmentez votre vitesse de frappe.
- Utilisez des outils qui procurent des gains de productivité. Par exemple ReSharper.
- Machines ou outils plus rapides. Comme plus RAM ou un disque SSD.
Je suis sûr qu'il y a certaines choses que vous pouvez faire dans le domaine des compétences en codage, mais il semble que vous êtes partout dans ce genre de choses. Les choses que j'ai énumérées ci-dessus sont généralement négligées par les développeurs.
Vous pouvez suivre un cours de saisie rapide. Je ne sais pas si taper plus vite est un problème mais "coder trop lentement" pourrait être causé par des vitesses de frappe simplement lentes.
Qu'en est-il des générateurs de code? Parfois, le code devient répétitif. La refactorisation peut en supprimer une partie, mais même dans ce cas, vous pouvez avoir des appels répétitifs à la même fonction refactorisée. Selon les données et le code avec lesquels vous travaillez, les générateurs de code (écrits en Excel, Perl, Java, peu importe ...) pourraient gagner beaucoup de temps . Et l'utilisation d'outils de génération de code pour le développement de l'interface utilisateur est généralement une évidence.
Et enfin, peut-être que les mesures sont fausses. Avez-vous considéré que vous codiez à la vitesse la plus rapide possible compte tenu de tout le reste, et que les délais sont trop courts, ce qui vous rend apparaît comme un codeur lent?
Sur la base des modifications apportées à votre question, il semble que vous pourriez soit prendre la route de certains de vos collègues et pirater ensemble la solution la plus rapide qui fonctionnera - et la documentation et l'AQ seront damnés!
Ou ... obtenez plus d'expérience et de pratique dans un domaine spécifique afin de connaître si bien la base de code et l'API que vous puissiez coder les solutions dans votre sommeil. Cela peut être fait mais nécessite plus de temps. Si les autres développeurs plus rapides que vous sont connus pour être plus expérimentés et plus expérimentés, alors il n'y a qu'une seule chose à faire - vous doit devenir plus senior et expérimenté!
L'avantage de Squeak pour le codage rapide va bien au-delà du simple "perfectionnement OOP compétences". Il y a une raison pour laquelle les interfaces graphiques modernes, ainsi que les IDE, ont été inventés sur Smalltalk, sans parler de JUNIT était SUNIT à Java, le terme "OOP" a été inventé pour décrire Smalltalk, etc., etc.
Il faut toujours utiliser le langage et l'environnement les mieux adaptés à tout ce que l'on espère accomplir, mais pour le prototypage général, au moins, je ferais correspondre Squeak à quoi que ce soit, à l'exception possible d'HyperCard, et même cela nécessiterait une analyse comparative pour voir ce qui était en fait plus rapide étant donné qu'il existe des installations de type hypercard dans Squeak.