千万级PV网站架构技术方案_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
千万级PV网站架构技术方案
上传于||文档简介
&&千​万​级​P​V​网​站​架​构​技​术​方​案​和​集​锦
阅读已结束，如果下载本文需要使用2下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩17页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢真正牛逼的 Java 技术人员和一般的 Java 技术人员，有什么区别？
按投票排序
作为一个用Java写业务应用系统的程序员，前两天刚跟一个初学java的人聊过这个话题，总结一下搬过来。Android之类的没做过，不敢评论。掌握java库常用的类，如java.lang包下面的大部分类。以及行业内常见的类库的使用方法，SSH那一套，各种log工具包，apache commons，Guava等等具备快速掌握新的工具包的能力。例如同样有比较不错的编程经验，一个熟练使用SSH，另一个没有用过。那熟练使用SSH的人如果学习SpringMVC就会比另外一个人快得多。当用过的工具包越来越的时候，学习新工具的时间就会越来越短。这里面的差别主要在对编程思想、最佳实践这一类的东西的理解上。对不同的技术，尤其是新技术的特点有一定的敏感性，如log4j和logback放在眼前，应该能分辨出哪个更适合自己的项目。了解常用的包的实现思路。例如用Struts2开发一段时间的JavaWeb程序之后，头脑中就要形成“怎样实现Struts2“的大体思路，能想清楚大概要做几件事才算是开发出一个MVC框架。当然，距离具体实现出来还会有很大的差距，但这些差距应该体现在细节处理上，如对配置文件的解析。掌握设计模式、重构等基本与语言无关，但在Java世界中应用很广的编程思想。既然Java的比较广泛的用途是用来实现特定业务（我的工作范畴内，也许不具备普适性），那就导致了，同样一段业务逻辑可以用各种各样的代码逻辑实现，从而使大量的劣质程序也可以稳定支撑系统运行。很多Java程序员就毁在这日复一日的逻辑实现上了。从几千行的大流水代码到良好架构，这中间的差别要在日常工作中慢慢体会。掌握与人配合开发的能力。Java的一大优势就是可以支撑大量廉价程序员的协同开发，既然大部分人都是廉价的，那成果的核心价值就必然决定于处于关键点的一两个非廉价人员。如何能做这个非廉价人员，把各种廉价人员整合起来，隔离廉价人员写出的劣质程序的影响，这应该也是高级程序员的必备技能之一。===做Java程序员三年，基本上没受过正规流程的培训，总结出来的大多都是野路子，并且只适用于各种xx管理系统的开发。感觉这一类Java程序的特点就是，你也能写，大牛也能写，都能运行，谁都说不出好坏来，但是这段代码生存个三五个月之后，人家的东西就是好。上面写的都比较虚，当年在iteye上看到个狗血帖子，调侃着在每一条后面加了几句评论，贴过来，算是在体现具体代码级别的一点观点吧。无聊时候的灌水作品，语言比较混乱。粘过来排版就丢了，只能大概重排一下。粗体字是原文，其余的是我的评论校园级别的程序员的标志：代码中最多的是嵌套if(null == xxx)，还要告诉你，null必须写在前面，我靠。防止把==写成=，c语言时代常犯的错误。由于null不能做左值，在写=的时候出现编译错误。一般来讲，在java中，由于boolean和其他类型不会作隐式转换，因此这么写没有意义。写着写着突然想起来这么个代码：Boolean b =if(b=null){}顺利编译通过，也许把null写在==的左侧还是有意义的。后台满是system.out.println("--------程序应该会运行到此处的。。。userId:")。调试程序过程中，如果想在控制台中打印什么东西，最好用log工具，如已经在多少年前就俗到家了的log4j。好处是：打印日志的语句和控制是否打印日志、控制怎样打印日志的语句是解耦的，可以在程序中随便写打印log的语句，然后在正式上线后，通过某个选项，令其全部失效。当年流行的组合是log4j+apache commons logging，在程序中引用commons logging的api，build path中放一个log4j的jar包然后再写个log4j的配置文件并且初始化一下，实际生效的就是log4j了。这样做的好处是，想换日志实现类的时候，不用修改程序代码。今年的流行款是logback+slf4j，对应上面那两个东西。logback的实现据说效率高了多少倍，不过除了非常关键的模块外，这点开销基本可以忽略不计。html页面总是对不起一两个div的线，老用firefox去框框显示那个div。搞前端的都是神，我到现在也对不齐那堆div。另提一句，bootstrap是良心作，好人一生平安。IO异常处理那个就是叠罗汉啊。异常处理是个技术活，我当年的思路是，根本不知道有非受控异常这件事，出现受控异常未处理的编译错误时，点开eclipse的自动处理选项，然后按照心情选一个。一点经验：数据库异常、io异常就直接上抛，如果框架非得搞成checked的话（譬如ibatis2.x），发现了就给封一层RuntimeException，一直抛到顶层让这个事务挂了就好了。然后客户会明确的知道这个程序sb了，怒不可遏的给维护打电话，然后维护远程ssh，重启数据库了事。如果项目经理稍稍良心一点的话，针对这种错误可以做的包括：1、打异常log，2、给客户一个明确的提示“系统挂掉了，请联系系统维护人员电话是13xxxxxxxxx”而不是显示一堆异常堆栈然后再让客户翻电话本。想写段代码自动处理这些异常的想法不是不能实现，但对于业务定制类的系统来说，代价太大。nullpointerexception、各种illegelxxxexception，其它各种开发人员懒得去学的异常，这些基本上都是程序的bug，开发测试阶段出现了就调整，打各种补丁，直至所有的测试流程都走通。实际运行阶段再出的话，类比上一条。在业务基本走通，正常流程都没问题了，而项目组又恰好有足够的时间投入在异常架构上，可以做下面的事：分析业务，找出需要处理的业务异常，如根据身份证号查出了两个完全不同的人等，定义处理这些异常的逻辑，定义项目级别的异常基类api，之后就可以从底层一层层的加各种if判断，抛出异常，再向上找到该处理异常的地方，写catch代码。最重要的就是在抛异常的时候，把所有有意义的信息都记录下来，比如上面说的身份证号的异常，起码要记录身份证号是什么、找出的两个人的主键，另外还可以记录操作时间、操作人等信息。只要在异常抛出的时候做到这一点，随便你决定在哪一层catch，哪怕只做个log，都会让维护人员、后续开发人员感谢你的良心。一般级别的程序员标志：会struts+spring+hibernate|mybatis，面试神器。曾经的观点：怎样用这些东西：找个文档读一点，都能学会。为什么要用这些东西：体现真正水平的问题。现在的观点：怎样用这些东西：做到随便给给技术，读读文档就能用上的，都是水平已经不错了的人。为什么要用这些东西：网上答案一搜一大把，需要分辨是直接拿的结论，还是真被某些雷炸过然后很良心的告诉你，struts2真操蛋。struts1、2、spring mvc这一层，用的并不多。由于没做过什么访问量特别高的项目，因此对struts2的效率并没有太多吐槽。现在的选择标准：1、是否提供了足够的语法糖让一般水平的人也能够快速开发 2、是否没有提供不恰当的语法糖，从而大幅度的增加维护难度。annotation、零配置这些东西，个人觉得最好用于元属性设置，而不要用于流程控制。曾经有个同事发现前台传进来的参数莫名其妙的会丢一个，后来发现在引用的某个jar包中有一个annotation方式定义的filter。尽管实际上的问题是架构组没有写完善的文档，没有做培训，但是经过那件事之后我也同意，这种东西放在一个统一的配置文件里面看着会更清楚一点，控制粒度也更细一点。当年实训初学spring就觉得这东西很蛋疼，迄今为止一直没遇到复杂度高到有大批量属性需要注入的地方。aop的应用场景倒是遇到几个，不过出于对庞大的spring以及配置文件膨胀的恐惧，我宁愿改变整个的框架，定一个抽象层然后用各种各样的strategy模式。倒是觉得有完善annotation支持的轻量级aop应该是个不错的选择。hibernate用的也不多，我好像对主流的s2sh有本能的抗拒……一直对sql的结构化有深深的执着，因为你真的不想没事总给别人调那一堆动辄五六行变量名很奇怪大小写都有的sql语句。所以在看到hibernate做某些复杂查询必须用hql的时候就放弃了这门技术了，sql本身就不想看，再发现这sql实际上是在java里面用String拼起来的……ibatis/Mybatis一系用的比较多的原因是，职业生涯用到的首套一站式框架的作者就用的这玩意儿，属于马屁股性质的事情。这东西的好处就是把sql和java代码分离开了，程序看起来比较干净。但是让每个模块的程序员都去决定要写哪些sql，怎样写，同样是个很可怕的事情。所以当年我定义了一套针对每张表的标准sql列表，几项最基本的CRUD操作。select操作只支持id查询和各个属性的and相等查询。这个基本上已经可以满足80%的需求了，剩下20%，定好了配置文件分割策略后，找个sql好点的人慢慢写就是了。另外，这东西的一大槽点是只支持假分页，我们的处理方式一般是忽悠客户买个内存大点的机器就得了，不具备这种忽悠机制的同行们请慎重选择，ibatis想解决这个问题需要hack jar包，mybatis也需要自己写个插件支持，大概有个半天到一天的工作量。再后来觉得配置文件有些繁琐，所以又在apache commons dbutils基础上封装了一套，不用写配置文件，定义好列名和属性名的映射关系后，自动生成CRUD操作并作db访问操作。在封装复杂的select操作时发现了nutz这个东西，觉得思路基本一致，就懒得再继续写了。nutz提供的dao工具实现了用比较结构化的方法拼sql语句，试了试，用着还不错。事务管理机制据说有槽点，没细看。决定我没有实际使用的槽点：1、不支持手动配置db和java的名称映射，而我给项目组定的映射规则又比较奇葩，给每个属性都写个annotation有点蛋疼。2、貌似是用反射方式直接读写java属性，而不是用java bean规范的get、set方法，而我的很多工具类都是做的虚拟属性，只有两个无比复杂的get/set方法，没有实际的属性。当发现annotation只能加在字段上时，欲哭无泪只好放弃了。现在项目中用着的还是mybatis，用官方提供的mybatis generator生成配置文件，单表操作支持得很完善，多表操作自己写sql解决。能分清楚group和having的区别。关于db另一个要说的问题：复杂的东西尽量别放sql里面。orm层提供基本操作就够了，剩下的逻辑交给java层表达。做好封装，实在有效率问题，再专门进行优化。好吧，我承认我不知道这哥俩到底有什么区别。数据库里的字段必须只能2个长度，不能32个长度，性能问题。表名要以T开头，蛋快碎了。长度问题没看懂要说什么。前两天遇到一个问题，在oracle中如果用char类型的，而实际内容又不正好等于char长度的时候，select出来的数据是带空格的……各种trim都感觉不太好使之后，果断varchar2了。反正这点效率差异，早就被各种奇葩的业务逻辑给抵消了，还是那句话，有问题的时候再优化。表名问题，我觉得加前缀还是为了跟视图进行区分。当表只有几张时，什么区分也不用做，当表有一百七十张时，什么区分都不管用。所以，战略上看需求决定就行了……一点经验：通通加T跟没加是一个效果。现在项目中的做法：数据库中大部分的表都是对应了一个业务实体，这些类直接写名字就行，在这些表上建的视图统一加一个V_前缀，也就能起到区分效果了。一般来讲，一百七十张表中至少有一百五十五张以上都是这种表。其他的表，则大多对应了某些特殊场景或算法，实际开发中一般由专门的核心人员负责，可以按照权限控制、事务控制等实际用途，加个什么前缀，谁负责哪个模块就关注哪个前缀就好了。会用jquery.ajax获取数据，不知道ajax的同步锁。我也不知道。对于一切锁，我的意见都是，上个最大粒度的，保证数据一致性。出现的所有问题具体分析，逐个减小锁的粒度。一会显示的表格有数据，一会又没数据啊，太生气了。遇到此类抱怨时：1、告诉他，工业界没有玄幻故事，2、再提同样的问题的话，辞了他。让这种人觉得自己还有混在程序员界的错觉是对他的不负责。详细记录当时的运行环境，一般都会找到原因的。骚年级别的程序员标志：懂div的float，clear的含义。1、上一套bootstrap，解决80%的问题。2、剩下20%的问题，找个跟你关系不错的前端，没事多请人家吃吃饭，然后就解决了。数据库超过n记录表横向纵向分表。问题在于，n等于几。高估n无所谓，反正要出现的问题肯定会出现。低估n的话，造成的进度损失会让你有自杀的冲动，造成的数据损失会让项目经理有杀了你的冲动。知道oracle的用with，这个sql写起来看起就舒服了。这个也不会，粗略google了一下，确实有点用途。看到aop能说一大堆废话，又是代理又是反射，就是没写过。你的错误在于，不知道用途就研究实现原理。DateUtil一定写过好多次，简直太复杂了，非常多的格式定义，那个static格式变量，必须要深刻理解才能知道。1、有句评价说的好：把一个工具包的几乎所有方法都写到标记过时，这是得有多仇视这个社会。2、自从有了JodaDate，妈妈再也不担心我的日期处理了。当一个同事又一次熬通宵写出一个DateUtil然后我拿出了JodaDate之后……砥柱级别的程序员标志：会架构程序，能用extjs或者easyui写个框架frame，还能写个递归menu。所有的知识点都很基础，但是能把这一切都完整写出来，完成debug之后让项目组用上，一段时间之后还能维护或者添加点新功能的，都是中流砥柱。说白了，这是个情商要求大于智商要求的活。业务系统定制开发，实际上都是这种类型的活。你并不需要有特别高深的技术，也不会突然面对多么巨大的困难，只会在一个个看似不起眼的bug中，把所有激情都消磨殆尽。会用ps处理图片，还能写上几个字，XXXX系统beta版本。会ps的都是神，不解释。基本上util包的作者，用log或者拦截器记录日志。并且，愿意跟一切动过你util包的人玩命。能用fiter或者Interceptor处理权限，但是搞不懂如何处理button的权限。在业务级别去掉button权限的需求就好了。真正的解决方案没有实际执行过，只是一个想法：系统建模的时候，权限模型直接建到操作级，比方说每个Action处理函数对应一个操作，针对这个操作定义每个角色的权限。button在概念上同样映射到权限就可以了。至于怎么针对函数做权限控制，随便你用xml或者annotation定义一下就行。明白了异常处理转换成RuntimeExcetion太好了，不会丢失而且好处理。异常处理真是个技术活。当我说，我也不知道我的方案好在哪，只是觉得你们的方式不优雅时，我清楚的听到了对方心里的嗤笑声。往往我的结论都会在大概三个模块开发周期之内被确认。page分页里代码和css样式和类class都在jsptag里，认为没法分啊，这个是典型。前端用于提交参数，目测所说的代码是计算page、rowperpage这些属性的。随便找套js grid控件，看看他们的参数提交方式，前端不依赖任何jsp，分到那个份上我觉得就足够了。小牛级别的程序员：知道url资源树和menu的区别。不明觉厉。这种概念性的东西其实挺多人都挺不重视的，曾经很反对这种不重视，但是重视了很多年还真没重视到什么收获。现在的观点就是，用到了再说。能手写css，懂important能拿来做啥，这个好玩得很。又是前端，上bootstrap吧能够理解数据库必须用主外键，否则那帮家伙一定会乱写程序。只要是实体类，必须有主键，并且一定要有物理主键，不能只依赖于逻辑主键。id这东西，找不到其他用途的话就简单的当个快速查询定位的工具就行。随着业务复杂度的增加，你会发现它的表现力越来越强。在大部分依赖于持久化的业务类系统中，可以简单的定义，有id就代表这东西存在，没id就代表不存在，顺着这条思路往下想，很多业务都会简化。只用id做外键，不要用神马身份证号、订单编号之类的东西。然后你的程序随便怎么写都能写得下去。会设计数据库模型，几百张表的小意思。针对真实世界，只作抽象，不作修改，保持整个系统概念上的一致性。然后你会发现，设计的模型会恰好符合数据库设计的各种准则。这时候这个数据库结构就能用了。如果你设计出一张自认为很有用的关系表，却起不出合适的名字来；或者数据库中有一个不是纯粹为了效率问题而设置的冗余字段，相信我，你终将遇到一个你的模型无法表现的业务需求。注释用//只有一行，不用/**多行,因为程序即注释。jdk标准注释都不用，那javadoc咋办？好吧，程序即注释这东西，几个水平相当、思路相近的人，通过不定期的结对编程、互相重构代码，还是可以做到的。如果是大规模的开发，还是建议通过架构层面合理的分层解决。知道struts模型驱动代替属性注入，方便太多事了。又一个语法糖。有了实际需求再用，到底用不用不要争论起来没完，遵循这两点就行了。这个真心不是核心问题。用过this做参数传递，哈好多人都没用见过。哈真神奇！这话真有人对我说过。技术上this就是个指向自身的引用。某些具体的场景确实用起来很有意思，高层面的意义还没太想清楚，只有一个模模糊糊的印象，大概就是做了一件把自身委托给其他对象的事，封装了某个参数传递的过程，也就是封装了自身和被委托类的关系。SE级别的程序员：研究过struts，hibernate的源代码，ui里有颜色互补概念，看起来是要舒服点啊。学源代码要跟写代码结合起来执行，学到了新的模式之后，多想想有什么应用场景，但是真的实际使用要慎重。譬如说看到struts2的层层wrapper模式后就用了一次，被喷了好长时间觉得struts，hibernate，spring，要扔掉一个框架，一定是spring，这个废啊。让我选的话，我扔hibernate。写过mvc，知道前端拦截器，中心分发器，后置处理，bean映射。要知道就算没有这些概念，代码层面也一定会实现mvc的全部功能。然后找到没有这些概念的代价，哪些东西就耦合了，哪些变更就应对不了了等等。最后你的水平就提高了。会用模型驱动user.save()，代替dao。少传一个参数，概念上优雅了一些。模型驱动太考验建模能力，一定要在一个范围内把所有问题想清楚再使用。建议把DDD那本书看个两三遍再说。不过这东西看上去真的很吸引人。能用metadata生成一堆乱七八杂的代码，这下爽多了。metadata的解释是“描述数据的数据”，比方说数据库的表结构定义可能就算是一种metadata。在写代码过程中能正确的抽象出元数据之后，眼光会提高一个层次，至于是不是要搞生成代码的工具，因项目而异。曾经用过一段时间的freemarker，写一些轻量级的代码生成工具还是挺好用的。研究过Annotation，用Annotation写过注解，知道Annotation如何继承，太复杂搞不懂。拿Annotation实现过一套Model工具，没有深入了解过ejb，可能有点entity bean的思路在里面把。前面说过一部分annotation了。这东西的好处就是把元数据跟java代码放到一起了，于是好找也好改了，坏处也是放在一起所以耦合了。如果代码量大到一定程度之后，最好把所有主力都集合到一块儿商量一下，到底是xml好还是annotation好。在代码量没大到一定程度，或者annotation配置的数据仅仅是annotation所在的类自己用的话，可以在开发效率上考虑一下这个问题。jdk提供了语言层面的annotation操作工具，使用简单，有一部分的编译期检查，写起来比xml要舒服。另外，个人认为annotation的语法不太适合定义层次太深的结构，在类前面写上四层annotation再用ide做个formatter，说实话挺愁人的。BOSS级别的程序员：仰慕一下。。。。以上经验建立在如下基础上：我做的项目是大部分是技术要求特别简单，业务要求中等复杂，需求变更特别频繁，开发人员平均素质不足，工期不是很紧的类型，所以关注点集中在如何通过分层隔离业务复杂度，以及如何通过语法糖来降低开发复杂度。bug方面，比较关注的是影响数据一致性的bug，只要不影响数据一致性，哪怕系统直接挂了，都不是影响项目的生死因素。在做技术方案的时候，比较倾向于：1、通过各种设计模式封装复杂度，提供尽量简单，甚至无脑开发的接口2、忽略一切效率问题，在业务打通之后再想优化的事3、能在编译器做的事就不往运行期放，哪怕会影响开发的灵活性
1.基础扎实，相对而言，某些语言的掌握可能并不深2.经验丰富（和年龄无关）3.动手能力强。打个比方，一人学习/使用java 2年，NB的人可能从没学过JAVA。但是遇到难题，他却能先解决掉。4.对计算机的热爱。非工作时观察下他们在看什么样网站，就能初步的判断出来。
记得很久很久以前我就被邀请过一次，因为看到已经有很好的答案了，就点了下赞同，没有回答。不想过了这么久，又被邀请了……为了防止以后还被莫名其妙地邀请，我就写两句吧。首先，我要声明，我不喜欢牛逼这个词。原因有二：词汇中有错别字，正确的写法应该是牛屄。不喜欢用家畜的生殖器描述我尊敬的人。所以，请允许我在后面的叙述中，使用”有能力“一词代替。或许表现力不如原词突出，权当我对此类人表达的一种尊重吧。那么，真正有能力的技术人员和普通技术人员有什么区别呢？刚才也说过了，现有答案很多都很好，我也赞同了其中一些。我再多说就是重复、抄袭、赘述，没有任何意义。我谨在这里将我认为最核心的内容总结两句：真正有能力的技术人员是服务于非技术内容的。普通的技术人员是服务于技术内容的。咦？我是不是漏掉了什么？哦，对了，JAVA这个词。我不是漏掉了，我是故意隐去了。因为如果还拘泥于某个语言层面，恐怕难以冠以真正有能力这一称号。
没有本质的差别。楼主问这个问题，是想知道什么呢？是想知道自己如何努力成为NB的程序员？还是自己是老板，想知道如何评估一个程序员是否NB? 还是只是增加一些茶余饭后的话题？NB的程序员都是从普通的程序员努力而来，只不过由于某种原因，他能坚持学习下来，并没有在NB之前就止步。原因有很多种，有的人是认准一条路就坚持下来，有的人是莫名其妙的自信认定自己不平凡天生就是做程序员的料，有的人是被逼得走投无路只好埋头学习；但是很多人却是有一种共同的原因：环境，不是他自己很强，而是周围的人太弱了，所以周围的人会夸奖他；这时候他就很有信心，很自然的认定自己是一个天生的NB程序员(周围的人也都这么认为)，从此就加倍努力。等到有一天发现自己其实并不是那么天生NB的时候，自己通过长期的努力已经让自己成为了一个有点NB的程序员了，这时候并不会觉得失望，反而就有更充足的信心继续努力下去。-------------------到了什么程度才算NB?---------------------------这个其实是问的别人的评价。想想你自己，什么时候觉得一个程序员很NB?不修边幅；沉默寡言；每天工作到深夜甚至凌晨；中午才来上班；藐视一切规则；经理都怕他，连老板都不敢惹他；你心中有一个这样的NB程序员，有木有？！其实这并不是NB的程序员，只是代表了内心深处叛逆的想法----想藐视规则，想跟老板吵架，想让别人不敢正视......其实这个问题应该是:-------------------往什么方向努力?-------------------------------这也是大多数同学所回答的问题。我补充一些和大家不同的东西。1.不要过于沉迷技术，要多考虑需要解决的问题，然后采用尽可能简单的技术去解决。高技术难道是你自己研究出来的，多半也只是抄来而已；能降低技术含量才是真本事。低技术含量，意味着低成本，高可靠性，别人容易看懂，容易维护2.注重沟通，多问问别人，至少得搞清楚真正的需求是什么3.不要宅在家里4.把握好自己的生活节奏，尽可能遵守常规的作息时间。年轻时候可能不觉得怎么样，其实熬夜很伤身体5.不要努力营造出别人心目中的神秘形象，那样不利于沟通
NB的程序员比较沉默小程序员爱叫唤：这个JVM太坑爹了，开源害死人了，Spring是不是有BUG啊，如此等等
你觉得你牛逼，你代码写的光辉灿烂，我就会去接手你的代码吗？不会的，除了我自己的代码，任何人的代码都是一坨翔，要不是为了工资，老子不愿意多看一眼。所以我反感别人提什么一般程序员，牛逼程序员。老子只看文档，看需求规格书，看概设详设，看个别核心的交互图和流程图。作为一个程序员，不应该忘本逐末去追求代码的华丽和规整，那东西有个屁用。如果你业务切割细腻，流程清晰，用一些设计工具生成的代码都比你的要华丽规整。还有就是设计模式，我觉得学是肯定要学的，但是学完就该把它忘了，千万别拿拿东西显摆再者java这方面，做web的比较多吧，把http研究清楚，学完这个，同行内就没人敢藐视你了再者学概念，而不要停留在语言上，network
filesystem
memory等等
学会用这个去概况你的知识
普通程序员在前面写代码，埋地雷。高手善后，排雷。
这个问题还邀请我这样的苦逼入门小学生...真是受宠若惊啊...我接触过的人都没多少，Java大牛就认识一个还没啥技术上的沟通...这问题我实在是说不上话啊....我的个人理解：能答出这个问题的都是牛B的Java程序员答不出来的是普通Java程序员我这样说了半天都是废话的是二逼程序员....
真正牛逼的人，干什么都是牛逼的。所以牛逼的Java程序员和一般的Java程序员的区别仅仅是那些人本身比较牛逼而已
四个级别1. 知其然2. 知其所以然3. 知其为何所以然4. 创造其为之所以然
已有帐号？
无法登录？
社交帐号登录真正牛逼的 Java 技术人员和一般的 Java 技术人员，有什么区别？
按时间排序
一般的就是是开发了个java web就满以为很厉害，不一般的就是哪里出了问题，去看看spring源码就解决了。
最牛的程序员, 当然是最普通的程序员.有良好的可替代性,就可以了.最研究或者比拼,当然是越牛越好.但是核心程序员要的就是普通.如果写的代码好,但是离了你无人能维护.生个疾病进度就受影响,那么还是开了这个人吧.鹤立鸡群的程序员绝对不是好程序员.
牛与不牛要说什么领域。单就某一语言来说，肯定是开发语言本身的是大牛。所以个人认为1，语言开发者2,编译器jvm等3应用平台开发/框架4应用程序开发者web,app5爱好者，初学我想提出这个问题的人就是要找个人崇拜一下，进入以上任意一个层级都有对象让你崇拜，自然不用问。估计你只能是5.那你就崇拜一下身边的先行者吧。且行且珍惜吧。共勉！
你觉得你牛逼，你代码写的光辉灿烂，我就会去接手你的代码吗？不会的，除了我自己的代码，任何人的代码都是一坨翔，要不是为了工资，老子不愿意多看一眼。所以我反感别人提什么一般程序员，牛逼程序员。老子只看文档，看需求规格书，看概设详设，看个别核心的交互图和流程图。作为一个程序员，不应该忘本逐末去追求代码的华丽和规整，那东西有个屁用。如果你业务切割细腻，流程清晰，用一些设计工具生成的代码都比你的要华丽规整。还有就是设计模式，我觉得学是肯定要学的，但是学完就该把它忘了，千万别拿拿东西显摆再者java这方面，做web的比较多吧，把http研究清楚，学完这个，同行内就没人敢藐视你了再者学概念，而不要停留在语言上，network
filesystem
memory等等
学会用这个去概况你的知识
记性好，打字速度快。
所处的环境不同
一直说自己一般的 Java 技术人员，才是真正牛逼的 Java 技术人员，他们执着，他们谦虚，他们对技术充满渴望。
牛逼的Java程序员用的是JDK1.6甚至1.7，一般的Java程序员都停留在JDK1.4。
第一层次:主要以实现功能为目的,这个层次可以细分为2类，第一，简单的实现功能，就是不考虑任何性能和可读性的。 第二，不仅能实现功能，而且可以实现很好的实现功能，比如可读性，性能等考虑. 第二层次:主要从架构的角度编写代码,也有两个层次，第一，为了实现架构而架构的程序员，比如把架构特意搞得很复杂，不复杂就没有技术含量，第二，为了产品而做架构的人，把问题复杂问题简单话，再把简单问题延伸话，这样的架构师是优秀的架构师.第三层次:站在市场的角度思考，设计产品的程序员，但是有一个前提，技术非常的牛逼。已经可以做到心中无产品甚是产品的感觉。并且很有想法和执行力，目前这样的极少。总之，现在不是分语言方向的时候，我觉得已经过时，现在考虑的是产品线的问题。做java的，如果产品需要为什么不可以搞搞linux
c。至少可以帮助你研究openjdk，不是到jni就扛不住的。同样学习c的一样为什么不可以学习java的一些开源思想？如果产品需要，那么牛人就是为实现企业利润而设计合理的架构，并不断的丰富和扩展。
一般程序员：知其然，NB程序员：知其所以然
真正牛逼的人，干什么都是牛逼的。所以牛逼的Java程序员和一般的Java程序员的区别仅仅是那些人本身比较牛逼而已
普通程序员在前面写代码，埋地雷。高手善后，排雷。
NB的程序员比较沉默小程序员爱叫唤：这个JVM太坑爹了，开源害死人了，Spring是不是有BUG啊，如此等等
我觉得一个会写用JUnit或者TestNG写单元测试的可以称之为入门的Java工程师。如果能做到下面这些算是合格的工程师知道如何使用Mockito,EasyMock,JMock中的一种写单元测试的时候会针对不同的测试场景单独写测试方法写单元测试的时候其测试方法的名称能反映测试场景写单元测试的时候遵循given-when-then的结构自觉的使用单元测试覆盖逻辑代码不过能达到合格水平同时能用英语沟通的很少很少，我在深圳招聘了1年也才碰到一个合格的。至于不写单元测试的技术人员我倒是碰到很多。
面对的问题复杂度越高区分度越大。搞个HelloWorld人人都会写，但碰到一个实际项目中的棘手问题比如服务器抛出个诡异的异常导致频繁GC以致宕机时，怎么快速定位问题、解决问题，以及从项目或框架层面一劳永逸的解决类似问题，这就是水平了。
其他标准不清楚，但我确定一点，一个真正NB的Java程序员：应该知道Java的缺陷；知道在适当的时候用适当的方法绕过这些缺陷；能接受其他人对这些缺陷的吐槽而不会暴跳如雷或急着为Java洗地。以上标准也适用于其它编程语言。
真正的大牛都是问题方案的提供者么？
作为一个用Java写业务应用系统的程序员，前两天刚跟一个初学java的人聊过这个话题，总结一下搬过来。Android之类的没做过，不敢评论。掌握java库常用的类，如java.lang包下面的大部分类。以及行业内常见的类库的使用方法，SSH那一套，各种log工具包，apache commons，Guava等等具备快速掌握新的工具包的能力。例如同样有比较不错的编程经验，一个熟练使用SSH，另一个没有用过。那熟练使用SSH的人如果学习SpringMVC就会比另外一个人快得多。当用过的工具包越来越的时候，学习新工具的时间就会越来越短。这里面的差别主要在对编程思想、最佳实践这一类的东西的理解上。对不同的技术，尤其是新技术的特点有一定的敏感性，如log4j和logback放在眼前，应该能分辨出哪个更适合自己的项目。了解常用的包的实现思路。例如用Struts2开发一段时间的JavaWeb程序之后，头脑中就要形成“怎样实现Struts2“的大体思路，能想清楚大概要做几件事才算是开发出一个MVC框架。当然，距离具体实现出来还会有很大的差距，但这些差距应该体现在细节处理上，如对配置文件的解析。掌握设计模式、重构等基本与语言无关，但在Java世界中应用很广的编程思想。既然Java的比较广泛的用途是用来实现特定业务（我的工作范畴内，也许不具备普适性），那就导致了，同样一段业务逻辑可以用各种各样的代码逻辑实现，从而使大量的劣质程序也可以稳定支撑系统运行。很多Java程序员就毁在这日复一日的逻辑实现上了。从几千行的大流水代码到良好架构，这中间的差别要在日常工作中慢慢体会。掌握与人配合开发的能力。Java的一大优势就是可以支撑大量廉价程序员的协同开发，既然大部分人都是廉价的，那成果的核心价值就必然决定于处于关键点的一两个非廉价人员。如何能做这个非廉价人员，把各种廉价人员整合起来，隔离廉价人员写出的劣质程序的影响，这应该也是高级程序员的必备技能之一。===做Java程序员三年，基本上没受过正规流程的培训，总结出来的大多都是野路子，并且只适用于各种xx管理系统的开发。感觉这一类Java程序的特点就是，你也能写，大牛也能写，都能运行，谁都说不出好坏来，但是这段代码生存个三五个月之后，人家的东西就是好。上面写的都比较虚，当年在iteye上看到个狗血帖子，调侃着在每一条后面加了几句评论，贴过来，算是在体现具体代码级别的一点观点吧。无聊时候的灌水作品，语言比较混乱。粘过来排版就丢了，只能大概重排一下。粗体字是原文，其余的是我的评论校园级别的程序员的标志：代码中最多的是嵌套if(null == xxx)，还要告诉你，null必须写在前面，我靠。防止把==写成=，c语言时代常犯的错误。由于null不能做左值，在写=的时候出现编译错误。一般来讲，在java中，由于boolean和其他类型不会作隐式转换，因此这么写没有意义。写着写着突然想起来这么个代码：Boolean b =if(b=null){}顺利编译通过，也许把null写在==的左侧还是有意义的。后台满是system.out.println("--------程序应该会运行到此处的。。。userId:")。调试程序过程中，如果想在控制台中打印什么东西，最好用log工具，如已经在多少年前就俗到家了的log4j。好处是：打印日志的语句和控制是否打印日志、控制怎样打印日志的语句是解耦的，可以在程序中随便写打印log的语句，然后在正式上线后，通过某个选项，令其全部失效。当年流行的组合是log4j+apache commons logging，在程序中引用commons logging的api，build path中放一个log4j的jar包然后再写个log4j的配置文件并且初始化一下，实际生效的就是log4j了。这样做的好处是，想换日志实现类的时候，不用修改程序代码。今年的流行款是logback+slf4j，对应上面那两个东西。logback的实现据说效率高了多少倍，不过除了非常关键的模块外，这点开销基本可以忽略不计。html页面总是对不起一两个div的线，老用firefox去框框显示那个div。搞前端的都是神，我到现在也对不齐那堆div。另提一句，bootstrap是良心作，好人一生平安。IO异常处理那个就是叠罗汉啊。异常处理是个技术活，我当年的思路是，根本不知道有非受控异常这件事，出现受控异常未处理的编译错误时，点开eclipse的自动处理选项，然后按照心情选一个。一点经验：数据库异常、io异常就直接上抛，如果框架非得搞成checked的话（譬如ibatis2.x），发现了就给封一层RuntimeException，一直抛到顶层让这个事务挂了就好了。然后客户会明确的知道这个程序sb了，怒不可遏的给维护打电话，然后维护远程ssh，重启数据库了事。如果项目经理稍稍良心一点的话，针对这种错误可以做的包括：1、打异常log，2、给客户一个明确的提示“系统挂掉了，请联系系统维护人员电话是13xxxxxxxxx”而不是显示一堆异常堆栈然后再让客户翻电话本。想写段代码自动处理这些异常的想法不是不能实现，但对于业务定制类的系统来说，代价太大。nullpointerexception、各种illegelxxxexception，其它各种开发人员懒得去学的异常，这些基本上都是程序的bug，开发测试阶段出现了就调整，打各种补丁，直至所有的测试流程都走通。实际运行阶段再出的话，类比上一条。在业务基本走通，正常流程都没问题了，而项目组又恰好有足够的时间投入在异常架构上，可以做下面的事：分析业务，找出需要处理的业务异常，如根据身份证号查出了两个完全不同的人等，定义处理这些异常的逻辑，定义项目级别的异常基类api，之后就可以从底层一层层的加各种if判断，抛出异常，再向上找到该处理异常的地方，写catch代码。最重要的就是在抛异常的时候，把所有有意义的信息都记录下来，比如上面说的身份证号的异常，起码要记录身份证号是什么、找出的两个人的主键，另外还可以记录操作时间、操作人等信息。只要在异常抛出的时候做到这一点，随便你决定在哪一层catch，哪怕只做个log，都会让维护人员、后续开发人员感谢你的良心。一般级别的程序员标志：会struts+spring+hibernate|mybatis，面试神器。曾经的观点：怎样用这些东西：找个文档读一点，都能学会。为什么要用这些东西：体现真正水平的问题。现在的观点：怎样用这些东西：做到随便给给技术，读读文档就能用上的，都是水平已经不错了的人。为什么要用这些东西：网上答案一搜一大把，需要分辨是直接拿的结论，还是真被某些雷炸过然后很良心的告诉你，struts2真操蛋。struts1、2、spring mvc这一层，用的并不多。由于没做过什么访问量特别高的项目，因此对struts2的效率并没有太多吐槽。现在的选择标准：1、是否提供了足够的语法糖让一般水平的人也能够快速开发 2、是否没有提供不恰当的语法糖，从而大幅度的增加维护难度。annotation、零配置这些东西，个人觉得最好用于元属性设置，而不要用于流程控制。曾经有个同事发现前台传进来的参数莫名其妙的会丢一个，后来发现在引用的某个jar包中有一个annotation方式定义的filter。尽管实际上的问题是架构组没有写完善的文档，没有做培训，但是经过那件事之后我也同意，这种东西放在一个统一的配置文件里面看着会更清楚一点，控制粒度也更细一点。当年实训初学spring就觉得这东西很蛋疼，迄今为止一直没遇到复杂度高到有大批量属性需要注入的地方。aop的应用场景倒是遇到几个，不过出于对庞大的spring以及配置文件膨胀的恐惧，我宁愿改变整个的框架，定一个抽象层然后用各种各样的strategy模式。倒是觉得有完善annotation支持的轻量级aop应该是个不错的选择。hibernate用的也不多，我好像对主流的s2sh有本能的抗拒……一直对sql的结构化有深深的执着，因为你真的不想没事总给别人调那一堆动辄五六行变量名很奇怪大小写都有的sql语句。所以在看到hibernate做某些复杂查询必须用hql的时候就放弃了这门技术了，sql本身就不想看，再发现这sql实际上是在java里面用String拼起来的……ibatis/Mybatis一系用的比较多的原因是，职业生涯用到的首套一站式框架的作者就用的这玩意儿，属于马屁股性质的事情。这东西的好处就是把sql和java代码分离开了，程序看起来比较干净。但是让每个模块的程序员都去决定要写哪些sql，怎样写，同样是个很可怕的事情。所以当年我定义了一套针对每张表的标准sql列表，几项最基本的CRUD操作。select操作只支持id查询和各个属性的and相等查询。这个基本上已经可以满足80%的需求了，剩下20%，定好了配置文件分割策略后，找个sql好点的人慢慢写就是了。另外，这东西的一大槽点是只支持假分页，我们的处理方式一般是忽悠客户买个内存大点的机器就得了，不具备这种忽悠机制的同行们请慎重选择，ibatis想解决这个问题需要hack jar包，mybatis也需要自己写个插件支持，大概有个半天到一天的工作量。再后来觉得配置文件有些繁琐，所以又在apache commons dbutils基础上封装了一套，不用写配置文件，定义好列名和属性名的映射关系后，自动生成CRUD操作并作db访问操作。在封装复杂的select操作时发现了nutz这个东西，觉得思路基本一致，就懒得再继续写了。nutz提供的dao工具实现了用比较结构化的方法拼sql语句，试了试，用着还不错。事务管理机制据说有槽点，没细看。决定我没有实际使用的槽点：1、不支持手动配置db和java的名称映射，而我给项目组定的映射规则又比较奇葩，给每个属性都写个annotation有点蛋疼。2、貌似是用反射方式直接读写java属性，而不是用java bean规范的get、set方法，而我的很多工具类都是做的虚拟属性，只有两个无比复杂的get/set方法，没有实际的属性。当发现annotation只能加在字段上时，欲哭无泪只好放弃了。现在项目中用着的还是mybatis，用官方提供的mybatis generator生成配置文件，单表操作支持得很完善，多表操作自己写sql解决。能分清楚group和having的区别。关于db另一个要说的问题：复杂的东西尽量别放sql里面。orm层提供基本操作就够了，剩下的逻辑交给java层表达。做好封装，实在有效率问题，再专门进行优化。好吧，我承认我不知道这哥俩到底有什么区别。数据库里的字段必须只能2个长度，不能32个长度，性能问题。表名要以T开头，蛋快碎了。长度问题没看懂要说什么。前两天遇到一个问题，在oracle中如果用char类型的，而实际内容又不正好等于char长度的时候，select出来的数据是带空格的……各种trim都感觉不太好使之后，果断varchar2了。反正这点效率差异，早就被各种奇葩的业务逻辑给抵消了，还是那句话，有问题的时候再优化。表名问题，我觉得加前缀还是为了跟视图进行区分。当表只有几张时，什么区分也不用做，当表有一百七十张时，什么区分都不管用。所以，战略上看需求决定就行了……一点经验：通通加T跟没加是一个效果。现在项目中的做法：数据库中大部分的表都是对应了一个业务实体，这些类直接写名字就行，在这些表上建的视图统一加一个V_前缀，也就能起到区分效果了。一般来讲，一百七十张表中至少有一百五十五张以上都是这种表。其他的表，则大多对应了某些特殊场景或算法，实际开发中一般由专门的核心人员负责，可以按照权限控制、事务控制等实际用途，加个什么前缀，谁负责哪个模块就关注哪个前缀就好了。会用jquery.ajax获取数据，不知道ajax的同步锁。我也不知道。对于一切锁，我的意见都是，上个最大粒度的，保证数据一致性。出现的所有问题具体分析，逐个减小锁的粒度。一会显示的表格有数据，一会又没数据啊，太生气了。遇到此类抱怨时：1、告诉他，工业界没有玄幻故事，2、再提同样的问题的话，辞了他。让这种人觉得自己还有混在程序员界的错觉是对他的不负责。详细记录当时的运行环境，一般都会找到原因的。骚年级别的程序员标志：懂div的float，clear的含义。1、上一套bootstrap，解决80%的问题。2、剩下20%的问题，找个跟你关系不错的前端，没事多请人家吃吃饭，然后就解决了。数据库超过n记录表横向纵向分表。问题在于，n等于几。高估n无所谓，反正要出现的问题肯定会出现。低估n的话，造成的进度损失会让你有自杀的冲动，造成的数据损失会让项目经理有杀了你的冲动。知道oracle的用with，这个sql写起来看起就舒服了。这个也不会，粗略google了一下，确实有点用途。看到aop能说一大堆废话，又是代理又是反射，就是没写过。你的错误在于，不知道用途就研究实现原理。DateUtil一定写过好多次，简直太复杂了，非常多的格式定义，那个static格式变量，必须要深刻理解才能知道。1、有句评价说的好：把一个工具包的几乎所有方法都写到标记过时，这是得有多仇视这个社会。2、自从有了JodaDate，妈妈再也不担心我的日期处理了。当一个同事又一次熬通宵写出一个DateUtil然后我拿出了JodaDate之后……砥柱级别的程序员标志：会架构程序，能用extjs或者easyui写个框架frame，还能写个递归menu。所有的知识点都很基础，但是能把这一切都完整写出来，完成debug之后让项目组用上，一段时间之后还能维护或者添加点新功能的，都是中流砥柱。说白了，这是个情商要求大于智商要求的活。业务系统定制开发，实际上都是这种类型的活。你并不需要有特别高深的技术，也不会突然面对多么巨大的困难，只会在一个个看似不起眼的bug中，把所有激情都消磨殆尽。会用ps处理图片，还能写上几个字，XXXX系统beta版本。会ps的都是神，不解释。基本上util包的作者，用log或者拦截器记录日志。并且，愿意跟一切动过你util包的人玩命。能用fiter或者Interceptor处理权限，但是搞不懂如何处理button的权限。在业务级别去掉button权限的需求就好了。真正的解决方案没有实际执行过，只是一个想法：系统建模的时候，权限模型直接建到操作级，比方说每个Action处理函数对应一个操作，针对这个操作定义每个角色的权限。button在概念上同样映射到权限就可以了。至于怎么针对函数做权限控制，随便你用xml或者annotation定义一下就行。明白了异常处理转换成RuntimeExcetion太好了，不会丢失而且好处理。异常处理真是个技术活。当我说，我也不知道我的方案好在哪，只是觉得你们的方式不优雅时，我清楚的听到了对方心里的嗤笑声。往往我的结论都会在大概三个模块开发周期之内被确认。page分页里代码和css样式和类class都在jsptag里，认为没法分啊，这个是典型。前端用于提交参数，目测所说的代码是计算page、rowperpage这些属性的。随便找套js grid控件，看看他们的参数提交方式，前端不依赖任何jsp，分到那个份上我觉得就足够了。小牛级别的程序员：知道url资源树和menu的区别。不明觉厉。这种概念性的东西其实挺多人都挺不重视的，曾经很反对这种不重视，但是重视了很多年还真没重视到什么收获。现在的观点就是，用到了再说。能手写css，懂important能拿来做啥，这个好玩得很。又是前端，上bootstrap吧能够理解数据库必须用主外键，否则那帮家伙一定会乱写程序。只要是实体类，必须有主键，并且一定要有物理主键，不能只依赖于逻辑主键。id这东西，找不到其他用途的话就简单的当个快速查询定位的工具就行。随着业务复杂度的增加，你会发现它的表现力越来越强。在大部分依赖于持久化的业务类系统中，可以简单的定义，有id就代表这东西存在，没id就代表不存在，顺着这条思路往下想，很多业务都会简化。只用id做外键，不要用神马身份证号、订单编号之类的东西。然后你的程序随便怎么写都能写得下去。会设计数据库模型，几百张表的小意思。针对真实世界，只作抽象，不作修改，保持整个系统概念上的一致性。然后你会发现，设计的模型会恰好符合数据库设计的各种准则。这时候这个数据库结构就能用了。如果你设计出一张自认为很有用的关系表，却起不出合适的名字来；或者数据库中有一个不是纯粹为了效率问题而设置的冗余字段，相信我，你终将遇到一个你的模型无法表现的业务需求。注释用//只有一行，不用/**多行,因为程序即注释。jdk标准注释都不用，那javadoc咋办？好吧，程序即注释这东西，几个水平相当、思路相近的人，通过不定期的结对编程、互相重构代码，还是可以做到的。如果是大规模的开发，还是建议通过架构层面合理的分层解决。知道struts模型驱动代替属性注入，方便太多事了。又一个语法糖。有了实际需求再用，到底用不用不要争论起来没完，遵循这两点就行了。这个真心不是核心问题。用过this做参数传递，哈好多人都没用见过。哈真神奇！这话真有人对我说过。技术上this就是个指向自身的引用。某些具体的场景确实用起来很有意思，高层面的意义还没太想清楚，只有一个模模糊糊的印象，大概就是做了一件把自身委托给其他对象的事，封装了某个参数传递的过程，也就是封装了自身和被委托类的关系。SE级别的程序员：研究过struts，hibernate的源代码，ui里有颜色互补概念，看起来是要舒服点啊。学源代码要跟写代码结合起来执行，学到了新的模式之后，多想想有什么应用场景，但是真的实际使用要慎重。譬如说看到struts2的层层wrapper模式后就用了一次，被喷了好长时间觉得struts，hibernate，spring，要扔掉一个框架，一定是spring，这个废啊。让我选的话，我扔hibernate。写过mvc，知道前端拦截器，中心分发器，后置处理，bean映射。要知道就算没有这些概念，代码层面也一定会实现mvc的全部功能。然后找到没有这些概念的代价，哪些东西就耦合了，哪些变更就应对不了了等等。最后你的水平就提高了。会用模型驱动user.save()，代替dao。少传一个参数，概念上优雅了一些。模型驱动太考验建模能力，一定要在一个范围内把所有问题想清楚再使用。建议把DDD那本书看个两三遍再说。不过这东西看上去真的很吸引人。能用metadata生成一堆乱七八杂的代码，这下爽多了。metadata的解释是“描述数据的数据”，比方说数据库的表结构定义可能就算是一种metadata。在写代码过程中能正确的抽象出元数据之后，眼光会提高一个层次，至于是不是要搞生成代码的工具，因项目而异。曾经用过一段时间的freemarker，写一些轻量级的代码生成工具还是挺好用的。研究过Annotation，用Annotation写过注解，知道Annotation如何继承，太复杂搞不懂。拿Annotation实现过一套Model工具，没有深入了解过ejb，可能有点entity bean的思路在里面把。前面说过一部分annotation了。这东西的好处就是把元数据跟java代码放到一起了，于是好找也好改了，坏处也是放在一起所以耦合了。如果代码量大到一定程度之后，最好把所有主力都集合到一块儿商量一下，到底是xml好还是annotation好。在代码量没大到一定程度，或者annotation配置的数据仅仅是annotation所在的类自己用的话，可以在开发效率上考虑一下这个问题。jdk提供了语言层面的annotation操作工具，使用简单，有一部分的编译期检查，写起来比xml要舒服。另外，个人认为annotation的语法不太适合定义层次太深的结构，在类前面写上四层annotation再用ide做个formatter，说实话挺愁人的。BOSS级别的程序员：仰慕一下。。。。以上经验建立在如下基础上：我做的项目是大部分是技术要求特别简单，业务要求中等复杂，需求变更特别频繁，开发人员平均素质不足，工期不是很紧的类型，所以关注点集中在如何通过分层隔离业务复杂度，以及如何通过语法糖来降低开发复杂度。bug方面，比较关注的是影响数据一致性的bug，只要不影响数据一致性，哪怕系统直接挂了，都不是影响项目的生死因素。在做技术方案的时候，比较倾向于：1、通过各种设计模式封装复杂度，提供尽量简单，甚至无脑开发的接口2、忽略一切效率问题，在业务打通之后再想优化的事3、能在编译器做的事就不往运行期放，哪怕会影响开发的灵活性
职业运动员和体育爱好者的区别。后者只是会干活而已。
已有帐号？
无法登录？
社交帐号登录