之前学习了bob大叔的《clean architecture》，可以说写的十分的精妙了，里面很多理念跟我的认知是一致的。因为现在我的存货也没有了，所以接下来准备基于此book写一些关于架构的文章。
首先所有的一切的出发点是基于这个判断：软件开发的成本主要是人力资源成本。然而这两者又不是成线性比例的，当软件过于混乱的时候再怎么增加人力只会让软件更混乱。架构要解决的问题就是人力成本和软件生产力之间的矛盾的问题。
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
这里可以举个普适的例子。一开始如果一个公司只有几个人，那么它release一个版本是很快的。然后随着软件在市场上的成功，它会release越来越多的版本，增加越来越多的功能，需要雇佣越来越多的人。然而雇佣越来越多人和几个release下来以后，如果去看每个员工的平均代码产出，发现其实生产率是不断下降的，而因为雇了越来越多人所以雇他们的cost是直线上升的。尽管软件在市场上很卖钱，却抵不上雇人的成本，最后到了一个点，投入产出比就变成了负的，这个项目就没法维持了。这是一种普遍现象，而架构要解决的问题就是如何在少雇人的情况下增加生产效率。
软件这个市场的竞争是非常激烈的，你比别人慢一拍，就很难活下去。所以老板们总是要越快越好，然而越快代码质量就越差，质量差的代码在今后的某个时间点最终会"反噬"，导致越来越慢。
老板们可能会很有信心的说先快一点上线，赚到钱了然后再改。然而这是一种overconfident，这种事情从来都没有发生过。因为一旦上线就意味着你已经进入和别的厂商竞争的race，而race一旦开始就停不下来了，你就会被逼着要越来越快，再也没有清理技术债的机会。
The fact is that making messes is always slower than staying clean, no matter which time scale you are using.
The only way to go fast, is to go well.
每一个软件，它展示给人的都有两种不同的价值，一种是这个软件的行为的价值，也就是说这个软件能不能work。另一种是这个软件的架构上的价值，也就是说这个软件的design能不能允许这个软件易于修改。
行为的价值还是架构的价值，哪个更重要？这是我很喜欢的一种思考方式，举出两个fundamental的东西，然后比较哪个更fundamental。
这里bob大叔提供了一个简单的思想实验：
如果一个软件它work的很好，但不能修改，也就是没有架构的价值，那么过不了多久它就不能适应新的需求而变的没用了。
如果一个软件它不work，也就是没有行为的价值，那么只要它有好的架构的价值，我总可以以相对较低的cost把它改成能work的。
显然，架构优先于行为，架构比行为更重要。然而老板们往往要的是它的行为正确，能及时上线，而少考虑了它的架构的价值。
以艾森豪威尔矩阵来说：
我们应该把关注点放在A、B象限上，架构是重要的，它就落在A、B象限，而行为相对不重要，它落在C、D象限。我们经常犯的一个错误是，把C象限和A象限搞反了。
判断架构的重要性，这个是developer的工作，that's what software developers were hired to do. 然而窘境在于，其他team的视角更在意于软件行为的价值。
bob原文：
Fulfilling this responsibility means wading into a fight - or perhaps a better word is "struggle". Frankly, that's always the way these things are done. The development team has to struggle for what they believe to be best for the company, and so do the management team, and the marketing team, and the sales team, and the operations team. It's always a struggle.
不过再怎么struggle，这也是一个developer的职责，to fight。Remember, as a software developer, you are a stakeholder.
网友评论