技术经验集
JAVA EE架构师 需要具备的知识
1、构架师胚胎(程序员)
学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信(通信协议)——学习搭建应用系统所必须的原材料。
2、构架师萌芽(高级程序员)
学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice(研究生可以研究网络计算机、高性能并发处理等内容)
3、构架师幼苗(设计师)
应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式(c++版本、java版本)、ejb设计模式、J2EE构架、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。
4、软件构架师的正是成型在于机遇、个人努力和天赋软件构架师其实是一种职位，但一个程序员在充分掌握软构架师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为一体的精英人才这可不是每个人都能够遇上的馅饼……
第一阶段,think in java关于java方面的特性都需要知道
第二阶段,要学会使用jdk的帮助文档,
第三阶段,开始看effective java
第四阶段,必看 java模式
后面还需要了解rup,uml东西
这些完了,经过一些列项目经历下,2-4年后你应该就可以到达java的中等水平了吧
Java学习的30个目标以及系统架构师推荐的书 收藏
第一阶段
2.你需要学习JAVA语言的基础知识以及它的核心类库 (collections，serialization，streams，networking， multithreading，reflection，event，handling，NIO，localization，以及其他)。
5.你需要学习java数据库技术，如JDBCAPI并且会使用至少一种persistence/ORM构架，例如Hibernate，JDO， CocoBase，TopLink，InsideLiberator(国产JDO红工厂软件)或者iBatis。
24.你应该熟练掌握一种JAVAIDE例如sunOne，netBeans，IntelliJIDEA或者Eclipse。(有些人更喜欢VI或EMACS来编写文件。随便你用什么了：)
26.你需要熟悉一种单元测试体系(JNunit)，并且学习不同的生成、部署工具(Ant，Maven)。
27.你需要熟悉一些在JAVA开发中经常用到的软件工程过程。例如RUP(RationalUnifiedProcess)andAgilemethodologies。
第二阶段
1.你需要精通面向对象分析与设计(OOA/OOD)、涉及模式(GOF，J2EEDP)以及综合模式。你应该十分了解UML，尤其是class，object，interaction以及statediagrams。
3.你应该了解JVM，classloaders，classreflect，以及垃圾回收的基本工作机制等。你应该有能力反编译一个类文件并且明白一些基本的汇编指令。
6.你还应该了解对象关系的阻抗失配的含义，以及它是如何影响业务对象的与关系型数据库的交互，和它的运行结果，还需要掌握不同的数据库产品运用，比如:oracle，mysql，mssqlserver。
7.你需要学习JAVA的沙盒安全模式(classloaders，bytecodeverification，managers，policyandpermissions，
codesigning， digitalsignatures，cryptography，certification，Kerberos，以及其他)还有不同的安全/认证 API，例如JAAS(JavaAuthenticationandAuthorizationService)，JCE (JavaCryptographyExtension)，JSSE(JavaSecureSocketExtension)，以及JGSS (JavaGeneralSecurityService)。
第三阶段
10.你需要学习如何使用及管理WEB服务器，例如tomcat，resin，Jrun，并且知道如何在其基础上扩展和维护WEB程序。
8.你需要学习Servlets，JSP，以及JSTL(StandardTagLibraries)和可以选择的第三方TagLibraries。
4.如果你将要 写客户端程序，你需要学习WEB的小应用程序(applet)，必需掌握GUI设计的思想和方法，以及桌面程序的SWING，AWT， SWT。你还应该对UI部件的JAVABEAN组件模式有所了解。JAVABEANS也被应用在JSP中以把业务逻辑从表现层中分离出来。（这条可有可无）
9.你需要熟悉主流的网页框架，例如JSF，Struts，Tapestry，Cocoon，WebWork，以及他们下面的涉及模式，如MVC/MODEL2。
14.你应该学习如何利用JAVAAPI和工具来构建WebService。例如JAX- RPC(JavaAPIforXML/RPC)，SAAJ (SOAPwithAttachmentsAPIforJava)，JAXB(JavaArchitectureforXMLBinding)，JAXM(JavaAPIforXMLMessaging)， JAXR(JavaAPIforXMLRegistries)，或者JWSDP(JavaWebServicesDeveloperPack)。
15.你需要学习一门轻量级应用程序框架，例如Spring，PicoContainer，Avalon，以及它们的IoC/DI风格(setter，constructor，interfaceinjection)。
20.你需要熟悉对不同有用的API和frame work等来为你服务。例如Log4J(logging/tracing)，Quartz (scheduling)，JGroups(networkgroupcommunication)，JCache(distributedcaching)， Lucene(full-textsearch)，JakartaCommons等等。
25.JAVA(精确的说是有些配置)是冗长的，它需要很多的人工代码(例如EJB)，所以你需要熟悉代码生成工具，例如XDoclet
第四阶段
16.你需要熟悉不同的J2EE技术，例如JNDI(JavaNamingandDirectoryInterface)，JMS (JavaMessageService)，JTA/JTS(JavaTransactionAPI /JavaTransactionService)，JMX (JavaManagementeXtensions)，以及JavaMail。
11.你需要学习分布式对象以及远程API，例如RMI和RMI/IIOP。
12.你需要掌握各种流行中间件技术标准和与java结合实现，比如Tuxedo、CROBA，当然也包括javaEE本身。
17.你需要学习企业级JavaBeans(EJB)以及它们的不同组件模式：Stateless/StatefulSessionBeans，EntityBeans(包含Bean- ManagedPersistence[BMP]或者Container-ManagedPersistence[CMP]和它的EJB-QL)，或者 Message-DrivenBeans(MDB)。
13.你需要学习最少一种的XMLAPI，例如JAXP(JavaAPIforXMLProcessing)，JDOM(JavaforXMLDocumentObjectModel)，DOM4J，或JAXR(JavaAPIforXMLRegistries)。
18.你需要学习如何管理与配置一个J2EE应用程序服务器，如WebLogic，JBoss等，并且利用它的附加服务，例如簇类，连接池以及分布式处理支援。你还需要了解如何在它上面封装和配置应用程序并且能够监控、调整它的性能。
第五阶段（优先级低）
19.你需要熟悉面向方面的程序设计以及面向属性的程序设计(这两个都被很容易混淆的缩写为AOP)，以及他们的主流JAVA规格和执行。例如AspectJ和AspectWerkz。
21.如果你将要对接或者正和旧的系统或者本地平台，你需要学习JNI (JavaNativeInterface) and JCA (JavaConnectorArchitecture)。
22.你需要熟悉JINI技术以及与它相关的分布式系统，比如掌握CROBA。
23.你需要JavaCommunityProcess(JCP)以及他的不同JavaSpecificationRequests(JSRs)，例如Portlets(168)，JOLAP(69)，DataMiningAPI(73)，等等。
28.你需要能够深入了解加熟练操作和配置不同的操作系统，比如GNU/linux，sunsolaris，macOS等，做为跨平台软件的开发者。
29.你还需要紧跟java发展的步伐，比如现在可以深入的学习javaME，以及各种java新规范，技术的运用，如新起的web富客户端技术。
30.你必需要对opensource有所了解，因为至少java的很多技术直接是靠开源来驱动发展的，如java3D技术。
====================================================================
附：
JAVA系统架构师应该看的几本书
Thinking in Java
Effective Java
UML基础、案例与应用
UML入门提高
软件工匠
设计模式——可复用面向对象软件的基础
重构-改善既有代码的设计
敏捷软件开发-原则、模式、实践
企业应用架构模式
Expert One-on-One J2EE Development without EJB
软件工程——实践者的研究方法
软件领导－－成功开发软件的指导准则
后面的两本书，其实已经有点属于项目经理的范畴了，不过还不是很深入，看看对做成功的系统架构师是很有好处。
企业应用的系统架构师应该关注的几个方面 (具体情况具体分析,以下未必准确，只是参考)
先来一些基础面试题，您答得出么？
1、说说JVM原理？内存泄露与溢出区别，何时产生内存泄露？
2、用java怎么实现有每天有1亿条记录的DB存储？mysql上亿记录数据量的数据库如何设计？
3、mysql支持事务吗？DB存储引擎有哪些？
4、mvc原理，mvc模式的优缺点,如果让你设计你会怎么改造MVC？
5、hibernate支持集群吗？如何实现集群？
6、tomcat 最多支持并发多少用户？
7、map原理，它是如何快速查找key的？map与set区别？
8、描术算法，如何有效合并两个文件：一个是1亿条的用户基本信息，另一个是用户每天看电影连续剧等的记录，5000万条。内存只有1G？？？
9、在1亿条用户记录里，如何快速查询统计出看了5个电影以上的用户？ ----可以参考 位图索引的原理
10、Spring如何实现IOC与AOP的，说出实现原理？
数据持久层的设计
在Spring和Hibernate，ibatis出来以前，几乎每家公司都有自己的一套方法和架构，而架构师的50％的精力也会集中到这上面，EJB只是增加架构师的负担。在Spring出来以后，基本上，大多数的架构师都从重复设计这个轮子的无用功中解脱出来了。Rod的轮子太好用了，基本上，大家只要套上去就行了，或者，剩下最重要的事情，是选择一个合适的数据库连接池的开源项目吧
MVC架构的具体设计
MVC只是个概要的概念，具体如何实现的具体技术很多，根据项目设计最恰当的架构
大并发性访问
太多了，包括从广域网到服务器到业务层再到架构再到程序、数据库的各种调优，如使用缓存，静态化，静动态server分离，在数据量达到一定程度时，使用集群技术，优先考虑利用服务器的集群，其次是硬件集群，最后才是应用本身加入集群功能
超大数据量返回结果
缓存命中率，分页，优化SQL语句，循环处理数据时尽可能共用对象，只保留关键数据，及时释放内存占用
超大文件的读取和生成
尽可能快的读取大文件，并进行分析。写入大文件时，如何及时释放内存。学会适当利用操作系统的命令行资源来更快完成任务。这方面经验比较少，以后有空研究。
多线程的应用和管理
线程池的管理和监控，线程的启动（包括定时启动），结束，回收，线程资源的释放，这句话太简单了，待深入研究
用户界面可用性设计
平衡速度和可用性，恰当的使用异步和同步技术，展现关键数据为重点
分布式的数据交流和集成
选择恰当的数据交互方式，从最泛滥低效的Web Service到最实用的文件共享
群集系统的管理
如何确保缓存的同步？如何确保对象唯一性？如何保证各台机器的同步？
是否采用EJB?如何利用J2EE的特性（例如JNDI)
复杂的业务规则
规则引擎和工作流引擎场景和应用
其实，作为一个真正的系统架构师，不应该局限于企业应用的系统，这种系统往往有数据库的局限性，有时候，应该考虑是否可以横向跨越，直接对其它系统做一些架构考虑，在没有丰富的实战经验的前提下，而只是看了其它人的系统和代码，就能够给出有效的设计指导。
例如对于一个下载软件，可以有如下考虑：
1. 未明和非法url的检验，已经下载失败的容许，信息记录
2. 多线程下载一个文件,文件的切分和拼合，部分切片丢失的拼合可能性
3. 下载线程管理
4. 服务器或者P2P的机器之间的通讯协议
5. 速度监控和限制
6. 下载进度的监控和显示
作为一个在线播放软件,可以做如下考虑
1. 播放速度的保证
机器的问题基本不存在了，关键是网络问题。如何在检测网络速度，根据影片的质量，并缓冲足够多的内容，保证播放一直尽可能顺利的完成。
2. 播放质量的保证
如何利用DirectX等技术,最快的进行渲染,是自己写底层,还是利用已有的API
由于没做过类似的项目，可以写的东西还是少很多了。
系统架构师应该有的素质：
1、 实际的编程经验
最少2年吧，多了就不说了，其实从大学就开始钻研的话，
2、 书面表达能力和口头交流能力
综合利用架构图，UML图，文字和代码片断，表达自己设计思想，至于是Word还是ppt，应该通吃
在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。
3、 自觉主动;积极解决设计问题
架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。
4、 抽象思维能力和总结能力
架构师，顾名思义，在系统未搭建好之前，就要能够有一个草图在心。而如果是对现有系统的改造，那么能在看过系统的文档（如果有的话）和代码后，就能总结出系统的架构特点。
架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。
开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。
5、 全面的技术资讯吸收能力和选择鉴别能力
作为开发人员出身，对于某一个具体问题的研究能力（虽然很多人总结为google能力），已经相当具备了。但是对技术资讯的全面接受和选择性深入了解能力，并且做出正确的判断，那些技术无非是厂家的噱头，而那些技术是真正可以用到项目，提高项目质量的好技术，这种能力确实至关重要的。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/fish88168/archive/2010/09/10/5875944.aspx
系统架构师知识结构
软件系统架构师综合的知识能力结构包括9个方面，即：
（1）战略规划能力。
（2）业务流程建模能力。
（3）信息数据架构能力。
（4）技术架构选择和实现能力。
（5）应用系统架构的解决和实现能力。
（6）基础IT知识及基础设施、资源调配的能力。
（7）信息安全技术支持与管理保障能力。
（8）IT审计、治理与基本需求分析、获取能力。
（9）面向软件系统可靠性与系统生命周期的质量保障服务能力。
作为系统架构师，必须成为所在开发团队的技术路线引导者；具有很强的系统思维的能力；需要从大量互相冲突的系统方法和工具中区分出哪些是有效的，哪些是无效的。架构师应当是一个成熟的、丰富的、有经验的、有良好教育的、学习快捷、善沟通和决策能力强的人。丰富是指他必须具有业务领域方面的工作知识，知识来源于经验或者教育。他必须广泛了解各种技术并精通一种特定技术，至少了解计算机通用技术以便确定哪种技术最优，或组织团队开展技术评估。优秀的架构师能考虑并评估所有可用来解决问题的总体技术方案。需要良好的书面和口头沟通技巧，一般通过可视化模型和小组讨论来沟通指导团队确保开发人员按照架构建造系统。
因此，系统架构师知识维度可以总结为"多层次+多方面"。所谓多层次，意味着系统架构师必须在体系结构、计算机软硬件与网络基础知识、信息化基础知识、信息安全与可靠性基础知识等基本功的层面上受过良好的教育和快捷的学习能力；还须在系统架构设计方法、设计模式、设计流程以及各种模型等方面有丰富的经验，广泛了解各种构件产品和技术并精通一种特定领域的架构设计；进一步，还须在系统架构设计实践层面，有自己的认识和理解，同时具有很强的表述能力；所谓多方面，意味着系统架构师在每个知识层面上必须具有技术、管理、心理和艺术等多方面的知识和能力。这和系统架构师的多角色特点是相关的。本书也正是从这个角度来介绍系统架构的知识体系，即从系统构件、模式和规划三个方面的技术基础、原理和方法的角度编写而成的关于软件架构师的基本知识结构和水平的教材。
---------------------------------------------------------------------------
从程序员到技术总监，分享10年开发经验
在中国有很多人都认为IT行为是吃青春饭的，如果过了30岁就很难有机会再发展下去！其实现实并不是这样子的，在下从事.NET及JAVA方面的开发的也有10年的时间了，在这里在下想凭借自己的亲身经历，与大家一起探讨一下。
明确入行的目的
很多人干IT这一行都冲着“收入高”这一点的，因为只要学会一点HTML, DIV+CSS，要做一个页面开发人员并不是一件难事，而且做一个页面开发人员更容易找到工作，收入比普通的工作还要高一些，所以成为了很多高校毕业生的选择。如果您只是抱着这样一个心态来入行的话，那阁下可真的要小心了。因为干IT这一行竞争本来就比较激烈，特别是页面设计这方面，能够开发的人很多，所以为了节省成本，大部分公司都会在需要的时候才招聘这类人员；在没有订单的时候，一些小公司还可能找各类的借口或者以降薪的手段去开除这类员工。而在招聘信息上常常会看到“招聘页面设计师，条件：30岁以下……欢迎应届毕业生前来应聘”这样一条，因为这一类工员对技术上的要求并不高，找应届生可以节约成本。所以在下觉得“IT行业是吃青春饭的”这句话只是对着以上这类人所说的，如果阁下缺乏“进取之心”，而只抱着“收入高，容易找工作”这样的态度而入行，那“IT行业是吃青春饭”将会应验了。
选择合适的工具
JAVA、C#、PHP、C++、VB……10多种热门的开发语言，哪一种最有发展潜力呢？其实开发语言只不过是一个工具，“与其分散进攻，不如全力一击”，无论是哪一种开发语言，只要您全力地去学习，到有了一定的熟悉程度的时候，要学习另一种的语言也是轻而易举的事情。开发语言主要分为三大类：
1. 网络开发
现在网络已经成为世界通讯的一座桥梁，好像Javascript、PHP、Ruby这几类开发语言大部分是用作网络开发方面。
2. 企业软件开发
JAVA、C#、VB这几类开发语言都实现了面向对象开发的目标，更多时候用于企业系统的开发。
3. 系统软件
C语言、C++、Objective-C这些软件更多是用在系统软件开发，嵌入式开发的方面。
当然，这分类不是绝对，像JAVA、C#、VB很多时候也用于动态网站的开发。在很开发项目都会使用集成开发的方式，同一个项目里面使用多种开发语言，各展所长，同步开发。但所以在刚入门的时候，建议您先为自己选择一种合适的开发工具，“专注地投入学习，全力一击”。
明确发展方向
当您对某种开发语言已经有了一定的了解，开始觉得自己如同“行尸走肉”，成为一个开发工具的时候，那您就应该要明确一下自己的发展方向了。
平常在公司，您可以看到做UI层的开发人员大多数都有20多岁，他们充满干劲，而且没有家庭负担，在两年前ASP.NET MVC 、Silverlight等刚出现的时候，他们可以在晚上回家的时候买几本书或者直接上网看看，研究三五个星期以后，对需要用到的技术就已经有一定的了解了。而年过30的人多数是已经成家了，他们每天9：00点上班唯一的希望就是快些到6：00点，能回家吃饭。吃完饭只想陪孩子玩一下，看看孩子的功课，对新增的技术缺乏了学习的欲望。所以很多接近30岁的程序员都有着一种逼迫感（包括30岁时候的我自己），再过几年应该怎么办？这时候，您就更应该明确一下目标，努力向自己的发展方向前进了。归纳一下，可从下面几项里选择适合自己的一条道路：
1. 从技术向业务过渡
在国外，很多发达国家都很重视人才，一个高级的程序员与一个Project Manager收入相差一般不超过15%。但中国是世界上人口最多的国家，国内人才众多，所以人才滥用的情况经常可以看到。一个小公司的开发部里面经常会见到新面孔，但PM却不会常换。因为做老板的对技术是一窍不通，依他们看来只到拉住PM的心，那技术方面方面就能搞得定，至于技术部要换人，他们根本不需要费力气去管。所以从一个技术员过渡到一个PM是向前发展的一个选择，但开发人员也需要知道，要成为一个PM不单单是使用技术，而更重要的是对管理方面的认识。一个PM主要的工作是组织团队，控制成本，管理业务，控制项目进度，与客户进行沟通，协调工作，定期进行工作报告等。所以要成为一个成功的PM更要重视组织能力，PM必须能提高团队的积极性，发挥团队所长，在有限的开发资源前提下为公司得到最大程度上的利润。成为一个PM后，通常不需要直接接触技术开发，而着重管理的是业务发展，但PM对技术也需要有一定的了解（在下曾经为PM对技术了解的必要性写过一篇文章，得到很多支持但也惹来不少的争议）。在这里我还是要强调自己的观点：要成为一个成功的PM最重视的是管理能力，但对技术也应该有足够的了解，因为这是与团队成员沟通的桥梁，只有这样才能与整个团队的成员有着紧密的结合，让团队成员感觉到他们自己存在的意义，从而调动团队的积极性，而不是漠视技术人员的存在。技术并非成为一个成功PM的充分条件但却是必要条件！
2. 从程序员向技术管理发展
其实一个Team Leader的职责与Project Manager相像，但Team Leader更着重于技术开发方面，通常一个大型项目都会有一两个开发团队由Team Leader带领，负责开发核心部分，而其它部分分派给不同开发小组或者分派给外包公司。在网上常看到几句话，贴切地形容了PM与TL的区别：“技术人员乐于被领导；但他们不喜欢被管理，不喜欢像牛一样被驱赶或指挥。管理者强迫人们服从他们的命令，而领导者则会带领他们一起工作。管理是客观的，没有个人感情因素，它假定被管理者没有思想和感受，被告知要做什么和该如何做。领导是引领、引导，它激励人们达成目标。领导力是带有强烈个人感情色彩的，它不是你能命令的，也不是你能测量评估和测试的。”
无论是PM与TL，对业务与技术都要有深入的了解，只是PM更侧重于业务的管理，盈利的多少，风险的大小等等，而TL则侧重于项目的成本，开发的难度，软件的架构等技术方面的问题。在某些人眼中，技术与管理就像鱼与熊掌，不可兼得，但依在下看来，两者却是秤不离砣，密不可分。只要及时提升自己对技术与管理的认识，不断地向深一层发展，要从程序员提升到技术管理人员只是时间的问题。打个比方，一个普通的.NET程序员，开始可能限制于ASP.NET的页面开发，但一旦他有了发展之心，他自然会对ASP.NET MVC、Silverlight、WinForm、WPF这些UI的开发手法感到兴趣，学习不需要多少时间，他可能就会认识这些UI开发只不过是一些工具，其实在开发原理上没什么区别。接着他就会向深一层的通讯模式进行了解，认识TCP/IP、Web Service、WCF、Remoting这些常用到的通讯方式，这时候他可能已经感觉到自己对开发技术有了进一步的了解。进而向工作流、设计模式、面向对象设计、领域驱动设计、面向服务开发等高层次进发，最后成为技术的领导者。上面只是一个比喻，但要注意的是，在学习的时期必须注意的是与同事之间沟通，很多的开发人员喜欢独来独往，开发的项目总想一个人搞定，不受外界的干扰。但要明白，就算你有天大的本事，一项大型的项目也不可能由你一个人全扛着。所以团队的合作性与同事间的沟通是必要的，这也是成功一个TL的必要条件。
3. 单方面向技术发展
能成功进行技术开发的尖端人才，这是在下最向往的工作，却也没本事登上这个位置。很多从事开发的人都会认为，业务总会带着“金钱的味道”，老板从来不管开发是否合符开发原则，是否经过必要测试，他们只会在客户面前无尽地吹嘘，项目到期能成功交货，只要不出什么大问题那这个项目就算成功了。其实我们也要明白：开发项目最终目标是为了赚钱，在开发过程中对项目成本的限制和效率的控制这也是必须，所以这才需要管理人员对项目进行管理。但开发人员也很想避开这“金钱的尘嚣”，全心投入到技术的世界当中。所以对技术有着浓厚兴趣的人，往往会深入地研究某一项技术，成为技术上的精英。但在这里说一句令人心淡的话：中国已经属于是世界上第二大经济体同盟国，但国民生产总值主要来源于第三方加工产业方面。中国可以说是人才济济，但却在高新产业上却比发达国家落后。这几年的确看到我们国家在高新科技上有着质的飞跃，但跟欧美发达国家还有着一段距离。所以想在中国成为尖端技术的人才，无可否定比在国外要难。依在下看来，要想成为尖端的开发者，必须对C、C++、汇编语言、嵌入式开发、Windows API、Linux API这些底层技术有着深入的了解。要知道解JAVA、.NET……等这些之所以称为高级开发语言，并不是指它们比C、C++、汇编语言更高级，而是指它们封装了C、C++等等的功能，更适合用于企业软件的开发，使开发变得简单。但如果要开发一些底层的软件，大型的系统的时候，就必须用到C、C++、汇编等开发语言，这是成功尖端人才的一个条件。
确定未来的目标
人是从历练中成长的，古人云：三十而立，形容的不是一个人的社会地位，经济来源，而是形容一个人对未来的目标，对人生的意向。要成为一个成功人，就应该早日为自己定下长期的发展目标，作为一个开发者也当如此。随着人的性格，取向各有不同，大家为自己所选择的路也有不同：
1. 自立门户，勇敢创业
快30岁了，很多人会认为要想真正赚得了钱，就应该自立门户，为自己创业建立一个基础。像北京、上海、广州
这些一级城市，要买房子，一手楼基本要在2万~4万元/平方米左右，而在一家普通的IT公司当上一个项目经理，基本收
入一般都在1.5万~3万之间（除非在大型的跨国企业内工作，那另当别论），要买一间100平方米左右的房子，就算不
吃不喝也几乎要10年的年薪，所以选择自主创业，是很多IT开发人员的一个未来目标，想要达到这个目标，就应该更
多地把业务作为重点。不可否认的一件事，在中国社会里很多时候讲的是“关系”，即使这30年的改革开放使中国的经
济蓬勃地发展起来，但几千年来留下的歪风还是不能完全的磨灭。所以想要创业的人事建议你要多跟客户打好关系，
与合作伙伴保持互利互动的模式，这将有利于日后事业的发展。
2. 急流勇退，退居二线
这也是不少人的选择。很多人在有了家庭以后，感觉到压力太大，人的一生并非只有事业，他们想把更多时间用
于对亲人的照顾，对孩子的关心上。所以很多人会选择一份像系统分析、系统维护、高校教师、专业学院讲师这一类的
工作。收入稳定，而且往往没有一线开发人员那么大的压力。
3. 不懈努力，更进一步
无论你是一个Project Manager或者是Team Leader，如果你想继续晋升一级，那还是会两极分化的。从一个PM到
一间公司的管理层，那所面对的事件会有很多变化。一个公司的总经理，要管理的不再是一到两个项目的成本，而是
整个部门的运作，整间公司的业务流程，所以要肩负的任务会更重。在下曾经有一位上司彭博士，他是企业的最高领导
人，年薪超过三百万，而且在报纸杂志上也曾经亮过相。平常只会在某些会议上轻轻地亮下相，说两句讲词，平常的
公司运作与业务管理都不需要他直接执行。这并不是说一个作为管理层很清闲，因为他们要面对的是更多的社会关系，
与公司合作企业的联系上。这跟一个PM的工作有很大的区别，所以要从一个PM晋升到管理层，那可是要付出更多的努力与汗水。
如果要从Team Leader上升为一个技术总监，那工作的方向也有所改变。像之前所说：一个TL可能更重视的是技术
层面，讲求与团队之间的互动合作性，更注重的是开发的完善。而一个技术总监就无需要直接参加某个项目的开发，而注
意的是开发的效率与成果，如何合理使用有限的开发资源，控制开发的风险和可能带来的效果。
发展感受
经历了8年多时间，在下从一个程序员到一个项目经理，之间经过很多的曲折，但因为每一个人的际遇都有所不同，
所走的路也有不同，正所谓条条大路通罗马，成功的路不止一条，在下也不想令各位误解，而只想为大家说一下我的发
展方向。如果您是一位开发人员，“程序员->架构师->Team
Leader（Project
Manager）->技术总监”是一条不错路，这也是在下选择的路。在我国，想要进一步提升自己，无论你想是以技术为重点
还是以业务为重点，都离不开管理二字。在一些大型的企业，一个团队往往会配备一个PM与一个架构师，尽管两个人
负责的任务各有不同，但你会看到一个架构师的收入往往不如一个PM，PM往往是这个团队的核心领导者，是关键人物。
因为公司能否赚钱，PM有着重要的作用。PM与TL并没有绝对的区别，而且在一些中小型企业，一个开发团队只有3~5人
，一个TL往往会兼备业务处理、成本控件、架构设计、开发管理等多项任务。所以在下会把Team
Leader与Project
Manager定于同一层次，一个公司的老板往往不会知道团队的架构师、程序员是何人，而只会向PM询问项目的进度，所以只
有晋升到这个层次，才有机会进一步提升管理能力，让自己有上升的空间。至于要成为一个技术总监，那要求就不再单单是对
单个项目的管理，而应该更则重于新兴技术的引用，开发资源的合理利用，对开发项目敏捷性的处理等等，对此在下也在试探当中，未敢多言。
与编程牵手 和代码共眠 从程序员到技术总监
从业IT十年,从程序员成为技术总监,现在回头看一看,这条路也伴随国内的IT一起风雨兼程10年,对IT技术由其是IT的纯软件开发这一块
,向即将要从事软件技术研发的朋友谈一谈我的看法:
一.认清当前IT形势,选择合适的技术方向和技术起点
估计大家都多多少少知道,这个IT行业知识的更新很快,竞争很急烈.
如果你对自己以后发展的方向在从业前有一个清析的计划或认识,相信你会比别人走得更好,走得更远,赚的钱也更多...呵呵
IT软件从业的方向,一般都会有这些机会:产品售前(市场,业务),产品开发(编码,设计,测试),产品售后(支持,实施),产品管理(项目管理等)
A.产品售前(市场,业务)
要从事这一块的工作,主要是在软件开发的前期(无产品),或者合同签订前期(有产品).
一般要求对相关的业务和技术都要求很高,这可不仅仅是要求人际关系,交际能力.
要想别人买你的产品,你得以专业的产品品质为后台,以专业的谈吐,专业的技术和专业的业务理解能力来取胜.
从业者要求:
要求从业者要有一定的社会经验,技术经验或业务经历,或一定的社会圈子和交际能力.
建议:
刚刚从学校毕业的朋友或不符合上面条件的朋友最好要考虑清楚了.当然这世上没有什么绝对的东西,就看你自己了.
现实情况:
据我所了解的,作这一块的都会是公司一些高层(有关系,有经验)和业务专家或特殊背景的人员等.
B.产品开发(编码,设计,测试)
这一块的工作,当然是IT从业大军的主力了,但也得要考虑清楚.
如果你要作设计师,或测试,最好先作一段时间的编码,
一个好的设计师是不可能不精通相关技术平台的!
国外好的测试人员也几乎是从开发人员中选出来的,基至是软件开发高手.
a.代码编写
在这一个职业选择范围内最好是从代码编写开始.当然你也可以先作测试,看看人家是怎么写代码的是如何来作这个软件的,
借用人家的测试经验也可以,以后有机会再来编一段时间的代码也行.
有时自己去写一个软件也可以,所以作编码和测试都是一个双向交互的.而不是编码在前测试在后的.
作代码的编写最好自己先看看别人的软件,或由一些高手带着指导一下,现在技术的学习都不成问题,关健是要连成一条线来学习和思考就会有一定的局限了.
所以要熟悉整个的项目流程或业务流程不是靠个人编码或在培训班学一下就能解决的,个人的技术学习和培训班大部分只能解决技术的学习问题,但作软件不仅是要技术呀
三分技术七分业务说得不为过,业务的学习也是一个开发人员所要必备的,如果你在不熟悉业务细节之前建议你不要急着去写代码,那样肯定会是对以后软件的影响很大.先要熟悉一下业务.
所以软件开发人员掌握一门技术平台和语言是必备条件但同时也必须要有一定的业务知识,这样才是一个合格的软件开发人员.当然精通软件编码,懂设计,熟悉业务,熟悉软件项目开发流程的软件开发人员是优秀的,那是高级研发人员的必备条件.
如果你才入门或转行或刚毕业,建议从基础的代码编写开始,跟着高手或找一些成熟的项目多学习,
b.软件设计
当然这个职业要求行业的经验,技术经验都要有一定的基础,薪水一般也会高很多,所以也是一些开发人员热烈追逐的目标.但一个好的设计师不是一二年所能练就的,精通编码,熟练设计模式和公司所采用的技术平台,熟练一些设计理论并实际多运用,熟练公司业务,其实这个层面的压力也最大,一个好的软件在设计上的比重几乎要占到七成.
建议刚毕业的朋友或软件初学者不要在这一块来凑热闹,即使你作成了设计师,但在我眼中看来你也不是一个合格的设计师...当然你有这个能力来作设计师就要恭喜你了.
c.软件测试
熟练软件测试的各种理论或实际运用,也要熟悉编码技术及相关的技术平台,熟练掌握业务.
软件测试中一般都会有:
单元测试,要求你熟练开发技术进行跟踪调试,也就是白盒测试了
集成测试,对整个项目流程的测试,要求掌握业务知识,对设计的软件能作功能上的测试或压力测试等
,属黑盒测试
确认测试,对业务要很熟悉,测试软件是否完全满足了客户的业务需求.
总体建议:
1.熟练一种技术平台,熟悉一种业务
刚入门的朋友很容易犯的一个毛病是,熟练:VB,VC,.NET,JAVA,C++,C,Dephi,PB,几乎市场上要用的他全部会,唉,如果我看到他的简历上有这么一句话,这个人肯定不会在我考虑的范围了.
现在全球用得最广最多的技术平台体系也就三大体系:
sun的J2EE技术体系(JAVA):在高安全性,高性能上更胜一步,中高端市场上用得多
微软件的技术体系(C++,.NET,c#,VB):在中,低端市场占绝对优势,也是全球个人电脑操作平台用户最多的.
CORBA技术体系统(一种分布式技术体系和标准),
全称:Common
Object Request Broker
Architecture：公共对象请求代理结构,可以用不同的编程语言写成，运行在不同的操作系统上，存在于不同的机器上。
一般介于底层和上层管理软件之间,
其他的还会包括底层开发:C,汇编,属纯底层的开发,当然要求技术的起点和业务背景更强,最好是学的专业:电子电气,嵌入式行业,机械制造,数据采集等...
看中你想要从事的技术体系,选好一门语言工具,好好上路吧...:)
永远要记住:你什么都想学,你什么都学不精
2.从基础入手,不要好高鹜远,眼高手低,要与实际结合
B.产品售后(支持,实施)
这一块对于开发技术的要求来讲不是那么明显,主要工作会在软件开发后的工作,跟客户打交道多,但更多要求体现在对业务的把握和客户的交际上.
有些软件产品业务比较成熟,如果参与这一阶段的工作,可以快速学习很多的业务知识,积累客户交往的经验
建议:刚入门或刚毕业的朋友,可以在这个工作上多选择,等待时机成熟,立马杀入软件的开发或设计阶段,当然,这一块的工作作得好也不容易,如果适合你作,
工作环境或工资都不错你就大可不必多想了...
C.产品管理(项目管理等)
这一块的工作主要体现在管理上,当然适合有一定经验或管理能力的人员来担当,
最后的技术从业方向总结：
技术型:先选择好一种技术平台,熟练一种开发语言和数据库...专业专注的搞几年再说
技术+管理型:如果你有一定的技术经验了,并且人际交往,管理能力不错,你就可以向这个方向发展
技术+业务型:精通一种技术平台,精通一种业务,好好搞,这种人才最受欢迎...
管理型:
如果你有一定的社会经验,从业经验,如果人际交往,管理能力还可以,老板也喜欢,就搞这个
业务型(市场):如果你对业务很感兴趣,跟客户的交往等也不错,你可以选择了,有适合的专业技术就更能锦上添花了
技术+市场+管理:老大的位置....:)
-------------------------------------------------------------------------------------------
校园级别的程序员的标志：
代码中最多的是嵌套if(null == xxx)，还要告诉你，null必须写在前面，我靠。
防止把==写成=，c语言时代常犯的错误。由于null不能做左值，在写=的时候出现编译错误。一般来讲，在java中，由于boolean和其他类型不会作隐式转换，因此这么写没有意义。
写着写着突然想起来这么个代码：
Boolean b = true;
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、忽略一切效率问题，在业务打通之后再想优化的事
1、构架师胚胎(程序员)
学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信(通信协议)——学习搭建应用系统所必须的原材料。
2、构架师萌芽(高级程序员)
学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice(研究生可以研究网络计算机、高性能并发处理等内容)
3、构架师幼苗(设计师)
应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式(c++版本、java版本)、ejb设计模式、J2EE构架、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。
4、软件构架师的正是成型在于机遇、个人努力和天赋软件构架师其实是一种职位，但一个程序员在充分掌握软构架师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为一体的精英人才这可不是每个人都能够遇上的馅饼……
第一阶段,think in java关于java方面的特性都需要知道
第二阶段,要学会使用jdk的帮助文档,
第三阶段,开始看effective java
第四阶段,必看 java模式
后面还需要了解rup,uml东西
这些完了,经过一些列项目经历下,2-4年后你应该就可以到达java的中等水平了吧
Java学习的30个目标以及系统架构师推荐的书 收藏
第一阶段
2.你需要学习JAVA语言的基础知识以及它的核心类库 (collections，serialization，streams，networking， multithreading，reflection，event，handling，NIO，localization，以及其他)。
5.你需要学习java数据库技术，如JDBCAPI并且会使用至少一种persistence/ORM构架，例如Hibernate，JDO， CocoBase，TopLink，InsideLiberator(国产JDO红工厂软件)或者iBatis。
24.你应该熟练掌握一种JAVAIDE例如sunOne，netBeans，IntelliJIDEA或者Eclipse。(有些人更喜欢VI或EMACS来编写文件。随便你用什么了：)
26.你需要熟悉一种单元测试体系(JNunit)，并且学习不同的生成、部署工具(Ant，Maven)。
27.你需要熟悉一些在JAVA开发中经常用到的软件工程过程。例如RUP(RationalUnifiedProcess)andAgilemethodologies。
第二阶段
1.你需要精通面向对象分析与设计(OOA/OOD)、涉及模式(GOF，J2EEDP)以及综合模式。你应该十分了解UML，尤其是class，object，interaction以及statediagrams。
3.你应该了解JVM，classloaders，classreflect，以及垃圾回收的基本工作机制等。你应该有能力反编译一个类文件并且明白一些基本的汇编指令。
6.你还应该了解对象关系的阻抗失配的含义，以及它是如何影响业务对象的与关系型数据库的交互，和它的运行结果，还需要掌握不同的数据库产品运用，比如:oracle，mysql，mssqlserver。
7.你需要学习JAVA的沙盒安全模式(classloaders，bytecodeverification，managers，policyandpermissions，
codesigning， digitalsignatures，cryptography，certification，Kerberos，以及其他)还有不同的安全/认证 API，例如JAAS(JavaAuthenticationandAuthorizationService)，JCE (JavaCryptographyExtension)，JSSE(JavaSecureSocketExtension)，以及JGSS (JavaGeneralSecurityService)。
第三阶段
10.你需要学习如何使用及管理WEB服务器，例如tomcat，resin，Jrun，并且知道如何在其基础上扩展和维护WEB程序。
8.你需要学习Servlets，JSP，以及JSTL(StandardTagLibraries)和可以选择的第三方TagLibraries。
4.如果你将要 写客户端程序，你需要学习WEB的小应用程序(applet)，必需掌握GUI设计的思想和方法，以及桌面程序的SWING，AWT， SWT。你还应该对UI部件的JAVABEAN组件模式有所了解。JAVABEANS也被应用在JSP中以把业务逻辑从表现层中分离出来。（这条可有可无）
9.你需要熟悉主流的网页框架，例如JSF，Struts，Tapestry，Cocoon，WebWork，以及他们下面的涉及模式，如MVC/MODEL2。
14.你应该学习如何利用JAVAAPI和工具来构建WebService。例如JAX- RPC(JavaAPIforXML/RPC)，SAAJ (SOAPwithAttachmentsAPIforJava)，JAXB(JavaArchitectureforXMLBinding)，JAXM(JavaAPIforXMLMessaging)， JAXR(JavaAPIforXMLRegistries)，或者JWSDP(JavaWebServicesDeveloperPack)。
15.你需要学习一门轻量级应用程序框架，例如Spring，PicoContainer，Avalon，以及它们的IoC/DI风格(setter，constructor，interfaceinjection)。
20.你需要熟悉对不同有用的API和frame work等来为你服务。例如Log4J(logging/tracing)，Quartz (scheduling)，JGroups(networkgroupcommunication)，JCache(distributedcaching)， Lucene(full-textsearch)，JakartaCommons等等。
25.JAVA(精确的说是有些配置)是冗长的，它需要很多的人工代码(例如EJB)，所以你需要熟悉代码生成工具，例如XDoclet
第四阶段
16.你需要熟悉不同的J2EE技术，例如JNDI(JavaNamingandDirectoryInterface)，JMS (JavaMessageService)，JTA/JTS(JavaTransactionAPI /JavaTransactionService)，JMX (JavaManagementeXtensions)，以及JavaMail。
11.你需要学习分布式对象以及远程API，例如RMI和RMI/IIOP。
12.你需要掌握各种流行中间件技术标准和与java结合实现，比如Tuxedo、CROBA，当然也包括javaEE本身。
17.你需要学习企业级JavaBeans(EJB)以及它们的不同组件模式：Stateless/StatefulSessionBeans，EntityBeans(包含Bean- ManagedPersistence[BMP]或者Container-ManagedPersistence[CMP]和它的EJB-QL)，或者 Message-DrivenBeans(MDB)。
13.你需要学习最少一种的XMLAPI，例如JAXP(JavaAPIforXMLProcessing)，JDOM(JavaforXMLDocumentObjectModel)，DOM4J，或JAXR(JavaAPIforXMLRegistries)。
18.你需要学习如何管理与配置一个J2EE应用程序服务器，如WebLogic，JBoss等，并且利用它的附加服务，例如簇类，连接池以及分布式处理支援。你还需要了解如何在它上面封装和配置应用程序并且能够监控、调整它的性能。
第五阶段（优先级低）
19.你需要熟悉面向方面的程序设计以及面向属性的程序设计(这两个都被很容易混淆的缩写为AOP)，以及他们的主流JAVA规格和执行。例如AspectJ和AspectWerkz。
21.如果你将要对接或者正和旧的系统或者本地平台，你需要学习JNI (JavaNativeInterface) and JCA (JavaConnectorArchitecture)。
22.你需要熟悉JINI技术以及与它相关的分布式系统，比如掌握CROBA。
23.你需要JavaCommunityProcess(JCP)以及他的不同JavaSpecificationRequests(JSRs)，例如Portlets(168)，JOLAP(69)，DataMiningAPI(73)，等等。
28.你需要能够深入了解加熟练操作和配置不同的操作系统，比如GNU/linux，sunsolaris，macOS等，做为跨平台软件的开发者。
29.你还需要紧跟java发展的步伐，比如现在可以深入的学习javaME，以及各种java新规范，技术的运用，如新起的web富客户端技术。
30.你必需要对opensource有所了解，因为至少java的很多技术直接是靠开源来驱动发展的，如java3D技术。
====================================================================
附：
JAVA系统架构师应该看的几本书
Thinking in Java
Effective Java
UML基础、案例与应用
UML入门提高
软件工匠
设计模式——可复用面向对象软件的基础
重构-改善既有代码的设计
敏捷软件开发-原则、模式、实践
企业应用架构模式
Expert One-on-One J2EE Development without EJB
软件工程——实践者的研究方法
软件领导－－成功开发软件的指导准则
后面的两本书，其实已经有点属于项目经理的范畴了，不过还不是很深入，看看对做成功的系统架构师是很有好处。
企业应用的系统架构师应该关注的几个方面 (具体情况具体分析,以下未必准确，只是参考)
先来一些基础面试题，您答得出么？
1、说说JVM原理？内存泄露与溢出区别，何时产生内存泄露？
2、用java怎么实现有每天有1亿条记录的DB存储？mysql上亿记录数据量的数据库如何设计？
3、mysql支持事务吗？DB存储引擎有哪些？
4、mvc原理，mvc模式的优缺点,如果让你设计你会怎么改造MVC？
5、hibernate支持集群吗？如何实现集群？
6、tomcat 最多支持并发多少用户？
7、map原理，它是如何快速查找key的？map与set区别？
8、描术算法，如何有效合并两个文件：一个是1亿条的用户基本信息，另一个是用户每天看电影连续剧等的记录，5000万条。内存只有1G？？？
9、在1亿条用户记录里，如何快速查询统计出看了5个电影以上的用户？ ----可以参考 位图索引的原理
10、Spring如何实现IOC与AOP的，说出实现原理？
数据持久层的设计
在Spring和Hibernate，ibatis出来以前，几乎每家公司都有自己的一套方法和架构，而架构师的50％的精力也会集中到这上面，EJB只是增加架构师的负担。在Spring出来以后，基本上，大多数的架构师都从重复设计这个轮子的无用功中解脱出来了。Rod的轮子太好用了，基本上，大家只要套上去就行了，或者，剩下最重要的事情，是选择一个合适的数据库连接池的开源项目吧
MVC架构的具体设计
MVC只是个概要的概念，具体如何实现的具体技术很多，根据项目设计最恰当的架构
大并发性访问
太多了，包括从广域网到服务器到业务层再到架构再到程序、数据库的各种调优，如使用缓存，静态化，静动态server分离，在数据量达到一定程度时，使用集群技术，优先考虑利用服务器的集群，其次是硬件集群，最后才是应用本身加入集群功能
超大数据量返回结果
缓存命中率，分页，优化SQL语句，循环处理数据时尽可能共用对象，只保留关键数据，及时释放内存占用
超大文件的读取和生成
尽可能快的读取大文件，并进行分析。写入大文件时，如何及时释放内存。学会适当利用操作系统的命令行资源来更快完成任务。这方面经验比较少，以后有空研究。
多线程的应用和管理
线程池的管理和监控，线程的启动（包括定时启动），结束，回收，线程资源的释放，这句话太简单了，待深入研究
用户界面可用性设计
平衡速度和可用性，恰当的使用异步和同步技术，展现关键数据为重点
分布式的数据交流和集成
选择恰当的数据交互方式，从最泛滥低效的Web Service到最实用的文件共享
群集系统的管理
如何确保缓存的同步？如何确保对象唯一性？如何保证各台机器的同步？
是否采用EJB?如何利用J2EE的特性（例如JNDI)
复杂的业务规则
规则引擎和工作流引擎场景和应用
其实，作为一个真正的系统架构师，不应该局限于企业应用的系统，这种系统往往有数据库的局限性，有时候，应该考虑是否可以横向跨越，直接对其它系统做一些架构考虑，在没有丰富的实战经验的前提下，而只是看了其它人的系统和代码，就能够给出有效的设计指导。
例如对于一个下载软件，可以有如下考虑：
1. 未明和非法url的检验，已经下载失败的容许，信息记录
2. 多线程下载一个文件,文件的切分和拼合，部分切片丢失的拼合可能性
3. 下载线程管理
4. 服务器或者P2P的机器之间的通讯协议
5. 速度监控和限制
6. 下载进度的监控和显示
作为一个在线播放软件,可以做如下考虑
1. 播放速度的保证
机器的问题基本不存在了，关键是网络问题。如何在检测网络速度，根据影片的质量，并缓冲足够多的内容，保证播放一直尽可能顺利的完成。
2. 播放质量的保证
如何利用DirectX等技术,最快的进行渲染,是自己写底层,还是利用已有的API
由于没做过类似的项目，可以写的东西还是少很多了。
系统架构师应该有的素质：
1、 实际的编程经验
最少2年吧，多了就不说了，其实从大学就开始钻研的话，
2、 书面表达能力和口头交流能力
综合利用架构图，UML图，文字和代码片断，表达自己设计思想，至于是Word还是ppt，应该通吃
在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。
3、 自觉主动;积极解决设计问题
架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。
4、 抽象思维能力和总结能力
架构师，顾名思义，在系统未搭建好之前，就要能够有一个草图在心。而如果是对现有系统的改造，那么能在看过系统的文档（如果有的话）和代码后，就能总结出系统的架构特点。
架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。
开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。
5、 全面的技术资讯吸收能力和选择鉴别能力
作为开发人员出身，对于某一个具体问题的研究能力（虽然很多人总结为google能力），已经相当具备了。但是对技术资讯的全面接受和选择性深入了解能力，并且做出正确的判断，那些技术无非是厂家的噱头，而那些技术是真正可以用到项目，提高项目质量的好技术，这种能力确实至关重要的。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/fish88168/archive/2010/09/10/5875944.aspx
系统架构师知识结构
软件系统架构师综合的知识能力结构包括9个方面，即：
（1）战略规划能力。
（2）业务流程建模能力。
（3）信息数据架构能力。
（4）技术架构选择和实现能力。
（5）应用系统架构的解决和实现能力。
（6）基础IT知识及基础设施、资源调配的能力。
（7）信息安全技术支持与管理保障能力。
（8）IT审计、治理与基本需求分析、获取能力。
（9）面向软件系统可靠性与系统生命周期的质量保障服务能力。
作为系统架构师，必须成为所在开发团队的技术路线引导者；具有很强的系统思维的能力；需要从大量互相冲突的系统方法和工具中区分出哪些是有效的，哪些是无效的。架构师应当是一个成熟的、丰富的、有经验的、有良好教育的、学习快捷、善沟通和决策能力强的人。丰富是指他必须具有业务领域方面的工作知识，知识来源于经验或者教育。他必须广泛了解各种技术并精通一种特定技术，至少了解计算机通用技术以便确定哪种技术最优，或组织团队开展技术评估。优秀的架构师能考虑并评估所有可用来解决问题的总体技术方案。需要良好的书面和口头沟通技巧，一般通过可视化模型和小组讨论来沟通指导团队确保开发人员按照架构建造系统。
因此，系统架构师知识维度可以总结为"多层次+多方面"。所谓多层次，意味着系统架构师必须在体系结构、计算机软硬件与网络基础知识、信息化基础知识、信息安全与可靠性基础知识等基本功的层面上受过良好的教育和快捷的学习能力；还须在系统架构设计方法、设计模式、设计流程以及各种模型等方面有丰富的经验，广泛了解各种构件产品和技术并精通一种特定领域的架构设计；进一步，还须在系统架构设计实践层面，有自己的认识和理解，同时具有很强的表述能力；所谓多方面，意味着系统架构师在每个知识层面上必须具有技术、管理、心理和艺术等多方面的知识和能力。这和系统架构师的多角色特点是相关的。本书也正是从这个角度来介绍系统架构的知识体系，即从系统构件、模式和规划三个方面的技术基础、原理和方法的角度编写而成的关于软件架构师的基本知识结构和水平的教材。
---------------------------------------------------------------------------
从程序员到技术总监，分享10年开发经验
在中国有很多人都认为IT行为是吃青春饭的，如果过了30岁就很难有机会再发展下去！其实现实并不是这样子的，在下从事.NET及JAVA方面的开发的也有10年的时间了，在这里在下想凭借自己的亲身经历，与大家一起探讨一下。
明确入行的目的
很多人干IT这一行都冲着“收入高”这一点的，因为只要学会一点HTML, DIV+CSS，要做一个页面开发人员并不是一件难事，而且做一个页面开发人员更容易找到工作，收入比普通的工作还要高一些，所以成为了很多高校毕业生的选择。如果您只是抱着这样一个心态来入行的话，那阁下可真的要小心了。因为干IT这一行竞争本来就比较激烈，特别是页面设计这方面，能够开发的人很多，所以为了节省成本，大部分公司都会在需要的时候才招聘这类人员；在没有订单的时候，一些小公司还可能找各类的借口或者以降薪的手段去开除这类员工。而在招聘信息上常常会看到“招聘页面设计师，条件：30岁以下……欢迎应届毕业生前来应聘”这样一条，因为这一类工员对技术上的要求并不高，找应届生可以节约成本。所以在下觉得“IT行业是吃青春饭的”这句话只是对着以上这类人所说的，如果阁下缺乏“进取之心”，而只抱着“收入高，容易找工作”这样的态度而入行，那“IT行业是吃青春饭”将会应验了。
选择合适的工具
JAVA、C#、PHP、C++、VB……10多种热门的开发语言，哪一种最有发展潜力呢？其实开发语言只不过是一个工具，“与其分散进攻，不如全力一击”，无论是哪一种开发语言，只要您全力地去学习，到有了一定的熟悉程度的时候，要学习另一种的语言也是轻而易举的事情。开发语言主要分为三大类：
1. 网络开发
现在网络已经成为世界通讯的一座桥梁，好像Javascript、PHP、Ruby这几类开发语言大部分是用作网络开发方面。
2. 企业软件开发
JAVA、C#、VB这几类开发语言都实现了面向对象开发的目标，更多时候用于企业系统的开发。
3. 系统软件
C语言、C++、Objective-C这些软件更多是用在系统软件开发，嵌入式开发的方面。
当然，这分类不是绝对，像JAVA、C#、VB很多时候也用于动态网站的开发。在很开发项目都会使用集成开发的方式，同一个项目里面使用多种开发语言，各展所长，同步开发。但所以在刚入门的时候，建议您先为自己选择一种合适的开发工具，“专注地投入学习，全力一击”。
明确发展方向
当您对某种开发语言已经有了一定的了解，开始觉得自己如同“行尸走肉”，成为一个开发工具的时候，那您就应该要明确一下自己的发展方向了。
平常在公司，您可以看到做UI层的开发人员大多数都有20多岁，他们充满干劲，而且没有家庭负担，在两年前ASP.NET MVC 、Silverlight等刚出现的时候，他们可以在晚上回家的时候买几本书或者直接上网看看，研究三五个星期以后，对需要用到的技术就已经有一定的了解了。而年过30的人多数是已经成家了，他们每天9：00点上班唯一的希望就是快些到6：00点，能回家吃饭。吃完饭只想陪孩子玩一下，看看孩子的功课，对新增的技术缺乏了学习的欲望。所以很多接近30岁的程序员都有着一种逼迫感（包括30岁时候的我自己），再过几年应该怎么办？这时候，您就更应该明确一下目标，努力向自己的发展方向前进了。归纳一下，可从下面几项里选择适合自己的一条道路：
1. 从技术向业务过渡
在国外，很多发达国家都很重视人才，一个高级的程序员与一个Project Manager收入相差一般不超过15%。但中国是世界上人口最多的国家，国内人才众多，所以人才滥用的情况经常可以看到。一个小公司的开发部里面经常会见到新面孔，但PM却不会常换。因为做老板的对技术是一窍不通，依他们看来只到拉住PM的心，那技术方面方面就能搞得定，至于技术部要换人，他们根本不需要费力气去管。所以从一个技术员过渡到一个PM是向前发展的一个选择，但开发人员也需要知道，要成为一个PM不单单是使用技术，而更重要的是对管理方面的认识。一个PM主要的工作是组织团队，控制成本，管理业务，控制项目进度，与客户进行沟通，协调工作，定期进行工作报告等。所以要成为一个成功的PM更要重视组织能力，PM必须能提高团队的积极性，发挥团队所长，在有限的开发资源前提下为公司得到最大程度上的利润。成为一个PM后，通常不需要直接接触技术开发，而着重管理的是业务发展，但PM对技术也需要有一定的了解（在下曾经为PM对技术了解的必要性写过一篇文章，得到很多支持但也惹来不少的争议）。在这里我还是要强调自己的观点：要成为一个成功的PM最重视的是管理能力，但对技术也应该有足够的了解，因为这是与团队成员沟通的桥梁，只有这样才能与整个团队的成员有着紧密的结合，让团队成员感觉到他们自己存在的意义，从而调动团队的积极性，而不是漠视技术人员的存在。技术并非成为一个成功PM的充分条件但却是必要条件！
2. 从程序员向技术管理发展
其实一个Team Leader的职责与Project Manager相像，但Team Leader更着重于技术开发方面，通常一个大型项目都会有一两个开发团队由Team Leader带领，负责开发核心部分，而其它部分分派给不同开发小组或者分派给外包公司。在网上常看到几句话，贴切地形容了PM与TL的区别：“技术人员乐于被领导；但他们不喜欢被管理，不喜欢像牛一样被驱赶或指挥。管理者强迫人们服从他们的命令，而领导者则会带领他们一起工作。管理是客观的，没有个人感情因素，它假定被管理者没有思想和感受，被告知要做什么和该如何做。领导是引领、引导，它激励人们达成目标。领导力是带有强烈个人感情色彩的，它不是你能命令的，也不是你能测量评估和测试的。”
无论是PM与TL，对业务与技术都要有深入的了解，只是PM更侧重于业务的管理，盈利的多少，风险的大小等等，而TL则侧重于项目的成本，开发的难度，软件的架构等技术方面的问题。在某些人眼中，技术与管理就像鱼与熊掌，不可兼得，但依在下看来，两者却是秤不离砣，密不可分。只要及时提升自己对技术与管理的认识，不断地向深一层发展，要从程序员提升到技术管理人员只是时间的问题。打个比方，一个普通的.NET程序员，开始可能限制于ASP.NET的页面开发，但一旦他有了发展之心，他自然会对ASP.NET MVC、Silverlight、WinForm、WPF这些UI的开发手法感到兴趣，学习不需要多少时间，他可能就会认识这些UI开发只不过是一些工具，其实在开发原理上没什么区别。接着他就会向深一层的通讯模式进行了解，认识TCP/IP、Web Service、WCF、Remoting这些常用到的通讯方式，这时候他可能已经感觉到自己对开发技术有了进一步的了解。进而向工作流、设计模式、面向对象设计、领域驱动设计、面向服务开发等高层次进发，最后成为技术的领导者。上面只是一个比喻，但要注意的是，在学习的时期必须注意的是与同事之间沟通，很多的开发人员喜欢独来独往，开发的项目总想一个人搞定，不受外界的干扰。但要明白，就算你有天大的本事，一项大型的项目也不可能由你一个人全扛着。所以团队的合作性与同事间的沟通是必要的，这也是成功一个TL的必要条件。
3. 单方面向技术发展
能成功进行技术开发的尖端人才，这是在下最向往的工作，却也没本事登上这个位置。很多从事开发的人都会认为，业务总会带着“金钱的味道”，老板从来不管开发是否合符开发原则，是否经过必要测试，他们只会在客户面前无尽地吹嘘，项目到期能成功交货，只要不出什么大问题那这个项目就算成功了。其实我们也要明白：开发项目最终目标是为了赚钱，在开发过程中对项目成本的限制和效率的控制这也是必须，所以这才需要管理人员对项目进行管理。但开发人员也很想避开这“金钱的尘嚣”，全心投入到技术的世界当中。所以对技术有着浓厚兴趣的人，往往会深入地研究某一项技术，成为技术上的精英。但在这里说一句令人心淡的话：中国已经属于是世界上第二大经济体同盟国，但国民生产总值主要来源于第三方加工产业方面。中国可以说是人才济济，但却在高新产业上却比发达国家落后。这几年的确看到我们国家在高新科技上有着质的飞跃，但跟欧美发达国家还有着一段距离。所以想在中国成为尖端技术的人才，无可否定比在国外要难。依在下看来，要想成为尖端的开发者，必须对C、C++、汇编语言、嵌入式开发、Windows API、Linux API这些底层技术有着深入的了解。要知道解JAVA、.NET……等这些之所以称为高级开发语言，并不是指它们比C、C++、汇编语言更高级，而是指它们封装了C、C++等等的功能，更适合用于企业软件的开发，使开发变得简单。但如果要开发一些底层的软件，大型的系统的时候，就必须用到C、C++、汇编等开发语言，这是成功尖端人才的一个条件。
确定未来的目标
人是从历练中成长的，古人云：三十而立，形容的不是一个人的社会地位，经济来源，而是形容一个人对未来的目标，对人生的意向。要成为一个成功人，就应该早日为自己定下长期的发展目标，作为一个开发者也当如此。随着人的性格，取向各有不同，大家为自己所选择的路也有不同：
1. 自立门户，勇敢创业
快30岁了，很多人会认为要想真正赚得了钱，就应该自立门户，为自己创业建立一个基础。像北京、上海、广州
这些一级城市，要买房子，一手楼基本要在2万~4万元/平方米左右，而在一家普通的IT公司当上一个项目经理，基本收
入一般都在1.5万~3万之间（除非在大型的跨国企业内工作，那另当别论），要买一间100平方米左右的房子，就算不
吃不喝也几乎要10年的年薪，所以选择自主创业，是很多IT开发人员的一个未来目标，想要达到这个目标，就应该更
多地把业务作为重点。不可否认的一件事，在中国社会里很多时候讲的是“关系”，即使这30年的改革开放使中国的经
济蓬勃地发展起来，但几千年来留下的歪风还是不能完全的磨灭。所以想要创业的人事建议你要多跟客户打好关系，
与合作伙伴保持互利互动的模式，这将有利于日后事业的发展。
2. 急流勇退，退居二线
这也是不少人的选择。很多人在有了家庭以后，感觉到压力太大，人的一生并非只有事业，他们想把更多时间用
于对亲人的照顾，对孩子的关心上。所以很多人会选择一份像系统分析、系统维护、高校教师、专业学院讲师这一类的
工作。收入稳定，而且往往没有一线开发人员那么大的压力。
3. 不懈努力，更进一步
无论你是一个Project Manager或者是Team Leader，如果你想继续晋升一级，那还是会两极分化的。从一个PM到
一间公司的管理层，那所面对的事件会有很多变化。一个公司的总经理，要管理的不再是一到两个项目的成本，而是
整个部门的运作，整间公司的业务流程，所以要肩负的任务会更重。在下曾经有一位上司彭博士，他是企业的最高领导
人，年薪超过三百万，而且在报纸杂志上也曾经亮过相。平常只会在某些会议上轻轻地亮下相，说两句讲词，平常的
公司运作与业务管理都不需要他直接执行。这并不是说一个作为管理层很清闲，因为他们要面对的是更多的社会关系，
与公司合作企业的联系上。这跟一个PM的工作有很大的区别，所以要从一个PM晋升到管理层，那可是要付出更多的努力与汗水。
如果要从Team Leader上升为一个技术总监，那工作的方向也有所改变。像之前所说：一个TL可能更重视的是技术
层面，讲求与团队之间的互动合作性，更注重的是开发的完善。而一个技术总监就无需要直接参加某个项目的开发，而注
意的是开发的效率与成果，如何合理使用有限的开发资源，控制开发的风险和可能带来的效果。
发展感受
经历了8年多时间，在下从一个程序员到一个项目经理，之间经过很多的曲折，但因为每一个人的际遇都有所不同，
所走的路也有不同，正所谓条条大路通罗马，成功的路不止一条，在下也不想令各位误解，而只想为大家说一下我的发
展方向。如果您是一位开发人员，“程序员->架构师->Team
Leader（Project
Manager）->技术总监”是一条不错路，这也是在下选择的路。在我国，想要进一步提升自己，无论你想是以技术为重点
还是以业务为重点，都离不开管理二字。在一些大型的企业，一个团队往往会配备一个PM与一个架构师，尽管两个人
负责的任务各有不同，但你会看到一个架构师的收入往往不如一个PM，PM往往是这个团队的核心领导者，是关键人物。
因为公司能否赚钱，PM有着重要的作用。PM与TL并没有绝对的区别，而且在一些中小型企业，一个开发团队只有3~5人
，一个TL往往会兼备业务处理、成本控件、架构设计、开发管理等多项任务。所以在下会把Team
Leader与Project
Manager定于同一层次，一个公司的老板往往不会知道团队的架构师、程序员是何人，而只会向PM询问项目的进度，所以只
有晋升到这个层次，才有机会进一步提升管理能力，让自己有上升的空间。至于要成为一个技术总监，那要求就不再单单是对
单个项目的管理，而应该更则重于新兴技术的引用，开发资源的合理利用，对开发项目敏捷性的处理等等，对此在下也在试探当中，未敢多言。
与编程牵手 和代码共眠 从程序员到技术总监
从业IT十年,从程序员成为技术总监,现在回头看一看,这条路也伴随国内的IT一起风雨兼程10年,对IT技术由其是IT的纯软件开发这一块
,向即将要从事软件技术研发的朋友谈一谈我的看法:
一.认清当前IT形势,选择合适的技术方向和技术起点
估计大家都多多少少知道,这个IT行业知识的更新很快,竞争很急烈.
如果你对自己以后发展的方向在从业前有一个清析的计划或认识,相信你会比别人走得更好,走得更远,赚的钱也更多...呵呵
IT软件从业的方向,一般都会有这些机会:产品售前(市场,业务),产品开发(编码,设计,测试),产品售后(支持,实施),产品管理(项目管理等)
A.产品售前(市场,业务)
要从事这一块的工作,主要是在软件开发的前期(无产品),或者合同签订前期(有产品).
一般要求对相关的业务和技术都要求很高,这可不仅仅是要求人际关系,交际能力.
要想别人买你的产品,你得以专业的产品品质为后台,以专业的谈吐,专业的技术和专业的业务理解能力来取胜.
从业者要求:
要求从业者要有一定的社会经验,技术经验或业务经历,或一定的社会圈子和交际能力.
建议:
刚刚从学校毕业的朋友或不符合上面条件的朋友最好要考虑清楚了.当然这世上没有什么绝对的东西,就看你自己了.
现实情况:
据我所了解的,作这一块的都会是公司一些高层(有关系,有经验)和业务专家或特殊背景的人员等.
B.产品开发(编码,设计,测试)
这一块的工作,当然是IT从业大军的主力了,但也得要考虑清楚.
如果你要作设计师,或测试,最好先作一段时间的编码,
一个好的设计师是不可能不精通相关技术平台的!
国外好的测试人员也几乎是从开发人员中选出来的,基至是软件开发高手.
a.代码编写
在这一个职业选择范围内最好是从代码编写开始.当然你也可以先作测试,看看人家是怎么写代码的是如何来作这个软件的,
借用人家的测试经验也可以,以后有机会再来编一段时间的代码也行.
有时自己去写一个软件也可以,所以作编码和测试都是一个双向交互的.而不是编码在前测试在后的.
作代码的编写最好自己先看看别人的软件,或由一些高手带着指导一下,现在技术的学习都不成问题,关健是要连成一条线来学习和思考就会有一定的局限了.
所以要熟悉整个的项目流程或业务流程不是靠个人编码或在培训班学一下就能解决的,个人的技术学习和培训班大部分只能解决技术的学习问题,但作软件不仅是要技术呀
三分技术七分业务说得不为过,业务的学习也是一个开发人员所要必备的,如果你在不熟悉业务细节之前建议你不要急着去写代码,那样肯定会是对以后软件的影响很大.先要熟悉一下业务.
所以软件开发人员掌握一门技术平台和语言是必备条件但同时也必须要有一定的业务知识,这样才是一个合格的软件开发人员.当然精通软件编码,懂设计,熟悉业务,熟悉软件项目开发流程的软件开发人员是优秀的,那是高级研发人员的必备条件.
如果你才入门或转行或刚毕业,建议从基础的代码编写开始,跟着高手或找一些成熟的项目多学习,
b.软件设计
当然这个职业要求行业的经验,技术经验都要有一定的基础,薪水一般也会高很多,所以也是一些开发人员热烈追逐的目标.但一个好的设计师不是一二年所能练就的,精通编码,熟练设计模式和公司所采用的技术平台,熟练一些设计理论并实际多运用,熟练公司业务,其实这个层面的压力也最大,一个好的软件在设计上的比重几乎要占到七成.
建议刚毕业的朋友或软件初学者不要在这一块来凑热闹,即使你作成了设计师,但在我眼中看来你也不是一个合格的设计师...当然你有这个能力来作设计师就要恭喜你了.
c.软件测试
熟练软件测试的各种理论或实际运用,也要熟悉编码技术及相关的技术平台,熟练掌握业务.
软件测试中一般都会有:
单元测试,要求你熟练开发技术进行跟踪调试,也就是白盒测试了
集成测试,对整个项目流程的测试,要求掌握业务知识,对设计的软件能作功能上的测试或压力测试等
,属黑盒测试
确认测试,对业务要很熟悉,测试软件是否完全满足了客户的业务需求.
总体建议:
1.熟练一种技术平台,熟悉一种业务
刚入门的朋友很容易犯的一个毛病是,熟练:VB,VC,.NET,JAVA,C++,C,Dephi,PB,几乎市场上要用的他全部会,唉,如果我看到他的简历上有这么一句话,这个人肯定不会在我考虑的范围了.
现在全球用得最广最多的技术平台体系也就三大体系:
sun的J2EE技术体系(JAVA):在高安全性,高性能上更胜一步,中高端市场上用得多
微软件的技术体系(C++,.NET,c#,VB):在中,低端市场占绝对优势,也是全球个人电脑操作平台用户最多的.
CORBA技术体系统(一种分布式技术体系和标准),
全称:Common
Object Request Broker
Architecture：公共对象请求代理结构,可以用不同的编程语言写成，运行在不同的操作系统上，存在于不同的机器上。
一般介于底层和上层管理软件之间,
其他的还会包括底层开发:C,汇编,属纯底层的开发,当然要求技术的起点和业务背景更强,最好是学的专业:电子电气,嵌入式行业,机械制造,数据采集等...
看中你想要从事的技术体系,选好一门语言工具,好好上路吧...:)
永远要记住:你什么都想学,你什么都学不精
2.从基础入手,不要好高鹜远,眼高手低,要与实际结合
B.产品售后(支持,实施)
这一块对于开发技术的要求来讲不是那么明显,主要工作会在软件开发后的工作,跟客户打交道多,但更多要求体现在对业务的把握和客户的交际上.
有些软件产品业务比较成熟,如果参与这一阶段的工作,可以快速学习很多的业务知识,积累客户交往的经验
建议:刚入门或刚毕业的朋友,可以在这个工作上多选择,等待时机成熟,立马杀入软件的开发或设计阶段,当然,这一块的工作作得好也不容易,如果适合你作,
工作环境或工资都不错你就大可不必多想了...
C.产品管理(项目管理等)
这一块的工作主要体现在管理上,当然适合有一定经验或管理能力的人员来担当,
最后的技术从业方向总结：
技术型:先选择好一种技术平台,熟练一种开发语言和数据库...专业专注的搞几年再说
技术+管理型:如果你有一定的技术经验了,并且人际交往,管理能力不错,你就可以向这个方向发展
技术+业务型:精通一种技术平台,精通一种业务,好好搞,这种人才最受欢迎...
管理型:
如果你有一定的社会经验,从业经验,如果人际交往,管理能力还可以,老板也喜欢,就搞这个
业务型(市场):如果你对业务很感兴趣,跟客户的交往等也不错,你可以选择了,有适合的专业技术就更能锦上添花了
技术+市场+管理:老大的位置....:)
-------------------------------------------------------------------------------------------
校园级别的程序员的标志：
代码中最多的是嵌套if(null == xxx)，还要告诉你，null必须写在前面，我靠。
防止把==写成=，c语言时代常犯的错误。由于null不能做左值，在写=的时候出现编译错误。一般来讲，在java中，由于boolean和其他类型不会作隐式转换，因此这么写没有意义。
写着写着突然想起来这么个代码：
Boolean b = true;
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、能在编译器做的事就不往运行期放，哪怕会影响开发的灵活性
--------------------------------------------------------------------------------------
架构师，当然是脑力劳动者，但是，同样是脑力劳动也存在重大的差别。有一类脑力劳动的成果，是比较容易被评价的。或者能够判断其对错：比如考试的分数；或者能够比较其高下：比如两个人下棋分出输赢；或者能够交由市场来判断：比如某种UI/UE设计，我们可以通过数据统计，了解其受用户欢迎的程度。
但是，架构设计只是软件开发过程中的一个环节，而在这个多人协作的场景中，我们很难单独评价架构的优劣。由于硬件、软件、部署、人员、测试、用户、市场等众多的差别，即使是非常相近的两个系统，我们也很难判断两个架构孰优孰劣。比如：eBay的架构与Taobao的架构哪个更加优秀？在交付拖延的时候，我们可以将问题归咎于开发团队的效率低下。在出现质量问题的时候，我们可以将问题归咎于测试团队的疏忽大意。在负载撑不住的时候，我们可以将问题归咎于运维团队不够专业，甚至是竞争对手的DDoS攻击。那么，在出现什么样的问题的时候，我们可以将责任归咎于架构呢？
所以，现状就是：架构师是一个很难做好的职业。但是，从某种意义上来说，又是一个非常容易混的职业。（当然，混是另一种需要持续修炼的高端技能。）因此，架构师也是特别需要强调自我修养与职业道德的职业。
什么是架构？什么是架构师？对于架构的定义，有很多种，我比较同意的一种定义是：“架构是一组关键决策”。这样的决策包括但不限于：使用什么操作系统、语言、框架与类库；是否在架构中使用某种全新的技术方案；优先考虑或满足哪一方面的需求以及如何在技术上实现这一点；更进一步的，面对一个不断发展的系统，哪些部分需要优先重构or优化、哪些决策需要重新考虑甚至修改；再进一步，某些前瞻性的考虑，也是架构决策的一部分，等到问题发生再来解决，同样是架构方面考虑不周。
能够做出这些决策的，就是架构师。或者说，在一个团队中，实际的最终决策者，就是事实上的架构师。无论他被赋予什么样的头衔。在一个团队中，我们总能找到这样的角色（无论他做得是不是称职），而一个优秀的架构师，就是通常能够做出“较多”正确决策的人。
架构师的工作是什么？仅仅做出决策是不够的，我们可以从时间线上来观察：在做出决策之前，架构师需要足够了解自己的“可选项”，无论是用户的实际需求，还是最新出现的技术和框架，并且都得要有足够深入的理解（否则就是在拍脑袋做决策）。这时，架构师的角色，是一个“研究者”。
在综合各项因素，甚至是相互矛盾的各种需求之后，在考虑到团队的实际能力与交付压力之后，在平衡了先进性与可靠性、扩展性与稳定性、重要性与紧迫性之后，架构师做出了一组决策。这时，架构师的角色，是一个“设计师”。
为了确保自己架构设计能够被正确地实施和贯彻，架构师需要与研发团队密切配合，或者说服、或者引导、或者辅导、或者鼓动、甚至需要某种“强有力的推进手段”，这对于架构师的「硬实力」与「软实力」都提出了很高的要求。这时，架构师的角色，是一个“Top Coder”。
在某些大公司，架构师还需做很多的文档工作，这些文档并不是交付给开发团队的说明性文档。而是某种向上级证明某某方案可行，某某架构有效的证明性文档。这时，架构师的角色，是一个“说服者”。
从上面的描述，我们也可以发现，架构师像是一个千面人：需要与上下前后左右的不同角色打交道；多面手：需要了解甚至掌握诸多不同的知识和技能。要想做好这个工作，提升自我修养是根本之道！
什么是架构师的自我修养？ 1. 以理解用户为荣，以想当然尔为耻
架构师不是产品经理，不是市场人员，不是客服人员。但是，如果只懂技术，只考虑技术，不能深入的理解用户的需求（强调一下，用户的真实需求！），就会做出“纯粹追求技术先进性”的想当然尔的架构出来。
2. 以脚踏实地为荣，以夸夸其谈为耻
架构师当然需要很强的表达能力，甚至还需要有忽悠能力。但是，无论是表达还是忽悠，都必须以“实力为基础”。如果不能脚踏实地，积累实力，只会夸夸其谈。那就相当可耻了。
3. 以身先士卒为荣，以指手画脚为耻
还是那个经典的台词“兄弟们跟我上”与“弟兄们给我上”的区别。如果对于一些困难的问题，架构师自己都搞不定，却摆出一副胸有成竹的表情：“这不是很简单的吗？你到网上搜一下嘛，资料大把大把的。”这种做派，就很令人不齿。
4. 以实践检验为荣，以道听途说为耻
如果某种技术，架构师自己都没有做过评测，没有看过框架代码，没有在过去的实践中应用过。却因为一篇文章，一个讲座，甚至某个大公司曾经用过这样的证据，就将一种技术引入到项目之中。这样的决策，很少有不失败的。
5. 以先见之明为荣，以后知后觉为耻
“过度设计”当然是一个贬义词，但是架构师一定要有前瞻能力。不能等到火烧起来了，再去救火。虽然在企业里，的确存在“救火英雄升迁快”的现象。但是，一个优秀的架构师，应该以“消除隐患于无形”为荣。
6. 以兼容并包为荣，以独断专行为耻
在架构领域，很少有唯一解、最优解。大多数时候，我们只能在多个各有优劣的方案中，反复权衡，考虑取舍。这时，开阔的视野、开放的心胸，就显得尤为重要。如果一味的独断专行，听不进团队里其他同事的意见（尤其是那些学习了乔布斯的架构师），就会非常危险。
7. 以主动学习为荣，以固步自封为耻
技术的进步实在太快，曾经有一种夸张的说法：“平均每天诞生一种革命性的、颠覆性的技术”。虽然有很多新技术，都在如此宣称，作为架构师，却必须不断地主动学习，了解，甚至在某些领域做一些初步的尝试。这样的过程，在架构师的整个职业生涯中，都无法停止。一旦产生了“固步自封”的念头，这个架构师也就“不过尔尔”了。
8. 以勇猛精进为荣，以疏忽懈怠为耻
架构师是一份困难的工作，更加重要的是：随着架构设计的完成，架构师的工作，才刚刚开始。接下来的任务，会非常琐碎，也许会更加困难。这份工作的主题是：“架构看护”尽可能保护架构，不会随着时间的推移，随着特性的增加，渐渐变得腐化。很多最初设计得相当优秀的架构，到最后变得不堪入目。说到底，还是要怪架构师没有能够坚持自己当初的决策。
如何提升架构师的自我修养？在《中庸》里，子曰：“好学近乎知，力行近乎仁，知耻近乎勇。知斯三者，则知所以修身；知所以修身，则知所以治人；知所以治人，则知所以治天下国家矣。”
简单的翻译解释下：好学就能显得有智慧（至少能有知识），力行就能不脱离群众（因不忘本而能具备仁慈之心），知耻就能守底线（有所为有所不为之勇）。能做到这三点，就算是懂得如何提升自己的修养了。懂得如何提升修养，才能懂得如何驾驭团队。懂得如何驾驭团队，才能创作出真正伟大的，甚至风行全球的软件产品来。
------------------------------------------------------------------------------------------------------