程序员的自我修养(1)

前言

回家之前刷了两天图书馆，找到几本好书，仔细阅读后做下读书笔记，然后准备动手开发之前都先过一遍。来让自己能够训练出写高质量的代码。第一本来自《The pragmatic programmer》(中文名《程序员修炼之道-从小工到专家》)

本书引申推荐书籍 《代码大全》 《UNIX编程艺术》 早读课微信群里有小伙伴推荐《编程匠艺》，建议配套阅读

正文

在所有弱点中，最大的弱点是害怕暴露弱点。注重实效的程序员对他的职业生涯负责，出错或者交付晚了都是无法避免的，我们必须诚实面对。在考虑回答之前，先在脑海里预演一遍“我试过这个了吗”，“除此之外我没有办法解决了吗”要提供各种选择，不要找借口

dont’t repeat yourself！一定要阅读别人的源码和文档。

你的知识和经验是你最重要的职业财富，遗憾的是它们是有时效的，随着知识价值的降低，你的价值也在降低。因此你需要经营你的知识资产。

1.定期投资（这里我提供几个思路：参加会议，参与社区，阅读新书，看新文章）

2.多元化是长期成功的关键。（这里我的解读有两种，一是你需要掌握的技术是多元化的，不要局限于某个技术。二，你的业务需要多元化，长期从事开发某个业务会让你的脑袋僵化，比如开发系统的可以去尝试自己写个小游戏，PC端开发可以考虑折腾下移动端开发，让脑袋不停运转起来。）

3.定期性的重新评估和平衡资产（因为你所掌握的是有时效的，技术发展很快，你需要时刻把握新技术潮流，凭借扎实的基础快速上手。）（因此我觉得最关键的是不要将自己视为某个职位的开发，而是将自己视为程序员，我现在从事某项专业工作开发，如果需要，我可以随时转为别的开发，因此牢固的基础是必备的。）可以定个目标:1.每年至少学习一种新语言2.每季度阅读一本技术书籍3.阅读非技术书籍

4.上课（这里可以是mooc，国内外的都可以，在现今知识大爆炸的时代，你想学是都可以学的。花钱的免费的都有。）

5.跟上潮流（这里我提供我的部分方法：每天关注本职工作开发领域的文章和新闻。在程序员招聘贴中看新技术的动态，对比自己掌握程度，薄弱的自己补。）

6.设法把你学到的用到你的当前的项目中，(比如学会了面向对象，就用其方式编程。学会了设计模式，就用不同模式设计接口，自己感受一下哪种更适合。)

曳光弹：我们需要找到某种东西，让我们能快速，直观和可重复的从需求出发，满足最终系统的某个方面请求。（类似于开发一个将接口结合的结构，它一开始只有单一功能就是连接端对端接口。但是一旦完成，你就有了可演示的产品，可扩展的架构，随即你只需要把预留的内容填充完毕即可。）

原型制作是一种学习经验，其价值并不在于所产生的代码，而在于所学到的经验教训。适合制作原型的有：架构，已有系统中的新功能，外部数据结构或内容，第三方工具或组件。性能问题。用户界面设计。

训练自己，编写出足够好的程序。你所制作的系统的范围和质量应该作为系统需求的一部分规定下来。(质量是个抽象，但其实大多数情况下应该是可控的，比如让你的代码更简洁一点，让你的接口更语义化，从小细节定下质量规范然后坚持下去。)

严格遵守正交性(改动A，绝对不会影响B)让你的代码保持解耦，避免用全局变量，避免写相似的函数（参考«设计模式»策略模式）。修改BUG的时候也是评估整个系统正交性的好时候，当你遇到问题时，评估修正的局部化成都。运用正交性原则，可以降低各组件间的相互依赖。（这点我觉得尤其适合你开发中期的时候重新审视你的项目代码和组件依赖。）

要持续不断的观察周围发生的事情，而不是你自己在做的事情。（偏个题，作为独立开发者需要关注的是开源社区，还有新技术，新思想。）

避免考巧合编程，要深思熟虑的编程：

1.总是意识到你在做什么(这点很重要，因为往往你在写功能模块的时候写着写着陷进去，太投入以至于忘记初衷是做什么，可能你的功能越写越多，但是这些都不在需求之内。)

2.不要盲目编程(开发之前做好计划，编写文档，画UML图，或者思维导图，将你的思路一个个罗列出来整合。当然小黑板方法也是可以的。)

3.按照计划行事(千万不要多事，就是你必须尽量在开发之前把需求标明，不然你会在开发过程中时不时多一个需求。。。然后陷入破窗)

4.依靠可靠地事物

5.为你的假定建立文档

6.为你的工作划分优先级，把时间花在最重要的方面。如果你的基本原则或者基本设施不正确，其他都是空的。

7.不要做历史的奴隶，不要让已有的代码支配将来的代码。如果不适用，可以把所有代码替换。准备好重构。

架构原型中解答具体问题:

1.主要组件的责任是否得到了良好定义

2.主要组件的协作是否得到良好定义

3.耦合是否最小化

4.你能否确定重复的潜在来源

5.接口定义和各项约束是否可以接受

6.每个模块在执行过程中是否能访问其所需要的数据，能否在需要的时候进行访问（这段让我思考到我们设计分析需求的时候往往是凭借个人经验去组合模块，但是一些潜在的比如约束等等都不大会想到，当然这些我也是在软件工程这门课备考的时候所看到的，这对于开发的确是起到引领性的作用。）

规划你想说出的东西，简略记下你想要交流的想法，并准备几种测试将讲清楚。了解你的听众：

1.你想让他们学到什么？

2.他们对你讲的什么感兴趣?

3.他们是否具备经验？

4.他们想要多少细节?

5.你想要让谁拥有这些信息？

6.你如何促使他们听你说话？

你说什么和你怎么样说同样重要。

批判地思考你读到的和听到的，你需要确保你资产的至少是准确的，没有受到炒作或者跟风的影响。（这点全靠经验，该交的智商税都少不了的大家。想要少交多读书多实验。）

准备重构之前考虑：1.是否重复2.非正交的设计3.过时的需求4.性能

开发项目时的心理有时候决定了你的项目衰败。（这点深有感触，有时候开发周期延长或者自己开发之前没有预设好风险，就会出现破窗户，然而最后又要逼着自己去修复使项目达到最基本可运行的状态。）当出现第一个破窗户时不要等到情况迅速恶劣化，而是一开始就采取行动使情势处于可控状态。

总结

在我独立开发过程中，我往往遇到的问题不是技术问题，而是架构问题，当你想转型将代码逻辑组织关系提升一个层次，会发现发自内心的无力，但是阅读这本书的过程中我发现了我该从哪些方面入手去突破。因此阅读经典的意义就在于此，你往往束手无策的时候它给你点亮一盏灯，让你明明接下去的路该如何走。