Quelle est la chose la plus importante, utile ou instructive que vous ayez apprise au cours des 12 derniers mois? [fermé]

Beaucoup de gens dans la communauté du codage parlent d'amélioration continue, de pratique délibérée et ainsi de suite - mais quand ils parlent de leurs pratiques actuelles, c'est presque comme s'ils `` jaillissaient entièrement formés des reins de Zeus '' parce que vous n'entendez pas comment leurs opinions ont changé avec le temps ou ce qu'ils ont appris récemment.

De temps en temps, même si je vais à une conférence, ou que je lis un livre, ou que je parle à quelqu'un, ils s'ouvrent un peu plus et je trouve que j'apprends beaucoup de ces idées.

Donc, si vous deviez choisir une chose parmi les 12 derniers mois que vous avez apprise, ce serait quoi?

J'ai appris qu'il ne faut qu'un seul gestionnaire pourri pour gâcher tout le projet, mais il faut beaucoup de bons programmeurs pour nettoyer le gâchis par la suite.

Après avoir appris quelques Clojure , j'ai commencé à réaliser l'utilité de la programmation fonctionnelle , et mon style de codage Java en a été fortement affecté. Contrairement à la croyance populaire, un langage de programmation fonctionnel n'est pas une condition préalable absolue pour faire de la programmation fonctionnelle.

Il est possible d'incorporer un certain nombre d'éléments de programmation fonctionnelle dans un langage impératif tel que Java, et même s'il n'est pas toujours idiomatique, il peut être très bénéfique dans certains problèmes. Par exemple, les classes anonymes sont à peu près égales aux fermetures, comme décrit dans wikipedia . L'évaluation paresseuse devrait être une norme plutôt que quelque chose d'inhabituel. L'immuabilité peut difficilement être surexploitée. Il suffit de surmonter l'idée (presque) obsolète selon laquelle la construction de nouveaux objets au lieu de mutation d'objets existants coûte cher en raison de la consommation de GC et de tas - dans 99,9% des cas, ce n'est tout simplement pas pertinent. En fait, le traitement parallèle peut même inverser l'argument de l'efficacité: créer de nouveaux objets immuables peut être moins cher que de muter ceux existants, car vous vous débarrassez du verrouillage.

Plus d'informations sur la réalisation de FP en Java pur ici , ici , ici et ici .

Même si vous avez une superbe équipe et une gestion compétente pour cette équipe, votre travail n'est toujours pas sûr. La haute direction peut toujours faire des bêtises, comme dissoudre toute votre direction.

En bref: la politique est importante, et parfois la politique qui vous affecte, vous ne pouvez pas la contrôler.

J'ai appris que le but des tests de logiciels est de trouver des bogues . Il ne s'agit pas de vérifier que le système est correct.

Il y a des facteurs psychologiques importants en jeu: si votre objectif est de montrer que le programme est «correct», vous graviterez vers des tests que vous savez réussir. Mais si votre objectif est de trouver des bogues, vous vous orienterez vers des tests qui pousseront vraiment votre système à ses limites.

Il y a même un changement important dans la langue que vous utilisez. Si un test trouve un bogue, vous l'appelez réussi . Si le test échoue [c'est-à-dire que le programme réussit], vous l'appelez infructueux . Je me suis surpris à aller dans le sens de la pensée de «vérification», et cela fait une grande différence.

Cet effet psychologique est discuté davantage dans The Art of Software Testing , un livre classique que je recommande fortement. L'auteur, Myers, recommande également que quiconque teste un programme ne soit pas l'auteur, ni même dans la même chaîne de gestion. Vous pouvez le faire si vous codez vous-même, il faut donc de la discipline.

Faire un développement piloté par les tests dès le début sur une livraison client pour voir comment cela affecterait la qualité du code, et ne s'exécuter qu'à partir du lanceur JUnit dans Eclipse. Cela a abouti à un meilleur produit.

La vraie valeur de la programmation sans ego.

À un certain niveau, j'ai toujours su que l'ego et la programmation ne se mélangent pas, mais je n'ai jamais tout à fait expliqué les conséquences. L'idée que vous devez examiner activement et trouver des failles dans vos propres pratiques est quelque chose que je n'ai commencé à réaliser que l'année dernière. J'apprends également à rechercher activement la critique de mes conceptions (à la fois dans l'interface utilisateur et dans le code).

Pour être honnête, cependant, j'apprends toujours à abandonner l'ego, et j'apprendrai probablement à le faire pour le reste de ma carrière de programmeur.

Voici ma réponse à ma propre question:

