我不是巴菲特，我错了！

首先感谢这几个月公司领导的关怀和帮助。这几个月来没有带动团队活跃起来，也没有使spens有个完美的结束。其实感到非常的抱歉和愧疚！不过个人觉得这几个月生活的还是蛮充实的。
1.SPENS项目使自己又熟练的使用了一次Eclipse的dump分析，解决了derby和Velocity内存泄漏，但这个项目里21个jar包里太多HTASH MAP的层层套用，WeakHashMap能最终完美解决内存泄漏，但我的提议被你们否决了。是的，我错了，可能有更好的办法吧，可惜我没有找到。看来真的需要巴菲特呀！

 

2.IBM的AppScan的运用。AppScan对于服务器安全有着至关重要的作用，首先它能查到Web2.0下面90%的安全漏洞，并且生成修复建议报告，它的运用能解决很大一部分安全性
问题。但是公司更关心的是信息传递中的安全。其实如果你真正当过黑客，你就知道查找你服务器端应用漏洞的攻击比中途拦截要容易的多。

3.OAuth探索，为了保障关键信息在网络传输中的安全我曾经在OAuth和https中权衡。没错，OAuth主要功能是第三方授权，我做的OAuth的两次交互例子也能起点安全的作用，至少我在200条/秒的测试下
没有看到服务器的瓶颈啊。https的性能只有普通http的30%左右。但领导们不太关心性能。是的，我也承认性能在还没有形成用户群体的时候是其次的考虑对象，但用户的感受度是至上的啊！我工作到今年有12年了，在12
年的IT生涯中，我只看到注重用户体验的公司起来了，不适合用户的公司倒下了。我记得我在中广瑞波的时候，黑龙江移动1.1亿用户总量，用户应用短信的延时从8秒减到了3秒以内，我们是多么的高兴！当我们为
7*24小时不间断提供服务而努力，当我们提出动态配置加载的时候。我们逐渐被雅斯拓、捷德等等这些巨人般的对手所尊重！但用户体验和性能在这里都被弱化了，这一切都显得不太重要了。领导们关心的只是“安全”。

4.Nginx的再次分享。是的，我一直是一个乐于分享的人，因为我知道分享的越多，你得到的也会越多（需要互动啊，就跟上台唱歌，下面麻木一片和掌声一片这心理是不一样滴）。我记得给组员们第一次分享就是从Nginx开始的。但是最终的分享没有带来我预想的共鸣。因为大家对：配置简单化、性能更优、配置更新后无需重启
等等的优点很漠然。我承认可能是我表达的不够优秀，清晰。但Nginx分享在梦想兄弟带来的是很多人的惊叹和赞赏啊！这又一次表明我在公司不入流啊。

5.代码的规范和质量不重要吗？我一直信奉一条就是软件质量是软件的生命，尤其在一个产品为导向的公司。对于代码的工整、清晰，注释完整我一直看的很重很重。这个观点是从06年进大唐十维软件园就坚定了的。因为进这家公司
开始的第一个项目就是伽利略渔业卫星计划-民用项目的设计和开发。在这里就开始了永恒的主题：质量与进度。在我的恩师晓林的带领下，我们有了自己的NIO框架（可能是最早的NIO框架），我们有了自己的文件队列（类似于后面ehcache）。我们有完整的单元测试，有清晰的注释和规范的代码格式。这使我坚信好的软件不是嘴上喊出来的，是用手一点一点敲出来的。以至于我敢说，在接下来所有的上线项目我的代码都能拿出来评审都能生成比较完整的javadoc。哪怕在中广瑞波项目最紧时候（移动OTA卡中央平台），代码曾写的很乱
但招标完后，我用了2周时间几乎替换了所有的注释和删除很多冗余代码。banq老师也说过：程序员写出代码是给机器读的，工程师写出的代码是给人看的。虽然最后中央平台项目招标失败（我们设计和质量评分在六家企业中排第二，但排名第一企业采取了零报价，我日啊这也行！），
但至少我们的软件质量上了一个层次，我们受到了移动研究院的关注和重视，我们也逐渐从竞争对手中脱颖而出！其实我很想让公司代码也和原来公司一样有个质的提高，并且对coreapi做了个较工整的版本，希望所有代码按这个模板规范起来。但大家对代码质量和注释好像漠不关心，
这一直困扰着我。也许是自己魅力不够吧，也或许是方式不对。（公司领导说过需要有巴菲特的感召力，我承认我离巴菲特的能力还差的太远了！）

