编程的精义

开发是一个阐述思想的过程，把想法转化成逻辑，最后变成代码，就是整个开发的过程。

编程，是开发的一环，也就是把逻辑转化为代码的过程。

正如文中所说的那样，“程序=算法+结构”。算法是顺序，分支，循环的组合变化，结构是思想在程序中的映射。因此，代码在编程里是最为easy的一环。

嘛~~第一章大致就是说了这么一个内容，强调了在编程过程中最为重要的反而是思想，逻辑。掌握语言和转化成代码其实都是最为容易的事。PS:是不是说我只要懂得足够多就能当PPT架构师了:)

当然，这里说代码是思想的转化自然是没什么问题的，然而写代码同样是一个磨练技艺的过程，怎么写更好，怎么写更易懂，怎么写更容易维护，这也是一个程序猿需要不断去锻炼学习的。PS：这一段与原文主旨没什么关系，只是忽然想到就加上了。不过话说回来，在这方面如果能做到尽善尽美，这让接盘子的人会非常开心吧(o゜▽゜)o☆

是懒人造就了方法

“懒人”是相对于“愚公”那种“勤快人”而言的，这里都加上了引号，主要还是因为这里都不是明面上的意思，“懒人”不是真正意义上的懒人，“勤快”也并非是什么好事。

对于开发而言，一味为了完成而做重复的工作是很可怕的，虽然结果可能没什么问题，但是其中的效率和后续要做的工作可能远高于开发时的工作量。

停下来，做一个会思考的“懒人”在开发中是很有必要的，抽象，方法的调整，不管是对于开发还是后续的维护，都是有益的

项目管理那些事

我是学管理出身的（不过是信息管理，O(∩_∩)O~），我的管理学老师曾经跟我们说过，“管理学是对人的研究”，管理学不同于其他研究性的学问，更多的关注与人的分工和人与人之间的关系。而对于一个技术出身的人，去做管理，不仅仅是角色的转变，做事方式、承担的责任都会发生变化。

作为项目管理者，你就是项目的总负责人，如果项目出了问题，你就是责任的承担着，将锅甩给谁都不好使，因为别人看到的就是如此：你带的团队，你接的活，你的项目失败了！仅此而已。

但往往失败都是能带来成长的，所谓失败是成功之母，不过并非对于所有人来说失败都是成功他母上的XD，只有能够从中发现问题，汲取经验的人，才能够更进一步。所以，项目失败之后不要总是埋怨这个，埋怨那个，更多的应该反思一下自己哪个环境没弄好，是核心人员选的不对？没有按照计划严格执行？团队沟通做的不好？还是自己没有起到好的带头作用？

说到沟通，从我的感觉来说（毕竟还没做过大的项目呢，/(ㄒoㄒ)/~~ ），越是大的项目，越有可能发生沟通上的问题。为什么这么说呢，简单点来说，就是人多事杂。不同的模块干活的人可能有好几个，他们之间沟通可能是没问题的，但是不同模块的负责人就不一定了，可能这边一个事完了，就继续搞下一个了，但是依赖有更新，接口有变更，这个没及时提，就会造成一些问题。这个只是一个非常浅显的例子，但是实际开发中类似的事情也并非不会发生（或许会很频繁也说不定XD）。

后续的巴拉巴拉

在后续的内容里作者讨论了人、组织以及关乎项目成败的种种因素，但看完之后隔了一段时间发现还有印象的内容就只剩下“造轮子”的讨论了（莫非我没有管理人员的命ORZ）。

对于重复造轮子，可能对于很多开发者或者跟我有相似工作经验的开发者而言（我主要做的是交付项目），造轮子是件很没有意义的事情，只有快速找个轮子把任务完成才是最为关键的。

然而，用了诸多轮子之后发现，当你遇到问题，你还是不得不去把轮子拆开，看看到底里面是怎么做的，然后一通调整，最后，你会发现你把原理弄明白了，然后自己重新做了一个轮子(lll￢ω￢)。

所以说，重复造轮子并非毫无意义，当你已经成了一个大神，应对各种问题都胸有成竹，那自然重复造轮子就显得是一种时间上的浪费，这是可耻的。可是大多数人都不是大神，很多东西并没有一个成熟的体系化的解决方案，因此，自己造个轮子不但学了技术，更是对自身实力的一种磨练和提升。

后记

其实在写最后一段内容的时候，离读完这本书已经过去了很长时间了（大概有一个月吧），很多后续内容也没有去仔细品味琢磨。不过从这本书中还是学到了很多东西，不管是技术上的还是管理上的，虽然书中并没有给出问题的解决方案（这点很遗憾），但却留出了很大的思考空间。总体而言是一本很有深度的书籍，我的水平不够就不进一步评价了，喵o(=•ェ•=)m

嗯，就这样吧，实在不知道写啥了XD