做一个现实主义，而不是理想主义

选用户（分层）——做业务——运维——开发

功能是用来跑的

用户 > 运维者 > 开发者 业务 > 运维者 > 开发者 所以瀑布开发流被淘汰，取而代之是敏捷开发和数据驱动、运营驱动

你先做一个产品出来看看，我再提需求。 很过分吗，想象大家在荒野求生，最初版本就是搭个火堆，砍点木头，然后才会逐步向外探索，在这个过程又会产生新的需求，你不能要求部落头领第一天就给一个城市规划图出来吧

苹果的业务大于用户？有没有可能是圈中了一批喜欢探索创新精神的人做用户的

非常过分，但实际过程不会这么理想，你所谓的火堆木头，都是明确的目的。而现实中，绝大部分用户其实根本不知道自己想要什么。是脚踩西瓜皮，滑到哪里算哪里。你指望按他们的需求做，那你的项目永远不可能结束。你也永远不可能拿到钱。

做软件外包、人力外包、自研开发 逻辑是不一样的

自研是不断地迭代，根据数据 运营驱动增长

外包就是确定性，确定边界然后开工

近日，十多年从事开发工作的 Facundo Olano 写了一篇关于“软件开发应该优先服务谁”的文章，引发了广发开发者讨论。Facundo 在文章中提出，业务和用户的优先级永远大于维护者，维护者大于开发者，但对于业务和用户的优先级，则无法确定。对此，有开发者提出，开发人员其实必须满足的是中层管理人员的需求，而不是实际用户的需求，否则就拿不到订单。那么，在这个研发生态里，开发者明显处于底层，那谁才处于“食物链的顶端”？

“代码的阅读次数大于编写次数。”相信很多程序员朋友都听过这句话，它提醒我们作为代码开发者，绝不应牺牲未来的阅读和修改空间来换取一己之便利。换句话说，代码的阅读量要多于编写量，所以最好想办法保证代码简洁明了，同时辅以测试和说明文档等有助于提高可维护性的要素。

我个人则将其总结为更简洁的表达方式：

维护者>作者

其实在代码编写之外，这样一条经验法则也同样适用于发现问题和做出决策。

代码是用来跑的，不是用来读的

代码只是我们达成目的的手段。软件都有自己的目的，负责为特定用户提供服务。如果代码无法达成这项目的、为用户提供良好的体验，那么无论代码本身质量多高、可维护性多棒、涉及的技术有多么精妙，都将毫无意义。因此：