自我介绍
我叫谢璟毅，是中国科学技术大学16级数院应用数学方向大四学生，现在MSRA VC组实习。平时喜欢唱歌（在没有人的时候），喜欢看电影，喜欢跑步和骑行。至于编程方面，机器学习、Web 前后端开发、Android 开发、PLT 等，个人都有所接触（算起来我已经有9年码龄，老了老了~）。最擅长 Python，喜欢鼓捣函数式编程语言。性格喜静，喜欢一个人独处。个人感觉这种性格既有好处也有坏处，好处是它让我拥有了较强的自学能力（因为有时不好意思问人），坏处是让我常常沉浸在自己的小世界里，狭窄了视野。
p.s. 个人平时不用博客园写东西，而是在自己的博客 https://www.hsfzxjy.site/ （虽然长草了一段时间了）。
现状经验和计划
| 技能 | 当前水平 | 目标 | 实现方法 |
|---|---|---|---|
| 程序理解 | 6 | 8 | 多阅读优秀的代码，同时掌握正确的阅读方式 |
| 程序设计 | 6 | 8 | 在实践中养成动手前先思考的好习惯，养成良好的编码习惯 |
| 单元测试 | 3 | 6 | 通过书籍或相关博客了解单元测试的方法论 |
| 代码复审 | 3 | 6 | 多参与类似的工作，在实践中学习 |
| 不同进程/线程/平台之间的联系与差异 | 3 | 7 | 通过相关文档学习 |
| 个人源码管理 | 6 | 8 | 多实践 |
心得
“你为何要来上课并认真参与”
专注于课堂不仅是为了获取知识，更是培养自己专注力的一种手段。因此即使某门课授课老师方式不对/讲的不好，这也不能成为翘课/不听讲的理由。因为这么做其实是让自己缺失了另一种训练——即专注力的训练。诚然不可否认专注力训练有多种方式，也不可否认某些学生有较强的自学能力，但这对大多说（大）学生而言是不成立的，上课认真听讲仍然是一个好的选择。
“师生关系”
赞同文中把师生关系喻为 Coach / Trainee 的观点。每个学生都怀着不同的目的参加训练/学习，因此老师也不能简单地一视同仁，即一致地严格要求或者一致地放水。老师为不同目标的学生提供不同程度的帮助，学生也根据自己的目标付出相应的努力。
关于参考和抄袭
个人认为，只要做法符合相应的标准（代码的 License，写论文注明出处，符合相关法律）便不算抄袭。人类如今的辉煌也是后人踩在前人的肩膀上走出来的，基于他人的想法/作品创作本没什么，关键在于手段要合理。
几年后，你可以做学术研究、做软件项目、做其他专业的工作，做公务员，出国深造，回家继承家族企业... ，不同的选择有不同的努力方向, 你今天是怎么为将来准备的？
个人对 Research 有热情，但更倾向于产品的开发。最理想的情况是毕业后找一个高薪（最好也是压力不大）的公司做开发，待财务自由后转到低压的环境，用业余时间干喜欢的事，陪喜欢的人。
做独立开发者我也想过，但真的太难了。微博上的 @Easy 大佬是一个成功的例子，但我自认为达不到他的高度，尤其在执行力和需求分析方面。而且一个人包揽所有事其实也是很累的，在这么多事里我感兴趣的只有开发——至少现在是如此。所以我还是老老实实打工吧。
代码量
（时间太久远了，无法精确到100行）
| 语言 | 代码量 | 来源 |
|---|---|---|
| Python | 20000+ | 若干网站的后端，学校的数值代数、运筹学、数学建模课程，机器学习研究项目，各种小脚本 |
| Javascript / Node.js | 10000+ | 若干网站的前端，各种小脚本（在 Web 技术栈里 JS 更顺手），Chrome 插件等等 |
| Pascal / Delphi | 8000 | NOIP，Win 32 时代各种小程序 |
| C / C++ | 6000 | 学校 C 语言，数据结构，算法基础课程 |
| Win32 ASM | 4000 | 早年因个人兴趣用汇编写过若干程序 |
| CSS / Less / Sass | 3000 | 若干网站前端 |
| Rust | 2500 | 个人兴趣 |
| Shell | 1000 | 各种小脚本 |
| Haskell | 500 | 个人兴趣 |
个人编程接触的早，由于很享受用代码创造新事物的感觉，一直以来都有保持编码的习惯，也积累了很多经验。但个人更希望能提升编码能力之外的软技能，比如需求分析、团队领导能力等等。这对未来的职业也是必要的。
你现在的道路很多前人曾经走过，他们有什么经验教训？请从博客末尾的文章列表任选一些阅读，针对其中一篇发表感想。
https://book.douban.com/subject/4006425/discussion/22803733/
我感觉自己一直一来都缺乏时间规划的观念。每天开始的时候都是很多事情并行操作，但有时到了最后每件事情都会出一些小问题。这个其实就是没有优先级概念的体现。我很认同这篇文章中的观点，即每天应该给要做的事情排序，然后按顺序为每件事情安排一段专属的处理时间。在特定的时间就做特定的事情，这样才能高效地完成任务。
关于《构建之法》的疑问
软件团队的人员也会流动，新的成员要尽快读懂已有的程序、了解程序的设计，这叫做程序理解（Program Comprehension）。 ——P18
问题 当面对一个庞大的，设计不算良好，代码风格不算规范的代码库时，应该如何快速地了解自己需要了解的部分？符合以上描述的代码库其实是很常见的。很多时候我们只需要关心代码库的一部分，也就是和自己工作相关的部分即可。但是不良的设计可能增加了模块间的耦合度，从而使我们难以界定什么地方该阅读什么地方不该阅读。同时不良的代码风格可能会拖慢我们阅读的速度。这时应该怎么办？
PM 的能力要求和任务 —— P195
问题 个人十分赞同此处对 PM 应具有的能力的描述，但不知道应该如何培养这种能力，尤其是预期用户的新需求。
早年本人曾为社团活动写过一个实时会议系统，其需求仅有“大概一两百个用户，需要支持一对一聊天，需要支持群聊”如此。我需要将此扩充成一个完整的系统。这其中其实还有诸多隐式需求是用户需要的，但是用户自身不知，或是表达不出来。其中令我记忆犹新的是会话列表的设计。由于可能存在上百个会话，我需要设计一个便捷的检索系统。当时我以自己的思维方式采用了这样一个的方案，即放置了一个支持拼音首字母检索的输入框。但网站上线后有些人反映这个功能很难用，他们更愿意接受“依标签归类好，然后用鼠标点”的方式。这其实体现了不同人群的不同习惯——我作为编码者是巴不得任何操作都可以用键盘解决，但对于普通人而言鼠标可能是更适合的方式。这就是一个需求预测错误的例子。
现在开发人员手头上有不少修改，分别属于不同的具体任务，那如何将这些修改迁入源代码控制系统中呢？——P230
问题 此处提到的仅是是添加新修改的流程，此处对应的修改应该都是比较小的修改。但若新需求与现有的架构不融洽又该怎么应对呢？我认为这是一个常常会遇到的问题。有时为了快速开发，或是因为时代的限制没有预测到新需求，我们没能将架构设计的便于扩展。此时若直接加入新需求，则会增加现有代码的“坏味道”。长期以往，可能会形成所谓的“只有上帝才看得懂”的代码。适时重构是一种选择。重构有着较大的时间成本，并且有不可预见的风险；但另一方面，重构可能给后续的开发带来便利，降低出错的概率。遇到这种情况，是应该重构，还是继续加入新代码呢？这其中我不清楚应该如何选择。
快速原型调研 （Quick Prototype）—— P166
问题 在项目的初期通常我们会设计产品的原型，可能是为了以此快速征求用户的想法，也可能是来自用户的要求。原型通常是一个简陋的、初步实现产品杀手级功能的一个程序。我的问题是，当产品进入正式研发阶段时，我们应该怎么对待这个原型程序呢？我们是应该基于原型的代码开发产品，还是从头开始写？感觉如果是从头开始写，相当于有些浪费了写原型的劳力。
单元测试应该由最熟悉代码的人（程序的作者）来写 —— P40
问题 然而最熟悉代码的人通常对代码会有先验的理解，从而可能会忽略一些错误。就好像文章写好后找错别字时，自己看可能看半天也看不出来，因为自己对这篇文章太熟了；但若交给一个不那么熟悉文章的人看，可能一下就找到错别字了。