《王垠博客》·简评·摘抄
简介
王垠这个人，从他的博文来看，是真正的特立独行，有自己的思想的，更重要的是，我很喜欢这种人，说不清为什么。。。（详细还是百度好些）
写点这个，是因为平时看的各种文章一看即过，自己没有意识，更谈不上思考。所以，利用下这点小小的时间，试验一段时间，亦或者纯粹是为了自己好玩，就是这样。
《DRY原则的误区》
突然发现博客更新了两篇，立马看了，对这篇文章比较感兴趣，先写点。
一、感慨！第一次接触DRY原则是研一时实习的一个敏捷项目。在一次迭代回顾会上从QA口中听到了这句“ Don't repeat yourself ”，瞬间一种高大上的感觉有木有，于是立马就喜欢上了这句话，还因此改了一年的企鹅签名...想想工作至今近一年，依然还是怀念当时的情景氛围...
二、抽象的时机，“我会等到事实证明重用一定会带来好处的时候，才会开始提取模板，进行抽象。经验告诉我，每一次积极地寻找抽象，最后的结果都是制造一些不必要的模板，搞得自己的代码自己都看不懂。” 很朴实的一句话！联系到自己，真的有时候片面追求代码的美观、或者抽象（？目前还达不到这个程度，但有这个意思），本来一笔下来，自然流畅的代码，最终都自己给自己挖了坑，下了套！记住这句，“如果你不能写出“可用”（usable）的代码，又何谈“可重用”（reusable）的代码呢？”
三、防止过早抽象的方法，先“可用”，再“可重用”，避免没有实际效果的抽象。
四、文章结尾的一句话，非常喜欢。“世界上有比这些喜欢提出‘原则’的软件工程专家深邃很多的人，他们懂得真正根本的原理。” 自认为，不管我们承认不承认，我们大部分人每天的工作其实真的非常肤浅，并且最罪恶的是我们并不自知！这里肤浅这个词并不表示贬义，而是“不自知”实在让我很不舒服，不多说！毕竟，这个世界上真正懂得本质原理，并且在做着创造性事情的人只占少数。也因为意识到这一点，我更深刻理解山外山，人外人，从而保持谦谨的道理。
-- 6.17
《什么是启发》
一、“在你的头脑里随时准备好12个问题。每当发生一件有趣的事情，就检查一下其中是否有问题可以由此获得线索。久而久之，人们就会称你为天才。” -- by Richard Feynman
二、为什么这种题材也需要写进博文呢？我突然意识到，是否王垠本人在工作(亦或生活)中并不是过的那么顺利？不然，即便说一句“你启发了我”，然后让人觉得高我一筹又如何？反正最终结果是人家帮助“我”解决了问题，这就是重要的。其他的，随便？
-- 4.25
《爱因斯坦谈教育》
一、“教一个人专业知识是不够的。通过专业知识，他可以变成一个有用的机器，但却不具有和谐的人格。”
二、“独立的，批判性的思维，必须从小培养。过度的，过于多样化的科目（分数制度）会破坏这种思维的发展。”
三、“教育应该是这样：被传授的知识应该被当成宝贵的礼物，而不是沉重的任务。”
-- 4.10
好文章！就是这题目白瞎了。。
一、“学术腐败”的恶性循环(可以扩展很多地方吧)、吸血鬼的故事。“每一个吸血鬼最开头都是受害者。我们同情那个受害者，然而他一旦变成了吸血鬼之后，就不再值得同情，因为他原来的灵魂已经不在了。”
二、各种比方很有意思，“非抢占线程调度算法”、“等待队列”、尤其“广度优先搜索算法”，简直形象。。说真话不容易。
三、“资本主义就像是一个内存分配和处理器调度没做好的操作系统，有些进程占用太多内存和 CPU，却没能有效利用，导致其他进程‘饿死’。”
四、“不要以为所谓的‘世界一流大学’里的情况就会好一些，因为没有人可以逃脱社会发展的规律。世界一流大学我见识得多了，本质都一样。而且由于很多人想进去，头破血流的机会还多一些。从那里面出来的人往往都有一种神经症，什么事都跟别人比想看看谁厉害，谁“优秀”，娱乐活动都不例外。以至于你怀疑他们是否知道自己为什么活着。”
五、“承认了自己在扯淡总是比举着高尚道德的牌子更加以德服人一些。.....发扬自嘲精神，勇于承认自己的现实和弱点，承认自己其实是不得已为了混饭吃，大家都是混饭吃的。有同情心才会有动力，同学们如果知道了你是在混口饭吃，反而会更加理解你的处境，停止质疑你的做法，进而帮助你继续混下去。”
上面这些段子以及最后一段非常有趣，也很有思考的味道。。这篇是典型的王垠风格，特立独行，敢说真话！
-- 4.9
《编程的宗派》
函数式编程，听着就很高大上。。虽然我不太懂，但我感觉就是在玩概念，跟面向对象编程一丘之貉。。
一，“在我的心目中其实只有一个概念，它叫做“编程”（programming）” -- 霸气测漏，喜欢
二，“编程最重要的事情，其实是让写出来的符号，能够简单地对实际或者想象出来的“世界”进行建模。” -- 大道至简。
三，对象思想，就是对数据访问的抽象。它的价值在于改变语义，却不需要修改代码。
四，对象思想与量子力学的“不可观测性”。
-- 4.5
《谈“测试驱动开发”》
大概去年九十月份接触TDD(Test-Driven Developmen)，这种开发方式确实有效果，但是只适合团队工程项目，个人的话看下面两点。。
一，“测试的构建，应该是在程序主体已经成形的情况下才能进行。如果程序属于创造性的设计，主体并未成形，过早的加入测试反而会大幅度的降低开发效率。”非常有道理！很赞同！盲目的构建测试用例费力不讨好！
二，对于测试的副作用，盲目依赖。个人倒是认为写完代码就跑测例不是依赖而是一种正确偷懒的方式。以我个人为例，写代码之前我肯定就自己脑子里逻辑验证，但我不能保证我逻辑想的跟我手动输入的代码完全保持一致，所以，对于我个人来说，写完代码再自己逻辑验证，简直是要命！
另外，盲目依赖似乎也是个伪命题。依赖就是偷懒，盲目依赖就是盲目偷懒。那我随便增加或修改代码，跑测例跑一次失败一次，失败又得自己找原因，这个过程不更费精力和时间？简直得不偿失啊！
三，关于代码“覆盖”的问题。“覆盖只是说你的代码被测试碰到过了，可是它在什么条件下碰到的却没法判断。”，测试用例不就是不断增量补充的啊？
四，测试驱动开发，所以重点在开发阶段。开发阶段只能尽量保证正确性，不能要求所有场景都能覆盖，完整的测试必然还是需要专门级的测试咯。
五，“美的程序不可能从修修补补中来。它必须完美的把握住事物的本质，否则就会有许许多多无法修补的特例。” 赞同！
-- 4.3《谈程序的“通用性”》
这不就是我关于之前《解密“设计模式”》中简评的核心思想么？...
一、谨防“过度工程”，代码需要实际被“重用”的地方要比想象中用到的少。
二、“考虑”到了通用性，并不等于实际“把握”住了通用性。因为，“能够准确的预测将来的需要，能够从代码中抽象出真正通用的框架，是一件非常困难的事情。它不止需要有编程的能力，而且需要对真实世界里的事物有强大的观察能力。”
三、程序初期设计过程中，过早的考虑到将来，并由此带来的多余的复杂性，有可能出现问题，导致无法设计出优雅的程序，效果适得其反。
四、结论，“在设计程序的时候，我们最好是先把手上的问题解决好。如果发现这段代码还可以被用在很多别的地方，到时候再把框架从中抽象出来也不迟。”
-- 4.2《我的个人防火墙》
“看微信朋友圈有一个好处就是，它可以让你清楚地看透一个人的内心和价值观。人总是会宣传符合自己价值观的内容。”
-- 3.26《程序语言与……》
与微波炉：
单一职责不逾矩，一类事物一类功能，同样，一种程序语言设计对应一类软件开发。与减肥：
一，减肥真理，让每天摄入的热量比消耗的少一些，跟《富爸爸穷爸爸》的理念如出一辙，追求财富自由，不过就是每天的收入比支出多一些…
二，编程跟减肥，不是看看编程宝典跟吃吃减肥灵药，需要付出，世上没有简单的事情，也更没有尤其艰难的事情，一切只取决于自己的思想觉悟深浅。
与棋：
一，可以了解下国际象棋、围棋规则。
二，什么是简单？直接，屈指可数但组合起来又有足够变化。这一条个人认为也是普世的准则。与音乐：
“我知道这些话说了也白说，因为他们没有用过我用过的语言，他们只看到名字却感觉不到本质，他们靠别人的评价来判断，而不是靠自己的心。所以像音乐一样，只有等有一天他们忽然觉悟，就像很多年前的我一样。”
不能说啥，还是境界问题…
与AK47
一，“程序员的武器应该像士兵的武器一样，方便他们找到问题…”
从这个角度说，C指针问题确实是坑爹，费了半天劲，不是在解决原问题。还有那么多人因为熟悉指针而自豪，显得自己牛逼…可是指针的优势怎么解释，存在即合理呀？这个正反面问题咋看待？
二，“AK 的美，在于它身上没有部件具有不必要的精确性。”
三，“Kalashnikov 不是天才，他不是为了发明而发明，他解决不了问题的时候就高兴地从别人那里学过来。”《不要做聪明人》
一，这个世界需要可爱的人。
二，不管是否有意，对比自身，我发现自己现在正慢慢变得孤僻，也一直在与“优秀人”比较，追求所谓“优秀”…我似乎已经走在成为傻B的康庄大道上，简直荣幸…需要反思哪个环节出了问题。
（再次查看，一直在与“优秀人”比，跟上篇评论不跟王垠比自相矛盾，说明潜意识里我就是在意这个的，只不过我潜在认为比不上他，所以不比，而跟自己身边看得到的人却还是在比较，所以归根结底我还是一个追求“做聪明”的人！）《我为什么不开发Yin语言》
一，如果只单单读这篇文章，两个字，自大！
二，真的是特立独行，敢说真话。这点之前也从各方面稍有了解，凭自己的直觉，我相信他有自己所说的实力。
三，开源精神扯淡说。开源越流行，成分越复杂，所谓林子大了鸟多。。从结果导向来说，开源的结果确实是成就了一批人的名气，但不否认我们这些人确实也看到了很多自认为优秀的代码。毕竟，境界不同。
四，工作生活需要平衡，享受生活。观点从来相同，但实践却未达到他的高度，我不去跟他比，跟每一天的自己比。
《解密“设计模式”》
一，设计模式只是经验积累，不是教条，需要了解，不能硬搬。
二，个人认为提出设计模式的初衷是为了使代码更加稳定，健壮，便于扩展，拥抱变化。这就注定了使用了设计模式的代码是个大而全的东西，而大而全的东西必然导致多出“绕弯”的地方，这是避免不了的。所以，代码写的短而精巧没有错，大而周到也没有错，关键是要清楚写代码的初衷。如果是系统化，平台化的工程，考虑周全，使用设计模式无可厚非。