6.对于设计的看法。我一直认为设计不用死搬硬套。对于一个很小项目需要都执行概要设计->详细设计->代码开发->测试   这个流程吗？我觉得对于功能简单、周期短的小项目概要设计一定下来就可以开发了。但是我又错了，领导们很看重这套流程，尤其重视详细设计，
我承认详细设计也很重要，但不是必需的啊，理由有三:

     1.详细设计对于交付及其重要，关键这个项目没得交啊。

     2.详细设计对于出产品手册和运维手册很重要，需要产品部和运维部通过详细设计写出手册。我们应该也没这需求。

     3.详细设计无法和程序代码保持一致性，太多精力花在详细设计上还不如花在注释和javadoc上。

其实javadoc可作为详细设计附件一直存在。并且可以和代码保持一致。

7.对于测试的看法。我一直比较欣赏测试驱动，以测试来保证代码的质量和低bug率。我也一直往这方面努力。其实我想在我的GNum中引入测试驱动，即先有JUnit单元测试代码再有业务逻辑代码。因为我认为代码质量重要的同时，测试也同样重要，并且意义深远。但是我可能又想多了，领导说看重的是设计（详细设计最重吧），测试不用我做啊。天啊，公司原来项目bug率这么高，而且一改东西原来正常功能不是也出问题吗？这就是没有边界测试，没有递归测试导致的啊！不重视测试能行吗？在没有用户量的情况下就频频出问题，如果用户上10万、20万、50万、100万呢？这样代码能挺住吗？能过关吗？能交付吗？是的，我不得不承认公司领导可能有更好的应对方法，我想的多余了！

8.对于纪律的看法。无规矩不成方圆，敏捷开发核心之中也强调纪律重要性和严肃性。其实对于管理者没有纪律约束，没有制度约束何谈管理？管理又是管的是什么呢？我记得我在中广瑞波时候带北邮研一和研二的学生，刚开始他们对我都或多或少有些抵触，可能是一流大学的优越性，也可能自命不凡吧。我在开始的确遇到了不少的困难，但
我向领导要来了给学生打实习分的资格并且一直不断分享工作中使用到的技术和思想。到最后大家都很融洽，并且每一个即将离开的学生都是感激不已的拿一顿大餐来报答我。看着他们有的进IBM，有的卓越的，有的进赛门铁克的，我由衷的祝福他们！但来到公司以后，领导没有给我任何权利来约束员工，我很被动，以至于任何东西都执行不下去。是的，
我不得不承认对于一个空降来的管理者，应该需要巴菲特式的才能，可惜我没有！

9.对于重构的看法。其实这个问题我在我的JavaEngineer高级群里和中国程序员联盟里都激烈的讨论过。我的观点就是：”真正的重构首先要：基于代码易读、工整、严谨，代码测试的完善，数据库设计的合理和科学。其次就是才能按模块的逐步重构和修改。"至少对于三个项目用一个库
数据完整性靠存储过程来保证的项目很难。数据完整性应该经历的3个阶段：
     1.存储过程（10年前）太落后
     2.外键约束（5年左右时间）成熟但不符合用户的行为习惯
     3.领域模型聚合（2年左右）比较超前，优点明显
我不得不激动的说，这种方式太落后了。我记得06年在大唐的时候就听说有个很牛的DBA（据说国内最早获得OCM认证的牛人），原来整个的项目都放到Oracle中包括对外提供所有服务。这位大哥都能轻松搞定，但随着神一般大哥的离去和用户量的激增，导致项目需要推翻重新设计。为了维护原有项目，请了3个DBA来代替这位牛人。我承认我们把数据库看的太重要了，所以我们需要分层设计来把部分数据库工作放到应用层上。因为这种过分依赖数据库方式真的已经过时了。NOSQL为什么兴起？为什么会有领域模型的设计？都说明了这点（大方向、大趋势啊）。对头，我不得不承认我又想多了，并且理想化了。可是我真的感觉这样项目的重构和我的理想有着天壤之别，我没有信心啊！是的，我再次承认了我不是巴菲特！

    基于上述简单的、粗略的表述我觉得我已经不适合这份工作，已经辜负了领导对我的期望，我更悔恨我为什么不是巴菲特？索罗斯也行啊！可惜我都不是，我只是一个普通的软件代码工作者，离开代码就心痒痒，一直天真的追寻着走自己的技术路线，并一直遵循着这样的综指：“代码质量、自动化测试的完善、纪律、必要的文档和详尽的计划才是软件的根基”
最后恭送商祺。就此别过！