读后感 《流星之绊》是东野圭吾在2008年发表的长篇小说，主要讲述兄妹三人夜出观看流星，回家发现父母双亡，此后在孤儿院长大。接着因为矢崎静奈被骗，他们兄妹三人气不过，开始了合伙设计诈骗他人。在这之后，因为一个偶然的事情，在父母被杀案件追诉期将近的日子，有明泰辅发现了曾在凶案现场碰到的那个男人，于是通过连环设计嫁祸凶手，企图用伪证迫使对方自行认罪。 这本书在看的过程中，看到矢崎静奈的所作所为，就不得不感叹，东野圭吾的书里好像就没有过好女人。《白夜行》的唐泽雪穗、《幻夜》里的新海美冬，都让人觉得后背发凉、毛骨悚然，像是无情的“杀人机器”，而这次静奈也通过伪装和演技，把很多男人玩得晕头转向。我本来以为又是熟悉的套路，但在最后一次行骗面对户神行成时，她却因为情愫萌生，变得犹犹豫豫，导致计划最终落败，但恰好是这一点，反而让人物变得更为立体了。 在阅读过程中，早就知道户神行成不会是凶手——因为推理小说的情节设计来说，明面上的答案都不会是真正的答案（除了《恶意》）。实不相瞒，看《恶意》这本书的时候我还想着，有没有可能以后写个小说让凶手就是主角“我”，没想到《恶意》直接实现了我的这个想法，真的太巧了。当然，后来知道阿加莎的《罗杰疑案》用过类似手法，不过那是后话了。 说回《流星之绊》，快结尾时还没有任何凶手的提示。因为凶手必须是早就出现的人，不可能凭空冒出来，这样才能情节反转。但我把出场人物想了一圈，好像没谁有强烈的动机，完全猜不出来。索性抱着看热闹的心态继续读下去，想看看东野圭吾怎么编下去。当有明功一回忆起似曾相识的画面时，我脑袋里突然冒出一个念头：难道凶手是有明泰辅？自己都不知道这想法怎么来的，接着又想会不会是矢崎静奈？毕竟没有血缘关系，谁知道是真的没血缘关系，还是假的，如果有其他隐情呢？再来次《白夜行》？不过他们当时都是小孩，还一起去看流星雨了，显然不太可能。 真正看到最后知道凶手是谁时，有点意外。倒不是说动机不行，就是感觉有点俗套，可能因为之前看过《新参者》，觉得类似的动机不够新颖，说服力也不够强。不过总体还行，至少比《梦幻花》好太多了。 摘抄 这个世界只有骗人和被骗。你们看看政治家、官僚，不都是在欺骗国民，中饱私囊？可明知是这样，国民就起来暴动了？没有吧，都死心了不是？所以，只要干得巧妙就是赢家。被骗了就去骗回来，同样，被我们骗了的人，如果不甘心吃亏，也可以再去骗别人。 钱财乃天下流转之物，那就让它流到我们这儿来吧。 我们要骗人，再也不受窝囊气了。 根据泰辅的经验，和女人比较疏远的男人有两种：一种是不讨女人喜欢，很卖力但对方不予理睬，还有一种是并非不受欢迎，但心思全被别的事情占了去，与女人无缘。 你善于合乎理性地做好工作，但却不知道，要打动人心光靠理性并不够。 花力气得到的答案比轻易就弄明白的更显珍贵。 人类的行为并非都能用理性来解释。或者应该说，不合情理的地方居多。盗窃杀人犯将罪证藏到天花板上，搬家时竟然忘了，这确实不太自然，有些鲁莽。但人就是这样，会犯这样那样的错误。还有，对于警察来说，那种事无关紧要。 外表越出众的人，越有可能深藏着一张人们无法想象的面孔。 为了生存。我们无依无靠，没有任何资本，要想活在这个世上，根本就没有选择手段的余地。如果允许我找一条理由，那就是我想履行责任，作为兄长的责任。当然，现在我已经知道这是个天大的错误。不管出于什么理由，也不该让他们成为罪犯。作为兄长，我应该阻止他们，我犯了严重的错误。

