我不是巴菲特,我错了!

首先感谢这几个月公司领导的关怀和帮助。这几个月来没有带动团队活跃起来,也没有使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.存储过程 太落后
2.外键约束 成熟但不符合用户的行为习惯
3.领域模型聚合 比较超前,优点明显
我不得不激动的说,这种方式太落后了。我记得06年在大唐的时候就听说有个很牛的DBA(据说国内最早获得OCM认证的牛人),原来整个的项目都放到Oracle中包括对外提供所有服务。这位大哥都能轻松搞定,但随着神一般大哥的离去和用户量的激增,导致项目需要推翻重新设计。为了维护原有项目,请了3个DBA来代替这位牛人。我承认我们把数据库看的太重要了,所以我们需要分层设计来把部分数据库工作放到应用层上。因为这种过分依赖数据库方式真的已经过时了。NOSQL为什么兴起?为什么会有领域模型的设计?都说明了这点(大方向、大趋势啊)。对头,我不得不承认我又想多了,并且理想化了。可是我真的感觉这样项目的重构和我的理想有着天壤之别,我没有信心啊!是的,我再次承认了我不是巴菲特!

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

企业不是实验室,企业需要的不是技术,是效益。

我原来的公司是一家互联网企业,可是研发团队只有4人(包括硬件工程师和DBA在内),一个250人的互联网软件公司,研发所占的比例居然如此之低。

好吧,我承认,一旦coreAPI稳定之后,想再给他升级是几乎不可能的事情,哪怕这个coreAPI是asp年代的产物,稍微修改之后就用在.NET 3.5上面了。

最近看了 血战长空,里面有个日本人这么说,两个国家打的就是工程师。
零式战机出来,可以打14:0

毫无疑问,楼主就是优秀的工程师。

其实你不要做所谓的巴菲特;你只要做你自己就好了,你已经够优秀了

我想说: 除了巴菲特,我们谁都不是巴菲特,我就是我,你就是你。
作为一个技术人员,随着年龄的增长,技术的集累以及我们持之以恒的努力,往往会赋予一定的管理职务,而我们技术人员往往缺乏“管理”的经验或能力,看看我们的职位名称:技术经理,项目经理,实施经理等等,何谓经理?经营+管理,经营谈不上,而管理又不行,那你就只剩下那点技术了,技术式的管理,严谨的逻辑,漂亮的流程,它并不是管理,它只是技术,所谓技术式的管理,它也只是我们想出来的而已。
我们换一种思维:把”经理“都换成”领导“,带领和引导你心目中的所谓的”下属“,你就能成为管理者。你认为为什么你的老板让你来当管理者?是因为你技术牛?牛人不可能一个人完成一个大项目,牛人不可能解决所有技术难题,你要想到:你的成功源自你,和你伟大的团队。
如果有5个人,技术都是一流,经验相当,而你是其中一员,并且不是管理者,你会乐意接受所谓的”权力“对你的作用吗?想想如果有这样的例子在你身边,那并不是因为你技术不如别人。以下一点看法:
1、你的提议被否决了,如果你认为是完美的东西,在别人看来它不一定完美,巴菲特善于倾听,总结,然后走向成功,成功之路永远不是一帆风顺的,看你有没有决心。
2、如果只有黑客才能明白的道理,我想你的老板不一定能明白,如果不需要黑客,那就是你没能讲明白,服务器的管理往往在服务中心有专人负责维护,也许会有更好的工具呢?
3、OAuth如果自己做验证服务器,成本将会很高,如果用开放的,在内部网络不通的情况下,服务将无法被访问。
4、麻木一片也许是因为真没什么新意,你以前的成功也许是基于某个环境,当然也许有人的因素,还是忘了它吧,或换成以他们感兴趣的方式去分享。分享往往是自己重新认识了一遍你分享的东西,你得到了,虽然没有得到你所想要的肯定,而那只不过是一点点的虚荣心罢了。

...
敏捷团队的核心是自我管理,你要来了打分的资格,失去的是你管理的能力,你教会了他们技术,却不一定教会了他们做管理,你的成员进了大公司,如IBM等,说明他们真的很优秀,你也要确实这么想,同时你还要这么做...那我们的组员将真的会很优秀,不信你试试。

以上一点见解,望兄么见怪,我从同样的道路走过来,也有同样的问题,我已意思到了这一点,并在改进和学习中,”领导“在于放下你技术的优势,进入另外一种优势(呵呵,还是虚荣心在作怪)。

佩服楼主的坚持和执着,谁说精细化的管理不叫管理叫技术,不敢苟同。技术12年,如果领导睿智,如果团队层次足够,不见得楼主会有这样的感慨。大家不觉得这样感慨是国内某些技术型公司或这个行业氛围的悲哀吗?在某个领域深耕多年后,依然抱有那份激情的人有多少?更多的是消尖脑袋的适应,个性的泯灭。

可以在更广阔的空间去发挥呀,本公司一直想找技术骨干呢,q我,693136377

我是相信技术流派的,几近狂热,且认为好的管理氛围,应当使得每个技术人员尽可能无约束的发挥。唯独之具有如此“技术精神”,方能实现史学家——黄仁宇所倡导的,建立一个“数目上”可掌控的国家(或是团队),而不是空泛的祭出“管理”之大旗,打压先进的技术流派之士。

但是,当下,很多所谓管理的权柄者,缺乏足够的“技术素养”,他们老气横秋,以致对先进的技术产生排斥。即便是技术人士如何苦口婆心阐释、劝导,甚至人话鬼话说尽也无效果,直至可预料到的问题产生并导致严重后果。这是技术流派的悲哀,让他们感受到一种“无力感”。

怀才不遇不一定产生“无力感”,但是“无力感”一定是怀才不遇,且更痛苦。

似有怨妇之嫌.

其实还有另外个转职方向,就是去国外团队混