读了王概凯《架构漫谈》九篇文章，去了解架构与架构师。我以为是技术文章，结果读下来，发现作者根本没在讲技术。他在讲什么？在讲“钻木取火”和“弓弦取火”有什么区别，在讲女主人让丈夫“把土豆切一半”结果丈夫削了半个土豆皮的笑话，在讲为什么有的架构师说话没人听。
说实话，有些地方看不太懂，但有些地方，我觉得我看懂了。
比如文章里反复在问一句话：“这是谁的问题？”
第一次看到是在讲架构切分那篇。作者说，很多架构搞砸了，不是因为技术不行，是因为一开始就没搞清楚“这是谁的问题”。他举了个例子：女主人让丈夫把袋子里的土豆切一半下锅，结果丈夫把每个土豆都削了一半皮。问题在哪？丈夫理解的是“执行指令”，但真正的问题是“做晚饭”。
我想到自己做课设的时候。上周写一个图书管理系统，需求文档里写着“实现用户登录功能”。我二话不说开始写注册、登录、session管理、密码加密，写了三天。写完发现，这个系统根本不需要用户注册——书是公开的，谁都能看，“登录”只是为了区分老师和学生。我做了个复杂的登录系统，但其实只需要一个下拉框让用户选身份。
这是谁的问题？是我的问题。我没问老师“登录用来干什么”，直接照着文档撸代码，做了个“削一半皮”的功能。作者说，把真正的问题找到，问题就已经解决了80%。当时没懂，现在有点懂了。
还有一篇讲架构师的“实权”。作者说，别空设架构师这个职位，要给他实权。不然设计方案没人听，落地落不下去，最后架构师就是个画图的。我们学生团队里没有“架构师”这个头衔，但有“组长”。我之前当组长，分配任务的时候特别客气：“你能做这个吗？”“你愿意做那个吗？”结果就是，有人拖到截止日期才说自己不会做，有人做着做着觉得没意思就换别的了，有人交上来的代码根本跑不通。最后我自己熬了三个通宵补坑。
下次我知道了，如果我是组长，我得有“分配任务的权”，也得有“如果做不完我来兜底的责”。这和文章里说的“权责对等”是一回事吧——虽然我做的不是什么大系统，只是几个人的课设，但这个道理是通的。有权利才有责任，有责任才有人听你的。没人听你的，什么架构都是白搭。
有一篇专门讲“怎么写好代码”。我以为会讲命名规范、设计模式、代码整洁之道。结果作者说，代码的问题往往不是代码本身的问题，是架构的问题。如果架构烂，再好的代码也救不回来。就像盖房子，如果地基歪了，用再好的砖也是歪楼。
想起上学期写的一个大作业，项目结构特别乱，各种文件堆在一个文件夹里。我花了两个周末“重构”——其实就是把文件分到不同文件夹，起了几个好听的名字。当时还挺得意，觉得代码变“整洁”了。现在想想，核心逻辑还是那一坨，只是换了件衣服。地基没动，只是重新刷了墙。代码写得好不好，可能真的不只是代码本身的事。
九篇文章读下来，最大的感受是：原来技术之外有这么多东西。在学校里，我们学的是怎么写代码、怎么调bug、怎么用框架。但这些文章讲的都是代码之外的事：怎么理解别人说的话，怎么把一个大问题切成小问题，怎么让别人愿意听你的。这些事课堂上不讲，但可能比写代码更重要。
作者有一句话我记下来了：“技术总是在人类解决对业务的要求不断提高的情况下产生。”意思是，技术是为了解决问题才出现的，不是为了技术本身。这话放在学生身上就是：我们写代码，是为了让那个图书管理系统能跑起来、能让老师查成绩、能让小组作业按时交上去——不是为了炫技，不是为了用上最新框架。
下次写项目的时候，我打算先问自己一句：我要解决的到底是什么问题？不是“老师要我写什么”，是“这个东西到底要干什么”。可能这就是我这几天读这些文章最大的收获。