Comment devenir un programmeur "plus rapide"?
Ma dernière évaluation de poste ne comportait qu'un seul point faible: la rapidité. Je suis déjà au courant de certaines choses que je peux faire pour améliorer cela, mais ce que je recherche, ce sont d'autres.
Quelqu'un a-t-il des astuces ou des conseils sur ce qu'il fait pour augmenter la vitesse de sa sortie sans sacrifier sa qualité?
Comment estimez-vous les délais et respectez-vous ces délais? Que faites-vous pour en faire plus dans des délais plus courts?
Tout commentaire est grandement apprécié, merci,
Éteignez l'ordinateur. Prenez un crayon et du papier. Dessinez votre conception. Revoyez-le avec vos pairs. Écrivez ensuite le code.
Quelques idées...
- Évitez le placage à l'or - ne faites que ce qui vous est demandé (en termes d'exigences)
- Comprendre les besoins de l'entreprise et le faire correctement dès la première fois
- Comprendre parfaitement votre environnement et vos outils
- Devenez une dactylo fantastique, utilisez des raccourcis clavier au lieu de la souris
- Adoptez une approche itérative et intégrez des contrôles d'intégrité pour vous assurer que vous êtes sur la bonne voie
- Ne réinventez pas la roue, envisagez de réutiliser le travail passé et le travail des autres
- Éliminez les distractions, ne continuez pas à consulter vos e-mails, à regarder à l'extérieur, à parler à vos collègues, etc.
- Ne vous surmenez pas - reconnaissez quand vous devez faire des pauses
Votre désir d'être un programmeur "plus rapide" en soi est louable. Cependant, ne pas livrer à temps ne signifie pas que vous êtes lent, cela signifie que le projet a été mal planifié. Être un programmeur "plus rapide" n'aidera pas; cela signifie simplement que vous dépasserez la date limite plus rapidement.
Vous (et votre équipe) faites l'une des erreurs suivantes (ou toutes):
- sous-estimation le travail qui doit être fait;
- manquant un gros besoin ou élément d'architecture lors de la planification;
- confus estimations du travail avec des estimations de calendrier et ne tenant pas compte des choses comme les réunions/téléphone/autres frais généraux;
Il existe plusieurs façons de résoudre l'un des trois problèmes ci-dessus. Mais avant de pouvoir améliorer l'un d'eux, vous devez savoir pourquoi les choses se passent comme elles le sont. Faites un post-mortem sur les deux ou trois dernières estimations de projets par rapport au temps réel pris et déterminez où le temps supplémentaire est allé.
Je vais le répéter à nouveau - être lent à écrire du code ne fera pas manquer le délai, si vous l'avez correctement planifié pour tenir compte de ce fait.
Vraiment, apprenez vraiment votre éditeur. Si vous utilisez un IDE assurez-vous que vous utilisez toutes les fonctionnalités qu'il offre. Obtenez une feuille de triche pour apprendre les raccourcis clavier de l'éditeur de votre choix. Si vous utilisez une configuration Shell raccourcis pour les répertoires couramment utilisés
"Quelqu'un a-t-il des astuces ou des conseils sur ce qu'il fait pour augmenter la vitesse de sa sortie sans sacrifier sa qualité?"
Beaucoup, beaucoup de gens aspirent à une qualité "ultime" au détriment de quelque chose qui est (a) simple, (b) fiable et (c) correct.
La façon la plus importante d'accélérer votre développement est de simplifier ce que vous faites pour que ce soit aussi simple que possible.
La plupart des gens qui ont des problèmes pour livrer à temps le font beaucoup trop. Et les raisons invoquées sont souvent stupides. Ce ne sont souvent que des exigences perçues, pas des exigences réelles.
J'ai entendu beaucoup de gens me dire ce que le client "attend". C'est une mauvaise politique.
Construisez la chose la plus simple possible. Si le client en demande plus, construisez plus. Mais construisez d'abord la chose la plus simple possible.
Évitez de peaufiner votre code à la perfection, faites-le simplement fonctionner. C'est ce que l'entreprise attend.
Mais souvent, l'augmentation de la vitesse implique de sacrifier la qualité.
Réutilisation - J'essaie de prendre en compte tous les éléments intelligents des projets précédents, afin de pouvoir les réutiliser dans de futures entreprises. Cela vaut toujours la peine de vous demander "est-ce que je pourrais l'utiliser à nouveau un jour?"
Rester simple.
Si vous utilisez TDD, vous devez suivre "rouge, vert, refactor":
- Écrivez un test qui échoue (rouge). (Souvent pour des fonctionnalités que votre code n'a pas encore.)
- Commettez des crimes de codage horribles pour réussir vos tests (vert). Hardcode si nécessaire.
- Refactor, cassant probablement les tests pendant un court moment, mais améliorant globalement la conception.
Téléchargez la documentation de toutes vos langues/bibliothèques localement sur votre ordinateur, puis débranchez votre câble réseau/éteignez Wi-Fi .
Ne pas essayer d'être drôle ici. Cela m'aide vraiment!
Remarquez lorsque vous lisez Stack Overflow depuis trop longtemps. L'excuse de "compilation" ne fonctionne que pendant si longtemps. :)
Évitez de changer de tâche trop souvent. Les distractions et le changement de tâche peuvent tuer une journée, même si vous utilisez des outils comme Mylyn pour gérer vos tâches.
Déterminez une granularité (par exemple, 30 minutes) et ne travaillez que sur des éléments liés à la tâche à accomplir. Tout le reste (nouveaux rapports de bogues, e-mails concernant d'autres problèmes, questions de procédure non liées) est retardé au moins jusqu'au "prochain point de contrôle". Assurez-vous de désactiver les notifications par e-mail pour ne pas vous faire piéger.
C'est particulièrement efficace si vous avez un copain dans votre équipe qui vous fera savoir si les choses fondent vraiment et nécessitent votre attention immédiate.
Faites-le bien, la meilleure façon, la première fois. Si cela signifie que vous devez vous arrêter et y réfléchir pendant un certain temps avant de commencer, faites-le. Fonctionne 90% du temps.
Apprenez à tapez le plus rapidement possible .
Je fais-le demain .
Getting Things Done est également extrêmement utile.
J'ai une courte durée d'attention de toute façon, alors ces livres m'aident à garder ma concentration ... que faisais-je encore?
Pratique et dur labeur.
Vous devez y consacrer du temps et des efforts. À mesure que vous devenez plus à l'aise et confiant avec les outils que vous utilisez, la vitesse et la créativité devraient suivre.
Si vous souhaitez améliorer une compétence particulière, cela peut également aider à concevoir des exercices qui vous permettront de travailler spécifiquement sur cela. Si votre lenteur est en phase de conception, essayez de trouver des problèmes de conception sur lesquels travailler en ligne. Refaire le même exercice vous permettra de le terminer plus rapidement et de pratiquer la vitesse. Personnellement, j'aime exercices d'algorithme de TopCoder pour pratiquer la vitesse de programmation pure. Ils ont aussi des défis de conception, mais je ne les ai pas essayés.
Apprenez-en plus sur The Zone, apprenez comment vous y mettre et apprenez à reconnaître quand vous n'y êtes pas.
Une fois que je suis "dans la zone", je suis extrêmement productif et le code sort juste de moi, souvent je peux faire 2 ou 3 jours de codage en 1 jour. Mais je trouve que souvent c'est difficile de se rendre à cet endroit, je me retrouve à tergiverser, distrait par d'autres choses (Stack Overflow par exemple).
Citation de quelles-astuces-utilisez-vous pour vous mettre dans la zone
Connaître bien votre IDE et votre framework. Devoir se tourner vers Google pour chaque petite chose prend du temps.
Avant de commencer à développer:
- Déconnectez-vous de votre boîte mail
- Désactivez tous les clients IM
- Demandez poliment à vos pairs de vous donner le temps de vous concentrer
- Bien sûr, arrêtez de surfer sur Internet
Chaque fois que vous êtes interrompu, vous ralentirez car il faut du temps à votre esprit pour se remettre sur la bonne voie avec ses pensées. J'ai entendu dire que pour chaque interruption, il faut à l'esprit humain 5 à 10 minutes pour revenir au processus de pensée qu'il avait avant l'interruption. Avec autant de temps par interruption, il ne faut pas perdre beaucoup de temps toute la journée.
Les membres de notre entreprise ont en fait pris le temps de bloquer leurs horaires et de déménager dans une salle de conférence vide pendant quelques heures chaque jour.
Apprenez votre développement IDE in and out. Apprenez les touches de raccourci. Apprenez à utiliser la souris moins. Je trouve que cela me fait gagner beaucoup de temps.
Êtes-vous plus lent que vos collègues ou vos estimations sont-elles plus optimistes?
Pour produire des logiciels plus rapidement, j'ai trouvé que la meilleure chose à faire est d'apprendre le mieux possible votre API d'exécution. Ne tapez pas la logique de liste quand une extension LINQ fera l'affaire; ne créez pas un groupe d'écouteurs d'événements lorsque la liaison fonctionnera, etc.
En ce qui concerne l'estimation, cela vient avec l'expérience. Vous pouvez utiliser un logiciel d'estimation pour vous aider à trouver de meilleures estimations.
Personnellement, j'ai trouvé avec des développeurs de niveau junior, prenez quelle que soit leur estimation initiale et multipliez-la par 2, puis doublez-la. Cela représentera tout l'apprentissage, les réunions, le temps perdu, etc. Les développeurs de niveau supérieur ont tendance à travailler avec un facteur de 2 sur leurs estimations.
Souvent, la question n'est pas de savoir si votre estimation était erronée. Votre estimation a-t-elle expliqué toutes les bonnes choses? Donnez-vous vos estimations et vos délais en termes d'effort de codage ou en termes de temps calendaire? Pensez à tout le temps de votre journée et à la quantité de codage réelle et productive par rapport aux réunions, à l'apprentissage, au débogage, etc.
Deux choses qui pourraient être impliquées, mais je n'ai pas encore vu parmi les réponses ici qui augmente la productivité sont:
Utilisez une sorte de scripts de construction et de déploiement. Compiler, déployer, redémarrer le serveur d'applications et ne pas perdre de temps ou de concentration, cela devrait être un genre de chose en un clic.
Ayez une sorte de contrôle de version. Devoir coder sans pouvoir annuler un changement, c'est comme essayer de marcher sur des œufs
Quelques idées me viennent à l'esprit:
Obtenez d'autres opinions sur vos estimations - Y a-t-il d'autres développeurs auxquels vous pourriez demander quelque chose comme "Hé, pensez-vous que vous pouvez faire ce genre de fonctionnalité dans ce délai?" L'idée étant que la contribution d'autres personnes peut aider à la précision dans certains cas, car quelqu'un peut noter un tas de choses que vous avez manquées lors de l'estimation.
Perfectionnez vos compétences d'estimation - Commencez à suivre votre situation par rapport aux estimations et pourquoi vous êtes absent: D'autres éléments de travail entraînent-ils le non-respect des délais? Est-ce que vous sous-estimez constamment la complexité de quelque chose? Donnez-vous un calendrier complet quand ce n'est pas pratique, par exemple. ce qui est demandé est suffisamment vague pour que la simple mise en place d'un prototype prenne des semaines et qu'il y ait ensuite une réévaluation de ce qui doit être fait d'autre? Faire cela peut aider le plus à développer cette compétence de sorte que si vous dites que quelque chose prendra x heures, vous pouvez avoir confiance en cela parce que vous l'avez fait maintes et maintes fois. Une autre façon de le dire est simplement la pratique, la pratique, la pratique.
Certes, vous les avez probablement déjà envisagés, mais je pensais simplement qu'il valait la peine de le dire pour les autres qui n'ont peut-être pas pris en compte ces idées.
- Connaissez la technologie à l'intérieur comme à l'extérieur.
- Arrêtez! Pense! Aller!
- Architecte pour tout ce qui peut survenir, mais n'implémentez que ce qui est vraiment demandé.
- KISS - Keep It Simple Stupid
- Si cela devient trop complexe, ce n'est probablement pas bien pensé. (Retournez à 2 et 4)
- Ne restez pas coincé dans 5. Il est souvent payant de recommencer à zéro (Retournez à 2 et 4)
- Revenez à 1.
Je pense que le mot clé ici est "l'actualité". Ils n'ont pas dit que vous étiez trop lent, mais plutôt que vous n'étiez pas ponctuel.
Dans la gestion de projet, il est important que le gestionnaire puisse estimer quand vos éléments de travail seront terminés avec précision. Je soupçonne que la principale raison pour laquelle vos efforts n'ont pas été jugés opportuns est que vous avez souvent eu des articles qui n'ont pas été livrés dans les délais et qui ont été livrés bien plus tard que prévu.
Pour améliorer votre rapidité, vous voudrez peut-être passer plus de temps à comprendre combien de temps il vous faudra pour terminer un élément de travail particulier compte tenu de vos compétences, de votre expérience et du domaine. Cela vous permettra de donner de meilleures estimations à votre chef de projet. La clé ici est "mieux" ... vous pouvez livrer à temps plus fréquemment en remplissant tout avec un facteur de fudge, mais ce que vous voulez vraiment rechercher, c'est une estimation plus précise.
J'en discuterais avec votre manager pour voir si c'est vraiment le problème. Sinon, vous pourriez finir par programmer deux fois plus vite, promettre des choses en deux fois moins de temps que d'habitude, et être toujours critiqué pour votre opportunité car vos estimations auront toujours le même facteur d'erreur.
Restez stable, restez stable.
Créez quelque chose qui implémente un petit peu de la fonctionnalité et assurez-vous qu'elle fonctionne de bout en bout. Ensuite, continuez à travailler pendant que vous ajoutez de nouveaux éléments de fonctionnalité. Oui, c'est en partie une pratique TDD, mais cela a du sens même si vous ne faites pas TDD.
La raison est que chaque fois que je vois quelqu'un avec 2 semaines de code qui n'a jamais été stable, il faut toujours 2 semaines pour obtenir stable.
Si vous restez stable, vous supprimez cette incertitude et vous vous donnez également un moyen de vous rapprocher de la date limite si nécessaire.
Le contre-argument évident est que cela prendra plus de temps que de simplement l'écrire une fois, car vous ferez du travail supplémentaire en stabilisant le code non final. Je n'achète pas ça une seconde. Quand vous avez du code qui fonctionne, vous changez 5 lignes, et quelque chose se casse, vous savez exactement où la rupture a dû se produire.
Si vous avez 10 000 lignes de code qui n'ont jamais fonctionné et que vous devez trouver une pause, vous avez une tonne de code à parcourir.
Petits changements incrémentiels sur un système qui est toujours stable FTW. Allez lentement pour aller vite.
Pour moi, obtenir une bonne productivité, c'est avoir une idée claire de ce que vous essayez de réaliser et comment vous y arriverez.
Presque toutes les réponses ont été dites à mort dans de nombreux endroits ici et ailleurs. Ou, au moins, je l'ai entendu à mort. Apprenez votre IDE, apprenez à taper plus rapidement, utilisez des frameworks, utilisez la génération de code, etc., etc. Mais étant le type de programmeur qui pose ces questions et fréquente des sites comme Stack Overflow vous saviez déjà ces choses. Vouliez-vous simplement les répéter ici ou vouliez-vous simplement évacuer un peu?
Mais si nous pouvions arriver à cet état? Je veux dire maîtriser toutes ces suggestions? Que se passerait-il alors? Bien. Je suppose que les délais seront encore réduits. Et encore une fois, nous reviendrons à une perception de la qualité. Je veux dire, notre métier a définitivement progressé et est devenu de plus en plus productif au fil des décennies. Mais la qualité a-t-elle augmenté pendant cette période (à l'exclusion bien sûr des toutes premières années)?
Ma réponse est simple: n logiciel de qualité prend du temps! Vous ne pouvez échanger que l'un contre l'autre (qualité/vitesse). Mais oui, nous savons tous que, cependant, nous ne sommes pas honnêtes quant à la mesure dans laquelle ce compromis aboutit souvent à la fin de l'échelle. Et nous sommes encore plus de menteurs dès le début des projets!
Je dis que vous n'êtes pas en faute ici. Le problème est le perception que les gens ont du temps que devrait prendre un logiciel de qualité. Nous nous trompons en croyant que nous sommes capables de créer des logiciels de qualité avec les types de délais de nos gestionnaires ou même nous estimons. Nous ne fabriquons pas de logiciels de qualité. Nous écrivons des logiciels qui fonctionnent mais parfois avec des flashs de qualité dans certains coins d'une application.
Alors, que pouvons-nous faire à ce sujet? Nous ne pouvons pas simplement convaincre nos patrons que nous devons doubler ou tripler l'investissement dans chacun de nos projets. Je dis l'exemple. Créez un logiciel vraiment génial en tant que projet parallèle. Mettez-y votre temps et ne faites aucun compromis. Faites tout de même attention à votre progression. Prenez note des tâches apparemment non liées dans lesquelles vous avez dû consacrer un temps inattendu et voyez si vous pouvez le justifier. Comparez cela à tous les autres projets sur lesquels vous avez travaillé. Soyez brutalement honnête avec vous-même et tous les aspects de cette analyse. Les choses supplémentaires que vous avez faites avec votre logiciel de qualité peuvent-elles être négligées dans les "vrais" projets au travail? Mais peut-être que votre tentative a échoué. Quelle était la raison? Vous êtes-vous ennuyé et vous êtes-vous précipité pour obtenir les fonctionnalités de base? Je n'ai pas encore fait quelque chose comme ça, c'est pourquoi je mets fin à cette pensée avec un certain doute - mais j'ai l'intention de l'essayer. Je te tiendrai au courant :).
Enfin, je pense que la plupart (sinon la totalité) des évaluations de performances sont tordues et extrêmement manipulatrices. Vous ne pouvez pas accélérer la qualité et la vitesse à 100%. Votre patron devrait vous évaluer par rapport à une norme définie par l'organisation. La norme de l'organisation sur le compromis entre qualité et rapidité. Imaginons qu'OrangeSoft Inc. attend 33% de qualité et 66% de vitesse. Donc, si vous écrivez du code qui a peut-être un tiers des tests unitaires, il devrait le faire, mais en le rattrapant avec une vitesse et un délai de livraison réduits, vous devriez obtenir un score de près de 100% sur votre avis! (Ce sont des analogies assez grossières mais vous obtenez le point). Mais à la place, ce qui se passe, c'est que Bob écrit du code extrêmement rapidement mais qui est notoirement bogué. Ainsi, lors de son examen des performances, il obtiendra 3/5 pour la qualité et 5/5 pour la vitesse. Carol, d'autre part, écrit le code beaucoup plus lentement mais produit beaucoup moins de bogues. Elle obtient 5/5 pour la qualité mais 3/5 pour la vitesse. Quoi qu'il en soit, Bob et Carol sont amarrés à leur relance. Est-il possible pour n'importe quel employé d'obtenir un score parfait? Est-ce juste?
La technique que j'utilise est prototypage évolutif
Vous pouvez google pour plus d'informations - mais si le besoin est de produire quelque chose rapidement, c'est la seule façon de procéder. De plus, cela a l'avantage que lorsque les utilisateurs disent qu'il l'aime, vous avez terminé (... et pouvez commencer à faire la documentation).
Quels sont vos goulots d'étranglement? Je trouve que penser est mon goulot d'étranglement habituel, donc améliorer ma vitesse de frappe (déjà bonne) ne ferait pratiquement rien. D'un autre côté, si la saisie n'est pas rapide et naturelle pour vous, cela pourrait bien vous ralentir.
Essayez-vous de faire plus que nécessaire? Habituellement, une entreprise voudra beaucoup de bon travail de votre part plutôt qu'un travail moins mais plus soigné, et l'ajout de fonctionnalités qui ne seront pas utilisées gaspille du temps et de l'argent sans retour sur investissement.
Êtes-vous trop pressé? Sous la pression du temps, les gens lésinent fréquemment sur la conception et la planification initiales, espérant que cela fonctionnera de toute façon. Ce n'est souvent pas le cas.
Gérez-vous le temps correctement? Le développement nécessite des morceaux de temps de réflexion ininterrompu, sinon vous serez inefficace et donc lent.
Lisez l'excellent livre de Neal Ford The Productive Programmer .
Il regorge de conseils utiles.
Éditer:
Et, comme mentionné ailleurs, lisez les documents de vos outils. J'apprends toujours de nouvelles choses pour Vim en lisant les wikis de Vim. De même, la simple lecture de la page de manuel pour bash ou zsh donne toujours de nouvelles astuces à utiliser.
J'ai lu il y a longtemps quelque chose sur l'optimisation qui m'a vraiment marqué. Je ne me souviens pas de la source ou des mots exacts, mais l'essentiel était: "La seule façon de faire fonctionner un programme plus rapidement est de le faire faire moins. Tout autre plan est juste cela." Il en va de même pour les humains. L'armée a également un dicton: "La hâte fait des déchets". Faire les mêmes choses que nous faisons maintenant, mais plus rapidement, ne fera que créer des problèmes. Il existe de nombreux plans différents pour devenir plus productifs, et je ne dis pas qu'ils ne sont pas efficaces, mais ils ne seront pas adaptés à vos besoins. Il vaut mieux regarder ce que vous faites et trouver les choses que vous faites qui ne sont pas productives, et les supprimer. Tout autre plan n'est qu'une version édulcorée de cela.
Voici ce qui fonctionne pour moi:
- Décomposez votre travail en petites tâches qui sont (1) définies dans la portée (2) courtes - par ex. 2 heures.
- Commencez la journée en les notant sur un papier, dans l'ordre. Tracez quelques lignes - des choses que vous vous attendez à faire avant le déjeuner, des choses que vous ferez à la fin de la journée, etc.
- Travaillez votre liste en rayant les éléments au fur et à mesure.
- Choses temporelles - si quelque chose commence à traîner, accordez-vous un délai de recherche avant de demander de l'aide ou résolvez de manière plus simple.
- Si possible, structurez votre travail de manière à vous engager publiquement dans ces délais - en entrant des estimations dans le suivi des bogues, etc.
- Si vous vous surprenez à tuer le temps de recherche, de lecture, etc., inversez l'ordre - par exemple, accordez-vous une récompense de 10 minutes si vous réussissez une tâche d'une heure dans les délais.
J'ai vu plusieurs commentaires selon lesquels vous devriez passer moins de temps sur Stack Overflow. Si vous l'utilisez correctement, Stack Overflow devrait vous rendre plus efficace, pas moins. Évitez les discussions et concentrez-vous sur son utilisation pour faire le travail.
Réutilisez les actifs des anciens projets.
Prenez une journée pour apprendre votre IDE. S'il ne fournit pas d'outils comme des snipets, la saisie automatique de code ... pensez à en obtenir un nouveau.
Mettez des raccourcis vers tout dans des endroits clés pour pouvoir accéder aux choses plus rapidement.
Obtenez un deuxième écran si ce n'est pas déjà le cas.
Ne vérifiez pas trop souvent vos e-mails.
Essayez de vous concentrer sur une seule tâche à la fois. Si ce n'est pas possible, suivez de près ce que vous faites et ne vous perdez pas entre 15 tâches indépendantes.
Utilisez du papier. Quand je travaille, j'ai toujours une version imprimée de mes tâches sur laquelle je peux prendre des notes, rayer et ainsi de suite. C'est bien plus rapide que d'aller sur un autre écran pour lire ou écrire quelque chose. À la fin de la journée, je prends 10 minutes pour tout copier dans le système. J'ai réalisé que cela me faisait gagner du temps chaque jour.
- Développez-vous de plus en plus en tant que programmeur, tous les jours ... Apprenez les modèles de conception!
- Utilisez TDD, mais d'une manière appropriée, les bogues que vous pouvez avoir dans votre code sont la chose la plus longue.
- tiliser ReSharper :)
Étant donné que de nombreuses autres réponses parlent de la conception, je m'en tiendrai à l'aspect mécanique pur du codage plus rapide. La plupart de cela est probablement évident, mais je le dirai quand même car je remarque que beaucoup de mes collègues ne font pas certaines de ces choses.
Remappez vos raccourcis clavier IDE afin que vous puissiez en faire la plupart avec votre main gauche. Cela libère la main de votre souris pour un code/refactoring rapide et furieux).
Apprenez à naviguer dans votre curseur et à sélectionner du texte à l'aide d'une combinaison de Ctrl, Shift, Touches directionnelles, Home et End.
Voici ma configuration C++ (Visual Studio avec Visual Assist X). J'ai un clavier norvégien, alors soyez indulgent avec moi:
Alt-Z: basculer entre .h et .cpp
Ctrl-Shift- <: Contexte sensible sautant à travers les références. (<pour moi, c'est la clé à gauche de Z, vous les Anglais, vous n'en avez pas. Mappez-la à Ctrl-Shift-Z alors.)
Alt- | : Implémenter la méthode. En écrivant d'abord l'en-tête et en appuyant simplement sur Alt- | tout le temps, vous pouvez créer le plan de la classe entière en quelques secondes. (| pour moi est la clé sous escape.) Cela est particulièrement vrai si vous placez les fichiers cpp et en-tête les uns à côté des autres dans l'éditeur de texte afin que l'en-tête ne ne vous obscurcissez pas à chaque fois que vous effectuez l'action.
Alt-R: renomme le symbole sous mon curseur.
Alt-D: ajoute un modèle de documentation pour la fonction sélectionnée.
Ceci, en plus de l'achèvement rapide du code, rend possible la refactorisation à gauche.
Extraits de code, expérience et enthousiasme sans fin. Lisez toujours des trucs: blogs de programmeurs, livres, littérature, mauvais code d'autres personnes. Vous obtiendrez plus rapidement si vous obtenez une vue plus large sur les choses. Si vous pouvez imaginer toutes sortes de processus d'arrière-plan complexes impliqués, et vous connaissez vraiment toute la complexité du système cible.
Le Pragmatic Programmer's Handbook est assez impressionnant: il s'agit des meilleures pratiques et des pièges majeurs de nombreux aspects différents du développement logiciel. Le canard en caoutchouc et les trucs semblent manifestement ringards et stupides. Cependant la nature de la plupart des problèmes de programmation est que nous avons tendance à penser beaucoup trop complexe. Je suis un grand fan de solutions simples et faciles: pas de grandes astuces, pas de hacks super-élégants: il suffit d'utiliser les solutions les plus simples.
Si votre équipe est bonne, vous pouvez essayer de travailler en collaboration: Bespin et certains autres frameworks permettent aujourd'hui d'éditer un fichier ensemble. C'est génial si vous êtes vraiment dedans et voyez votre collègue faire la magie;).
Essayez de vérifier vos e-mails avec des intervalles plus longs et arrêtez d'utiliser les outils sociaux en ligne comme Twitter, Facebook, etc.
Utilisez ceci fond d'écran .
Essayez de travailler avec une vue de face ouverte. J'utilise habituellement la salle de conférence lorsqu'elle est gratuite, cela m'aide à me concentrer!
Essayez de travailler avec d'autres programmeurs autour de vous.
L'astuce n'est pas d'écrire du code plus rapidement, mais d'écrire du code de travail plus rapidement.
Plus tôt vous repérez un bogue, moins d'effort est nécessaire pour le corriger - c'est la principale chose qui affecte les performances du programmeur.
Il ne s'agit pas de la vitesse à laquelle vous tapez ou de la vitesse de votre compilateur, mais de la vitesse à laquelle vous pouvez identifier les bogues et les corriger au fur et à mesure.
Par conséquent, je suggère la programmation par paires comme un moyen d'être plus rapide - cela évite vraiment les bugs. Cela et le développement piloté par les tests. Avoir deux paires d'yeux rend les bugs plus de deux fois plus difficiles à traverser (je pense quand même).
D'autres conseils seraient
- Essayez de réduire au minimum le délai d'exécution du test de code - cela dépend évidemment de votre plate-forme et de vos outils. Si vous travaillez sur un système embarqué idiot avec des outils boiteux, le délai d'exécution peut être assez important (par exemple si vous devez reconstruire une image système et redémarrer le périphérique), les machines virtuelles ou les simulateurs peuvent vous aider ici.
- Si ce n'est pas la programmation par paires, demandez à d'autres occasionnellement des révisions de code informelles, mais uniquement à des pauses logiques dans votre (et, espérons-le, leur) flux. Faites cela en plus de votre processus de révision de code formel que vous avez sans aucun doute.
- Restez simple - ne faites pas trop d'ingénieur. Vous n'en aurez pas besoin.
Écrivez vos propres outils de productivité. Ils peuvent prendre du temps au départ pour écrire, mais le gain peut être important au fil du temps.
Quelques outils que j'ai écrits et que j'utilise tout le temps:
- Un formateur SQL.
- Un générateur SQL automatique: il suffit de sélectionner les tables.
- Un simple prioriseur de tâches, pour que je puisse voir toutes mes tâches en une seule fois.
- Un rappel de tâche qui me harcèle périodiquement.
- Une application qui prend du texte délimité et vous permet de le traiter comme une feuille de calcul et comme du texte.
- Un formateur de page PHP/Javascript/HTML. Une aubaine lorsque vous travaillez avec le code des autres.
J'ai écrit beaucoup d'autres petits outils de mon temps qui sont tombés au bord du chemin, mais cela valait toujours la peine.
J'aime vraiment écouter de la musique pendant que je programme parce que j'ai l'impression que cela me détend et que je peux me concentrer.
Une chaise confortable. Je n'utilise jamais les laboratoires informatiques de mon école pour programmer parce que les chaises de bureau sont incroyablement inconfortables.
Mangez quelque chose à l'avance car rien ne tue ma motivation comme la faim persistante.
Entraine toi. Cela, et mettre la main sur des outils de productivité qui vous permettent d'aller plus vite.
Par exemple (vous n'avez pas mentionné la plateforme sur laquelle vous travaillez), dans l'environnement .NET, il y a Resharper.
Renégociez les estimations et les délais. Assurez-vous que vous est celui qui dit combien de temps quelque chose prendra, et ne succombez à aucune suggestion "eh bien, nous devons le faire plus tôt" ou "que diriez-vous d'un objectif-cible".
Lisez l'article de Joel Spolsky sur les estimations, qui préconise essentiellement de diviser le travail en petits morceaux, et estimez chacun. Si l'un d'eux est compté en jours, décomposez-le davantage jusqu'à ce que vous ayez tout estimé en heures.
Vous et votre patron/évaluateur devez déterminer combien de temps vous avez réellement à programmer. Retirez les réunions, les e-mails, la documentation, les tests, les autres interruptions à partir du moment où vous êtes censé travailler et voyez ce qui reste.
Essayez de surveiller votre temps pour obtenir une référence sur la durée de certaines tâches. Il y aura des moments productifs (pour moi tôt dans la journée ou n'importe quelle période de temps au travail sans interruption) et des moments improductifs. Trouvez une moyenne.
Vous pouvez déterminer qu'une tâche donnée prend 8 heures à programmer, mais je doute que vous le fassiez en une journée.
J'essaierais également de vous comparer aux autres. La culture d'entreprise peut être de mettre beaucoup d'heures.
Eh bien, je pense que je ne suis pas lent, mais le travail qui m'a été donné a tendance à remplir le temps disponible.
Quoi qu'il en soit, j'entends souvent "Gee, tu as fait ça vite", mais ce n'est pas d'être un codeur rapide, c'est de coder moins.
Je pense que la principale façon de coder moins est de penser comme une DSL. Si vous ne pouvez pas obtenir le code généré pour vous par un préprocesseur, écrivez un générateur de code. Cela n'a pas besoin d'être compliqué. L'objectif est, si vous disposez d'une seule exigence autonome, de minimiser le nombre de différences de code source nécessaires pour implémenter cette exigence. Idéalement, ce nombre est 1. Si vous pouvez le faire descendre autour de 3-6 en moyenne, c'est plutôt bien. (Ce n'est pas seulement que vous écrivez moins. Plus ce nombre est petit, plus le nombre de bogues que vous mettez est petit, et que vraiment fait gagner du temps.)
Pour ce faire, je recommande de faire optimisation des performances , car vous découvrirez alors quelles pratiques de codage conduisent aux plus grands ralentissements, et elles conduisent également à du code gonflé. En particulier, structure de données excessive et programmation de type événement/notification. Ces choses seules contribuent massivement au volume de code.
Une grande partie du volume de code de nos jours est due à l'interface utilisateur, surtout si elle est flexible dynamiquement. Je suis tombé sur un moyen de faire cette partie, appelée Dynamic Dialogs , qui a une courbe d'apprentissage difficile mais réduit le code de l'interface utilisateur d'environ un ordre de grandeur.
Vous devrez trouver votre propre chemin à ce sujet, je le crains, mais bonne chance.
Gardez votre vie personnelle en ordre. Dormez beaucoup, mangez sainement et prenez des vitamines, surtout si vous avez une carence en fer. Éloignez-vous de "la boisson" - si vous voyez ce que je veux dire. Et rappelez-vous, "Le vin et les femmes peuvent égarer un homme sage."
Créez également des modèles de votre code et un "générateur de code" qui fonctionne à l'aide de modèles d'expression régulière. SI vous vous retrouvez à copier et coller, puis à rechercher et remplacer des classes similaires, automatisez ce processus. Je l'ai fait pour mes PHP, dans lesquels je peux créer une application CRUD, complète avec tous les composants MVC de base, basés sur mes tableaux de données - les modèles de données se ressemblent tous sauf le les tableaux de données qu'ils représentent, ils sont donc configurés dans des modèles et utilisés pour générer mon code initial. Économise des heures de saisie.
Enfin, dites à toutes les personnes impliquées dans le projet que le code va prendre 1/4 à 1/2 fois plus longtemps que VOUS ne le pensez. Négociez plus de respiration pour vous-même, dès le début. "Tard" est un terme relatif. Lorsque des changements se produisent dans le projet, à mi-parcours, informez tout le monde à l'avance que 8 heures de travail supplémentaires ont été ajoutées. Un système de suivi, tel que celui proposé dans "FogBugz", pourrait vous être utile, ainsi qu'aux gestionnaires, pour prévoir combien de temps il faudra pour faire quelque chose, en fonction des expériences précédentes. J'essaie de prendre le tact, "Il n'était pas tard - j'ai utilisé le temps nécessaire pour accomplir cette fonction - cela a simplement pris plus de temps que prévu."
Un autre programmeur peut dire: "Eh bien, j'aurais pu le faire plus rapidement ..." Peut-être, peut-être pas, ce n'est pas un point qui mérite d'être débattu ou de se battre - il y aura toujours un gars "intelligent" essayant d'appuyer sur ce bouton. Il vous ralentira si vous y réfléchissez! C'est toujours une mauvaise situation quand c'est votre patron. À ce stade, j'envisagerais de chercher un autre emploi, car ce type de patron est un arrogant JERK, dans mon livre.
Q: Que faites-vous pour en faire plus dans des délais plus courts?
R: Tous les jours, venez au bureau et écrivez tout ce que vous voudriez terminer dans cela (notes autocollantes) Notes Outlook. Commencez à travailler sur cet ordre des articles. Croyez-moi à la fin de la journée, vous sentirez que vous avez fait ce que vous aviez prévu et c'est un grand sentiment.
Programme de paires - cela a toutes sortes d'avantages:
- vous oblige à articuler/clarifier votre pensée
- vous donne un aperçu du fonctionnement de quelqu'un d'autre, de nombreuses idées que vous pouvez adopter/essayer
- apprendre les nouvelles technologies directement de quelqu'un d'autre qui les connaît
- prenez de petits conseils de productivité des autres. Vous voyez toujours quelqu'un utiliser une commande de menu que vous ne compreniez pas auparavant, ou une commande Unix utile.
Écrivez moins de code.
Bannissez Not-Invented-Here et faites bon usage des bibliothèques/frameworks/toolkits existants pour fournir des fonctionnalités communes (et généralement non définissantes) afin que vous n'ayez qu'à écrire ce qui est nouveau. Pour les parties que vous avez besoin d'écrire vous-même, construisez-les en pensant à la réutilisation afin de ne pas avoir à les réécrire pour le prochain projet.
Même si vous n'augmentez pas le nombre de lignes de code de travail que vous produisez par jour, vous pouvez toujours en faire plus en moins de temps en faisant en sorte que chaque ligne en fasse plus.
La seule chose claire que j'ai trouvée qui fonctionne est de ne pas être distrait. Ce qui, dans certains environnements, est impossible. Mais être capable de se concentrer sur la tâche spécifique et SEULEMENT sur cette tâche l'emportera probablement sur autre chose. Ces changements de contexte sont de très gros puits de temps.
Jongler pendant une pause
Boire Yerba Mate au lieu de café
C'est toujours la même décision unique, développement rapide vs qualité, lisibilité, extensibilité. Glisser-déposer des contrôles et des fichiers code-behind infinis (rapides et sales) ou de la modularité, des modèles et des pratiques (investissement à long terme)?
À mon avis, tout le monde doit investir dans le codage à long terme. Au fil du temps, le développement rapide sera également de grande qualité.
Cependant, au cas où je ne comprendrais pas votre demande et si vous cherchez des réponses en termes d'aspects pratiques d'un développement rapide, comme l'outillage, les générateurs de code et d'autres choses, mon avis est de commencer à utiliser Resharper et d'en apprendre le plus possible sur votre = IDE :)
UTILISEZ DES CADRES !! Ne vous embêtez pas avec le codage en dur!
Tout d'abord, vous ne devriez pas concevoir un système basé sur quelques réunions avec des utilisateurs finaux. En fait, vous ne devriez pas être impliqué dans la phase des exigences d'un projet, c'est pour les analystes commerciaux et les utilisateurs finaux de travailler.
La deuxième phase devrait être vos exigences techniques, c'est là que vous commencerez à travailler avec les analystes commerciaux pour trouver une solution aux spécifications demandées.
C'est maintenant la partie importante. Assurez-vous que vous comprenez à la fois les exigences de l'utilisateur final et les exigences fonctionnelles, il est inutile de commencer quelque chose uniquement pour découvrir qu'il ne répond pas aux attentes des utilisateurs. Parlez si vous ne comprenez pas quelque chose.
Maintenant, il est temps de frapper l'éditeur. Mais mon approche est de ne jamais écrire de vrai code, toujours d'écrire d'abord une pile absolue de commentaires, de le faire en pseudo-code si cela vous est facile, peu importe, tant qu'il est clair et facile à lire/comprendre.
Une fois que vous avez fait vos commentaires, vous pouvez commencer a) à écrire vos scénarios de test b) à écrire l'implémentation.
En fonction de votre environnement, il vaut mieux commencer par (a) mais malheureusement commencer par (b), puis essayer de forcer les tests pour respecter l'implémentation. Franchement cependant, si vous faisiez partie d'une grande entreprise, un département rédigerait les cas de test pour vous avant même de commencer à faire quoi que ce soit.
Tout le monde dit "vérifier les e-mails", mais pensez au temps que vous passez à rédiger des e-mails très techniques. Je peux facilement passer une heure à rédiger un seul e-mail. Pour y remédier, je pouvais soit 1) ne pas écrire autant, soit 2) remettre à plus tard les éléments techniques (et ceux qui m'obligent à lire le code pour répondre) jusqu'à ce que cela soit absolument nécessaire.
Lors de l'écriture de code, CodeRush aide beaucoup, surtout lorsque vous maîtrisez ses raccourcis. De plus, c'est gratuit: D
Je passe un peu de temps chaque semaine à chercher de nouvelles façons créatives de faire des choses qui peuvent ou non être directement liées à ce sur quoi je travaille actuellement. Souvent, je trouve de nouveaux trucs ou outils que je n'ai jamais connus, ce qui accélère mon flux de travail.
Familiarisez-vous intimement avec votre IDE.
Si votre IDE est Visual Studio, alors je recommande fortement le livre de Sara Ford .
- apprendre les modèles de conception. Ils vous aident à comprendre les problèmes, font de vous un meilleur programmeur -> vous permettront de programmer beaucoup plus rapidement car vous avez déjà à l'esprit des solutions pour plusieurs problèmes
- extraire les parties répétitives de votre programme. S'il y a une logique qui se répète dans plusieurs programmes que vous écrivez, pensez à les généraliser et à les extraire dans une bibliothèque de classes que vous pouvez ensuite réutiliser sur les nouvelles applications que vous écrivez. Standardize choses: investissez un peu de temps pour découvrir comment certaines tâches répétitives sont le mieux faites. Documentez les étapes à suivre. La prochaine fois, vous saurez exactement comment les résoudre/les appliquer.
- Principe KISS
- La génération de code sera utile (une fois qu'un outil utile sera disponible). Les générateurs ont récemment gagné en popularité.
Note: Faire simplement fonctionner les choses est pire !! Comme certains le mentionnent simplement pour pirater les choses jusqu'à ce qu'elles fonctionnent, vous serez plus rapide pour le moment. Des bugs arriveront cependant qui comptent également en termes de vitesse de programmation. Si je dois écrire une fonctionnalité et que j'investis dans une bonne écriture, ayant un bon design, peut-être bien testé (avec des tests unitaires) et que j'aurai besoin d'une demi-journée. Mais supposez que c'était le cas et que votre fonctionnalité fonctionne et que vous n'ayez pas à la toucher à nouveau. Un autre programmeur, juste concentré sur la réalisation rapide de son objectif, fera (peut-être) une mauvaise conception, en raison de tests manquants qu'il ne prendra pas en compte (ne sera pas conscient) des limites, des cas exceptionnels. Il aura besoin de 2 heures (disons). Des bugs arriveront, il devra à nouveau toucher le code, le corriger, éventuellement le prolonger (des heures seront à nouveau investies). Le code sera difficile à maintenir etc ... résumé: à la fin il passera beaucoup de temps et la frustration sera plus grande.
Utilisez un disposition du clavier ergonomique optimisée . Certains sont même destinés aux programmeurs, via des caractères spéciaux très accessibles.
Travail à domicile. Quand j'ai une échéance difficile et que je dois me concentrer complètement sur un problème, je dis à mon patron que je travaille à domicile. Cela me permet de configurer mon environnement de manière optimale, de réduire les interruptions et de me concentrer comme un faisceau laser sur le problème.
Vous obtiendrez plus rapidement avec l'expérience et mémoriserez l'API beaucoup plus.
Mes jours de recherche sur le Web pour des fragments de code sont beaucoup plus courts maintenant que j'ai appris à mieux coder.
Oh, vous voudrez peut-être aussi essayer d'utiliser des concepts de programmation fonctionnelle et lamda pour réduire votre code :)
Être enthousiasmé par ce que vous faites est un excellent moyen d'augmenter l'efficacité. Assurez-vous que c'est amusant!
Je pense que dessiner votre idée sur papier, rappelez-vous ce genre de choses, est un excellent moyen de donner corps à certaines idées. En tant que programmeurs, qu'ils soient professionnels ou amateurs, nous passons tellement de temps à regarder l'écran, qu'il est bon d'avoir un autre point de vente sur lequel mettre vos idées. Je trouve que gratter les choses, tracer des lignes hâtives reliant les idées, encercler les choses, souligner, etc. ajoute à l'accent mis sur une idée et peut vraiment vous aider à trier une idée beaucoup plus rapidement que d'essayer de la structurer dès le départ ou dans une forme assistée par ordinateur.
Une autre chose qui aide est le prototypage de petites pièces. J'ai écouté un podcast audio TED hier soir où le conférencier discutait de la construction de petites structures à partir de bâtonnets de spaghetti et de guimauve, apparemment, c'est une étude assez largement utilisée pour tester les capacités de construction sociale de petits groupes ... de toute façon, les groupes qui l'ont toujours fait mieux, en plus des architectes qui comprenaient le renforcement et la construction de bâtiments étaient des enfants parce qu'ils utilisaient un flux de rétroaction constant pour obtenir des résultats. Je pense que vous pouvez également jeter cela dans une idée de programmation où vous voyez que faire de petites choses et obtenir des résultats est non seulement plus productif, mais beaucoup plus amusant et utile que de construire une construction géante et de passer des jours à la déboguer ... c'est tué certaines de mes idées "amusantes" dans le passé, c'est sûr.
Lorsque je suis au bureau et que je dois rester concentré, je ferme mon client de messagerie. Rien ne détruit l'efficacité pour moi plus vite que la tentation constante de "jeter un coup d'œil rapide" sur le message qui vient d'arriver. J'ai également joué avec la technique de Pomodoro pour gérer les perturbations et maintenir la concentration.
Utilisez des générateurs de code chaque fois que cela est possible. Parfois, même Microsoft Excel (ou OpenOffice Calc) s'avère être un puissant outil générateur de code.
Autrement dit, tableau blanc -> décomposer en exigences testables en tâches (j'ai utilisé Team Foundation pour garder une trace de chaque tâche et combien de temps cela devrait prendre.)
Utilisez des tests pour vous assurer que vous obtenez ce qui est requis, rien de plus rien de moins. (Ne vous inquiétez pas encore des performances.)
Passez d'une exigence à l'autre et testez après chaque étape. Une fois chaque tâche terminée, vous devriez avoir une estimation précise du temps restant.
Lorsque toutes les exigences sont remplies, revenez en arrière et "polissez-le".
Faire le travail des jambes oblige d'abord à aplanir toutes les exigences, ce qui permet de gagner du temps en faisant les choses correctement la première fois.
Si cela est fait correctement, cela devrait permettre de passer plus de temps sur Stack Overflow :)
Bonne chance
Il y a un tas de bonnes idées ici. Pour m'aider à entrer dans la "zone", j'utilise une minuterie réglée à 27 minutes d'intervalle. Je trouve qu'une fois en mode travail, il est facile de travailler bien au-delà du buzzer et travailler avec le flux est indolore. Il est cependant difficile d'y arriver.
La seule chose que j'ai remarquée affectant le plus ma vitesse est la motivation et le plaisir. Cela peut sembler flou, mais quand je suis motivé et que je fais quelque chose que je trouve amusant, je peux être extrêmement efficace. D'un autre côté, quand je ne suis ni l'un ni l'autre, j'ai vraiment l'impression de devoir pousser chaque ligne de code hors de moi.
Trouvez vos points forts, qu'est-ce qui vous motive vraiment et quel genre de tâches aimez-vous vraiment faire? Et pouvez-vous affecter votre planification afin que vous puissiez le faire? Pour moi, c'est quand je parviens à résoudre des problèmes et des problèmes de conception, et quand je sens que j'ai une partie du projet.
Il y a quelques mois, nous avions un petit projet que notre petite équipe était chargée de réaliser et c'était un délai très important et très irréaliste. Cependant, nous étions tous très motivés et nous nous sommes beaucoup amusés à le faire et à le faire à temps, avec un client heureux. La raison de ma motivation était que nous étions très impliqués dans le projet et que nous devions trouver des idées créatives pour lui. J'ai aussi pu faire les parties que j'apprécie vraiment.
Cependant, récemment, j'ai été impliqué dans un projet où je suis essentiellement un singe de code, je fais juste des tâches engourdissantes et frustrantes, ou j'ai juste des trucs de réparation rapide de la manière la plus rapide possible qui, je le sais, me reviendra et me mordra fort un jour un avenir proche, et il a été douloureusement lent.
Alors, quels sont vos points forts?
- Savoir ce que vous voulez faire et vous y intéresser
- Passez quelques heures à rechercher du code sur la façon de le faire
- Copiez et collez du code pour obtenir le résultat final
- Travaillez sur une interface graphique de base pour faire le travail, ne passez pas de temps à le faire paraître joli
- Tester et déboguer
- Travailler sur un joli gui
"Rapidité" n'est pas la même chose que "rapide". Si tel était le problème, votre évaluation aurait dû dire "lent". Soyez donc avant de prendre le chemin que vous proposez, assurez-vous de savoir ce qu'on attend de vous.
Cela pourrait signifier n'importe quoi; cela peut même signifier que vous n'entrez au bureau que 20 minutes après vos collègues ou que vous avez une mauvaise gestion du temps. Cela n'a peut-être rien à voir avec votre "vitesse de programmation".
Je passe probablement le plus de temps à concevoir et planifier; il est plus facile de planifier des tâches à partir d'une bonne analyse et d'une bonne conception, et vous donnerez alors de meilleures estimations qui seront crues. De plus, d'une bonne conception, le codage devient un processus beaucoup plus simple et plus dirigé. Il permet également de diviser une tâche et de la répartir entre d'autres développeurs.
J'ai pratiquement triplé ma vitesse de codage C avec VIM .
CodeRush! Tu piges! Aimer!
Choisissez un éditeur rapide, un compilateur rapide et un logiciel d'écriture avec un temps d'exécution rapide. De cette façon, vous pouvez faire dix fois plus d'erreurs qu'un programmeur normal et devenir encore meilleur que les autres. C'est probablement l'une des raisons pour lesquelles les applications Google sont si populaires. Le développement Web est rempli de bugs désagréables, et écrire plus de logiciels sur la plate-forme de buggy est pénible. Mais le temps de réponse entre la modification du code et la visualisation du résultat est si rapide qu'il est toujours plus facile de faire fonctionner cette montagne de déchets que d'étendre les programmes c ++. :)
Passez plus de temps à rassembler les choses dans votre esprit que devant l'IDE. Lorsque vous avez un plan, vous avez déjà la plupart du travail déjà fait. La mise en œuvre ne représente que les 20% restants. Si vous êtes bloqué lors de l'écriture de code en raison de problèmes spécifiques à la plate-forme, respectez le plan et continuez à implémenter et à tester le reste. En fin de compte, abordez tous les endroits que vous avez laissés, en les résolvant un par un - il est possible que certains soient liés, et en résoudre quelques-uns pourrait être suffisant pour comprendre le reste. J'utilise généralement des solutions de contournement pour de tels problèmes, en ajoutant des commentaires "// TO CHANGE" aux endroits particuliers du code et en réécrivant ceux qui ont le plus d'impact sur la qualité et les performances à la fin, si je n'ai pas le temps de résoudre tous les problèmes. d’entre eux avant la date limite.
Construisez votre propre bibliothèque de code
Chaque fois que vous codez une nouvelle fonctionnalité, essayez de la garder aussi générique que possible, mais pas trop générique. À court terme, cela sera un peu plus lent, mais à long terme, à mesure que votre bibliothèque de codes s'agrandit, chaque nouveau projet sera achevé plus rapidement car de nombreuses applications métier ont des besoins similaires (pas toujours) mais suffisamment proches pour que beaucoup de le code peut être réutilisé.
Plus rapide ne signifie pas mieux. Si vous parvenez à être un programmeur plus rapide et meilleur. Tout se résume à l'équilibre. Combien de temps pouvez-vous faire cela? La réflexion, la patience et la planification sont toujours payantes. Parfois, "rapide" dans le monde du développement peut apporter les pires résultats.
Déconstruire. Divisez tout ce que vous créez en fonctionnalités plus petites que vous pouvez implémenter par étapes. Ensuite, chaque fois que vous avez fait un de ces petits morceaux et que vous avez testé pour confirmer qu'il ne casse rien, déployez-le et montrez-le aux pouvoirs en place.
L'utilisation de petites itérations vous aidera souvent à terminer le projet plus grand plus rapidement et mieux, car vous obtenez des commentaires au fur et à mesure et vous n'aurez pas besoin de revenir en arrière et de refaire autant. Mais même si ce n'est pas le cas, vous montrez des progrès constants, ce qui présente un avantage psychologique solide et redonne confiance à votre manager ou client.
Le développement piloté par les tests aide également beaucoup avec cette approche. Au début, il peut sembler que l'écriture des tests ralentit d'abord les choses - mais cela gagne du temps dans les bogues que vous éviterez, et selon la façon dont vous les écrivez, les tests eux-mêmes pourraient être un livrable que vous pouvez montrer aux pouvoirs en place et confirmez le comportement de l'application avant même de tout écrire.
Si vous programmez en C, l'apprentissage des hacks de bits est un must pour devenir un programmeur plus rapide. Lisez également les pratiques de codage des meilleurs classeurs sur Topcoder.com. Leur code est très petit et efficace.
Devenez plus rapide programmeur en ralentissant lorsque vous concevez et codez.
- Pensez à ce que vous faites.
- Considérez les implications de votre conception.
- Faites-le bien la première fois (testez vigoureusement votre propre code).
Cela peut sembler plus lent, mais votre débit sera plus rapide que ces jockeys de code qui effectuent une itération en 4 heures, puis ont besoin de 6 tours d'AQ avant leur le code passe.
Re: Comment l'estimer et s'y tenir:
Lors de l'estimation, rappelez-vous loi de Hofstadter ainsi que cette boutade: "Tout prend plus de temps que cela". Faites une estimation raisonnable du temps que devrait prendre quelque chose, puis doublez-le ou triplez-le avant qu'il ne sorte de votre bouche. Il y aura des complications, des revers, des distractions, des choses que vous oubliez, etc. Mieux vaut sous-promettre et sur-livrer que vice-versa.
En respectant les estimations, faites de votre mieux pour terminer votre travail efficacement. Lorsque des problèmes surviennent, communiquez les retards tôt. Cela donne à chacun le temps d'ajuster ses attentes. Si votre explication est raisonnable, vous recevrez peut-être plus de temps ou d'assistance ou des distractions (comme un voisin bruyant) seront retirées de votre chemin.
Les pratiques suivantes sont bien connues mais souvent négligées pour diverses raisons, souvent en raison de délais serrés, elles méritent donc d'être mentionnées ici (en fait, ce sont des mécanismes permettant de passer du temps à l'avance pour éviter de dépenser davantage plus tard):
Faites développement piloté par les tests; cela vous aidera à écrire uniquement la quantité de code réellement requise et vous aidera à éviter l'introduction de bogues lors de l'ajout de fonctionnalités ou de la refactorisation
Écrivez commentaires, mais uniquement lorsque le code est suffisamment complexe pour le justifier
Refactoriser et simplifier votre code souvent
Utilisez un logiciel de contrôle de source décent (comme Git ou Mercurial) -si votre employeur utilise autre chose, utilisez le vôtre localement-
Commit le code change souvent: pour chaque fonctionnalité ou refactoring, faites un commit, car revenir en arrière vous coûtera moins cher si quelque chose tourne mal
N'ayez pas peur de branche; Git a notamment un mécanisme de branchement très rapide et "sûr" (par exemple, par rapport à Subversion)
Personnellement, je pense que tout est question de réutilisation du code. À moins que vous ne fassiez des choses entièrement personnalisées à chaque fois, vous devriez avoir une bibliothèque de fonctions d'utilisation commune vers laquelle vous pouvez vous tourner. J'ai un utils.php dans lequel j'ai tout un "junkyard" de fonctions que j'ai utilisé sur des projets précédents. Économise une tonne de temps lorsque je dois faire quelque chose de similaire.
Bonne chance et ne vous découragez pas. Je pense que nous nous sommes tous sentis parfois lents ou "stupides". Je sais que je l'ai!
Utilisez des outils d'analyse statique.
Ils vous aident à trouver plus de bogues au moment de la compilation que vous auriez autrement dû traquer au moment de l'exécution.
En particulier lors de la création d'applications multithreads, elles sont une véritable aide.
Ce sont toutes de bonnes suggestions. J'ajouterais ma propre technique de productivité qui consiste à savoir comment faire avancer les choses non seulement avec un code minimal mais avec un code de redondance minimal.
En général, cela signifie que moins la structure des données est meilleure.
Pour créer du code avec une redondance minimale, il faut de la créativité et de la volonté de faire les choses de manière à imposer une courbe d'apprentissage. C'est le prix de la productivité. Voici un exemple.