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

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.231.52.27 -- 　　「大哥！你....」 　　「你在以旁門左道的方法，逼自己的劍氣踰越極限﹖」 　　「廢話！」應雄反駁： 　　「什麼旁門左道﹖能夠將最強的功力提昇至無法再上的強中之強， 才是必勝的最佳戰略！」 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.132.117.169