Re: [請益] 新人的訓練

看板Soft_Job作者qrtt1 (null)時間12年前 (2011/09/08 00:48)推噓17(17推 0噓 17→)

留言34則, 18人參與討論串2/2 (看更多)

目前看起來，你還在能自由安排時間的狀態。即使現在覺得相當地悠閒，但事實上有許多準備工作在你踏出新手村之前能做的。 =============================== 觀察情勢與環境 =============================== 這裡不討論人際關係，而是觀察一個 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

推

mocad

09/08 01:21, , 1^F

09/08 01:21, 1^F

推

leicheong

09/08 07:38, , 2^F

09/08 07:38, 2^F

→

leicheong

09/08 07:39, , 3^F

09/08 07:39, 3^F