写一个功能应该从定义开始。
作为功能的实现者，对于实现细节的追求似乎刻在了骨子里， 我们追求性能优化， 更有效的算法，更少的内存占用，更可控的数据流行为... 这些永远是没有错的，人们总是追求更好的产品。但是开发一个新的产品的时候，这样的思维惯性实际上会带来一些困扰。
一个很愚蠢的恶循环是， 我们想要一个很好的产品，于是我们使用更好的技术，在细节处精益求精，这导致我们永远会发现更好的做法，于是我们永远无法完成这个产品。更好一些的是，在一开始就敲定设计然后实装。这是比较传统的做法，适用于很多大型系统，而敏捷开发则是对这类做法的一种扩展，由于小型的系统对于细节设计的需求并不像大型系统那样的高，修改也比较容易，所以设计工作和开发工作被整合，通过将传统流程简单化，多轮化，团队得以用更快的速度交付产品并获取反馈。这些年为了适应这样的趋势，市场上出现了许多的相关服务和工具。
有没有一种模式，可以适应大规模开发的需求，同时提速到类敏捷开发的速度？几年前我读过关于领域驱动设计的几本书，这是一种很好的开发模式，但是它对于团队的要求比较高，换句话说，它依然是一个高成本的选择，同时，如果不能快速磨合整个团队，他的开发速度依旧是偏慢的。
现有的开发模式似乎总是要求人们去学习一些新的概念，有没有通用的概念可以让我们直接上手？其实是有的，因为这个领域的人们或多或少都得学点数学。
是的，数学， 或许是这个世界上最多人使用的，最具有共识力的一种工具模型。我的父母或许不懂怎么写一个软件统计和计算每月营业额，但是他们也能通过数学手段得到一样的结果。当我们去查看我们的软件的构造和逻辑的时候，他们只是一些数学理论的实际应用而已！在现代的许多设计理念里可以看到数学的影子，或许是时候把概念引回纯粹的数学领域了。
这些年函数式编程的日趋流行，似乎正是这种思想的一种实际体现。所以让我们回到最开始的那句话：写一个功能应该从定义开始。这句话其实是关于数学的，数学是关于定义的，严谨的定义带来严密的证明，一个可供证明的定义才是可用的，安全的。集合论群论圈论拓扑学等诸多定义定理使得我们可以在这基础上构建一个可供证明的安全的，可扩展的稳定系统架构，强大的限制性条件使得每一个功能都能严密统合，而不用去关注最底层的实现细节。