分享:給年輕程式設計的忠告

  • 當你遇到問題時,花個 15 分鐘常識尋找答案。如果還是不行,就問問別人吧。
  • 問問題並不是丟臉的事情。
  • 但如果你因為你問問而感到自豪,這就不太對了。
  • 每次修改程式碼都要讓它變得更好,無論是增修文件的說明、語法細節、設計模式或補上測試程式碼。都會有人相當感激你,而這個人也可能是未來的自己。
  • 測試程式碼也需要註解。
  • 找到仍讓自己抽離工作的方式,堅持下去。
  • 程式設計師最好的進步方式就是寫是程式。
  • 別忘了,閱讀程式碼也是使用軟體的一種方式。
  • 不要排斥程式碼複查、討論設計架構,這是團隊合作讓程式碼更精進最好的方式。
  • 單純的解讀每個人的想法,儘管對方可能並不單純,但這會讓你活得快樂一點。
  • 爭論時,問問自己這個問題是否值得,否則你將會花許多時間在爭論一個函數的命名。
  • 命名仍然是相當重要的,約定成俗也是相當重要的。
  • 溝通的軟實力比你撰寫程式碼的硬實力還來的重要,注意任何人或是事的暗示。
  • 為自己做的事情感到驕傲,但失敗時會一次摧毀這份自豪。
  • 你將會失敗,恩對,而且很常這樣。測試的範圍不夠廣泛,會忽略掉一些細節,會完全錯過掉某個使用案例,你的工作將會搖搖欲墜。
  • 別小看自己,學習犯錯也是一種學習。
  • 想法 > 對話 > 電子郵件 > 文件 > 程式碼。
  • 按上述的順序改善或加強。
  • 所有的文件都應同步被更新。
  • 就算要來不及了也別忘了程式碼的可靠度。
  • 凡事都有原因:一個六年前撰寫、功能不明的爬蟲程式,有可能當時他們只有兩天的開發時間。在遇到這種情況是請先假設這個開發人員不是無藥可救的大笨蛋,這樣會讓你好受一些。
  • “無聊” 比 “聰明” 更能提升程式碼的品質。
  • 任何程式碼都有技術債,就算是一個只用一次就會刪掉的指令,或是維持現狀並不會再改變的程式碼,都是未來的技術債。
  • 自己衡量自己的實力,並投入時間在你覺得正確的方向上。每個人都有自己的優缺點,空泛且不專精的學習和鑽牛角尖在某項技術上都不是好事情。
  • 花時間學習使用各種工具並不丟臉。
  • 任何能幫助你工作的東西:程式語言、既定的程式碼風格、編輯器,甚至耳機、椅子、終端機的字體、桌面背景、咖啡等。
  • 盡可能地幫助更多人。

翻譯自:jmduke 部落格

If you are faced with a question to which you don’t know the answer, spend fifteen minutes looking for the answer yourself. Then ask someone else.

There is no shame in asking questions.

There is a great deal of shame in being too proud to ask questions.

Always leave a codebase cleaner than you found it — whether it’s adding documentation, cleaning up syntax, or fixing an edge case. Someone will be grateful, even if that someone is Future You.

Tests deserve comments, too.

Decide what you’re willing to leave at work. Stick to it.

The best way to improve as a programmer is to program; the best way to improve as a software developer is to use software.

Never forget that one can use software by reading it.

Don’t treat code reviews or design critiques as a adversarial process; recognize that its a cooperative effort to refine artifacts into their best possible form.

Assume that everyone has the best intentions. Even if they don’t, it’ll make your life easier.

When debating an issue, ask yourself “how much do I really care about this?” Otherwise, you will inevitably spend time and energy debating whether something should be named FooWidgetProcessor or FooWidgetHandler.

Sometimes, though, it’s important to decide whether or not something should be FooWidgetProcessor versus FooWidgetHandler. Naming is important; conventions are important.

Communication is a more important skill than code. Be cautious of anyone or anything that implies otherwise.
Take enough pride in your work to be happy when it succeeds but not enough to be destroyed when it fails.

Your stuff will fail, like, a lot. The test data won’t be extensive enough; there will be an edge case you missed; you will miss a use case; your work will not be resilient enough or robust enough or gracious enough.

Don’t think less of yourself for it; learning through error is still learning.

In ascending order of robustness: thought, conversation, email, documentation, code.

Optimize for robustness.

All documents are living documents.

Don’t confuse reliability with uptime.

Everything happened for a reason, even if it’s that six-year-old cron job that checks for emails containing the word “yes”, and even if the reason was “we had to ship this feature in two days.” Pretending that past developers are incorrigible bogeymen is only going to cause you more grief.

“Boring” is a better heuristic for code quality than “clever”.

All code is technical debt. Even if its a CLI that you think you’ll use for a one-off job and then delete; even if its a ‘stop-gap measure’. (Stop-gap measures stop being stop-gap measures as soon as they’re promoted to prod, at which point they become the status quo.)

You make what you measure. Invest a lot of time in making sure that you’re measuring the right things.
Everyone knows some things better than you and some things worse than you. Investing too much in either is a bad idea.

There is no shame in investing in your tools.

Consider everything that helps you work as a tool: your language, your code conventions, your IDE, your headphones, your chair, your iTerm font, your desktop background, your coffee.

Help as many people as possible.

分享到