Que doit savoir chaque programmeur?
Quels que soient les langages de programmation ou les systèmes d'exploitation utilisés ou l'environnement dans lequel ils se développent, que doit savoir chaque programmeur?
Quelques antécédents:
Je souhaite devenir le meilleur programmeur possible. Dans le cadre de ce processus, j'essaie de comprendre ce que je ne sais pas et cela me serait très utile si je le faisais. Bien qu'il y ait des tas de listes dans le sens de "n choses que tout développeur [de langage de programmation d'insertion] devrait savoir", je n'ai pas encore trouvé quelque chose de similaire qui ne se limite pas à un langage spécifique.
Je m'attends également à ce que ces informations intéressent et profitent aux autres.
- Travaillez en petites équipes (2-10) où vous êtes l'un des programmeurs les plus faibles. Vous apprendrez beaucoup plus en travaillant avec des gens expérimentés qu'en contractant/en indépendant et en lisant des livres.
- Des rythmes laids, complets et fonctionnels, élégants, incomplets et cassés.
- Découvrez tous les concepts à la mode, qu'ils soient bons, mauvais ou que le jury est toujours absent (par exemple MVC, Ruby on Rails, développement piloté par les tests, respectivement)) afin que vous puissiez ignorer ou l'embrasser avec raison.
- Comment écrire des commentaires et nommer correctement vos variables/méthodes/objets/fonctions. Lisez la dernière édition de Code Complete pour des suggestions.
Comment rester fier de son travail et être capable d'admettre ses erreurs en même temps.
N'avalez pas la fierté!
Je vis par ces devises:
"Le succès, c'est 10% d'inspiration et 90% de transpiration."
"Combien de fois vous ai-je dit que lorsque vous avez éliminé l'impossible, tout ce qui reste, aussi improbable soit-il, doit être la vérité?"
Quand je me mets au travail, mon ego reste dans la voiture. Rien ne compte plus que le travail et sa qualité. Ne prenez jamais la critique personnellement et écoutez tout le monde, aussi stupide que cela puisse paraître. Mais ne compromettez jamais la qualité simplement parce qu'elle est plus rapide ou plus facile.
Et bien sûr, apprenez, apprenez, apprenez. :)
Devrait savoir quoi coder et comment coder. si je ne sais pas, alors devrait au moins avoir la capacité et l'enthousiasme pour l'apprendre!
Sachez qu'un bon (le meilleur) programme n'est pas nécessairement celui qui fonctionne le plus vite. Un bon programme est celui qui: - Est facile à comprendre et à modifier. - Est facile à utiliser - il a une interface simple/claire/facile à apprendre.
J'aime dire que les meilleurs programmeurs sont ceux qui peuvent écrire des programmes que même les pires programmeurs peuvent comprendre et même les utilisateurs les plus occasionnels peuvent utiliser.
Excellent fil! J'ajouterai que j'ai beaucoup appris des livres de Programming Pearls.
Je suis assez passionné par les mathématiques, mais je pense que celui qui arrive avec le temps que les programmeurs devraient savoir est ce que les lapins à chasser et ceux à lâcher. Lorsque vous recherchez une réponse à une question et que vous ne pouvez trouver la réponse nulle part, il n'abandonne pas pour essayer une approche différente. Nous sommes payés pour résoudre des problèmes, nous ne sommes pas payés sur la méthode par laquelle nous résolvons le problème.
Vous pouvez et ferez aussi des erreurs. Cela aide de deux manières. Tout d'abord, vous ne vous déprimez pas. Deuxièmement, vous ne méprisez pas vos collègues. Cette seconde vous aidera dans votre carrière.
vous discipliner pour écrire un logiciel qui est assez bon même s'il n'est pas parfait
Comment écrire de façon claire et concise. Je ne parle pas de code, mais ce serait bien aussi.
Chaque programmeur doit savoir comment résoudre les problèmes. Il est important d'aborder chaque tâche avec un esprit ouvert quant aux outils et méthodologies à utiliser. Parfois, les cadres ou les modèles seront la réponse, mais parfois ils ne le seront pas.
Jouez au jeu, apprenez que la plupart de votre travail quotidien sera consacré à la politique du lieu de travail et non à la programmation.
Contrôle de version, évidemment. Mais plus important encore, la mécanique d'un ordinateur.
Théorie du compilateur: comment transformer un langage en un autre? Sans une idée de comment cela fonctionne et de ce qu'il peut faire, le code est forcément plein de mauvaises décisions. Les compilateurs ont tendance à sembler magiques aux non-initiés, et ils ont tendance à écrire du code horrible.
Architecture informatique: vous devez comprendre la machine en profondeur dans une certaine mesure pour vraiment écrire du bon code. Même au-dessus de plusieurs couches de middleware, la machine fondamentale brillera. Vous devez comprendre les caches, le multitraitement, le fonctionnement de IO, à un certain niveau, pour avoir une chance décente d'écrire du code décent. fonctionne bien jusqu'à un certain point - mais quand il se brise en raison d'un manque de synchronisation ou frappe un mur de performances, vous devez comprendre ce qui se passe à l'intérieur des entrailles de la machine.
Entourez-vous de personnes plus intelligentes que vous.
Le domaine problématique dans lequel ils travaillent.
Chaque développeur devrait lire ceci post :
"Il est plus difficile de lire du code que de l'écrire"
La seule chose à laquelle je peux renoncer pour obtenir des conseils:
- La programmation n'est pas seulement un travail, c'est une forme d'art
- La programmation est la seule forme d'art où il vaut mieux être paresseux.
Maintenant, pas la forme de paresseux où vous récupérez du code sur un projet open source, pensez que c'est assez bon et copiez-collez-le dans votre propre application, je veux dire se préparer à être paresseux à l'avenir.
J'essaie toujours de tout décomposer en objets standard de base qui effectuent des tâches dédiées. Un objet SSH qui gère la connexion SSH et SCP'ing, un objet dbconnection qui gère toutes les communications db, vous l'appelez.
Déposez-le, faites-le fonctionner et vous avez terminé. Plus vous êtes un bon programmeur, plus il est facile de faire quelque chose.
Aussi, si vous n'êtes pas assez paresseux (par exemple, vérifiez TheDailyWTF ), procurez-vous un autre emploi. Il devrait y avoir quelque chose en vous qui fait que vous ne voulez pas réimplémenter le langage de programmation dans le langage lui-même, ou faire l'une des autres choses stupides qui vous voyez sur TheDailyWtf.
Sachez qu'il y a plus d'une façon de le faire. C'est la devise de Perl, mais elle est très générale. Vous pouvez également apprendre le chanson du logiciel libre .
Humilité. Vous êtes un être humain, pas une extension de la machine sur laquelle vous travaillez. Vous ne savez pas et ne saurez jamais tout et vous ferez toujours des erreurs.
Savoir ne pas tout réinventer. La grande majorité des problèmes rencontrés par un développeur a été rencontrée et résolue avec succès par des développeurs plus intelligents il y a longtemps. Ne pas utiliser ces connaissances est la plus grosse erreur qu'un développeur puisse faire. Dans le pire des cas, on ne pourra pas résoudre le problème. Dans le meilleur des cas, on perdra du temps à trouver une solution qui existe déjà.
Goran
Si P == NP
Et l'assemblage, sur une plate-forme. Vous ne voudrez probablement jamais l'utiliser, mais sachant que ce ne sont pas des tortues (ou des objets) tout le long, l'octet s'arrête ici.
Je plaisante bien sûr à propos de NP, mais une compréhension des problèmes réellement difficiles à résoudre de manière problématique peut être très utile.
Comprenez la différence entre l'idéalisme et le pragmatisme, et pourquoi les deux sont importants lors de la conception de logiciels.
Ce sont des choses que j'ai apprises par essais et erreurs au cours de mes études et de ma carrière. Je dirais que ces leçons m'ont bien servi même si c'est parfois une lutte pour surmonter mes propres lacunes.
Comment conceptualiser un problème avant d'essayer de le coder. Concevoir à l'avance est important et avoir la capacité de conceptualiser correctement le problème aide à obtenir une bonne conception.
Humilité. Nous n'arrêtons jamais d'apprendre et nous ne devons jamais supposer que nous savons tout. Il y a toujours quelque chose à apprendre, et nous aurons toujours des moments où nous aurons tort. Il est important de reconnaître et d'accepter cela.
Comment casser le code. Beaucoup avec qui j'ai travaillé (y compris moi) ont codé pour répondre aux exigences et n'ont pas passé assez de temps à vérifier que le code était robuste aux mauvaises données et aux mauvais flux de contrôle.
Comment comprendre le code. Emprunter aux autres n'est pas une mauvaise chose, mais emprunter sans comprendre ce qui est emprunté est une mauvaise habitude. Ce n'est pas parce qu'il ressemble à un canard et qu'il plonge comme un canard qu'il ne mangera pas comme un lion ou BM comme un éléphant volant.
Se mettre à la place du développeur qui pourrait éventuellement se charger du projet - commenter et nommer judicieusement.
Chaque programmeur devrait voir au moins une fois son client/utilisateur. Vous aurez une meilleure vue de l'utilisateur et pourquoi il a parfois des exigences "étranges".
Si vous obtenez un rapport de bogue, ne cherchez pas une personne à blâmer et repensez. C'est peut-être de ta faute.
Récemment, j'ai lu des blogs crédibles de responsables techniques se plaignant que presque tous les candidats à des postes de programmation ne peuvent pas réellement coder, y compris ceux avec des diplômes CS. Si cela est vrai, la réponse à votre question est claire: ce que chaque programmeur doit savoir, c'est s'il peut réellement programmer. Sans avertissement, vous devriez pouvoir écouter un problème simple, puis vous asseoir devant un ordinateur et coder une solution correcte en quelques minutes.
Voir http://steve.yegge.googlepages.com/five-essential-phone-screen-questions
Général:
- Comment apprendre (les choses vont toujours changer)
- Comment communiquer avec des personnes non techniques
- Comment communiquer avec les techniciens
- Comment travailler en groupe
- Comment gérer son temps
- Comment décomposer les projets, estimer et planifier
- Comment objecter ou critiquer sans être une bite
Technique:
- Structures de données de base (listes, hachages, tas, etc.) Même si la langue de votre choix les implémente pour vous, elles ne doivent toujours pas être des boîtes noires.
- Quelques algorithmes différents et comment analyser les temps d'exécution. Pas tout le monde a besoin de connaître le tri, mais pour être honnête, tant de gens le savent, vous êtes en petite minorité si vous ne le faites pas.
La plupart des choses à partir de là sont difficiles à généraliser. Par exemple, une personne travaillant sur des contrôleurs intégrés n'a probablement pas besoin de connaître SQL, de même un DBA n'a probablement pas besoin de connaître la STL.
Chaque programmeur doit connaître les bases du matériel sous-jacent sur lequel il travaille. Quelle est la différence entre les langues avant d'en choisir une. Connaissez chaque centimètre de la langue sur laquelle il travaille. Connaître près de 10 conteneurs différents. Programmation générique. logique booléenne de base, quelques principes mathématiques de base. les 100 algorithmes de base. Et de bonnes techniques de lunettes.
MAIS la meilleure capacité d'un bon programmeur est la résolution de problèmes et la pensée originale et croyez-moi, vous ne pouvez pas apprendre cela, vous êtes né avec.
Outre l'évidence:
Compétences en communication
Graphique, parlé et écrit.
Ne présumez rien. Comme dans la cellule de Stephen King ... Assume fait un cul avec U et moi
Attention au complicateur!
un bon développeur doit pouvoir;
- prendre du recul par rapport au code une fois et regarder la situation dans son ensemble
- expliquer ce (et pourquoi) qu'ils font à un collègue développeur et au bureau PA et au directeur et au directeur marketing ....
- comprendre que si la spécification n'a pas été modifiée au moment du lancement, quelque chose est inévitablement/intrinsèquement incorrect
- prendre le développeur de créativité comme un moyen d'apprentissage
- N'arrêtez JAMAIS d'apprendre
- obtenir toujours un buzz sur le développement de bons logiciels/codes
Sachez quand vous arrêter.
Ne gâchez pas un bon programme par l'embellissement et le raffinement excessifs. Passez à autre chose et laissez votre code se mettre en place pendant un certain temps.
- Extrait de "The Pragmatic Programmer"
Bien que parfois, je ne peux pas m'en empêcher et mes mains me démangent simplement pour l'optimiser un peu plus. =)
Au lieu de pointer du doigt, pointez sur les solutions possibles. C'est le résultat positif qui compte.
(extrait de: "Pratiques d'un développeur agile")
- SQL
- matlab
- une OO langue
- un langage fonctionnel
- un langage de script
- Lex/yacc ou des outils d'analyse similaires
- et peut-être tex, prolog, vhdl, postscript
Quelques heures ou quelques jours d'exploration suffisent. Pas besoin d'être très familier avec ces choses.
Le point principal est d'élargir le voir du programmeur: il existe de nombreux types de programmation qui sont si différents. Ne laissez pas le langage que vous utilisez limiter votre réflexion.
Ma valeur de 0,02 centime ......
Ne pas savoir comment vous allez concevoir/coder/accomplir une tâche pendant que le client le demande n'est pas une raison suffisante pour rejeter la demande du client. Parfois, nous devons accepter de faire quelque chose car le client en a besoin ... et PUIS savoir comment le faire.
Comme Patton l'a dit un jour: "Nous sommes en train de faire l'impossible" ... n'importe quel slob peut accomplir ce qui est possible. Cette dernière partie, j'ai ajouté;))
Beaucoup de bonnes réponses ici, mais je vais en jeter une autre: ne comptez pas sur votre travail pour améliorer vos compétences. De nombreux programmeurs pensent que l'équivalent de cinq ans à suivre des commandes et à corriger des bogues dans un magasin informatique typique, faisant de la programmation CRUD, en fait automatiquement un "programmeur senior". Pas nécessairement: j'aime la ligne de Jared Richardson, "Certains programmeurs ont acquis cinq ans d'expérience. Et certains programmeurs ont acquis un an d'expérience, cinq fois."
Acceptez que c'est finalement VOTRE responsabilité (PAS celle de votre patron) d'améliorer vos compétences, d'apprendre de nouvelles langues et de produire un code bien conçu et de meilleure qualité. Cela pourrait signifier écrire vos propres outils au travail, cela pourrait signifier un projet parallèle réalisé pendant votre temps libre, cela pourrait signifier un nouveau livre technologique par mois, ou cela pourrait signifier contribuer à un projet open source. Si vous pouvez trouver un projet lié à quelque chose qui vous passionne, tant mieux.
Que vous soyez salarié ou entrepreneur ... au final, nous sommes TOUS indépendants.
97 choses que chaque programmeur devrait savoir: http://programmer.97things.oreilly.com/wiki/index.php/Edited%5FContributions
L'existence de http://stackoverflow.com
Comment utiliser Google
Laissez tomber votre ego
La critique n'est pas mauvaise
Embrasser l'échec
Récupérez rapidement après une panne
Pratique, pratique, pratique ....
Avoir hâte d'apprendre des autres
Soyez prêt à changer
Comment comprendre un programme écrit dans un langage de programmation que vous n'avez pas appris.
(par exemple, un Java lisant du code C # sans apprendre C #)
Que vous devez manger votre propre nourriture pour chien si vous voulez vraiment créer un code robuste.
Apprenez LISP.
ESR cloué celui-ci :
"les langues d'une importance particulière pour les pirates comprennent Perl et LISP" ... "LISP mérite d'être appris pour une raison différente - la profonde expérience des Lumières que vous vivrez lorsque vous l'obtiendrez enfin. Cette expérience fera de vous un meilleur programmeur pour le reste de vos jours, même si vous n'utilisez jamais vraiment LISP lui-même. "
Je n'ai jamais vu un programmeur LISP qui ne pouvait pas très facilement choisir une nouvelle langue, bien que j'aie vu beaucoup, beaucoup de programmeurs spécialisés dans toutes les autres langues imaginables qui ont eu du mal à apprendre de nouvelles langues. Il y a quelque chose dans LISP qui étire le cerveau. (Je pense que cela a à voir avec la circularité de la définition de quelque chose en soi.) Comme un contorsionniste, rien d'autre ne semble plus étirer.
Mon collège exigeait que tous les étudiants suivent des cours de langues et de cultures étrangères, y compris des cultures non occidentales. Je suis étonné que nous ayons permis aux gens de terminer leurs études à l'école d'informatique après avoir seulement appris le C++ et Java.
Oui, lors de l'embauche, je me classe de cette façon au-dessus de beaucoup d'autres choses ici. N'importe quel programmeur LISP peut apprendre le "contrôle des sources, les tests unitaires et l'intégration continue" en un rien de temps, mais un programmeur Java uniquement qui connaît ces 3 choses peut très bien avoir du mal avec les fermetures, les analyseurs ou quelque chose dont j'ai réellement besoin. Si vous connaissez l'informatique et la programmation, nous pouvons vous enseigner les processus, mais pas l'inverse - ou du moins, pas à une échelle de temps que je suis prêt à subventionner avec la paie.
En tant que diplômé d'université, il y a tellement de choses que je n'ai pas apprises à l'école, que j'ai dû reprendre par moi-même. Je pourrais continuer sur les différentes choses que j'ai dû apprendre par moi-même, mais cela pourrait prendre un certain temps :) Au lieu de cela, je suggère que les éléments suivants l'emportent sur tout outil ou technologie spécifique:
Continuez à apprendre de nouvelles choses. Vous devez avoir le souci de l'amélioration continue afin de rester vif et compétitif.
C'est drôle, mais je trouve que la compétence la plus importante dans mon travail est la recherche sur Google. Parfois, je google problème avant même d'y penser :)
.
de Wikipedia
The Mother of All Demos est un nom donné rétrospectivement à la démonstration de Douglas Engelbart du 9 décembre 1968 à la Fall Joint Computer Conference (FJCC) au Convention Center de San Francisco, dans laquelle un certain nombre de technologies expérimentales devenues monnaie courante ont été présentées. . La démonstration présentait la première souris d'ordinateur que le public ait jamais vue, ainsi que l'introduction de texte interactif, de vidéoconférence, de téléconférence, de courrier électronique, d'hypertexte et d'un éditeur collaboratif en temps réel.
Chaque programmeur est un programmeur. Il y a aussi les concepteurs et les analystes. Si la phase d'analyse a été sautée, personne ne devrait blâmer le programmeur s'il programme de mauvaises choses ...
Bien sûr, les petits projets peuvent n'avoir qu'un seul développeur, mais vous obtenez le point.
En avalant vos lignes de fierté - apprenez à divorcer vos idées en un clin d'œil si une meilleure idée est proposée.
- Soyez humble d'apprendre de nouvelles choses.
- Participez à la communauté linguistique.
Mathématiques. La programmation n'est qu'un sous-ensemble effroyablement minuscule du langage des mathématiques.
En plus de savoir comment faire le cool, la plaque de chaudière, le borning et le redondant. Sachez et apprenez une chose, vous êtes remplaçable. Une fois que vous aurez surmonté cela, votre travail sera plus facile. Sachez que même s'il y a du "temps sur Internet", certaines choses qui valent la peine prennent également du temps et ne peuvent pas être accomplies en cinq minutes, quoi qu'en pense votre patron.
- Trop apprendre de tes erreurs.
- Regex - que je ne connais toujours pas :-(
- Contrôle de version.
- Où s'arrêter avec des optimisations de performances.
Connaître et comprendre la théorie et les algorithmes. N'importe qui pourrait apprendre à coder, mais seuls quelques-uns deviennent ceux qui peuvent apprendre à coder.
Étape 1. Lisez http://www.pragprog.com/the-pragmatic-programmer .
Étape 2. Gagnez.
Comprenez les choses par vous-même. Ou, au moins, essayez vraiment et honnêtement de résoudre le problème par vous-même. Vous en apprendrez plus que jamais, vous obtiendrez la réponse de quelqu'un d'autre, et ce sera beaucoup plus gratifiant.
La programmation fait des ordinateurs
1) Get input
2) Process input data
3) Generate output
Les ordinateurs sont stupides mais très rapides ..
Et sans électricité "ni source d'énergie pertinente", il n'y a pas de cuillère.
chaque programmeur doit être gourmand en ressources - doit constamment apprendre et s'adapter.
Ma liste:
- Attachez de l'importance et connaissez bien la science et la logique de la programmation plus que la technologie sur laquelle vous travaillez!
- Faites preuve d'empathie pour l'utilisateur final et ne lui donnez pas quelque chose juste pour montrer que vous maîtrisez une certaine technique ou technologie. c'est-à-dire ne lui forcez pas une fusée alors que ce dont il a besoin est en fait un vélo.
La satisfaction des utilisateurs est importante, la qualité du code n'est pas tellement
to understand
to think
to write well
to optemize
..and to cheer up :D
Soyez juste un bon joueur d'équipe - acceptez toujours les commentaires comme une suggestion d'amélioration et non une critique destructrice.
Comment faire face aux gens frustrants sans perdre votre sang-froid.
Lorsque le gestionnaire dépose une liste d'articles sur votre bureau et dit qu'il s'attend à ce qu'ils soient effectués vendredi; Lorsque le DBA exécute un script de chargement de données deux fois; Lorsque l'administrateur système déploie la mauvaise version de votre code; Lorsque l'utilisateur vous demande d'expliquer comment cela fonctionne, à nouveau - C'est à ce moment que vous avez besoin de pouvoir le gérer avec grâce. Parce que vous allez devoir travailler avec tous ces gens, et ça ira beaucoup mieux s'ils ne pensent pas que vous êtes un sale con, peu importe comment faux ils le sont.
Vous ne saurez jamais autant que vous le pensez. Même après quelques années dans l'entreprise, vous continuerez à rencontrer des gens qui en savent plus que vous sur votre domaine d'expertise personnel. Ne vous en faites pas et continuez d'étudier et d'apprendre.
Vous n'aurez jamais appris suffisamment de langues, d'architectures, de paradigmes ou de mots à la mode. Parce qu'une fois que vous pensez tout savoir, quelqu'un inventera une nouvelle (insérez la technologie préférée ici) et vous serez à nouveau déconnecté.
Vous serez ce vieux mec fuddy assez tôt. Coupez-lui un peu de mou et supposez qu'il était une fois, il/elle était à votre place.
Sortez des sentiers battus!
Le monde réel peut ne pas fonctionner de la même manière que lorsque vous étiez à l'école. Acceptez que la façon dont une entreprise gère son développement logiciel ne correspondra pas exactement à la théorie selon laquelle on vous a enseigné.
Prenez le temps de comprendre comment les choses fonctionnent dans une nouvelle organisation. Cela s'applique à tout le monde, mais les diplômés peuvent, espérons-le, trouver plus à réfléchir que les autres.
Les compétences nécessaires pour obtenir un emploi de développement et les compétences nécessaires pour réussir dans un travail de développement sont souvent deux choses très différentes. En faisant des choix de carrière, préférez les endroits où ils sont les mêmes.
Inversement, dans la plupart des travaux, 95% de vos besoins en structure de données/algorithme sont couverts par des classes de bibliothèque. 95% de votre temps sera perdu en traitant du code non maintenable écrit par des personnes qui sont des ninjas à CS mais qui ont les compétences d'ingénierie d'un castor lobotomisé.
Comment un vétérinaire fait son travail!
Aujourd'hui, je suis tombé sur ce livre. C'est un livre très agréable et un bon résumé de toutes les meilleures pratiques.
Penser hors des sentiers battus est généralement une bonne chose! La plupart du développement n'est pas seulement simple.
Comment tirer parti de leur réseau de contacts à la fois en interne au sein de leur organisation actuelle et en externe, car vous ne savez jamais quand vous aurez besoin de quelqu'un pour réfléchir à un problème avec vous ou d'où le prochain projet intéressant pourrait provenir.
Chaque programmeur doit savoir accompagner le code d'une bonne documentation.
Je trouve que le code bien documenté (utilisation généralisée des commentaires intégrés) est plus facile à maintenir et à mettre à niveau.
Lorsqu'un programmeur intègre sa justification pour une implémentation (en ligne avec le code), je peux passer moins de temps à le comprendre et plus de temps sur la tâche à accomplir, qu'il s'agisse d'ajouter des fonctionnalités ou de déboguer d'autres problèmes connexes.