《软件开发者路线图》读书随笔

《软件开发者路线图》读书随笔

昨天是光棍节，现在大家应该都叫双十一了。学校一篇热闹，而我整天都在进行托福考试前的最后复习。今天终于考完了，在出国前这么一段时间都不会太忙，但是时间不能浪费啊，所以看书吧。下了好多“程序员必读书”。今天就开始看第一本——软件开发者路线图，从学徒到高手。一共200页。下载地址在这里：点我

这本书讲了什么

//TODO

安排学习

学习的主要方式当然是会阅读。教材、博客或者论文都是知识的来源。然而现在有太多的书籍而且质量良莠不齐，有时候想读书却不知道该读哪一本，作者针对这个问题提出了一个方案：维护一个书籍列表，用来跟踪打算读的书和已经读过的书。基于分享的精神，可以考虑把这张表保存在公共空间。不仅别人可以从你的书单收益，而且也有可能从别人活得宝贵的意见。
“任何一本书，你能从中获得的最有价值的东西就是一列值得阅读的其他书目。”当一本书重复出现在别的书的参考书目里面，说明你应该把这本书移动到阅读列表的顶部。

作者给的另外两个重要意见是：钻研名著和深入挖掘。特别是深入挖掘。作者给出这样的情景让我感同身受：当被分配任务或者作业的时候，因为有严格的时限，所以人们只学习了足以完成该任务的知识，而没有对问题和知识有深入的理解。有问题就Google，看一篇最易懂的博客，然后复制粘贴样例代码，我就经常干这种事情啊！
只拥有表面知识后果是，作者说，我们可能尝试去解决已经有众所周知解决方案或者根本不能解决的问题。（我有一点不同意的是：这个问题应该只是因为知识的广度不够造成的。在知识的深度上，比如数学的原理，有选择的去钻研应该更高效一些。）
两个解决知识不够深入的方法：接触第一手的资料，了解新知识所在的大框架。
接触第一手资料，弄明白他们当初想要解决的问题。了解思想第一次被表达时的上下文，这是思想的精髓。作者举了RFC文档作为例子。
对于新的知识，“寻找可用于防止新知识的思想结构”。比如，这个背后是否隐含着一种更基本的计算机科学概念，这个方法是否是一种思想的特例。例如：正则表达式和有限自动机的关系。

除了阅读书籍之外，作者还强调了学习常用的工具的重要性。

与人连接

作为学生，平时除了小组完成作业，与人一起工作的机会不同，同人也没有太多机会认识厉害的人（有，但是少）。与人共事不仅是学习，也是一种激励自己的方式。我一直苦于不知道如何认识更多热爱和擅长编程的人。作者在书里给了一些解决方案：

积极加入网络社区，或者线下的聚会。一定保持谦逊，永远努力去跟更厉害的人共事。从他人身上不仅是学习知识，也是学习日常高效的工作习惯。

找一位对开源项目有浓厚兴趣的人，每周安排一个晚上，跟他一起完成一个项目。

如果新加入一个项目同时自己能力有限，主动去完成简单无趣却又必须完成的任务。我曾在另一个地方也听说，通过完成简单的需求来逐渐参与一个开源项目这个方法。

拓宽信息的来源。比如：注册博客聚合器，关注一些大师Twitter（或者微博），订阅在线邮件列表，参加技术大会，写信给读过的书的作者以及网上大量的在线教程

学习方法

不断实践：从类似《编程珠玑》这样的书中找一个练习，接下来的四个星期每个星期练习一遍。思考自己使用的方法的变化以及从中体现出来的问题。

质脆玩具：使用自己最喜欢的工具构件一个最简单的Wiki，功能简单但是保证最高的质量。随后的完善中，根据自己的兴趣尝试让自己的Wiki变得与众不同。到底做什么不重要，只要你实践，学习。

使用源码：下载一个开源项目，阅读源代码。考虑代码的组织有什么道理。尝试重构代码，从而帮助你理解项目。记录新奇的算法，数据结构和设计理念，写一篇博客记下来。

记录所学：写在印象笔记，博客，或者日志上。注意要定期读一读以前写过的东西。

分享所学：教别人是一种非常强大的学习方法。“一个人在教，两个人在学。”把一个知识写成一篇博客，或者将大量知识写成一个系列教程。不要忽略自己的分享给别人的帮助。因为你自己正处于入门阶段，你写出来的东西就更容易被读者理解。

自我评估：技艺不精的人常常不知道自己技艺不精，同时也不善于评估自己和他人的技能。建立机制获得评估自己绩效的外部数据，高效的寻求反馈。例如使用测试驱动开发这类技术，代码复审和结对编程。参加工作面试获得别人对你的评价。