近日在网上读到《邵凯：用友的程序员文化》，对其中的一些观点有些陋见：
“用友的成功体现在程序员身上，有三个方面：专注财务和管理软件领域、用户需求第一、强调程序可靠性。”
这里其实是指三个方面的要求：行业专注、符合客户需求、程序的健壮和稳定，对此，我认为这其实是三个不同层面的要求。
第一：行业专注是指公司决策层对于发展方向或者从事领域的执着，这一点对于一般公司员工大概是无能为力的吧；
第二：对客户需求的重视以及对客户需求的分析，这或许是“应用专家”等售前分析或者相关需求分析人员的主要职责所在，对客户需求的重视程度，当然是应用专家、产品经理等人员所作的工作，因为技术人员正常情况下是不会直接面对客户的，他们对客户需求的变更或者其他响应也应该是基于上层下达的相关开发、修改任务；
第三：有多方面的因素会决定代码的质量。首先，最重要的是系统的架构，这一点不光关系到整个系统的可扩展性等问题，还关乎代码的质量，譬如代码层次组织的合理性、代码执行、调用的效率、代码重用…… 这在很大程度上影响了最终代码编写人员的代码设计的方式、方法，对此，我认为系统架构是所有技术保障的基础，其次，良好的内部组件的设计也是影响组件使用程序质量的重要因素。在管理系统中但凡涉及数据库操作，因此对数据库结构设计、存储过程的设计使用等也对客户端程序的设计有着重大影响。在一个组件化设计的系统中，真正客户端代码的逻辑和代码复杂性是很低的，其基本上是对众多组件的一种粘合，和对操作界面的组织。因此架构和组件的设计就变得异乎寻常的重要了。
“另外很重要的一群体是应用专家，因为用友是做管理软件的，让只懂软件技术的程序员设计一个ERP应用算法是不可想象的，必须首先由懂得应用领域业务的专家提出最优化的应用模型。”
对于这一点，大家基本都是认可的，关键是贯彻执行的程度不同。在很多小软件公司可能因为成本或认识上的原因，系统分析员通常要兼任这两种截然不同的职务，这最终导致的结果就是需求不符或者操作流程和操作习惯完全让客户无法接受。技术人员对业务逻辑的理解方式和客户、行业专家的理解通常是相差甚远的，技术人员对客户需求在理解上产生的偏差将最终导致系统无法被客户接受！这样错误是致命的。见图：
最后一点是关于 代码评审（Preview Code）和开发文档的。
我发现在很多软件公司，开发文档通常是由开发人员根据所写的代码在事后整理和撰写出来的，或者是设计人员在早期写的文档，这些文档本身的指导性就不够强，在随后的开发中其对设计和代码的变更的反应也不同步，长此以往，文档就变得不再是可信任的了，其最多只能是读解代码的一种次要文档了。而由开发人员后期整理出来的文档虽然与代码是同步的，但是其可读性和条理性不强，而且很多时候是应付上级要求所产生的，读起来也是晦涩难懂，甚至不如看代码直接易懂！
在文档上一定不能为了文档而文档，这样不但没有达到应有的效果，甚至费时费事，在这方面，我觉得C#中的XML文档与代码结合的非常好，同时也易于开发人员同步维护，而且有统一的格式规范。
