&p&【编者按】起初我是在2010年5月为Fuel Your Coding网站写的这篇文章。然后这个网站现在已经不存在了，为了让爱好编程的人们能够继续受益，所以在这里重新发表这篇文章。我考虑过是否要按照现如今的情况来对这篇文章进行修改，但是我认为它已经足够经得住检验了。只有少许的部分可能不尽人意。尽情的欣赏这篇文章吧。&/p&&p&正如每个人都知道的那样，写更多的代码是提高编程能力最显著方法。但是我所确信的另外一种可以提高编程能力的方法是与写代码完全相反的。我将要尽可能清楚的陈述这种方法。&/p&&p&只有大量的阅读别人的代码才能显著的提高你自己的编程能力。&/p&&p&不论你是否相信，但是我觉得你可以试一下，你会觉得自己所花的时间是完全值得的。&/p&&p&在这篇文章里我将会教你如何选择阅读的内容以及教会你如何阅读。如果你已经知道如何阅读代码，或许你已经发现通过你的努力可以获取更多。如果你还不知道如何很好的阅读代码，那么请一定继续往下看。&/p&&p&&b&读什么？&/b&&/p&&p&我们很难决定阅读什么样的代码，也很难给别人建议。我不会简单的给你指出你应该读什么样的代码，因为它最终还是取决于你喜欢读什么。我会给你提供一些参考，使得你能够有所侧重的去选择阅读什么代码。&/p&&ul&&li& 阅读你信赖的代码&/li&&/ul&&br&&p&你已经在使用的插件或者库会是很好的选择。&/p&&p&一个你十分喜欢的WordPress plugin&/p&&p&一个你已经发现很有用处的Ruby gem&/p&&p&一个你会经常回顾的jQuery plugin&/p&&p&这些都是极其不错的可以作为候选的地方。如果你已经对其公开的APIs十分的熟悉，那么理解其内在的工作原理已经不再是一件困难的事情。另外，作为一个代码的使用者，你有机会为其添加文件，实现一个新的功能，或者对原来的项目提出修改的建议。&/p&&ul&&li& 阅读那些能够让你眼前一亮的代码&br&&/li&&/ul&&br&&p&我还记得第一次看 280 Slides 的时候就心想这些代码让我眼前一亮。随后我迅速发现这个网站的源代码是Cappuccino的开源项目。当这一信息在我的大脑深处徘徊的时候我猛然想起另外一个让我印象深刻的软件也是运行在Cappuccino上的，这时候我知道了有一个我可以学习到很多东西的项目了。有什么是让你最近印象深刻的？它是一个开源项目吗？如果是的话，那么它将会是一个值得你去读的代码，因为这些代码会像最终的应用一样吸引你。&/p&&ul&&li& 读那些你认为是大牛所写的代码&/li&&/ul&&br&&img src=&/v2-b0e7cf40ccf223e2416c6_b.png& data-rawwidth=&438& data-rawheight=&88& class=&origin_image zh-lightbox-thumb& width=&438& data-original=&/v2-b0e7cf40ccf223e2416c6_r.png&&&p&如果你已经用开源项目的软件编程了一段时间，&/p&&p&那么肯定有发现其他能够让你印象深刻的程序员。&/p&&p&我的脑海中有那么几个能够写出让我十分羡慕的代码的程序员。&/p&&p&如果你的印象里还没有这样的开发者，只要你愿意的话是很容易找到一个的。他/她或许在过去已经写了属于以下2个类型中的代码。（一种是你所依赖的，另一种是令你印象深刻的）&/p&&ul&&li& 读那些你可以意会的代码&br&&/li&&/ul&&br&&p&如果你勇于冒险的话，那么有可能会考虑深入研究类似Ruby on Rails, Drupal, 或者 jQuery的大项目。我建议你现在最好不要接触类似的项目，除非你在阅读代码方面已经很有经验了。&/p&&p&大的项目有很多可以移动的模块，你可能会纠结于很多概念而无法及时学到很多知识。疑惑会令人泄气，在阅读大的项目的过程中更加容易产生疑惑和泄气的负面情绪。从一个小的项目入手的好处在于整个程序的完整逻辑可以在脑海中浮现。剩下的就是去探索其细节并从中学习。&/p&&p&&b&如何阅读代码？&/b&&/p&&p&既然你已经选择了一些要读的代码，那么什么是最好的阅读方式呢？我在过去阅读了许多的代码，因此可以给你推荐一些可以最大化投资回报率的方法。&/p&&p&下面请看这张大图&/p&&img src=&/v2-e8c85ccdb2e2_b.png& data-rawwidth=&230& data-rawheight=&510& class=&content_image& width=&230&&&p&假设你已经在阅读代码方面达到了一个突出的水平了。如果没有，那么建议你去查看项目的网站、使用说明书、文件或是任何除了代码外帮助你理解的内容。&/p&&p&那么，我首先建议的是使自己的脑海里有这个项目清晰的框架。其工作量是基于你所选取的代码库的大小。但是只要是大于一个文件的项目都会消耗一定的时间。&/p&&p&首先对文件的结构加以注释。如果一个编者的文件具有像TextMate一样的可视化视图结构将会极大的帮助这一步骤的完成。譬如这里有一个Twitter Ruby gem的完美概要。&/p&&p&这一步骤的目标是为了让你更加的熟悉代码。找出那些文件包含/需要/加载其他的文件，以及代码主题的位置，是否用过命名空间，或是其他诸如此类的东西。如果你已经了解了大的架构，那么你就可以深入去关注其细节了。&/p&&ul&&li& 记录下你所发现的东西&br&&/li&&/ul&&br&&p&阅读代码应该是一个主动的行为。我鼓励你根据自己的想法增加一些评论，当你理解程序的流程的时候记录下你的假设以及自己的结论。那么刚开始的时候你的评论可能是这样的：&/p&&img src=&/v2-b4bfb8887ebb9c1f723ba25f5bb542fb_b.jpg& data-rawwidth=&1270& data-rawheight=&189& class=&origin_image zh-lightbox-thumb& width=&1270& data-original=&/v2-b4bfb8887ebb9c1f723ba25f5bb542fb_r.jpg&&&p&当你的理解不断的进步的时候你会减少那些碎片化的评论并且能够增加一些更加有意义或权威的评论，这些评论或许能够对完善原来的项目有所帮助。&/p&&ul&&li& 使用测试，Luke&br&&/li&&/ul&&br&&p&但愿你选择的项目有测试的套件，如果没有的话你可以完全跳过这一部分（或者重新选择一个有的项目）。&/p&&p&测试是一个很好的地方能够让你随时阅读别人的代码因为它们记录了这些代码需要实现的功能。一些测试能够提供很多的信息，但是不论写的有多好，你在测试里可以比在执行里更好的发现作者的意图。在你阅读代码的时候尽量让其测试的套件成功运行。这会让你的开发环境得到合理的配置，也会让你更加自信的去做出一些改变。&/p&&ul&&li& 执行，调整，再执行&br&&/li&&/ul&&br&&p&谁说看代码的时候就不能执行代码？只有将一切东西拆解再将其恢复原样才能真正的理解其本质。还记得那些你所经历的测试吗？在失败后，增加一些代码，或者在不破坏的前提下改变其执行的情况。尝试增加一些你觉得很酷的小属性，或者在项目范围内增加一些记录，这样你就可以在编写代码的不同阶段打印输出。这些还仅仅是阅读代码吗？&/p&&p&这是毫无疑问的，但是从这个角度看更像是一段奇妙的经历而不是阅读一篇神秘的小说。这是一件非常好的事情。&/p&&ul&&li& 冲洗和重复&br&&/li&&/ul&&br&&p&一旦你阅读完一个代码库，立即选取另外一个并重复之前的步骤。你只有阅读足够多的代码，才能提高阅读新的代码的效率。你会发现你的投入产出比在不断的上升并且发现这是一个十分有趣的学习过程。&/p&&ul&&li&从哪里开始？&br&&/li&&/ul&&br&&p&在我的代码阅读资源中，GitHub是对我影响最大的。在这个网站里，你能够很快找到新项目以及其作者，如果你不使用这个网站那么对你来说是一个很大的损失。我建议先从GitHub上开始直到你能够找到一个可以学习的项目。记住下面这段话并开始阅读吧。&/p&&p&你是怎么看的？你是把阅读代码当成一种学习的手段吗？你会给别人推荐哪些项目？最近是否阅读过很好的代码？&/p&&p&因为The Wayback Machine的缘故你可以阅读到原来的文章。&/p&&p&作者介绍：Jerod Santo是Changelog Media的主编和合伙人。他联合主编了旗舰博客—The Changelog，他领导了所有使得Changelog变得更加酷炫的项目。他也经营着自己的订制软件公司Object Lateral。&/p&&br&&p&本文由北邮@爱可可-爱生活 老师推荐，阿里云云栖社区组织翻译。&/p&&p&文章原标题《One Sure-Fire Way to Improve Your Coding》，作者：Jerod Santo&/p&&h3&更多相关文章&/h3&&h1&&a href=&/p/& class=&internal&&不想被选择推荐看下这篇：程序员生存定律1&/a&&/h1&&h1&&a href=&/p/& class=&internal&&程序员生存定律2-打造属于自己的稀缺性&/a&&/h1&
【编者按】起初我是在2010年5月为Fuel Your Coding网站写的这篇文章。然后这个网站现在已经不存在了，为了让爱好编程的人们能够继续受益，所以在这里重新发表这篇文章。我考虑过是否要按照现如今的情况来对这篇文章进行修改，但是我认为它已经足够经得住检…
谢邀。&br&&br&这种困惑相信很多技术人员和技术管理人员都存在，包括我自己，当然这种困惑本身也是符合学习曲线规律的，即任何一个技术学习和实践，越是到后面学习的时间
越长，本身能力提升越慢。但是往往真能够坚持和专注，能够耐得住寂寞等到量变到质变的那一刻，就是一种一览众山小的新境界。&br&&br&对于上面提到的三个困惑点，自己简单思考如下：&br&&br&&b&其一，技术学习的困惑&/b&，
任何新技术或知识点的学习，在当前互联网和信息如此发达的情况下，只要你有兴趣就一定能够找到相关的学习资料进行自我学习，兴趣往往是第一个驱动点。但是
问题的关键点还是在于学习后的新技术如何深入，新技术如何去实践？没有真正的实践总结，没有真实的大型项目实战驱动，你将发现理论终归是理论，理论要转化
为你的实战经验是相当困难的。&br&&br&如果一个新技术的学习没有实战机会，那么你自己也很难真正保持长久的兴趣，能够做到熟悉或知道已经不错了，
而要真正做到精通或理解就很难。大量技术的深入学习往往都是在实践中真正遇到了复杂的问题，在问题驱动下的学习和深入，这些错综复杂的问题往往涉及庞大的
知识面，而且各个知识点之间相互影响。我们如果有实践机会能够不断的解决这类问题，不断优化和持续改进，技术自然深入。&br&&br&举一个简单的例子
来说，对于海量数据处理下的高并发互联网架构，这类架构知识有不少书籍都在系统的讲，往往也有很大技术专家的实践分享。我们学习这些理论往往看起来简单，
也容易理解，但是即使你学习了这些知识，如果没有相应的大型互联网系统架构设计场景给你实践，那理论终究是理论，这些理论本身你也很难真正的深入学习。正
是由于这个原因，技术学习的困惑不是简单的兴趣问题，而是是否有大型项目实践机会和锻炼的问题，但是往往大部分的公司都无法真正提供这种大型项目的机会，
你要完全通过自己学习和模拟试验来深入掌握这些技术就变成了空话。&br&&br&&b&其二，技术学习的深度和广度问题&/b&，对于这个问题简单回答就是对于技术管理型人员重点是更广的知识面和综合能力提升，即广度更加重要而不是落入某一个深度细节。对于专业技术型人员，则是技术深度更加重要，因为技术的深度往往才真正为你创造更大的价值。&br&&br&技
术管理型人员需要更加关注整个知识体系的构建，其中包括重要的软技能。这类人员的重点是总体规划和设计，能够对问题进行分解。对于分解后的技术问题和细节
则可以转交到细分岗位的专业人员去做。要做到这点我们仍然需要有大量的技术积累，因为这是你和专业技术人员沟通的桥梁和通用词汇。&br&&br&对于专
业技术人员，技术的深度往往更加重要，深度才是最终创造价值。前面已经谈到过，技术深度的提升越到后面越慢，学习的周期和时间成本越大。也正是由于这个原
因，能够超这个技术金字塔顶尖上去发展的人越少，自然你个人的核心价值体现越大。个人的精力是有限的，要想做到全栈技术人才的人相当少，即使是全栈技术人
才更常见的情况往往是在自己最擅长的专业技术上能够打到95分以上，而围绕核心专业技术的相关技术能够打到80分以上。&br&&br&理解了这点，我们
就更加清楚技术人员应该更加注意技术深度的积累，能够长期专注在一个专业技术方向上，这个目标选择定了，你会发现对于广度知识的选择就不是漫无目的和随意
的，任何广度知识的选择都是这些广度知识是为了支撑你在深度上进行突破。当我们技术深入到瓶颈期后，如果自己反思和回溯，都会发现是知识广度上出现了问
题，需要暂时停顿下来先补充广度。但是广度的补充不是最终目标，最终还得回到深度钻研上来。&br&&br&&b&最后一点，技术方向的选择。&/b&对
于这点个人最大的一个感受就是当你真正在某一个技术领域发展到一定阶段的时候，一定不会是像自己还是新人那样狂热的追求新技术和热点。即专家更多要考虑的
是业务和问题驱动技术，用最适用的架构在当前解决最重要的问题并保留一定的扩展性，而对于大部分技术思维人员往往考虑的是技术驱动业务，只是对技术感兴趣
而不是对业务和问题域感兴趣。&br&&br&技术发展趋势和迭代的快速，你任何当前选择的技术或框架都可能在2-3年后就过时，但是如果当前的技术能够很好的支撑业务就是最好的技术。如果有不能更好支撑的地方我们就要考虑基于当前遇到的性能或扩展性问题我们究竟应该引入什么新的技术来解决，并做好方案选择和评估。&br&&br&所
以最后一个问题个人认为不是技术方向的问题，对于任何新技术都应该有敏锐的嗅觉去了解，但是并不是每个技术都要真正在项目里面使用。项目不是新技术的试验
地，本身也不存在技术驱动的技术方向选择问题。而只存在业务和问题域驱动的技术架构优化。业务和问题驱动IT和技术，是从单纯技术思维开始转变的一个重
谢邀。 这种困惑相信很多技术人员和技术管理人员都存在，包括我自己，当然这种困惑本身也是符合学习曲线规律的，即任何一个技术学习和实践，越是到后面学习的时间
越长，本身能力提升越慢。但是往往真能够坚持和专注，能够耐得住寂寞等到量变到质变的那一刻…
&p&不管您是否承认，除去极少数天赋异禀、骨骼惊奇的天才程序员，我们大部分人都是普通人，都需要遵循“一万小时定律”，才能从平凡变成超凡。&/p&&p&凡人要从一个小菜鸟成长为全栈工程师，只能从少到多、慢慢积累知识和经验。职业生涯的本质，就是在一个专业方向上积累信息。这里我推荐采用“先精后广，一专多长”的流程来学习。采用这种方式来学习，不光可以触类旁通、举一反三，还让我们学习得更快，而且循序渐进更符合一般人的职业生涯发展。&/p&先精后广，一专多长&p&“先精后广，一专多长”是指，建议初学者学习全栈技能的时候，先在一个特定的方向上有比较深入的钻研，然后再将学习目标渐渐推广开来。比如先从前端方向入手，掌握了基本的HTML、CSS、JavaScript之后，不要转头向服务器端语言或者App方向发展，而是深入到性能优化、SEO、多种框架、响应式页面等前端细节中去。经过一到两年的深入研究之后，再去学习其他方向。&/p&&p&如果在创业公司做全栈的工作，一般也不会要求一个人处理所有的技术工作，至少会有两三个人组成团队来做项目。大家在分配工作的时候，可以按照每个人的偏好和技术特点，进行前后端的分工，不用完全按照每个人做一个模块的方式来分工。这种分工的界限不一定要很绝对，在不同职位的工作范畴中，可以有一些重合的区域。&/p&&p&如果是毕业生或者初学者，我不建议在刚开始的一到两年接触太多技术，杂而不精，结果可能会对后面的职业道路产生副作用。&/p&&p&为什么我强调在开始的时候有一个专精方向的重要性呢？因为这样您才能在求职的时候有一个“亮点”。&/p&&p&平心而论，程序员在市场上的供求关系比很多其他职业都更有利于求职者，在微博、Twitter、V2EX上都会有很多引人注目的招聘启示，大家对优秀程序员的需求从来就没有减少过。&/p&&p&虽然优秀的程序员总是能找到工作并且工资不低，但是很多程序员投出的简历都石沉大海，一个主要原因是由于求职者的简历没有亮点，或者说从工作经历中提取不出来一个亮点。&/p&&p&让我们做一个情景假设，作为一个有两年工作经验的全栈工程师，您看到腾讯有一个职位空缺。&/p&&p&腾讯社交用户体验设计部招聘前端开发，要求如下。&/p&&ul&&li&本科以上学历。&/li&&li&两年以上工作经验。&/li&&li&精通HTML、CSS、JavaScript等前端相关技术,熟悉W3C网页标准。&/li&&li&熟悉至少一种后台语言的开发机制(如Java、C++等)。&/li&&li&有一定架构能力和算法能力，有良好编码规范。&/li&&li&良好的学习能力、沟通能力，追求完美，有工作激情，能在较大强度下工作。&/li&&li&热爱互联网，喜欢研究各种互联网技术者更好。&/li&&/ul&&p&您想，自己完全满足要求啊，于是一封简历就投递到面试官的邮箱，里面用大段文字表达自己全面的能力完全符合这个要求，而且自己还有亢奋的激情和浓厚的兴趣。&/p&&p&但是您从面试官的角度来想想，他收到了多少份简历呢？对于一个大公司的HR，可能100个都算少。&/p&&p&根据中国招聘平台拉勾网“2015年互联网人才流动报告”，前端相关岗位的简历投递数只有岗位数的一半。与此同时，服务器开发方向（比如Java、PHP、C++等）的简历投递数都大大高于岗位数。从图表可以看出，前端开发仍然处于人才紧缺阶段。&/p&&p&HR要从100个符合要求的人中选择10个来面试，您的简历中的哪一点能吸引他呢？有的竞争者有丰富的移动端作品，有的竞争者提到他很擅长页面性能优化、响应式、页面渲染效率，有的写过JavaScript框架……而您只是一个普通的满足要求的人。&/p&&img src=&/19cadfc593f_b.jpg& data-rawwidth=&700& data-rawheight=&540& class=&origin_image zh-lightbox-thumb& width=&700& data-original=&/19cadfc593f_r.jpg&&&p&不同职位的供求关系是不一样的。&/p&&p&您可能会说，我爱好广泛，学习能力强，我会一点PHP，做过Wordpress主题，会一点Java，毕业设计做过一个小客户端应用，什么都会一点……但最终您仍然会得到一个“无亮点”的评价，被无情地淘汰掉。因为虽然您会的技能很多，但大多只能算是“及格”的东西。&/p&&p&所以，作为一个求职者，无论是毕业生还是社会招聘，仅仅满足招聘要求是不够的。您需要在招聘要求的方向上以200%的能力来得到这个职位。&/p&&p&一个求职者在整个流程中会受到多方考核：HR考核您的成本和价值，专业面试官（不是全栈工程师）考核您的专业能力，经理考核您的沟通能力。在所有这些考核中，其实每一环都是漏斗型筛选，会过滤掉一些人。&/p&&p&好消息是，由于程序员的供求关系，只要您的专业能力够强，您就有很大的概率通过整个面试录用流程。我一次又一次提到“供求关系”这个词，是因为在商业社会，所有的商品（包括人才）的价值来自于供求关系，而不是生产成本。生产成本是准入门槛，但绝不是核心竞争力。&/p&&p&让我再次重复这一点，作为求职者，一定要在某个特定方向上有非常深入的理解。仅仅会做还不够，还要理解背后的原因，还有背后的背后的原因。有些面试官的习惯是，在一个问题上深入地问下去，从经验问到操作过程，再问到技术原理，一直深入到面试官问不下去了，或者求职者答不上来了。所以，理解得越深刻，您就越有优势。&/p&&p&有了一个专长，得到一个能让您成长的工作，进入强大的团队，您就能有自己的阵地，以此为生，然后再逐步学习更加广博的知识，朝自己的个人目标去努力。如果您连阵地都不稳固，就不存在开枝散叶、落地生根的可能性了。&/p&&p&假设您已经在一个中等规模以上的公司找到了工作，那就会有一个专门的岗业。经过几年的工作和练习，您会在专业知识上达到很熟练的程度，日常需求都已经在您的“舒适区”，现在您终于准备好了。既然您的目标是做一个全栈工程师，那么从哪些技术开始入手呢？&/p&围绕商业目标&p&我的第一条建议是，在考虑做什么项目的时候，围绕商业利益作为目标。归根结底，技术是服务于商业目标的。&/p&&p&在计算机科学诞生的短短几十年中，热门的技术和平台一直在发生巨大的变化。&/p&&p&服务器端的平台和语言从C到C++、Java、Python，再到如今的Node.js，变化从来没有停止过。&/p&&p&客户端则分浏览器和原生开发两个分支。浏览器方面，Web标准是一个活的标准，意思是说，有一些新的提案不停地加入到标准之中，这是一个动态滚动的标准，而不是印刷出来的定案。&/p&&p&各种浏览器的市场份额每隔两年就会发生天翻地覆的变化，从moz到Webkit，我们见证了Webkit的发展壮大。&/p&&p&移动端设备的市场份额之争更是激烈，曾经的诺基亚和摩托罗拉被新起之秀收购，iOS和Android之争还在继续……&/p&&p&仅仅据我所知，2014年到2015年腾讯就有很多团队进行了从PC端到移动端、从HTML5到原生App开发的各种转型。没有人能说得准下个季度我们团队的目标是什么，每半年就有一次大的调整，而小的调整从来就没有停止过。“变化”是唯一保持不变的东西，每个人都在不停地学习新的技术。&/p&&p&相对来说，商业目标是稳定的。把关注点放在商业目标而不是技术上，就能选择出更适合完成商业目标的技术，这样就能做出更为客观的决定。更重要的是，在这个过程中您学习到的不仅仅是技术，更是一种潜在的思维方式，这种思维方式可以帮助您提升综合竞争力，是一种“硬通货”的能力。&/p&&p&老板雇用一个员工，不是因为他能写程序，而是因为他能帮助自己赚钱。赚钱有两种方法：减少成本，或者增加收入。程序员如果能加快内部系统的运行效率，让产品制作流程更加顺畅，就是减少成本。如果能让用户更容易地购买产品，或者提高服务质量吸引更多用户，就能增加收入。在老板看来，程序员只是一个昂贵的劳动力，他会不会写程序都没那么重要，重要的是能赚钱。&/p&&p&所以如果您想成为一个高级开发者（或者高级设计师），就一定要学会这种思维方式。&/p&&p&所谓“商业目标”要广义地去解读。对于直接制作产品，给用户使用的团队，就需要对外关注如何提高产品质量、降低产品成本；对内应该关注如何优化流程、减少错误率。如果团队输出的成果是公司内其他部门需要的原材料，就要关注下游的需求，研究如何更好地输出成果，如何在流程上使得输出产品的过程更顺畅。&/p&&p&关注商业目标需要持久的练习。等到自己成为全栈工程师，或者成为团队管理者，更加需要在多个目标任务之中做出选择。全栈工程师需要做和能够做的事情是很多的，他会很多技能，也负责处理很多工作，所以他更需要能力从诸多事情中找到最有商业价值的一个：可能是制作一款工具提升团队效率，也可能是成本上的优化。&/p&&p&全栈工程师可以做得事情越多，就越需要具备判断做什么的能力。如果增加一个用户需要的功能是加分项的话，拒绝一个用户不需要的需求更加值得推崇。&/p&&p&一切都要围绕商业目标来进行，包括您做的项目、您的汇报方式，以及您在学习新技能时进行的取舍。&/p&&p&我在公司的技术通道{![腾讯员工可以根据自己的特长和兴趣，选择走管理的发展通道，也可以选择技术、设计、产品、市场等专业发展通道。在不同的发展等级上，都设计有配套的能力要素。]}中会发现有这样一些开发者，他们做项目的驱动力是“技术”本身，而不是“商业”目标。比如说，他们针对微信平台做了一个活动推广页，使用了很多华丽的3D旋转和SVG动画。好的方面如下。&/p&&ul&&li&用的技术很新潮，满足了自己的炫技虚荣心。&/li&&li&朋友圈（其实都是前端同事）传播很广。&/li&&li&在高端机器和大屏幕机器上效果很好。&/li&&/ul&&p&坏的方面如下。&/p&&ul&&li&在低端机和慢速网络下效果不好。&/li&&li&沉浸在技术的实现中，而忽略用户体验。&/li&&li&打开页面就自动播放音乐，让用户感觉很突然。&/li&&/ul&&p&我老婆是一位财务人员，她每次看到朋友圈这种很炫酷但需要加载的页面就会马上关掉，有时候耐心等待打开之后也是眼花缭乱，不知所以。所以有时候我会思考，一个技术的圈子，在热烈讨论某个推广页又用了某某炫酷新技术的时候，有没有想到普通用户根本不买单呢？&/p&&p&再来说说一个好的案例。&/p&&p&我在面试求职者时遇到一个综合能力不错的候选人，他是一个全栈工程师。我问他，您现在掌握的技术比较多，那您未来的职业规划是怎样的？他说，他觉得用什么语言并不重要，但是最近一年开始把重心放在Android开发上，因为移动端App开发是现在的潮流，有很大的需求，在这里可以有所成就。但在未来，不排除改变方向去做别的事情的可能，到时候可能是iOS或者其他新的系统。基本上来说，自己掌握的知识体系是可以复用的，但也期待学习新的语言。&/p&&p&我喜欢他这样的态度，对未来有自己的方向，但也知道自己没法看得太清晰。对商业和市场有想法，而且自己也有足够的技术能力和自信向未来前进。相比而言，有些候选者的项目经验和学习技能很杂，东一锤子西一榔头，有些时候纯粹是为了折腾而折腾。&/p&&p&记住，当您只有一把锤子，您看什么都是钉子。而如果您痴迷于工具，反而看不到问题所在。因此，要先看看有哪些问题需要解决，然后再补充您的工具箱。永远从商业目标的角度来决定学习哪些东西，而不是纯粹为了锻炼技术能力而去学习。&/p&&img src=&/93e76fee5e4b2d07aab549f7644e4fbb_b.jpg& data-rawwidth=&700& data-rawheight=&469& class=&origin_image zh-lightbox-thumb& width=&700& data-original=&/93e76fee5e4b2d07aab549f7644e4fbb_r.jpg&&&br&全栈工程师希望丰富自己的工具箱，而不是用一把锤子处理所有工作。&br&关注用户体验&p&我的第二条建议是，从用户体验的角度考虑问题。&/p&&p&用户体验是用户使用产品时的心理、感受、印象、评价。生活中处处涉及用户的体验，闹钟、牙刷、马桶、书包、公交、红绿灯、手机、电脑、键盘、鼠标……每天，我们都在和产品打交道，每天都在使用和体验产品。&/p&每一个糟糕的体验背后都蕴含着商机&p&全栈工程师应该关注用户体验，并且掌握用户体验相关的知识。即使一个技术达人能够以一己之力搭建一个站点，但他如果不关注用户和客户的体验，那么他做的产品可能会很糟糕。这样的产品除了“能用”之外什么优点都没有。&/p&&p&所有优秀的工程师所做的一切都是在优化用户体验：优化性能的开发者是在积极地提升用户体验和交互；设计师有意用颜色、空间、大小和表单的排列方式让用户体验更顺畅好用；而内容运营者认为某些内容重要，某些内容不重要，也是在考虑如何提升用户的体验。&/p&&p&我在2010年加入腾讯的时候，公司只有一万多人。那时候，我需要办一些行政手续，需要公司开具薪酬证明，整个操作流程是这样的。&/p&&p&打开公司论坛，搜索“薪酬证明”，搜索到一篇文章，里面讲到找一位人力资源的员工来办理。&/p&&p&我打开RTX（腾讯内部使用的工作通讯软件，类似QQ），找到这位人力资源的员工，问他座位在哪里；跑到他座位上，此时已经有几个人在排队了，我排在后面；到我了，我告诉他我要办薪酬证明，并告诉他我的RTX ID；等待10分钟后，他打印出一张薪酬证明，签字盖章后给我。整个过程耗费了我一个小时的时间。&/p&&p&2015年，我要申请美国旅游签证，需要开具薪酬证明。我从平时的宣传渠道得知，现在人力资源的很多服务都可以在线上办理了，于是我尝试了一下，现在开薪酬证明的流程是这样的。&/p&&ul&&li&&p&关注“HR助手”的微信公共账号，它自动识别出我是腾讯员工，也得到了我的ID。&/p&&/li&&li&&p&选择“我要办证明”→“收入证明”，在证明用途一栏，选择“签证类”→“旅游签证”，并提交一些个人信息。&/p&&/li&&li&&p&输入我的办公座位号，提交给系统。&/p&&/li&&/ul&&p&第二天，一个漂亮的红色大信封放在我座位上。打开一看，里面包括中英文两份收入证明，还有我的旅游目的地以及时间，整个收入证明既漂亮又专业，是为签证量身打造。从提交系统到拿到最终的证明，我只花了几分钟，过程顺畅快速，体验非常好。&/p&&img src=&/7f6b8d3f999b6dbba5aab8_b.jpg& data-rawwidth=&356& data-rawheight=&488& class=&content_image& width=&356&&&img src=&/95e59bcd8e3cccf51112b63_b.jpg& data-rawwidth=&366& data-rawheight=&486& class=&content_image& width=&366&&&p&从2010年到2015年，经过这几年的发展，腾讯的员工规模已经达到了三万多人，翻了三倍。HR流程如果还以旧的方式运作，可能得加派好几倍的人手，浪费所有员工不知道多少时间。但是现在通过自动化的系统，用户满意度大大提高。一个内部员工使用的系统，尚且有如此的优化空间和投入力度，何况是对外直接出售服务的公司呢？&/p&&p&我这样被公司服务“惯坏”的人，往往对社会上其他服务更加挑剔。此外，在深圳这样一个服务业水平居全国前三的城市居住惯了，去其他城市也经常会有被“怠慢”的感觉。我想这就是所谓“由俭入奢易，由奢入俭难”。&/p&&p&所以，用户现在都被手机中那些提供优质体验的App“惯坏”了，想让他们再接受陈旧的设计和体验，就更加难上加难了。&/p&用户是谁&p&“站在用户的角度想问题”这样一句朴实的话，可以指导我们做很多事情，但是很多时候我们忽略了这一步。&/p&&p&就像“体验”泛指所有生活中所有的体验。这里的“用户”仍然是一个广义的定义：所有您为之服务的人。&/p&&p&比如做一次演讲或者汇报，第一件要紧的事不应该是做PPT，而应该是调查听众，站在听众的角度去思考：听众知道什么信息，听众想知道什么。如果给您的老板汇报，您不能期望他了解您所做项目的技术细节，而且他想知道的也不是技术细节，而是项目进度和风险。但是如果在一个技术论坛上分享，您就不能期望听众都知道您的项目背景和目标，需要花一点时间去介绍，听众也不想知道太多细节的东西，只需要介绍一些决策和架构的大方向。&/p&&p&写邮件的时候，收件人（还有可能这封邮件被转发之后的收件人）就是用户，那么写邮件的一些技巧就包括：尽量简短，不要给收件人太大压力；把结论放在邮件的开始，方便对方快速了解情况；如果需要老板拍板，给出选择题，而不是问答题。总而言之，以对方能理解、会关注的方式来表达自己做了什么。&/p&&p&作为前端工程师，上游的设计师、下游的后台工程师，都可以认为是前端团队的用户。如果细心观察，就可以发现这里面有一些痛点。因为领导没有自己敲代码，所以他可能不会发现这些痛点，也就不会安排您去做优化工作。所以这里需要您自己去观察和优化流程。&/p&&p&很多程序员的第一个想法是做工具，但是想想我刚才说的话，老板雇用您不是因为您能写代码（或者做工具），而是因为您能帮他赚钱。所以您要用一切办法，去优化流程解决痛点，做工具是一个可选的方法，但不应该是您的第一个想法，更不是唯一的办法。假使真的是做了一个工具，最终汇报邮件的时候，不要以“我做了一个工具……”开头，而应该以“我发现了一个问题……”开始。&/p&大巧若拙&p&老子（两个字都请以三声阅读）说，大巧若拙。&/p&&p&意思是，指真正聪明的人，不会显露自己，反面从表面看好像还很笨拙。用户体验不只是界面和交互这样可以直观感受的东西，还包括一些隐藏在用户界面背后的细节和规范。&/p&&p&就像冰山，露出水面的部分只占整个冰山的1/9，用户看到的只是显露出来的部分。背后的部分一般用户是看不到的：比如用户研究，用研团队会通过调查，输出一些用户画像，影响整个产品的功能方向、设计风格；还有设计规范，设计团队在设计产品的一开始制定了规范之后，新增加的功能和页面都必须遵循已有的设计规范，这样整个产品是统一的，能够给用户专业的感觉。&/p&&p&为什么现在很多商业公司花了大把的钱和精力开发出独立运行的App，体验却很糟糕，甚至很多用户反馈称App还不如微信公共号好用？&/p&&img src=&/790fd110a3a90d9054cf9e_b.jpg& data-rawwidth=&700& data-rawheight=&385& class=&origin_image zh-lightbox-thumb& width=&700& data-original=&/790fd110a3a90d9054cf9e_r.jpg&&&br&用户体验只是冰山上露出的一小部分。&br&&p&一个很大的原因就是公司不重视用户体验，觉得用户研究和交互这种东西，不用专业人员去做，让设计师搞定就好了；或者老板拍脑袋定方案，做出的东西花里胡哨、炫酷狂拽，但就是让用户摸不着头脑。相反，微信花了很大的精力去做深入的研究，最后设计出了一套看似简单，但是可用性非常好的框架。然后微信开放后台系统给第三方，第三方公共号可以定制的地方有限，只能把功能往里面套，不太容易出错，用户体验自然就上来了。&/p&&p&反观某些银行的App，几乎每个标签页的设计风格都不一样，而且喜欢自己设计键盘，每次在输入密码的时候都非常不方便，其实这是没有必要的。&/p&做自己会用的产品&p&创业公司做产品，CEO一定要是自己的目标用户。因为如果自己都不体验自己的产品，就很难发现用户在使用产品过程中遇到的糟糕体验。我们经常在网上看见网民抱怨办理公共事务时手续很麻烦，很多流程设置得让人抓狂。我想，这里面有一个很大的原因就是，设计公共事务流程的人，自己本身不是目标用户。&/p&&p&网上有个段子，说一般的产品经理没办法把自己代入成“小白”用户，做出的东西只有他自己会用；高级产品经理经过半小时的冥想可以进入小白状态；张小龙和马化腾这样的大师级产品经理需要两分钟；而乔布斯可以随时切换大师级产品经理和小白的状态。这就是为什么他会说“stay hungry, stay foolish”。&/p&&p&我如果开创一个公司需要招聘“全栈工程师”，我要求的三个能力就是一专多长、关注商业目标、关注用户体验。&/p&&p&有志往全栈工程师方向发展的学生，我推荐从入门简单的前端开发开始学，而且从拉勾网“2015互联网人才流动报告”来看，职位多、简历少排名第一的职位是前端开发。而且因为前端开发处于互联网开发的中间环节，可以从上下游入手，渐渐地接触Web开发的完整流程。第三个原因是，前端开发直接面对最终用户，也可以锻炼自己对用户体验的感觉。&/p&&p&当然，前端并不是唯一的选择，您也可以从其他职位开始，专注地学习这个职位需要的技术，到达一定的深度之后，扩展自己的知识面，往一专多长方向去发展。下一章专门介绍如何从学生转型为全栈工程师。&/p&&p&因为看到了这个问题，刚好作者余果的《全栈工程师的自我修养》又有讲到，就分享出来给大家&br&&/p&&img src=&/fdce3dea2ed9bcfa31f4cfa_b.jpg& data-rawwidth=&271& data-rawheight=&356& class=&content_image& width=&271&&
不管您是否承认，除去极少数天赋异禀、骨骼惊奇的天才程序员，我们大部分人都是普通人，都需要遵循“一万小时定律”，才能从平凡变成超凡。凡人要从一个小菜鸟成长为全栈工程师，只能从少到多、慢慢积累知识和经验。职业生涯的本质，就是在一个专业方向上积…
&p&从全栈工程师到全栈员工，软件吞噬世界的步伐又进了一步。以下是 Chris Messina的&a href=&///?target=https%3A///%40chrismessina/the-full-stack-employee-ed0db089f0a1& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&文章&i class=&icon-external&&&/i&&/a&&/p&&img src=&/cbf0dfed3d87bd686d564143_b.jpg& data-rawwidth=&800& data-rawheight=&753& class=&origin_image zh-lightbox-thumb& width=&800& data-original=&/cbf0dfed3d87bd686d564143_r.jpg&&&br&&p&在我离开 Google快两年之后，我开始意识到职业环境正在发生的变化。传统的管理纪律正在渐渐瓦解。要想在&a href=&///?target=http%3A///tag/%25e8%e5%259c%25ba& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&职场&i class=&icon-external&&&/i&&/a&上成功，需要的技能比以往更加多样而难以定义。如今，要想在职场上有所成就，你必须成为一个真正的博学者，成为一名全能全栈员工。&/p&&br&&p&&strong&什么是全栈员工（full-stack employee）？&/strong&&/p&&br&&p&就像“全栈工程师（full-stack engineer）”和“全栈创业（full-stack startup）”一样，全栈员工（full-stack employee）拥有超强的综合技能，有着无法估量的价值。他们可以在快速演进、变革的技术浪潮中如鱼得水。他们可以在事实稀缺、观点横飞的过剩信息中凭直觉做决定。全栈员工能够熟练运用设计语言，明白使用卡通字体无异于犯罪行为，轻车熟路地嘲弄Keynote、Sketch抑或是Skitch。他们清楚用户界面（UI）和用户体验（UX）的区别。&/p&&br&&p&他们可以和人讨论工程问题，能搞清楚算法、编程，也能理解前端的等级和后端的等级根本不是一回事。虽然他们可能并不亲自编程，但他们知道GitHub、StackOverflow都是做什么的。如果必要，他们会暴力破解一段“复制粘贴”的脚本，在CSV文件中进行基础分析。&/p&&br&&p&他们是最新锐的社交应用的用户，深谙自我推广 之道。他们既可以在听众面前循循善诱地耐心讲故事，也可以在看了3分钟kickstarter视频后就能指出：亮明要点的时间不能长于一段Instagram、Vine短视频。注意力就是这个时代的硬通货。&/p&&br&&p&全栈员工对新的想法、最棒的实现路径、提升生产力和与愉悦度的事情有着“贪得无厌”的胃口。他们对世界及其运转规则充满好奇心，想知道如何留下自己的印记。正是这一点使他们与过去时代的人们区分开来。开始一份工作时，全栈员工不会戴上“眼罩”埋头苦干，而是始终与行业的发展保持同步，因为他们清楚：变革往往出现在边缘地带，不能只盯着脚下的一亩三分地。&/p&&br&&p&&strong&一名全栈员工是什么样子的？&/strong&&/p&&br&&p&有了24小时在线的移动设备，工作和非工作之间的界限正在模糊，既然工作正在变得碎片化，全栈员工要清楚地意识到自己的生活方式也要随之变化，比如使用整体式单色衣柜、功能明确的厨具。&/p&&p&成为全栈员工意味着要在两极之间来回切换。他们既要适应单兵作战，自给自足（比如自己安排时间，使用自己的设备工作），也要能和团队高效协作。过去，在大型团队中，往往需要有一名 IT经理来决定使用何种技术。如今，随着人们越来越多地使用个人设备工作，员工需要自己来搞定跨设备、跨平台沟通等问题。就拿企业协作工具来说。Slack可以整合所有东西，而微软却只对自己平台上的工具开放特权。如果你不能接入其他人的 API，你已经落后于时代了。全栈员工也是如此——他们至少应该熟知所有最新的应用，这样才不会落伍出局。&/p&&br&&p&全栈员工必须要在自己的领域有深刻的洞见，同时也要机动地应对优先事项的转换，胜任不同的安排。组织的扁平化已经不是新现象，变革的动力可能来自顶层，也可能来自底层，有时候需要个体来决定事情的优先级。现场服务工程师（FSE，Field Service Engineer）应该遍布组织内部，却又不能分布的过于稀疏。即使不用监控每一位员工，他们也应该知道每一个人在做什么，保证他们在不熟悉的事情上不会手足无措。&/p&&br&&p&要成为一名全栈员工不是一件容易的事，回报却也很丰厚。首先，他们可以更自由地按照自己的方式、在自己喜欢的地方（Teleport等服务可以帮助他们找到价廉的工作地点）、喜欢的时间工作。他们可以使用最新的工具，自给自足，自我管理。由于他们的工作涉及多领域、多学科之间的协作，会带来更宽广的视野，更丰富多彩的经历。在组织内部，他们的影响力也会不断上升，对组织的成败也将担负起更大的责任，团队的成功与否更加休戚相关。&/p&&br&&p&&strong&这对雇主和管理者意味着什么？&/strong&&/p&&br&&p&对于企业和管理者来说，在人力市场上争夺全栈员工意味着很多准备工作。首先，你们做好准备来吸引、留住这些人才了吗？其次，你们团队的工作风格是否明确，你们对远程办公的支持如何？再次，你们允许的工作时间，支持员工自主安排工作计划吗？最后，你们会给他们留出健身、养生、陪伴家人的时间吗？&/p&&br&&p&Google虽然充分考虑到了员工的健康、精神需求，但反过来也要求员工高度负责。 Google的员工可以以任何方式在任何时间、任何地点工作，只要能最大程度发挥创造力。但它同时希望员工能够随时参加一场临时安排的快速议事会。你的团队准备好了吗？&/p&&br&&p&如果你还没有尝试过，不妨一试，来感受下”全栈员工“的工作环境是什么样子的。不同背景的人们在一个公共空间内彼此协作。他们一直在线，通过Slack等协作对话平台交流。大多数全员协作空间都是临时搭建，多种实体、虚拟的工具混合使用（白板、投影仪、会议室、视频会议设备等）。&/p&&p&对于职员和管理者来说，最需要培养的是”同理心“——员工和管理者都要对彼此有一种“同情的理解”，在彼此沟通、协作、要求时能够提出具体的需求。因为未来的工作需要高度的灵活性和自主性，但这并不意味着每个人给自己下达工作命令、工作指标。管理者的角色依然是必要的。&/p&&br&&p&&strong&未来的工作是什么样子的？&/strong&&/p&&br&&p&说未来的职场将由全栈员工引领，无疑有些夸张，但这是一个显而易见的趋势。毫无疑问，工作的定义正在发生变化，员工的最大价值是应对不确定性，能够从海量的信息中提炼出有效的战略、战术。&/p&&br&&p&而且，在工作机器人大规模“入侵”之前，我们只有10年的时间。他们正在取代体育新闻、驾驶、快递等重复性工作，人们要重新思考适合自己的角色。感知和综合的能力将是第一位的，而语言、辨析力和同感力在进行复杂、敏感的任务是都是必备技能。全栈员工将帮助我们向未来过渡，将成为新的混合经济中的关键角色。&/p&
从全栈工程师到全栈员工，软件吞噬世界的步伐又进了一步。以下是 Chris Messina的 在我离开 Google快两年之后，我开始意识到职业环境正在发生的变化。传统的管理纪律正在渐渐瓦解。要想在上成功，需要的技能比以往更加多样而难以定义。如今，要想在…
Full Stack Developer 在国内不被接受的一个主要原因是公司缺乏稳定的 T 线（技术职位晋升路线）。&br&&br&太多有才华的人写了几年代码最后都去做了管理。而今天的网络相关技术，聪明又能持续学习的人，在三年之内可以在一个领域做到很高的水准。&b&那么如果你做五年，十年甚至十五年呢？&/b&&br&我以为你成为 Full Stack Developer
是很自然的选择，而且可以跟随最顶尖的技术。这种人并不罕见，我认识的人中
&a data-hash=&a615a4c25bafeda56ca96f& href=&///people/a615a4c25bafeda56ca96f& class=&member_mention& data-editable=&true& data-title=&@徐 乐乐& data-tip=&p$b$a615a4c25bafeda56ca96f& data-hovercard=&p$b$a615a4c25bafeda56ca96f&&@徐 乐乐&/a& 就是个例子。&br&&br&相信 Full Stack Developer 的核心并非否定团队和协作，而是更多的体现在架构设计，快速原型和 TroubleShooting 方面。&br&&br&随着今天的分层越来越清晰，平台和语言越来越有特点，更加全面的技术人员可以根据不同的语言搭建整个架构。&br&数据一致性要求高？那么使用事务管理久经考验的 Spring？还要考虑 scale ？那么放在 Oracle 里面做还是放在 Application Server 的 Transaction 管理里面做？简单请求的高并发？那么 Node.js 也许不错。 Web App 快速原型，那么 Rails 也许不错。邮件模板和自动发送？ PHP 有现成的东西为什么不用？前端数据和交互复杂？ 为什么不试试 emberjs （ PS ：选前端框架对于架构人员来说简直像女人逛银座一样令人兴奋。甚至有人用几乎所有的框架写了同样的 Web App 来供他们试用： &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&TodoMVC&i class=&icon-external&&&/i&&/a&）？想绕过苹果的 App Store 的审查机制频繁发布？可以考虑在 iOS Apps 里面嵌入 HTML5 。&br&&br&Full Stack Developer 在快速原型上也很有优势，因为省去了大量的管理和沟通成本。而且，这并非就意味着一定在代码质量或者测试上有缩水。 &br&MVC 前后都可以用。一个写过 test_helper.rb 的人做前端，一定会搜索 javascript TTD 。同样，用过 javascipt lint 的人一定可以找到 stylecheck 。语言和平台会变化，聪明的方法和工具都是共通的。懂得基本的字体知识和排版审美难道和 CSS 不是天生一对？&br&&br&TroubleShooting 方面 Full Stack Developer 同样优势巨大。&br&服务器压力太大未必需要通过后端解决，优化个 SQL 写个 Hint 是选择，而拿一部分数据和运算到前端也许是更加合理和低成本的选择。一个系统运行多年，最后遗留的问题很可能需要对业务和技术都有深入理解的人才能解决。&br&&br&从以上内容可以看出， Full Stack Developer 并非杂而全 - Facebook 也不会雇庸手。他要求的是一种更加全面的深入。 一方面，他是技术人员不断学习的结果。另一方面，他也是对自己事业的一种责任：&br&&br&技术人员的价值不是指派做了一半的 issue 给队友，而是更快更好的&b&搞定事情&/b&。
Full Stack Developer 在国内不被接受的一个主要原因是公司缺乏稳定的 T 线（技术职位晋升路线）。 太多有才华的人写了几年代码最后都去做了管理。而今天的网络相关技术，聪明又能持续学习的人，在三年之内可以在一个领域做到很高的水准。那么如果你做五年…
工作的项目总会有诸多的限制，诸多的历史包袱，导致整个项目做完都有一堆糟点。&br&那么完全可以在平时做公司项目的时候，把脑袋里蹦出的这些想法记下来，在业余的时候，按照自己的想法做一遍。那么你就会发现，那些地方为什么当时的架构师要这么设计，那些你想的太简单了。&br&这样重复几次，一年下来5到6个项目，你完全可以突飞猛进了。&br&我现在工作的习惯:&br&项目的进度优先级最高，在任何设计，开发，测试的时候，有想法记录下来。&br&每个项目都建立两个笔记，坑点和待研究问题。&br&坑点记录的是项目中踩过的坑。待研究问题记录的是你项目开发中的想法，那些你没时间去验证的问题。&br&后续项目完工有时间，或者业余时间，把这两个笔记翻出来，完成这些内容。&br&再后续就是准对个别点深入研究，写一篇文章除了分享给大家。&br&&img src=&/v2-baff0cec542_b.png& data-rawwidth=&1080& data-rawheight=&12915& class=&origin_image zh-lightbox-thumb& width=&1080& data-original=&/v2-baff0cec542_r.png&&&br&&br&&img src=&/v2-007d1eccd414eecde9ec9_b.jpg& data-rawwidth=&1080& data-rawheight=&6903& class=&origin_image zh-lightbox-thumb& width=&1080& data-original=&/v2-007d1eccd414eecde9ec9_r.jpg&&&br&&br&&br&以上是我做了10年as400之后，在去年转行做了java之后开始实施的。
工作的项目总会有诸多的限制，诸多的历史包袱，导致整个项目做完都有一堆糟点。 那么完全可以在平时做公司项目的时候，把脑袋里蹦出的这些想法记下来，在业余的时候，按照自己的想法做一遍。那么你就会发现，那些地方为什么当时的架构师要这么设计，那些你…
已有帐号？
无法登录？
社交帐号登录
2895 人关注
262 条内容
12776 人关注
394 条内容
226 人关注
245 条内容
1657 人关注
583 条内容
10915 人关注
1356 条内容}