在编程世界里，技术的打磨往往像是工匠雕琢作品，但若无法转化为产品的成功，所有的精致都不过是空中楼阁。读《程序员修炼之道》时，我深刻意识到，务实不仅仅是技术的选择，更是产品迭代和商业模式成功的关键。
在现代社会，全身心投入之前，测试想法并得到反馈是至关重要的。由用户参与评判，够好的软件就是最好的，而不能过度追求完美。好改，能适应使用者的就是好的设计。
贯穿商业模式、产品到软件设计，有一个原则就是其实谁也没有标准答案，尽早交付，通过持续的收集信息，不断调整方向瞄准，直到击中，这是最重要的原则。作者在书中严格地区分了原型和曳光弹这两种探索正确产品方向的方法。
从技艺精进到产品突破：刻意练习的反思
有几年的时间，我自己对于刻意练习非常偏执，在技巧、熟练度和手艺的提升上确实有很大的收获，但是当时感受到两个问题。
首先，光是单纯的磨练技艺，是无法带来产品和商业模式上的成功的。过度的修饰和精炼很多时候反而会消磨前进的动力。相比之下，使用曳光弹，快速原型、沟通反馈，数据驱动，才是更好的解决方案。
其次，就是缺乏对前沿知识的关注，总是在特定的波段上温故已有知识，有种停滞的感觉。这样会想，大学时，一个学期十八门课，定期考试，用产出来推动的学习的模式，虽然不那么舒适，但是这种方式的确更适合学习大量新知识。
像专业投资理财一样学习
对于阅读技术书籍，其实作者的要求不是很高，在广泛阅读的同时，一个月一本技术书是基准。我觉得还可以在一年里，集中性的再抽出一个月时间，大量阅读技术书，效果也会很好，可以尝试一下。
作者非常务实的思想，还体现在，对于成功投资原则的理解，完全不亚于专业书籍和理财专家。我们对于专业技术，计算机软件工程和科学知识，也应该这样投资。
正规投资者有定期投资的习惯，多样化是长线成功的关键，聪明的投资者会平衡保守型和高风险高回报型投资组合，投资者用低买高卖来获得最大的回报；同时还应该定期审查和重新平衡投资组合。
正交性与DRY原则
务实的软件开发方法中，如果说有一条最重要的原则，我觉得一定是正交性。正交可以带来低耦合，分离关注点、单一职责都是正交的体现。微服务同样也是在部署层面和团队职能上的正交。
DRY（不要重复自己），也是很重要的原则。但是我们知道，在软件开发中复用不是最重要的事，关键是语义清晰，知识必须单一、明确、权威，看似一样的代码未必是重复。这也正是编程中艺术的地方。
可测试性与解耦
可测试性和正交解耦是分不开的，具备良好可测试性的代码，一定是没有对全局变量的依赖，保持不可变性，确定的输入产生特定的输出。还有对外部资源的的引用，也应遵循这一原则，因为任何可变的外部资源，都是全局数据，也就是有副作用，会被共享。
把所有都外部依赖封装成抽象是一个良好的实践，依赖抽象而不是实现，可以提高整个系统的灵活性。
对此，我觉得非常同意作者说的，保持代码简洁，不要打破第一扇窗户。
软件开发就像园艺：可测试和重构的思考
测试是从代码中获取反馈的过程，而不仅仅是寻找Bug。正如作者所说，测试的好处更主要来自对测试的思考，什么样的代码设计出来更易于测试，思考可测试性对代码的影响，用这样的方式，设计出的代码就是可测试的。
关键在于对代码的思考和理解，而不是必须真的写出来的自动测试代码。这也是很偏艺术的地方。当然，如果是时间和成本允许的话，在遵循测试金字塔原则的情况下，还是尽量应该把自动化测试的代码写出来。
自动测试同样面临边际收益递减，属于过度追求完美，任何对完美和健壮性的追求，都应该适可而止，不要超过能看见的范围，这个可以确定的预见的范围，不管对于产品还是开发，都应该是几周，最多不超过一两个月。
在作者看来，重构也应该是非常微小步骤的改进，任何大规模的重写，都不能算是重构，就像裁剪树枝一样。所以说软件开发更像园艺，软件并非砖石堆砌，而是一个有机体，无法得到计划中结果的东西都需要删除或者修剪。
我觉得软件开发中，有一个很有用的原则，在决定代码到底分还是合的时候很有用，可以根据最小删除成本来考虑。
用文本来存储知识
此外作者毫不掩饰用可以版本化的纯文本来持久化存储知识的偏爱，只要不是确定为了性能要压缩信息，用可以自解释的文本永远是最佳选择。这也是我自己非常认同，并且在实践中采用的原则。
首先是可读性，代码和数据不仅仅是机器执行的指令，更是开发者之间沟通和协作的桥梁。在没有足够的精力，维护大量冗余文档的时候，所见即所得的文本信息，是最好的文档，没有任何二义性，也不需要额外跳转和查询知识。
然后是关于建模，这是有点类似活文档的概念，在我们开发软件的时候，第一步，其实是对物理世界，或者需求的建模，将物理世界的所有概念，反映到系统中，所有概念一一对应，是基础，只要有完备的结构化文本，我们可以通过各种代码生成器、规则引擎，自动的生成代码或者执行逻辑；文档本身就解释了程序的行为。
敏捷思维与组织架构
敏捷思想关注的是如何有效地工作，是关于如何做事的，迈出一小步，评估并根据反馈调整下一步行动，持续针对流程做实验，改进流程，才是敏捷团队的核心，而不是迷信时髦的方法。
康威定律决定了，任何软件的架构，最终都是组织沟通结构的反映。应用康威定律，可以有意识地按照代码所期待的样子，来组织团队。现在比较流行说的组织能力，我觉得也是类似的概念。
我觉得需要注意的是，组织的沟通结构，不可避免要受到创始人的性格、预算、收入来源和融资结构的影响，而不是空中楼阁。
编程、架构、产品设计和经营都是一样，采取经过深思熟虑的小步骤，及时检查数据和用户反馈，应该在推进前不断调整，避免过大的步骤和任务，用反馈频率作为节拍器。
构建软件的唯一方法是增量式的，逐步构建端到端功能的小块，一边工作一边解决问题，在解决问题的过程中不断学习，应用过程中学到的知识充实代码，让客户参与每一个步骤并让他们指导这个构建的过程。
结语：务实之道
说到具体的软件开发实践，我觉得，在结果难以预测的产品探索过程中，每次迭代都应该在整个开发流水线上避免重复的工作。每个工序和步骤都应该尽快将可用的产出交付到下游，就像在黑暗中射击一样，不必追求完美主义，关键是尽可能交付可演示且能正常工作的内容，交付的过程就是沟通和学习的过程。当然，推进时要牢记约束理论的指导，及时识别并优化瓶颈，并根据瓶颈调整节奏，以确保整个流程的高效进行。
在《程序员修炼之道》中，务实的方法论贯穿始终。技术的打磨是基础，但只有通过迭代、反馈与不断适应，才能成就伟大的产品。真正的成功在于打破迷雾，精益求精，最终让产品在市场上成功。
从技术打磨到产品验证：读《程序员修炼之道》的务实之道
https://mp.weixin.qq.com/s/V0i45pRy8Twgz-Jy64x6dw