如果说这世界一直在鱼的统治下发展出了文明，我估计它们很可能会出一本书叫做《鱼与自然，和谐发展》。
我始终认为，“人”不可能是这颗星球上最伟大的存在，所以我不喜欢刻意把“人”和“动物”区分开来。说得不好听点，我们一直标榜的智力、情感、想象、语言等终极技能，其实在其他哺乳动物身上都能找到缩影，我们没什么了不起，只是脑子相比其他动物强一点罢了。也许站在大自然的角度来看，就好比大部分动物都有脖子，只是长颈鹿的比较突出，大部分动物都会跑，只是豹子跑得快一点。我们生理上的任何一项特征都不可能是所有物种当中独有的。
我们总倾向于假定其他人也和我们一样思考。但其实不是。心理学家把这种现象称为“错误共识效应”。当别人和我们有不同的见解和行为的时候，我们很可能会在潜意识里给他们贴上SB(not english)的标签。
这种偏见解释了为什么程序员很难站在用户立场。用户不会想程序员一样思考。首先，他们平时用电脑就不多。他们既不知道也不关心电脑是如何工作的。这就意味着他们无法用任何程序员熟悉的问题解决技术。他们无法识别程序员围绕界面产出的模型和提示。
观察用户是了解用户的想法的最佳方案。请求用户使用一款与你正在开发的相似软件来完成任务。确保任务是真实的：“添加一列数字”即可；“计算你最近一月花费”那就更好了。要避免太特殊的任务，“您可以选中这些表格但愿并在最下方编辑求和公式吗？” - 这个问题有个很大的线索。让用户谈他/她的进展。不要打断！不要试图给予帮助。不断问你自己“为什么他会这么做？”以及“为什么她不这么做？”
你首先要留意用户在做相同事情的核心。他们以相同的顺序完成任务 - 并在同样的地方犯同样的错误。你应该围绕这些核心行为做设计。这与设计会议不同，设计会议倾向于听一种声音“如果是用户，他们想要什么…?”这将导致进一步细化功能然后一直惑于用户想要什么。所以，观察用户并消除这些困惑。
你将看到用户卡壳的时候。当你卡壳了，你会环顾四周。当用户卡壳了，他们会缩小注意力。对他们而言想从屏幕的其他地方找到解决方案是更困难的。其中一个原因就是帮助文就是个垃圾的用户界面。如果你有指导手册或帮助文档，要确保能够正确定位到问题。因为用户的注意力会集中到为什么工具提示要比帮助菜单更有用。
用户总是糊里糊涂的，无论有多复杂，它们总会找到一种方式坚持下去。所以最好仅提供一种明显的做事方法，而不是两三种快捷方式。你总能发现用户表达他们想要的和他们实际做的是有差距的。通常召集用户问它们需要什么是很糟糕的方式。这也是为什么观察用户以捕捉他们真正需要的才是最佳方案。花一个小时观察用户要远远好过你花一天时间来猜测用户想法，前者可以获得更多真正有效信息。
函数式编程最近重新引起了主流编程社区的兴趣。其中一个原因就是功能范式能够很好地应对我们的行业朝着多核方向发展所带来的挑战。无论如何，这无疑是一项重要的应用，但这并不是本文劝你要了解函数式编程的原因。
掌握函数式编程范式可以很好地提高你的代码质量。如果你深度理解并应用函数式编程范式，你的设计将拥有更高的引用透明度。
引用透明是一个非常值得拥有的特性：它意味着无论何时何地调用一个函数，同样的输入总能得到同样的输出。换句话说，功能评估对可变状态的副作用影响会越少——理想情况下，毫无影响。
命令式代码的一个主要缺陷可归因于可变变量。每个人读到这里都将调查为何有些值在特殊情况下不符合预期。可见的语义可缓解这些隐藏缺陷，或者至少迅速缩小其所在范围，但它们真正的凶手实际上可能是采用过度可变设计的结果。
并且关于这方面我们不大可能从业内获得太多帮助，面向对象的介绍默认地促进这种设计，因为他们经常显示有相对长生命周期的对象图形组成的例子，并把它们称为设置方法(mutator method我理解为setter)，这可能变得很危险。无论如何，通过严谨的测试驱动设计，尤其是当需要保证“模拟角色，并非对象”的时候，可以设计不必要的可变性。
Net Result(最终结果？)是一种设计，通常拥有更好的职责分配、更多更小的函数，作用于传递给他们参数的较小函数，而不是引入可变的成员变量(setter)。他们拥有更少的缺陷，而且也更容易调试，因为它们对与设计中引入的异常值的定位更容易，而不是推断导致错误的上下文分配。这相当于更高的引用透明度，并且没什么能够像这些想法像学函数式编程一样深刻入骨，这种计算模型是常态。
当然，这种方法并非在所有情况下都适用。在面向对象系统中，这些风格相比于用户接口开发，领域模型开发能够得到更好的结果（好比协同能够有效降低业务角色的复杂度）
掌握函数式编程范例，以便于你能将所学到的应用到其他领域。你的对象系统(对于一个而言)将与引用透明的优点产生共鸣，并且更接近它们的功能对等物，比你认为的还要多得多。事实上，有人甚至断言函数式编程和面向对象的顶点就是彼此的影子，是一种计算的阴阳两面。
本来准备把本书留到周末再读，因为感冒，晚上实在没有力气去学习和编程训练，便端起了这本《心法》，作为我了解稻盛和夫哲学的阶段性收尾。
如果说《干法》、《活法》读起来会感觉这位老人的“迷信”思想很重的话，那《心法》更是有过之无不及。不过他的“迷信”可不是把符文烧成灰泡水喝那种无厘头式行为艺术，而是人生观和价值观的表达，很多人(包括我在内)听说稻盛先生更多是他一手创办并带领京瓷、第二电电杀入世界500强，晚年近80岁的他更是在日本政府再三邀请下出手掌舵濒临破产的日航，仅花了一年便奇迹般地大幅扭亏为盈。所以可能更多人想的是学习他的经营之道，但我三本书看下来，稻盛先生似乎并没有一味宣扬他经营企业的方法，而是一直强调做人做事的原则，就像我在读书中他所宣扬的“迷信”，明白了科学传授的是方法论，没有是非善恶之分，作为人更重要的是心境，只要正确地做人自然能把事做成，否则方法学到手，心思歪了，容易作恶呀。
本书既为《活法》，自然主要围绕作者对于人生哲学、生命追求等阐明了自己的观点，前4部分比较好理解，要努力奋斗、要回归本真、要懂的活着是一场修行，要心存善念。至于最后一部分“与宇宙潮流协调和谐”，坦白说，我真没这么高的境界，着实不能体会作者的内心思想。我想，让我多经历一些感悟一些之后再来翻看这本书，可能是个不错的选择！
不论你想干嘛，三思而后行——Anon
不管开局多么美好，你都无法避免某些时刻的压力。当“保质保量”和“赶工期”摆在你的眼前，选择“赶工期”意味着你很快会返工。尤其是你给自己、团队、客户作出某些承诺后，就意味着你选择了后者，通常在下次迭代那些赶工导致的问题就会浮现出来，反而导致工期延长。Martin Fowler 在他的技术债分类中把这种现象称为deliberate technical debt(故意的技术债)，注意不要和无意的技术债混淆（前者是你和你的团队明知这样做会出问题，还选择这么做）。
“技术债”就像一次借贷：短期内你能从中获益，但必须为此支付利息直到还清为止。代码中的投机(Shortcuts in the code)会导致你的代码很难再增加新功能或重构，也是缺陷和脆弱的测试用例的温床，时间越长越糟糕。当你着手准备修复时最初的问题时，在此之上可能还会面对一堆堆被不太正确的选择（越来越歪）。而事实上，你总是等到bug一发不可收拾的地步才会回来修复它。燃鹅，这早已发展到你承担不起的时间和风险。
有时你必须引入技术债去应付截止日期或一些功能雏形，尽量别尝试这么做，除非情况已经是非做不可了。但是（一个大大的但是）你必须跟踪这个技术债而且要尽快偿还或者把事情迅速平息下来。当你决定妥协时，为了确保这笔债不会被遗忘，一定要在你的系统问题跟踪里加入此项任务清单或日志。
如果你打算在下次迭代的时候就偿还此债务，它的成本是最低的。未偿还的部分应该作为累计利息被跟踪，以使成本可见。同时这也将作为影响项目的业务价值权重，确保偿还的优先级。至于如何计算和跟踪这些利息并加以权衡，取决于项目的细节，但跟踪是必须的。
尽可能还清技术债，否则就太轻率了不是吗。
我今年30岁，如果生命允许，我想再工作50年。
周末清晨，我例行早起准备读一读这本经营圣经，结果女儿也跟着我起来了，只好无奈切换到带娃模式，顺便补上之前落下的电影《芳华》，由衷感慨那个时代人们的纯粹、青涩，同时也真心被革命前辈的付出与命运所感动。还好，踏实的人终究会有踏实的归宿。
午后，趁着女儿睡觉的时候，跑到书房捧起了这本书《干法》，待女儿2小时睡醒后我居然已翻完了大半，算是我读的最快的一次了，本来下周末才需要git commit的读后感，结果下午又花了一个多小时把书读完了😂，好吧，读后感走起…
这是一本了不起的书，翻译的也很棒！这么伟大的一本书，我大概花了4年的时间才读完，4年前刚拿到这本书的那天我读完了封面，4年的最后三个礼拜，我读完了剩下的所有页。
大概在2017年初就买了这本《只是为了好玩——Linux之父林纳斯自传》，先说说这本书吧：错别字太多了！！！印刷太不严谨了！！！我在阅读过程中一度怀疑买了个盗版，说这些不是为了表达对人民邮电出版社的不满，就是为了证明老子读过！！！是不是有点嚣张了😏，我不过想陈述事实，如果你能自动忽略文中毫无理由的字体/字号变换，把“借口”写成“接口”等等，我还是建议你去读一读这本书，真的蛮有意思！我不知道英文版如何，毕竟连CET-4都考了7次的人，这辈子都不可能对此做评价了😂。本书总体而言可分为三大主题，Linus的成长，Linux的成长，Linus+Linux的一些琐事和哲学思想（主要围绕开源运动、人生在探讨）。坦白说，就这本书的文字而言，确实带有很多“放荡不羁”的个性，但也为阅读带来了更多的趣味性，比如时不时的会出现“做爱”、“性”等字眼，比如与权威的各种骂战等。可是那有怎样呢，面对这位教父级的人物，你敢评头论足吗，你敢有异议吗，你敢说吗，你敢吗！好吧，那我就随便说两句…