时间轴+读书笔记

        * 读这本书真得是消耗了太多的精力，倒不是书不好，而是自己太浮躁，很多书读不进去。
        * 第一次借这本书应该是2012年，没看几页就满30天，还。
        * 第二次是2013年初，毕业前，还是读不进去。
        * 这一次是2014年2月，在独墅湖图书馆借的，超期60天，终于字啊5月5日看完。
        * 其实真正看这本书，加起来也不到一周时间，27万字的非技术书籍，不需要花太多时间，可我这过去的90个/800多个日夜，都做了些什么呢？
        * 喊了无数遍浮躁，从来没安静下来过。

终于读完了，长嘘一口气，记了3700字的读书笔记，贴上来分享下吧，虽然有点乱。


时间轴

        * 2002-10 第一个官方声明（挖了很大一个坑，群众的期待太高）
        * 2002-10 kapor start to write blog
        * 2002-11后台工作陷入困境
        * 2003-01-底 第一次集成~
        * 2003-02-20 pre-alpha发布
        * 2003-03 toy到岗，development manager，制定开发计划
        * 2003-04-21 v0.1 第一个公众预览版，24小时15000次下载
        * 2003-06 roy开博客
        *
                * 1. 反思进度为什么特别慢
                *
                        * 更民主，缺少等级结构
                        * 遵从集体意见，作决定很慢
                        * 等级结构是把顽固程序猿组织起来的有效手段
                        * 在网景，写代码是重中之重，解放人力有助于写代码就是好决定；在OSAF，很难为写代码扫清障碍

                * 2. 新项目，重起炉灶，不确定性大
                * 3. 幻想多于代码；hertz让开发者停止设计，开始编码->先干起来，再变成大东西->激情开干，然后顺其自然

        * 2003-07-17 第一章 死定了
        * 2003-09-25 chandler v0.2 比v0.1还差
        * 2003-10 首席开发经理 micheal toy辞职
        * 2004-02-26 chandler v0.3 包括CPIA的工作版和更新的资料库
        * 2004-05-18 老大kapor宣布退出团队会议，不负责细节，授权给经理自治
        * 2004-04-01
        *
                * microsoft宣布longhorn推迟发布
                * google在愚人节发布gmail，包含很多特性，比如邮件不用文件夹，用搜索，AJAX
                * osaf和ms都步履维艰，新一代产品以web形式出现

        * 2004-09-07 开始用贴纸而不是excel记录work item->v0.4 27张，v0.5 45张，v0.5 33张，v0.7以后33张，太多了->此计大秒
        * 2004-秋天 v0.4
        * 2005-03-29 v0.5
        * 2005-11 v0.6



        * 人物表
        *
                * mitchell kapor 莲花创始人,OSAF发起人，资助者
                * michael toy
                *
                        * rogue龙与地下城
                        * SGI部门管理
                        * 网景创始人之一

                * andy hertzfield / matintosh kernel
                * john anderson系统架构师，mac
                * lou montulli
                * jed burgess新手
                * katie parlante，stanford girl , 新手
                * roy & aleks totic，在网景发家，后来在湖边无所事事，又出来干活。干了6个月后离开chandler，“我太具破坏性，想把事情快速地推动起来，组织里有些人希望谨慎，安全的开发方式”，roy去eclipse做python模块, aleks回湖区搞创投
                * chi-chao Lam,PM
                * Pieter Hartsook,PR记者，分析师
                * David McCusker 数据存储
                * jage jibs-stanford GUI
                * mimi Yin，UI designer
                * lisa 杜索特:2004-03加入，负责webDAV标准