Il y a environ un an, il a cliqué sur le fait que les tests d'acceptation automatisés ne devaient pas être des versions automatisées des tests que nos testeurs auraient effectués manuellement. Se concentrer sur des tests par rapport à des spécifications uniques plutôt que d'essayer de frapper autant que possible en une seule passe a rendu les tests beaucoup plus simples, plus faciles à lire et contribue également à encourager la livraison incrémentielle.

J'ai appris comment un concept mathématique comme Semirings s'applique aux algorithmes. Avec cela, vous pouvez montrer comment certains algorithmes sont identiques, sauf pour utiliser un semiring différent. Cela ne devrait pas être si étrange pour moi en tant que programmeur, mais ma tête a soufflé.

Outre la politique mentionnée par Frank Shearar , j'ai récemment découvert QUnit et JSCoverage qui ont fait ma journée. Et le mois. Je n'aurais jamais pensé qu'il serait possible de tester JavaScript à l'unité avec une couverture de code, mais le voici ... :-)

Mes trois principaux remerciements pour la dernière année de programmation s'adressent aux personnes suivantes (par ordre décroissant d'importance et de reconnaissance):

• le paradigme de programmation fonctionnelle pour ouvrir mon esprit à d'autres façons, souvent plus élégantes et laconiques, d'exprimer des idées et des algorithmes en code. Je pense que mes compétences générales en programmation se sont beaucoup améliorées en très peu de temps, grâce à des idées de programmation fonctionnelle.

  (Mes remerciements personnels vont à Tomáš Petříček pour son excellent livre Programmation fonctionnelle dans le monde réel .)

• L' injection de dépendances et les tests unitaires m'ont appris que la composition d'objets est sans doute le meilleur moyen de créer des systèmes complexes (orientés objet) (et que l'héritage de classe n'est pas aussi important que je le pensais). Les deux m'ont appris et m'ont fait réfléchir sur la meilleure façon de composer des systèmes et sur la façon d'écrire des composants qui sont faciles à utiliser, mais encore suffisamment flexibles pour être réutilisés.

  (Si je devais mentionner une bonne ressource pédagogique, je dirais Art of Unit Testing de Roy Osherove .)

Tous ces éléments combinés m'ont amené à écrire du code qui contient généralement moins de bogues qu'auparavant, car j'écris maintenant un code qui est beaucoup plus facile à comprendre et à se tromper que ce que j'ai précédemment publié.

Ce qui change dans l'industrie des logiciels en évolution rapide, la courbe d'apprentissage est toujours là. "S'il n'y avait qu'un moyen d'apprendre sans prendre le temps d'apprendre."

J'ai appris qu'être vendu à une nouvelle entreprise peut en effet améliorer votre travail. Mon organisation a été achetée à notre ancienne entreprise en mai, et les choses semblent s'améliorer. La nouvelle entreprise a épargné peu ou pas de dépenses avec notre nouveau bureau, remplacé nos machines de développement obsolètes par des équipements du 21e siècle, fait preuve de flexibilité dans la gestion de nos projets et nous a généralement fait nous sentir tous les bienvenus.

C'est un peu déprimant d'être vendu (un peu comme un serf ayant un nouveau seigneur féodal parce qu'il est lié à une terre qui a changé de mains), mais le résultat final a été bien meilleur que ce à quoi je m'attendais.

Je dirais que l'utilisation des tests unitaires Microsoft dans Visual Studio 2010.

J'ai trouvé très facile de déboguer une méthode de test spécifique.

Je pourrais exécuter à tout moment mon projet de test afin de voir si l'application de la couche de gestion fonctionne correctement. Le processus de test garantit que mon équipe ne devrait avoir aucun problème lors du déploiement de la solution complète pour les visiteurs de notre site Web.

• Apprentissage de Python de base (en l'utilisant parfois pour écrire des scripts rapides)

• ArchLinux installé dans VM (avait Ubuntu dans VM plus tôt, mon PC est rapide maintenant!)

• Commencé avec MATLAB (en particulier pour tracer des graphiques et des vérifications numériques rapides)

• Passé à Mercurial (de SVN) (ramification et fusion!)

Apprendre le modèle MVVM m'a aidé à devenir beaucoup moins un hack.

J'ai dû commencer à maintenir une application Web Python - j'ai donc décidé que c'était aussi le bon moment pour apprendre Vim . Maintenant, j'utilise le plugin IdeaVim pour Intellij pour mon développement Java et Flex et je crois vraiment que cela a rendu ma frappe plus rapide et plus efficace.