环信首席架构师：做业务系统如何成长为架构师？
你需要的只是持续学习，包接口也可以变成包老师
之前说到在『在行』开了个聊天话题『如何成长为一个合格的架构师』。前段时间有个朋友找到我，问了个非常典型的问题。
他说：『我现在在做偏业务开发方向的工作，在平时需要如何积累基础服务和系统架构方面的经验和知识。 』
很显然他意识到了两种系统的区别，而且正在试图转型。然而我知道，他也走进了一个让人难以反驳的认识误区，这就是，因为业务系统技术要求不高，所以开发人员在走向架构师的路上成长缓慢。
业务系统技术要求有多高
如果说从门槛来看，业务逻辑确实是最容易写的代码。产出好量化，功能又好测试。就算真的坏了，系统一般不会因此垮掉。只是，门槛低并不意味着容易做好。
有一种工作是API设计与实现，行话叫『包接口』，也是很多同学刚毕业的第一份工作。这事说起来简单，只要调用方跟被调用方协商一致即可，但是真正做的时候你会发现很多问题。
调用方首当其冲。如果命名混乱，找到想要的接口和参数就会变得很难。而如果你错误码定义得不够清晰，调通一个接口将会变成一个令人崩溃的事情。
被调用方也没有轻松到哪里去。如果没有遵循正交原则，那么你每个接口都可能涉及后端的很多资源调用和库的引用，导致服务不可避免得变大。一个资源的变化，都将有可能会影响到很多接口，这对回归测试和问题排查都将是一个灾难。
如果你在做一个平台，情况会变得更加严重。抽象不足的话，用户的每一个需求都会变成新的接口。而一旦发布出去，你就要保持其兼容性，也就是说，这辈子都是你的接口了。如果开始的时候没考虑到版本，那么恭喜你，从此要转行技术支持了。
这方面微信的开放平台接口，基本算是一个反例。返回数据JSON和XML混排，超出限制后无响应！？可惜的是，由于平台变大，作为调用方的开发者只能被欺（qiang）负（jian）。
现在所有的服务都在云化，其中的基础就是API化，这个事情也变得越来越重要。推荐在做这方面工作的看看 Principles of good RESTful API Design。http://codeplanet.io/principles-good-restful-api-design/
做业务系统会遇到很多这样的工作，做出来简单，但做好却难。是什么让我们却止步于做出来，并因此想做些有挑战的事呢？
被逼的工作，被逼的学习
因为大多数人都需要工作，很多人在做着自己不那么喜欢的工作。或因为感情，或因为压力，必须做完现在的事情。不喜欢意味着不会朝思暮想，不会为伊消得人憔悴。再好的职业素养，也不会改变做完即可的态度。
如果你是被逼学习型，找一份自己更喜欢的工作，事不宜迟。这里有一点个人的建议是，如果要走技术路线，不要做外包。
我们不排除有些工作因为容易掌握，大多数人都只是做完即可，但更多的情况是，不是工作要求低，而是做的人放低了对自己的要求。就像本文前面的业务系统，虽说离架构设计很远，但是基本功都是一样的。
值得注意的是，在一个分工明确的团队里，并不是所有人要做所有事，但是好的团队里所有人会了解所有事。一个开发者如果不了解上层服务的需求，不了解下层服务的设计，很难做好服务的。
只有对其他组件建立足够的了解，才能设计出一致的服务，减少过度优化和不当依赖。知道什么时候该容忍错误，什么时候该放弃请求，才能在出问题的时候快速定位，才能一起做好服务。
这种了解，就来自于对架构设计的理解。
不要被你的思想局限
如果你喜欢自己现在的事情，那么要恭喜你，你很幸运。而你需要注意的是，不要被自己的思想局限。虽然没人会要求你像卖油翁一样，在能倒油的时候练习从铜钱内穿过，但你至少要知道，还是有很多可以做的。
就拿本文开头的例子，你以为只是设计一个API，但其实API到底层数据到映射和转换，已经涉及了架构设计的基础。你以为只是设计成RESTful，但其实还可以做成自动测试的框架，像Swagger，或者RAML，或者API Blueprint。你以为你只是在包接口，其实是放弃了对自己的要求而已。
人永远不知道自己不知道的东西，这也是我们需要持续学习的原因。
包接口也能变成包老师。
阅读其他文章，请关注知乎专栏『 一乐来了 』
之前说到在『在行』开了个聊天话题『如何成长为一个合格的架构师』。前段时间有个朋友找到我，问了个非常典型的问题。
图片来源：Live Business Art Board
他说：『我现在在做偏业务开发方向的工作，在平时需要如何积累基础服务和系统架构方面的经验和知识。 』
很显然他意识到了两种系统的区别，而且正在试图转型。然而我知道，他也走进了一个让人难以反驳的认识误区，这就是，因为业务系统技术要求不高，所以开发人员在走向架构师的路上成长缓慢。
业务系统技术要求有多高
如果说从门槛来看，业务逻辑确实是最容易写的代码。产出好量化，功能又好测试。就算真的坏了，系统一般不会因此垮掉。只是，门槛低并不意味着容易做好。
有一种工作是API设计与实现，行话叫『包接口』，也是很多同学刚毕业的第一份工作。这事说起来简单，只要调用方跟被调用方协商一致即可，但是真正做的时候你会发现很多问题。
调用方首当其冲。如果命名混乱，找到想要的接口和参数就会变得很难。而如果你错误码定义得不够清晰，调通一个接口将会变成一个令人崩溃的事情。
被调用方也没有轻松到哪里去。如果没有遵循正交原则，那么你每个接口都可能涉及后端的很多资源调用和库的引用，导致服务不可避免得变大。一个资源的变化，都将有可能会影响到很多接口，这对回归测试和问题排查都将是一个灾难。
如果你在做一个平台，情况会变得更加严重。抽象不足的话，用户的每一个需求都会变成新的接口。而一旦发布出去，你就要保持其兼容性，也就是说，这辈子都是你的接口了。如果开始的时候没考虑到版本，那么恭喜你，从此要转行技术支持了。
这方面微信的开放平台接口，基本算是一个反例。返回数据JSON和XML混排，超出限制后无响应！？可惜的是，由于平台变大，作为调用方的开发者只能被欺（qiang）负（jian）。
现在所有的服务都在云化，其中的基础就是API化，这个事情也变得越来越重要。推荐在做这方面工作的看看 Principles of good RESTful API Design。http://codeplanet.io/principles-good-restful-api-design/
做业务系统会遇到很多这样的工作，做出来简单，但做好却难。是什么让我们却止步于做出来，并因此想做些有挑战的事呢？
图片来源：Surreal & Conceptual Photography by Diggie Vitt
被逼的工作，被逼的学习
因为大多数人都需要工作，很多人在做着自己不那么喜欢的工作。或因为感情，或因为压力，必须做完现在的事情。不喜欢意味着不会朝思暮想，不会为伊消得人憔悴。再好的职业素养，也不会改变做完即可的态度。
如果你是被逼学习型，找一份自己更喜欢的工作，事不宜迟。这里有一点个人的建议是，如果要走技术路线，不要做外包。
我们不排除有些工作因为容易掌握，大多数人都只是做完即可，但更多的情况是，不是工作要求低，而是做的人放低了对自己的要求。就像本文前面的业务系统，虽说离架构设计很远，但是基本功都是一样的。
值得注意的是，在一个分工明确的团队里，并不是所有人要做所有事，但是好的团队里所有人会了解所有事。一个开发者如果不了解上层服务的需求，不了解下层服务的设计，很难做好服务的。
只有对其他组件建立足够的了解，才能设计出一致的服务，减少过度优化和不当依赖。知道什么时候该容忍错误，什么时候该放弃请求，才能在出问题的时候快速定位，才能一起做好服务。
这种了解，就来自于对架构设计的理解。
不要被你的思想局限
如果你喜欢自己现在的事情，那么要恭喜你，你很幸运。而你需要注意的是，不要被自己的思想局限。虽然没人会要求你像卖油翁一样，在能倒油的时候练习从铜钱内穿过，但你至少要知道，还是有很多可以做的。
就拿本文开头的例子，你以为只是设计一个API，但其实API到底层数据到映射和转换，已经涉及了架构设计的基础。你以为只是设计成RESTful，但其实还可以做成自动测试的框架，像Swagger，或者RAML，或者API Blueprint。你以为你只是在包接口，其实是放弃了对自己的要求而已。
人永远不知道自己不知道的东西，这也是我们需要持续学习的原因。
包接口也能变成包老师。
图片来源：苍老师书法
阅读其他文章，请关注知乎专栏『 一乐来了 』
