新项目中需要学习的东西

当前所在的项目算得上是一个银行系统的特大型的项目了，有很多的东西可以学，这个项目上承载了很多的思想，方法，技术，管理的内容。在工作实践中需要透过现象看到本质，需要挖掘问题，多见识不同的东西。

将理论联系实际，使理论和实际紧密结合起来，多实践，多深挖，多看书，看博客，多讨论，多记录，多写。

能够在实际中分析和解决问题，并且形成这样的思路和结构化的方法。

能够联系起来，各个部分，知识点，思想，方法。

学习的能力

对于一个步骤繁琐的工作一定不要试图相信你自己的经验和记忆力，务必是要按着操作步骤和检查点，一步步的做，很多时候最后发现问题都是前面没有按操作步骤导致的。（摘自人月神话http://blog.sina.com.cn/s/blog_493a84550101frig.html）

大项目锻炼人，但是如果你不主动去思考，主动去承担更多的工作事务，主动的去关心更多的事情，那么也无法真正锻炼到。大项目给你的是足够的项目信息量，足够复杂的外围环境，足够多的知识和信息，那么除了在积极主动以外更加重要的往往是好问和多思，通过大项目实践机会将知识点串接起来。多想想如何做的更好，如何更加有效率和保证质量。（摘自人月神话http://blog.sina.com.cn/s/blog_493a84550101fvkm.html）

分解是理解和认识事物，解决问题的关键方法，而分解的另外一个目的就是促进了在解决问题过程中的并行任务执行。例如架构设计一方面是解决问题的关键转换，同时架构设计又是后续设计开发能够并行，并行是基于架构接口规划为基础，而不是没有架构分解，接口设计就乱并行导致后续无法集成。

我们讲的顾问能力往往是一种综合能力和素质，有时候看上去往往只差一点点，但是往往却是量变到质变的差距，空间上看差距不大，但是需要的时间上锻炼往往却很长。这种能力是独立思考，系统思维，分解整合，演绎归纳的能力。在于面对新问题的时候独立分析和解决的融会贯通能力。既把控全局高屋建瓴又重视细节的能力。在于长年的实践积累到经验和思维转换的能力。在于理论指导实践又实践反刍理论的能力。（摘自人月神话http://blog.sina.com.cn/s/blog_493a84550101fuko.html）

为之于未有，始之于未然，一个人对风险需要有两个关键能力，一个是预知和识别风险的能力，一个是化解风险的能力。（摘自人月神话http://blog.sina.com.cn/s/blog_493a84550101fxo6.html）

最近在工作上特别忙，但是忙的时候也不能停止思考。任何当前的忙往往都是原有的风险意识不够和准备不足，没有认识到事物本身的复杂性，没有及早的对风险进行识别和环节。有时候忙的时候暴露问题是好事，问题暴露的需要的就是反思原来的实践和做法，真正能够持续改进，否则只有陷入持续的忙乱。前面已经谈到，很多时候不是没有意识到问题和风险，而是极强的本位主义影响，不关自己的事情一定不关心，那么对于一个大项目整体而言，如此多的相互约束和依赖，接口和协同，大家都是这个思想的话真正就很难做好了。

我原来谈到过，你原来已有的很多工作经验都将在后续的工作和项目实践中应用到。这些实践和经验积累都是相当重要的。我们强调的只是不要在同一重复性的技术和项目上进行积累，真正的接触到更多的技术，更多的项目，更多的客户，只有项目实践一线的经验，项目实践中问题的分析和解决对你来说才是最宝贵的。技术本身积累可能容易，但是项目实践经验的积累，项目实践中关键问题诊断和分析技术的积累却是不容易的。对于大项目实践来说，一个是需要的严格的技术积累，一个是需要业务的积累，否则来做一个优秀的技术人员都困难。

做一个专业领域的业务系统之难，不是体现在通用的软件开发技术上面，而是体现在对业务和模型的熟悉度上面。对业务和模型不熟悉，知其然不知其所以然，开发出来的全部是单个功能点的增删改查的话，最多也就是把自己的开发能力练了下，而更多需要的则是系统分析和架构能力。大型业务系统的复杂度主要体现在两个方面，一个是业务和组件间本身的交互和协同复杂，一个是体现在底层的数据架构和模型的复杂。我们为何说类OA类的业务系统简单，原因就在于上面的两点复杂性都不在。正是由于上面两点复杂性都不在，工作流模型本身又可以统一建模和抽象，因此类OA类系统是最适合建设为快速开发平台类的应用。

