本文已經過原作者 qrtt1 同意轉載。
原發表於批踢踢實業坊 Soft_Job 板。文章代碼(AID): #1EPw1wG3
原始文章位址：http://www.ptt.cc/bbs/Soft_Job/M.1315414138.A.403.html
作者 qrtt1 (null) 看板 Soft_Job
標題 Re: [請益] 新人的訓練
時間 Thu Sep 8 00:48:56 2011
───────────────────────────────────────
目前看起來，你還在能自由安排時間的狀態。
即使現在覺得相當地悠閒，但事實上有許多準備工作在你踏出新手村之前能做的。
觀察情勢與環境
這裡不討論人際關係，而是觀察一個 task 是由何處產生的，最後導向何處。
如果是做產品的，可能會是 QA 要求修 BUG，可能是進行 PM 規劃的進度。
如果是新創的公司，可能會是一段 brainstroming 後的概念證明實作。
這些流程大概是你工作好一段時間會有的流程，
但初始可能只是分到別人 task 的一小塊。
比較少會有全新的內容到你手上，
除非大家已經對你的 coding style 與程度有足夠的理解。
在剛開始，你還沒有足夠的知識處理全新的局面時，
你可能會被指派到分析 Bug 的 root cause，
如果分析的出來就能試著解看看，如果分析不出來，你得練習你的回應方式。
『不知道』、『不懂』都是最簡單，最輕鬆的回應。
但這對你的信任感與可靠度提昇沒有幫助。
如果你想要能處理更多豐富且多變的問題，
你得在這理的回應練習一下。
在毫無頭緒的時候，有幾種方式獲得幫助。
- 一定要把有 bug 的程式執行起來。
- 對流程毫無概念時：
一定要讓程式跑起來，善用 debugger 配合單步追蹤。
並試著寫下你對流程的理且，配合程式命名慣例，
或註解上用到的 term 去相互解釋。 - 即使用了 debugger 也無法理解流程，
也許能試著回到再原始一點的 log message， - 若上招也起不了作用，只好麻煩同事給你一個清晰的輪廓。
(若有人願意講，你最好筆記下來。這是難得的機會)
但在這一步之前，你最好能描述一套你自已的理解，
並說明試著用這個理解的方式去解釋、或分析 bug 成因似乎對不上。
請同事指出你的盲點。
註：也許有人不好意思問，但只要想著
『如果我會了，就是減輕大家的負擔。』就會覺得這麼做是正確的。
註：對自己描述自己的思路是相當有益的。
對自己的理解再理解，有時能發現自己的盲點，或是新的選擇。 - 如果你已經拿到『版本控制系統』與『議題追蹤系統』帳號，
試著找詢相關專案的 bug，取出 bug 解決前的版本，試著分析問題看看。
有了自己的見解後，你再去比對修正版本的解法。
註：如果還沒有跟同事混熟，這時的解法如果有不同，就不用硬著頭皮去問了。
依個人成長背景的不同，偶爾會有想要抵抗陌生人的情緒出現。
準備好你的工作環境
在進行上一段修煉的同時，你應該會接觸到同事使用的開發環境。
- 如果打字太慢，請有空就練習。雖然開發軟體不是打字而已，
但不要讓打字的不流暢感阻礙了你開發的流暢度。 - 準備你的 IDE。這裡的 IDE 並不是單純指 Visual Stuido 與 Eclipse 這類東西，
而是輔助你工作流程流暢的各種設置。
以我個人的情況來說，大部分時間在寫 Android Library 與 NDK，
在 Java 部分是使用 Eclipse 為主要開發介面，
而 NDK 部分，我是使用 vim 寫 c 配合 ndk-build。
要怎麼讓這二組我所習慣的不同語言的開發環境緊密結合呢？
特別是它們二個產出的檔案得複製到約定的位置才能正常運作(當然也包含相依的檔案)。
這裡我利用 Eclipse + Ant Builder Script 做一些自動複製的行為，
讓 NDK 部分編譯完成，只要 refresh project
就會自動將 Eclipse 管理外的檔案連帶做一些額外的動作。
利用這些用來將你各種開發環境『黏』起來的 script，才是完整的『IDE』。
因為我們不能只在別人預先提供好的 Eclipse 下流暢，
或是在 vim + c + make 的情況下，『個別』地流暢。 - 善用 IDE 內圖形化的除錯介面
有些人知道 IDE 自動完成很好用，但卻從來沒用過 debugger。
對 debugger 的掌握最好要知道：- 編譯出來的程式是否含有 debugger 所需的資訊 (turn on/off)
- 如何跑一般模式與 debug 模式
- 了解 breakpoint：
如何設定、如何列出已設的 breakpoint、如何刪除、如何暫時停用。 - debugger 執行到 breakpoint 時，停下了。如何查看 breakpoint 之前的變數內容。
- step into, step over, return 或切換不同 thread 的功能
- 使用 Watcher
- 記錄環境設定與備份檔案
有些時候，我們會面臨不得不重建環境的情況。
而這個動作，可能在剛進公司時，前輩會比較有耐心教你。
你得妥善記錄，除了重灌 OS 的時間，你最好能在半小時內完成這個動作。- 環境變數設定(PATH, etc ...)
- 安裝各種 SDK、下載需要的 library、建立開發用 server (httpd, db, memcached ...)
- 配置 IDE 與 glue script
- 安裝版本控制系統 client，並確定能由版本控制系統取回你需要的程式
(只需確定能 checkout/clone 即可，因為加上下載時間，你可能來不及。
如果立刻取得程式碼是重要的，那請在移機前備份，或放在重建時的第1步做)
熟悉那搭起高樓的磚頭
- 熟悉函式庫
觀察公司使用那些 library 或 framework。
不管他們是不是 3rd-party 的產物，專案裡總有些基礎的材料。
熟悉他們總是會有好處的。 - 熟悉例行公式的相關實作
以 Web App 為例，將有一部分實作是與資料庫讀寫相關。
對你個人來說，這些例行公事的基礎是否掌握住了？
保存你的成果
在先前提到『版本控制系統』，雖然這不是每個公司都有。
但這會關係到你如何處理每日的工作成果，並且是否容易回溯到特定的狀態。
我個人很重視版本控制系統的使用：
版本控制隨筆 (1)
版本控制隨筆 (2) 關於開發支線
如果你的公司有版本控制系統，你能先熟悉它的所有操作方式。
而學習的重點很簡單，你得學會版控的 CRUD。
以 Mercurial: The Definitive Guide 來說，
它除第一章的基本教學，還有提供：
Chapter 5. Mercurial in daily use
讓學習的人能用較短的時間，先掌握一些基本指令來處理日常工作所需。
就算你使用的版本控制系統不是 Mercurial，
你也可以透過這樣的段落安排抓出一些必學的要點。
如果你的公司沒有版本控制系統，或是版本控制系統很難用！
通常與『分散式版本控制系統』合用會是一種快樂自處的方式。
如果你對版本控制系統沒有概念，就想像成是電玩裡的金手指吧。
想在任何時間點都備份，並且能回到備份的時間點重新來過。
簡單地說，你得在新的環境照顧好你自己。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
本文已經過原作者 qrtt1 同意轉載。
原發表於批踢踢實業坊 Soft_Job 板。文章代碼(AID): #1EPw1wG3
原始文章位址：http://www.ptt.cc/bbs/Soft_Job/M.1315414138.A.403.html
--
補充相關連結：
- 打字練習網站：
- 版本控制：
- TortoiseGit, 分散式版本控制（雖然我自己目前還是用 TortoiseHg，但打算找機會跳 Git）
留言列表
文書處理 (5)