读书笔记

        * 我看到了什么：
        *
                * 很多软工的名言/总结（摘录于书中）
                * 硅谷不同工程师的生活

        * 只有任务分工给互相无需沟通的人，人和月才是可以互换的
        * 软件受到“序列约束”，限制了任务的分解程度
        * 开源：
        *
                * 只要有足够多的beta半测试人员和开发者，bug发现很快(这是chrome区别于IE的地方，商业公司也能用开源的思路开发软件)
                * 反对声音：
                *
                        * 技术支持少
                        * 分支，另立山头


        * 莲花的anenda失败
        *
                * 太超前
                * 错过公司的战略，无辜牺牲
                * 创新和灵活性对于用户来说太多

        * 写软件灾难的书很多
        *
                * 《软件开发滑铁卢》《死亡之旅》《软件极限》
                * 故事总是这样的：一群激情洋溢的程序猿，面对棘手问题，被坏经理/需求。。最后等会计师和律师收拾残局

        * 没有银弹
        *
                * 构建软件系统最难的就是精确定义要做什么东西
                * 选项太多，随性而为，心血来潮

        * 后台陷入迷宫后
        *
                * 请别重复发明python和zope，开发者已经创造出来，积累大批绝佳的技术财富
                * 做好项目的关键在于复用，继承成功经验，而不是重造轮子。
                * 看看用多少代码就可以写出来吧

        * 《人件集》
        *
                * 程序员喜欢写代码
                * 而不是看文档，看别人的代码
                * 同等条件下，喜欢重头设计制造
                * 不肯研究别人，甚至都不看一眼
                * =>开源和google改变了这种情况，缩短寻找的时间
                * per/python也提供大量的库，省的耗时造轮子
                * 库多了，也会搞不清哪里有，会重复
                * =>信息过载是最大挑战！
                * sourceforge/github上面肯定有人造好了，只是：找不到/找到太多选择

        * 可复用软件悖论
        *
                * 总能找到满足大部分需要的代码，然后，那部分做不到的，恰好是这个项目需要创新的地方->创建项目的出发点~

        * 他基本上一事无成，不管原因何在，总之就是没做出东西来。
        * 他开始干，而且做到了， 尽管有点脆弱~
        * toy他具有衡量好的development manager的唯一资质：有据可查
        *
                * 不擅长处理人员事务：指导、绩效考核等

        * 《硅谷革命》revolution of vally
        *
                * 回忆macintosh岁月

        * 软件开发对【绩效考核】有天然的抵抗力
        *
                * 行数不是衡量好参数
                * 难以划分成难度或尺寸相似的单元，时间也估不准，bug修复的难易也不同
                * 不同程序员生产力差10倍，配置人员和预估时间一样充满挫败感

        * Linux对做大型开源项目的建议：别做大项目
        * demo day很有效果，每次例会让大家演示小进步，使大家欢腾
        * 特性驱动还是进度驱动？两者都有
        * 【布鲁克是法则】人月神话
        * 跟踪进度是为了协调工作，而不是表扬和批评谁。//要求两周发布一次里程碑，但是这也耗掉了很多时间
        * 【招人】如果多招一倍的人呢？第一年会拖慢进度，第三年才会开始有回报->可是我们的work item大概是两年时间->懂了
        * 【工作环境】环境宜人，午餐很好，时间弹性，气氛融洽。mimi yin可以早上去上瑜伽课，晚点到；某人可以在西雅图一个岛上工作，几个月来一次bay area
        * 【软件开发计划】
        *
                * 提供详细计划和日程安排， watts humphrey,IBM OS360项目管理大师
                *
                        * 1. 计划是强制性的
                        * 2. 计划是自底向上，由程序员的经验而来，而不是管理者拍脑袋和市场期望而来

                * 后来watts做出CMM模型
                *
                        * 第一级什么都没做
                        * 第二级组这做些计划，跟踪，配置管理
                        * 第三级定义过程，如何工作，如何完成任务，可训练的事项
                        * 第四级有跟踪自己工作的框架
                        * 第五级持续改进过程

                * 瀑布模型
                * 螺旋模型，更快迭代周期的小瀑布
                * Kent Beck等17人： Agile software development
                *
                        * XP extreme Programming
                        *
                                * 适用于有经验coder组成的小团队
                                * 先写测试
                                * 和客户一起
                                * 结对编程，多人看


                * Joel spolsky on software
                *
                        * joel test: 12 question
                        *
                                1. source version control
                                2. step build?
                                3. daily build
                                4. bug datebase
                                5. fix bug before write new code
                                6. work item match work doing
                                7. rules
                                8. quiet environment
                                9. best tools in the world
                                10. tester
                                11. write code when interview
                                12. 走廊测试（随便拉个人过来做测试）

                        * 12分最佳，11可以接受，10分以下很差，因为微软一直是12分
                        * 微软质量高，但太慢。
                        *
                                * 就像军队内务，保持战斗力，但耗时间。
                                * 微软80%-90%时间都在做内务


                * 37 signals
                *
                        * 一个在丹麦的程序猿搞定，只做web,因为时差，每天讨论时间很少，程序员专心工作
                        * 用ruby，后来把框架抽出，就是ruby on rails
                        * “灵活性被过分高估，约束才是解放”，约束程序员的可选手段，让编程更简单
                        * google也是小团队，开发周期紧迫，上线再根据反馈改进


        * 更多阅读
        *
                * chrome的开发方式
                *
                        * http://en.wikipedia.org/wiki/Google_Chrome
                        * http://www.niallkennedy.com/blog/2008/09/google-chrome.html
                        * 开源的团队！
                        * 每次build，都依赖很多外面的东西


                * cm的开发方式，steve Kondik
                *
                        * 第三方rom,短时间内发布最新android的优化版本
                        * 3000+ development & user
                        * 7人核心core team
                        * 市场
                        *
                                * 很多厂商没精力升级非主力机型的rom，cm吸收这些用户
                                * 硬件成熟使得rom作用越来越大
                                * 中国是主要市场，有一切：用户，rom，碎片化生态圈，没google的控制








附我的短评：
精彩的软件工程故事书，讲的不仅仅是chandler开发的故事，还引经据典，讲述和总结了很多其他软件的开发过程/不同软件开发理念等等。

初期看这本书，其实是想了解基金会+开源这种软件开发模式。

读完这本书，发现看到的不仅仅是chandler的开发，也是很多其他软件的开发过程。

内容很丰富，很适合作为软工入门学生的科普书籍。如果我是老师的话，我会推荐这本书给本科生。