阅读时间：2018年2月5号
这次主要是读完梦断代码的的前4章之后，记录下来所得到的感悟。
不知道是不是因为没有经历过真正的软件设计，我在读梦断代码的时候感觉到明显的吃力，尽管已经读了大概有4章，还是没有从这4章中提取出一个大致的主线。如果说有的话，就是关于两点：1.软件是个黑洞，无数的公司，企业全都栽在了这个上面；2.关于Chandler的设计，作者好像是以这个软件作为一个模型来揭示关于软件行业的问题。
首先，来说说第一个问题。在没有接触这个之前，我确实是没有想过，软件会是很难，确切的说是软件工程很难。因为软件很难这句话其实是有歧义的。似乎每个人都可以设计一款软件，在借助一个very easy的编译器，实现一个简单的操作（当然复杂的操作可以由专业人士来实现）。总之，如果单论一个软件，其实不难。最为困难的是，木有足够的资源和时间可以浪费。毕竟就算没有资金的限制，没有股东们一看无法盈利就掐断供给的行为，须知人的需求也是在不停的改变的。没有人会为了一个工程等到海枯石烂，而没人用的工程本身就没有价值。
为了实现软件的实效性，先人做了很多的探索。就书中观点，依次是布鲁克斯定律：“往已经延误的工程中填补人力，只能让工程继续延误。”李纳斯法则，“低成本，接入互联网这样的网络，让开发者能够迅速建立可信的沟通通道。储存可以被开放访问的共享知识和代码池水；形成良好的合作风气，尽快的增加合格成员”。两个相反的观点。也有人提出说等级化的管理才是控制桀骜的程序猿的最佳途径。当然，就现在的情形来看，现在的企业家很明显采取的是李纳斯法则所述的观点，不过结果依旧不怎么尽如人意，在后面，书中列出了完成工程的比例，依旧有超过三分之二的软件没有按时按照要求交付。这是对人的管理。
至于对代码的管理，也分出了两个观点：一种就是大教堂式的开发，也就是传统的开发模式，封闭自己的源代码，只让固定的人看到自己的源代码。这样做的优点很简单，保护源代码的版权，就能保证自己的产品的收益。并且能够按照一个指定的方向发展，不大会偏离方向，集中力量只做一点。至于缺点也很明显，没有别人看不到源代码的情况下，只能等待开发的公司自己更新版本，修复bug才能让自己的软件，或者依赖于该软件的软件重新运行。同时，几个人的团队总是比不上所有的人都能参与开发出来的软件，因为相互之间的交流可以诞生思想和灵感。
另一个也是我比较喜欢的一种，那就是代码开源（尤其是对于我这样的小菜鸡来说，代码开源真是太重要了，可以学到很多）。这个优点我就不多说了。
最后呢，还有一个小点，那就是在agenda之魂中有一个非常重要的观点，那就是先扔进计算机，延后处理。也就是用户可以随意输入数据，然后按照用户自己定义的方式进行查找，这个功能我感觉到现在还是一种bug级别的应用，简直不是给人用的。