我的IT从业心得

我的IT从业心得：

正确定位：

对于一个软件公司或部门，正确的定位将决定其竞争力乃至生命周期。在我的15年it经历当中，这个概念是逐渐明确的。我看到很多软件公司或技术团队，花费大量的成本（人+时间）在不该做的事情上，导致了最终惨痛的失败。

2009年我在一次行业论坛上遇到一位来自中国移动研发中心的项目经理，他向我介绍了ophone的开发，和移动mm计划。可是很可惜，这些庞大的项目到了2012年彻底失败，中国移动为此承受了巨大的亏损，上千名开发人员的心血不了了之。这件事情再次印证了我的定位观。google和apple都是是技术驱动产品再驱动市场，但是这样的企业在中国没有土壤。

我在后来的工作中，常常与公司高层探讨的这个问题：市场驱动产品，产品驱动技术，这样定位，风险最小，生存的机会最大。it不是高科技，it是我们推行一个个盈利计划的手段。这个观点到了今天，更加确定，更加重要。

低成本策略：

2005年以前，国内少有人提及软件的重用，之后，随着软件设计技术的发展，一段时间，我听到最多的论点就是软件的重用，我也迷恋其中。但事实上，代码或软件组件会随着它的业务价值的升高而失去重用价值。盲目追求重用或通用，只能再次提高整个系统的开发成本，并最终折损整体效率和稳定性。

软件的开发成本即人和时间，我们首先必须依赖优秀的框架，用更少的人，更短的时间达成预期。优秀的框架，大大缩小软件缺陷范围，帮助软件系统尽早进入稳定期。

只写业务代码，杜绝技术型代码，即：杜绝在现代软件产品中编制有某种“技术含量”的代码，这类功能点，都有标准且稳定的实现。

杜绝“企业标准”，开发或封装自己的软件架构、框架，会与整个行业脱离，如果你有一个自认为优秀的技术体系，那一定要为它建立一个开源社区，让更多的团队接受它、考验它（如sap的abap），否则，你或者你的技术终将消失。对于it企业来说，只有那些绝对与技术无关的代码才是真正的财富。

客户需求：

软件行业里，施工型软件系统所创造的产值超过80%，这类软件系统的启动前期，分析人员会抱怨需求不明确，或几乎没有需求，但是事实上，在一个特定行业里，信息化需求只是没有写到纸上，一个好的系统分析工程师，是可以凭专业知识和行业经验来挖掘80%的客户需求的，而这部分需求几乎可以在整个工程20%的时间内构建出来。接下来需要在这80%的客户需求基础上，挖掘更多的深层次的潜在需求，而这20%的深层次需求，差不多需要消耗掉整个工程成本的80%，但是这部分工作将决定一个it施工单位的行业竞争力。

不可能有一个erp软件，能够用于两个不同的企业。sap发展了40年，也没有做到这一点，sap的全部积累，在于他的需求挖掘能力和快速开发模型，但是sap的竞争力也在不断萎缩，这是时代造成的，it技术的发展，带给我们的是：更低的门槛、更短的学习时间、更稳定的基础运行环境、更低廉的上游成本。这使得那些跨越时代，付出过巨大努力的it企业，要么成为标准，要么被标准淘汰。

软件设计方法：

2000年，uml在国内很受追捧，当时我还曾因为某一条关联线的虚实与同行争吵。在后来的多年的设计工作中，我常常用一些静态uml图作为和同事交流的准备文档，当时流行的一句话是：agraph worth 1000words，可惜这句话在我多年的工作中并未成为真理。看看springsource的文档，看看百度和腾讯的openapi，根本没有uml的影子。在一些必要的场景里，一张uml图，不要包含超过10个类/元素，并且一定附上一大段文字加以解释，否则，这样的uml图不能界定任何问题，并必然地导致歧义。

很多技术主管喜爱绘制“架构图”或“系统拓卜”，他们会在visio里面绘制漂亮的框框，让我眼花缭乱，这种表达方法必须谨慎使用，它有很强的渲染成分，而掩饰了系统实际的复杂状况，或错误地解释实际的模块间关系。

