一咬牙，真的就在7月31号把这本书看完了。看得马马虎虎、囫囵吞枣。看得不大懂，大师的书不是那么容易看懂的。准备下次再看，下次应该懂的就多一点了。所谓读书百遍其义自见。但不知下次是什么时候。
有什么收获？至少知道了几个原则：单一责任原则、开放-封闭原则、里氏替代原则等等，以前闻所未闻。至少知道几种模式。虽然还不会用，但终究会产生一些潜移默化的效果。我相信还是会有进步，慢慢来。
以前看到网上很多人说写代码不是长久之计，要想好发展方向，30岁之后还是底层程序员日子就很难过了。果真如此吗？不是那样的。 Robert C.Martin 在1993年时已有20年开发经验，他在一个开始只有2人、后来增加到5人的团队中花了4年时间开发一个考试系统。20年开发经验仍旧亲自操刀，所以成就了一位大师。我国鲜有知名大师，我觉得可能是因为没有一直写代码。像我们，好多人干了两三年就要当项目经理了。自己代码都还没写清楚就要指挥小弟怎样写代码了。我们本身就不重视代码，管它好不好，要快点写出来了，有那个功能点就行了，验收通过、拿到钱了就了事。而验收时那些专家根本不看代码，系统都不看，有可能都不懂代码。中国特色可能决定了中国的程序员出不了大师。
我这种理想主义者，虽然代码还是写得一塌糊涂，但至少有想写好点的想法。有时候我对项目经理说“这代码太乱了，不好改，我像重构一下”，项目经理不假思索“先实现功能，重构最后来做”。也不问究竟有多乱，会造成什么后果。我当然知道重构越早越好、越早收到的回报越多，但我一般不跟他争论，我也说不出为什么一定要给我时间让我重构。怎么办呢？边写新代码边改旧代码吧。新的功能出来了，旧的破代码也有所改观。有时我觉得好像是自讨苦吃，自己找些事情来做，但实际上我还是方便了自己，因为把旧代码改好了，增加新功能就容易得多。这叫付出总会有回报。
以前看到网上很多人说写代码不是长久之计，要想好发展方向，30岁之后还是底层程序员日子就很难过了。果真如此吗？不是那样的。 Robert C.Martin 在1993年时已有20年开发经验，他在一个开始只有2人、后来增加到5人的团队中花了4年时间开发一个考试系统。20年开发经验仍旧亲自操刀，所以成就了一位大师。我国鲜有知名大师，我觉得可能是因为没有一直写代码。像我们，好多人干了两三年就要当项目经理了。自己代码都还没写清楚就要指挥小弟怎样写代码了。我们本身就不重视代码，管它好不好，要快点写出来了，有那个功能点就行了，验收通过、拿到钱了就了事。而验收时那些专家根本不看代码，系统都不看，有可能都不懂代码。中国特色可能决定了中国的程序员出不了大师。
我这种理想主义者，虽然代码还是写得一塌糊涂，但至少有想写好点的想法。有时候我对项目经理说“这代码太乱了，不好改，我像重构一下”，项目经理不假思索“先实现功能，重构最后来做”。也不问究竟有多乱，会造成什么后果。我当然知道重构越早越好、越早收到的回报越多，但我一般不跟他争论，我也说不出为什么一定要给我时间让我重构。怎么办呢？边写新代码边改旧代码吧。新的功能出来了，旧的破代码也有所改观。有时我觉得好像是自讨苦吃，自己找些事情来做，但实际上我还是方便了自己，因为把旧代码改好了，增加新功能就容易得多。这叫付出总会有回报。