最近一直在思考阅读的意义。每次看完一本书，总觉得应该留下点什么，因为如果不及时记录，时间一久，连当时对这本书的感受都会变得模糊。更糟糕的是，有些书的内容甚至完全记不清了。比如东野圭吾的《盛夏的方程式》和《祈祷落幕时》，明明是读过的，现在却连故事主线都讲不出来，甚至可能记岔了细节。 所以，打算新开一个读后感系列，把看完一本书后的感受都写一写，不需要强求自己提炼出什么深刻见解。感受毕竟是主观之物，只要是真实的，那就可以，比如随手写下对某个情节的吐槽，或者对某句话的感触，甚至只是简单复述一下故事内容。关键是，把这些零散的想法及时记下来，哪怕只是片段式的笔记，也能在未来某个时刻重新唤起当时的自己。 阅读本身是私人的体验，思考的深浅因人而异。与其纠结于有没有价值，不如专注于有没有动过脑。只要读了、想了，哪怕只是片刻的触动，也是一种收获。而记录的意义，不是为了证明自己读了多少本书，而是为了对抗遗忘，让那些稍纵即逝的感受有机会被保留下来。

我们部门在开发一些项目时，确实需要借用设备，但每次开发新需求时都要从硬件部门借设备，开发完成后又要归还。这种频繁的借还流程不仅增加了沟通成本，还导致项目负责人和开发人员对设备的功能和应用场景缺乏直观的了解。有时甚至连设备长什么样都不知道，这显然不利于我们真正理解业务需求，甚至可能导致开发方向与实际业务脱节。 有人提议是否可以申请一些设备常驻我们部门，让项目相关人员在开发过程中能够随时试用设备，真实感受应用场景，同时遇到问题时可以立即用设备重现和排查。这个想法确实有一定道理，但仔细想想，设备本身也在不断迭代，如果设备长期放在我们部门，可能只能停留在某个版本，后续更新无法跟上，反而会限制我们的开发思路。此外，设备的使用频率主要集中在开发阶段，项目上线后很少再被关注，长期占用硬件资源可能造成浪费。 其实，我们的核心问题并不是设备是否常驻，而是如何让开发人员在开发阶段有机会试用设备，从而增强对业务的理解和对设备功能的熟悉。与其申请设备常驻，不如在开发阶段短期借用设备，确保开发人员在关键阶段能够充分接触和使用设备，同时避免资源的长期占用。这样既能满足开发需求，又能兼顾资源的合理利用。

虽然在项目开发前期，我们已经做好准备工作，一个环节到一个环节有条不紊地执行，但不可否认，在这个过程中，难免会出现需求变更的情况。作为项目负责人，应该怎么去处理这件事呢？ 项目遇到需求变更，通常都是新增需求，很少是减少需求的变更。简而言之，就是增加了工作量。而项目负责人面临的难题在于：如何在不影响整体计划的前提下，高效应对这种变化。需求变更的规模有大有小，不可一概而论。如果是小的变更，那无伤大雅，适当微调即可。但倘若是很大的变更，比如新增的功能开发需要一两周甚至更长时间，那么整个项目计划可能就需要推倒重做，这无可厚非。 我们要探讨的是介于这大小之间的需求变更——那些有机会在当前计划里解决掉的需求，比如增加了一周的工作量。你有信心能按当前制定的计划如期交付吗？现在的情况是，我们可能只是将需求变更分为大小两个情况：小的微调，大的立刻调整项目计划，然后项目上线时间就会变更。久而久之，这种处理方式可能会让人觉得理所当然。 事实上，大部分项目开发工作是有协商空间的，并未被完全限定死。遇到突发情况，比如客户需求变更，但交付时间没有任何商量余地时，项目负责人该怎么办？有人可能会说加班，但有时加班未必能解决问题。 也许现在我们可以慢慢培养这方面的意识和能力，在平时多积累这方面的经验，避免真正遇到事情时手忙脚乱、无从下手。也就是说，我们可以将需求变更分为三种情况：小的变更，微调即可；大的变更，比如需要增加两周工作量，那就变更项目计划；中等变更，比如需要增加一周工作量，我们先不急于调整计划 ，而是先想一想：有没有什么办法可以在不变更计划的情况下解决这个问题？然后将各种可能的解决方案列出来（1、2、3……），召集项目其他成员一起讨论。也许经过多轮讨论，我们就能找到解决方案。如果讨论后仍无法解决，再根据实际情况变更项目计划。

Algorithm 实现代码如下： 解题思路： Review Tip Share 一文读懂：PMF（product market fit）与产品管理 “一些初创企业，花很多的时间专注于他的新技术、新功能、新创意，不做用户访谈，花极少的时间验证市场需求、用户付费意愿，最后用一个产品去解决一个不存在的问题或者市场，拿着锤子找钉子，这样的结果大概率也是失败的。”