第一周博客做业

自我介绍

我叫谢璟毅，是中国科学技术大学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

问题 然而最熟悉代码的人一般对代码会有先验的理解，从而可能会忽略一些错误。就好像文章写好后找错别字时，本身看可能看半天也看不出来，由于本身对这篇文章太熟了；但若交给一个不那么熟悉文章的人看，可能一下就找到错别字了。