优秀程序员需要具备的特质
其实相对于架构师和CTO来讲，做程序员是最简单的，只需要会写代码就可以，但问题是，只要会写代码就能成为一个优秀的程序员吗？答案显然是否定的。因为，成为一个优秀的程序员，需要多重考量，还需要具备一些特质。我根据自己的经验总结了五点，我把它称为“五精”。
1.精细，在细节之处深思熟虑。比如代码结构、变量命名、作用域、封装、类的关系等细节。举个例子，对一个变量的命名，应该用短命名，还是长命名，用A来表示，还是用一个特别长的句子来表示？这些细节，在你写代码时，就应该仔细衡量，因为它将影响代码后续的可读性与可维护性。
2.精湛，写出漂亮的代码。在豆瓣任职时，我们有一句半开玩笑的话，说豆瓣是工程师文化，意思是工程师要有文化。我觉得除了文化之外，工程师还需要有一定的美感，分辨一个设计是否简洁、优雅、高效。
3.精通，了解上下游知识。除了关注自己写的代码与模块，一个优秀的程序员还需要对上下游的知识有所了解。比如你是负责前端的，那你也需要了解一下后端是如何迎合你的请求的；如果你负责后端，你还需要考虑你的代码是如何做运维的；当你去访问数据库时，你需要了解，数据库是怎样应对你的产品请求的。只有将上下游的支撑都了解之后，写代码时，才能够更加准确、更加高效。
4.精深，掌握技术细节。包括语言细节、类库细节、算法细节、运行环境细节，等等。比如你使用一门语言，那你需要知道这门语言的各种语法细节，以及在什么地方最容易出错，怎么做能够有效的规避它等。再比如你使用的类库是怎样实现的，它在什么场景下的表现最好，在哪些场景下会出现问题等。还有运行环境，你不仅需要考虑业务逻辑，你可能还要考虑内存占用问题、缓存问题、磁盘问题等。这些都需要你对技术细节有较深的掌握度。
5.精明，做到准确交付。一个优秀的程序员不仅需要优雅、高效的实现需求，还需要在准确的时间内，交付符合质量的内容，这就需要我们去理解需求，并通过协商和沟通对不合适的需求作出调整。另外，也需要我们准确的评估工作量，判断优先级事项，做出考量和取舍。
而当你到达考量与取舍阶段时，就说明你已经开始具备一些架构师所需的特质了。
如何成为一名优秀的程序员
那怎么做，才能拥有这些优秀程序员需要具备的特质呢？我认为最重要的事情是互相学习，向更优秀的人学习。
举个例子，在豆瓣时，我们有一个非常好的实践就是做Code Review。最开始的时候，大家把所有的代码投到屏幕上，并各自讲出写代码的思路，其他人可以自由发表评论。这样做其实效率非常低，但我们一直坚持了下来，直到GitHub出现，我们用其中Pull Request的方式来做Code Review，效率才大大提高。
用GitHub做Code Review，收到的评论会非常多。如果一段代码几乎没有人表达反对意见，很大程度就能代表这是一个不错的代码。如果出现一段糟糕的代码，评论内容就会非常犀利的指出问题。也正是在这样不断评判与被评判的过程中，大家逐渐学会提高自己的代码水平，成为一个更加优秀的程序员。
另外，我们可以多参与技术社区，多参加各种技术交流活动和技术大会，多多跟他人交流。我们也可以不断地去参与开源项目，现在是一个最好的时代，GitHub的存在，让每个程序员能更容易地看到更多优秀的代码。
从程序员到架构师
你可能会问，那是不是一个程序员，只要能写出漂亮的代码，并且能够优雅、高效地实现业务需求，做到准确交付，就一定能成为架构师呢？
答案是否定的，即使一个程序员做到了“五精”，把“五精”做得再好，他的个人能力也是有上限的，他所实现的系统的复杂度也是有上限的，而业务的发展会远远超出个人的能力。
因此，我们需要把业务需求拆分成多个组件，再将每个组件分发给优秀的程序员来完成，通过互相协作，最终完成一个整体的业务需求。
在这里，分发的工作就是架构师的职责，架构师主要在解决Scalability的问题。它包括两个方面，一方面是人的Scale，比如业务需求变复杂后，单人不足以承担，这时就需要多人协作，那如何分解业务，如何将分解后的业务匹配合适的人，如何协作，就需要架构师来进行判断。
另一方面是量的Scale，比如当QPS从几十个增加到成千上万个，甚至几十万个的时候，面对这种情况该怎么办？这就是架构师需要解决的问题。
因此，当你从实现一个具体的功能，到考虑解决Scale问题的时候，你就已经开始走上了架构师这条路。即使你的title还是程序员，但是，你已经开始向架构师这个角色转变了。
总结
本文，我主要分享了一名优秀程序员所需具备的特质，即精细、精湛、精通、精深、精明这五个特质。另外，从程序员到架构师，不在于title如何，而是当你的着眼点更上一个层级，更多的理解业务需求，然后思考如何解决宏观问题、提炼通用组件、设计协作方式等问题的时候，你就是一名架构师了。
优秀架构师需要具备的能力
我觉得一名优秀的架构师，需要以下这四个关键能力：取舍、前瞻、抽象、容错。
1.取舍
一个架构总是有优有劣，它不会是完美的、普适的，也不存在一个架构在A场景能用，在B场景也最适用的情况，所以就需要我们准确判断，作出取舍。
我们可以根据具体的业务需求来调整架构，也就是以当前的业务需求，选出最匹配的架构。另外，架构师还需要根据现状衡量好需求和资源、效率和安全、时延和吞吐等等之间的关系，做出判断。比如对于在线系统，可能更重要的是保证它的高时延，因此就可以牺牲一定的吞吐量，而对于离线系统，吞吐量则更重要一些。
2.前瞻
架构师需要具备一定的前瞻性，因为架构的调整周期比较长。这也是程序员和架构师之间一个很大的区别所在。
程序员负责一个项目，在当前的互联网协议下，项目的迭代周期非常快，基本以天或周为单位，最多一个月。如果发现不合适的代码，需要重构，程序员基本也能在几天或几周内就能完成重构。
而架构的调整是相对漫长的过程，可能需要数月，甚至要上年。因此，在设计架构时就需要架构师具备前瞻意识，对很多不确定的事情做出预判，比如未来访问量会增长到什么程度，会不会产生新的业务，这些会对系统产生什么样新的要求等等。
3.抽象
除了懂得取舍和拥有前瞻意识，架构师在设计架构时还要掌握抽象的方法，不能胡子眉毛一把抓，要做好分层和区隔。
因为架构师面对的是一个很庞大的系统，为了避免过早陷入细节，不要去看各个组件的细节，而是把它们的角色定义下来之后，再分块来思考。而在看每个分块时，其他分块都可以视为一个抽象的概念，另外，也需要考虑复用的问题。
举个例子，我们现在正在做的对话机器人，就运用了分层思想，并且高复用，一个对话机器人可以完成各种各样的业务需求。这其实是一个非常复杂的系统，里面有各种各样的对话机器人的模块，有的特别适合去做检索式的查询，还有的适合做任务导向的、产品推荐导向的对话等等。
我们把对话机器人抽象成一个通用的接口，再将它分为一个个小机器人。这样一来，每个小机器人只需要关注自己的业务模块就行了。然后，我们会在前端再引入一个路由机器人，由路由机器人根据当前对话管理的状态，来判断当前的对话应该交给哪个小机器人去完成。这就是典型的分层的思想。
4.容错
相比程序员，架构师面对的环境要恶劣的多，因为系统复杂了，出错的几率也增加了，每个节点、每个功能都有可能出错，所以这就需要架构师为错误而设计，事先做好解决方案。
除了出错，还有可能产生数据丢失的情况，这个可以通过备份来预防。有句话说“备份不做，日子甭过”，做好备份也是非常关键的。
另外，如果出现故障，该怎样去恢复呢？我们现在普遍的做法是不修只换，因为如果要修复一个异常状态，可能修复后还会出现连带问题，而如果能通过技术手段，删除已出现的故障，换一个全新的系统，就能够保证它迅速恢复到正常状态。
总结
职业发展的过程，就是眼界不断提高的过程。对于程序员而言，从写代码，到关注代码与代码之间的关系，再到关注代码与系统之间的关系，这时，他就开始承担了架构师的职责。
架构师主要是在做系统的事情，他的着眼点会从系统与系统之间的关系，到系统与业务之间的关系，到这时，他开始承担一些CTO的职责。而对于CTO而言，他关注的是业务，然后逐渐关心业务与业务之间的关系，最后关心业务与战略方向的关系。这个眼界提升的过程就是从程序员、架构师到CTO的发展路径。