大家都有大项目实践的机会时候，有的人走的更远，有的人仍然在原地。机会对大家都是相同的，重点还是自己的思维和意识，如果时刻将自己约束在一个很小的范围，经常被动的接受工作和任务，不关注全局，不关注内在机理，凡事都不深入思考一步，那么真正能够得到大的提升和锻炼是相当困难的。（摘自人月神话http://blog.sina.com.cn/s/blog_493a84550101g4at.html）

个项目要能够真正成功，可以业务或技术能力差一点，但是必须要有风险意识，全生命周期的风险意识。

基于角色的访问控制RBAC权限模型和流程引擎模型是做任何应用系统的基础，也是最基础的共性基础能力组件。

异常和日志往往不可分，虽然说日志包括了各种操作级和数据级的审计日志，但是对于任何异常处理一定涉及到日志的记录。对于日志记录优选方式仍然是直接log后结构化入数据库的日志表，但是这种模式下如果出现数据库异常往往会无法记录日志，因此还得考虑在出现数据库异常的时候日志能够记录到应用服务器上的日志文件上面。对于日志强调的是分类和分级，对于异常则需要考虑应用的各个分层上异常的处理和不屏蔽任何异常，对于日志加异常目的则是快速的分析和定位问题。如果达不到这个目的，那么我们在这块的处理就存在大缺陷。

对于性能问题则更加复杂，对于一个大项目而言，往往从一开始的IT基础架构选择，应用架构和开发框架的选择，应用总体的架构设计就决定了性能的好坏。但是我们往往犯错的地方确是在架构设计和开发阶段忽视了性能风险和驱动，而把所有的风险和问题都遗留到最后通过性能优化来解决。这导致的问题就是最后出现的性能问题一发不可收拾，只有推倒重来。

对于分析和设计，更是一个有意思的话题，有时候我们谈没有分析和设计，有时候又谈过渡设计和超前设计。而真正需要的往往则是最适用的设计，即满足当前的业务需求又有一定的扩展性和前瞻性。不论是谈需求和架构，里面可能都涉及到定义，分析和设计等方面的内容。如需求定义，需求分析，需求设计和开发；架构分析和架构设计等。但是要意识到的是需求的目标始终是通过各种形式化的方法来描述和定义清楚现实世界，而架构的核心则是要通过模型来抽象现实世界。

我们在进行抽象和可扩展性设计的过程中，会出现大量的元模型数据库，配置和模板库等，要注意到虽然这些数据库表结构可能一开始就定下来了，但是表里面的数据的准备，关系的建立仍然是分析和设计的过程。要知道，如果不做这些元模型库或表，那么往往就需要建立更多的各种支持扩展的特定表，这些元模型数据和扩展的特定表并没有区别，因此其本质也是一种设计。

不是大项目就能锻炼人，能够锻炼和提升自我的只有求知的欲望，对质量的一丝不苟，专注一件事情并做到极致的思维和意识。有的人缺的是态度，而更多的人缺乏的是思考的意识（摘自人月神话http://blog.sina.com.cn/s/blog_493a84550101ga5e.html）

对于意识首先不能和思考等同，我们每天都在进行思考和各种思维活动，你今天出门要带什么东西需要思考，解决一个问题需要思考，进餐馆点菜可能也需要思考，这些都是各种思维活动，但是这些并不是我们所说的意识。意识属于思考，但是意识只是思考中很小一部分的内容。如果要给意识一个简单的说明，则是在某个阶段或某个时间点，你需要去做什么事情，当你做了这些事情后可以使我们的产出物或结果持续改进，可以使我们个人的经验和能力持续提升，如果符合这个说法，那就是一种意识活动。

如果这个说法成立的话，那么我们就应该在空闲的时候有学习的意识，在解决问题后有反思的意识，在重复性的工作中有自动化的意识，在分析和诊断问题的时候有刨根究底的意识，在他人帮你解决问题后有一种审视自我知识缺陷的意识。这些意识和态度不同，态度可以帮助你持续的有责任心的做一件事情，而真正只有意识的转变才可能帮助你更加高效独立的做好各种事情，并持续的提升自我的能力。

每个人的潜力是巨大的，很多时候不缺在态度上，而缺在意识上，你可能一直在往前走，但是身后往往就有一扇门可以通达更加宽广的世界，但是你没有意识到。（摘自人月神话http://blog.sina.com.cn/s/blog_493a84550101gdfc.html）