※ [本文转录自 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，
你也可以透过这样的段落安排抓出一些必学的要点。
如果你的公司没有版本控制系统，或是版本控制系统很难用！
通常与‘分布式版本控制系统’合用会是一种快乐自处的方式。
如果你对版本控制系统没有概念，就想像成是电玩里的金手指吧。
想在任何时间点都备份，并且能回到备份的时间点重新来过。
简单地说，你得在新的环境照顾好你自己。