关于公司技术框架的一些思考

终于一个成型的网站建立起来了。公司的技术运行总算有了一些开端。逐渐进入两个产品开发的间歇期，怎样利用这段时间为将来开发打些基础，是个很艰难的话题。很明显大家都想学习些新的技术，但怎么学、学什么。好像大家都很迷茫。

究其原因,有以下问题：
    1：浮躁，没有心思一个方向钻下去。觉得够用就行，只要有个开端就说会了、懂了、掌握了。就可以满世界宣传，这东西太容易了。这项技术有什么缺陷、适用于什么场景（别告诉我它是万能的永动机、包治百病的良药）、能否工程化等等的问题从来没有考虑过，或者认为根本就不是自己考虑的问题。舞台上不紧张的演员不是好演员，好的技术人员在用某项技术时心中应该战战兢兢，不应该总是一副初生牛犊不怕虎的无知者无畏的态度。不了解、也不想了解哪些业务需要用到这些技术的态度。骨子里认为：技术是用来炫耀的、实用不是我的事。  
   2：应付，课题的选择没有深度和持续性。终于“强迫”上司使用了我选择的技术了、我可牛了。诸不知也许只是为了照顾到你那可怜的虚荣心。你选择的技术在实际应用时、需要你的上司、你的同事、甚至你的老板在为这项技术修修补补，放弃他们大多数人熟练的技术，为你这初生的牛犊付出代价。只对你有好处、这一番过后，终于会了这项技术，大家也多了一个只会些皮毛的选择。这是怎样的一个选择，不珍惜以前技术的成果，碰到问题没有在以前技术上解决的勇气，根本就不想深入钻研。对于技术团队来说，这团队又掰了一个玉米，以前的玉米也抛弃了。深层原因：大家都自由发展，选择的课题只在能简单应用的基础上。所有的研究不触及到算法、不触及到源代码、不深入研究、够用就行。穷于应付、频繁的转换认识肤浅的技术。 

3：自大，团队技术没有核心。团队没有方向、没有核心。没有主动发现课题、研究技术的氛围。每个人都是自大狂，技术不互相讨论、不讲求团队协作、今天会议决定使用的技术明天就私自改了（因为我是牛人、我想用什么就用什么的心态）。随心所欲、对于技术蜻蜓点水。交付的研究任务，必须有一个详细配置和使用步骤的有图、有代码、有详细说明的简单易懂的文档。这是公司的软件资产的一部分。技术不应只存在脑子里、口头上，要善于总结和条理化。而写下来，是条理化的第一步。 

以上问题出现的原因及解决案： 

1：目前的技术学习没有大的方向。相对于业务来说，技术应该是稳定的。业务的变换会要求技术的灵活，技术的灵活来自于对技术的深层理解和多次深层次的应用，理解的深刻而从来没用过或浅显的应用永远只是纸上谈兵。所以转换技术要慎之又慎。我认为：现有的技术方向没有大的问题，不用推倒重来。现阶段的重要任务是小步快跑的优化。任何大的架构上全面修改都不是现阶段的紧急任务，挖掘现有框架上的潜力，持续不断的改进功能，优化流程。技术持续不断的向深处发展，而不是广度发展是现阶段的技术方向。 

2：研究课题的选择不慎重，太随意。课题的选择必须是业务的需要和团队的讨论结果。可以自主选择或创造研究课题，但必须书面提出、公告。研究结果阶段汇报、持续不断的研究，不能蜻蜓点水，不能求广不求深。 

3：事事都想推倒重来不可取。立足于现有，不鼓励强拆再建。尊重而不崇拜以前的技术成果才是良好的心态。 

4：着手全面制定各项技术规范。详细设计书模板、coding规约（java版、sql版、shell版）、软件开发各工程要领（项目管理制度及文书格式、代码review制度、单体测试规则及工具）。 

5：提高：学习各种设计模式，至少能熟练应用3-5个设计模式。能够理解现有框架意图及优劣，提出改进而不是抛弃的意见、建议、措施。 
      6：对问题持续跟踪，不做甩手掌柜。意见提出、转身就走。这不是技术人员的态度，更不是优秀技术人员的态度。作为一个leader，到底为那个程序员调试过几个代码？解决了几个问题？代码实现简单，在低级别的程序员不能发现问题时，亲自上阵一行行调试代码解决问题才是职责所在。一碰到问题就说框架问题，仿佛真的是换个框架，一切就OK。回避真正要解决问题，因为不可能遇到问题就换框架，所以原有的问题就解决不了，这样的人的确很萌。