很多比较原始的沟通方式，至今仍然可靠、高效，比如：以接口定义作为沟通语言，关注接口而让实现留在程序员的心里；以原型代码、伪码作为沟通语言。面对面的自然语言沟通绝对不应被电子文档取代。当然，我们不应将一个复杂的模块交给一位没有经验的程序员，一名开发者的信誉决定了他所负责的接口、模块、产品的质量，这是毋庸置疑的。所以，过分强调设计过程的严谨性，绝对是一种浪费。

行业经验积累/领域积累：

一个软件公司或团队的生命力，在于某一领域或行业里面的积累，对于工程型软件企业，行业经验可以保证挖掘客户需求的时候，能够不断触及、解决更深层的问题，也就是80%以外的问题，而内行和外行的区别，即表现在这里。

同理，对于那些专注某一消费领域的公司，如视频服务提供商、策略游戏服务提供商，他们则需要长期不屑地积累特定领域内的技术和消费者习惯。

代码最小化原则：

我在2009年，为自己的团队制定了一项绩效原则，在制定一项任务的时候，会估计完成它所需的代码数量，在任务交付的时候，除以实际的代码数量，作为得分。我在公司里宣扬“惜墨如金”的编程精神。很多java程序员并未深入了解jdk，而很多来自开源社区的稳定技术，进一步补充了java语言的能力，这些程序员会不辞辛苦地编写很多不必要的代码，而对于单元测试和ue测试，我们无法发现任何问题。而正是这样的代码，埋伏了同样多的隐患，代码的易手更加困难，并且创建人很可能主观地将简单问题复杂化，并因此促进这类代码在公司里的传播，造成隐患的扩大，如果是关键应用或底层应用，则可能使企业蒙受巨大的损失。

软件工程师基本素质：

关注软件技术的演进，勇于不断推翻自己已经获得的成绩，勇于让新兴事物、自己不熟悉的技术，颠覆自己固有的技术形态。懂与用，有着很大区别，很多同行在探讨专业问题的时候，喜欢融汇贯通，喻其广博，我不喜欢这样，作为一个it从业人员，知道一项技术，粗略一用，知其然，一定轻言懂。每一种技术都有适宜场景，各种技术之间存在融合、适配的门道，在不知其所以然的情况下使用一项技术，往往会导致严重的后果，并且在错误的场景下，越是深入应用某种技术，最终的损失越大。

团队建设：

teambuilding是各个软件单位常提的字眼，它几乎总是被解读为聚餐和郊游。实际上，这样的团队建设几乎是无效的。一个好的团队无疑是创造优秀软件的必要条件，但是一些重要团队建设原则却往往被忽视。团队成员间的友谊和信任，是在共同开发某个产品，共同解决一个问题的过程中建立的。共同分享系统上线的喜悦，远远超过美酒佳肴带来的短暂燥热。好的软件技术人员，不愿意在无所事事的氛围里生存，更不愿意在无意义的作业中浪费自己的才能，所以好的团队首先应当建立紧张有序的工作氛围，合理安排开发进度，让每个人能够不断感受到成就，才是正确的团队法则。

同时，保持适当的人员流动性，也是必要的，团队没有必要固池在一成不变的氛围里，新的空气会带来新的生命力和生产力。而与大势相悖的成员应当果断地移至其它岗位或被淘汰。好的团队对于主管挑战很大，几乎完全取决于主管的能力和态度。在面试新人的时候，我比较喜欢实事求是、踏实肯干的人，我常问的问题是，你认为自己的强项、弱点是什么？我认为清楚自己是清楚世界的前提。

对于刚毕业的年轻人，他们最大的优势就是大胆和热情。我的方法是不要让他们做“低级”的编码工作。今天，很多先进技术，其门槛很低，不许要专门的指导，依据简单的起步说明或示例，就能让刚刚涉足软件开发的人开始工作，很多年轻的it从业者，狂热地追求这种“时尚”的感觉，我们不妨好好加以利用。