二. 卓信的技术价值观与人才观

在技术路线，技术栈的选择以及发展、实践中，有以下的一些原则 ，我们认为应当是卓信所有技术相关人员应当树立在心中的价值观：

2.1 技术价值观

2.1.1 出来混，总是要还的，不要忽视技术债务

技术债务」是开发团队在设计或架构选型时，从短期效应的角度选择了一个易于实现的方案。 但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务。 简单的说就是为了快速地解决问题，而采取的不规范的方案。

项目实现的过程中，因为时间压力，因为人员的能力、视野所限，有意无意的会采用一些权宜的方法，一些临时性的解决方案。随着时间的推移，这类问题会逐步积累，而什么时间会爆发很难说，最终的结果可能就是项目结项了，维护不动了，性能有问题，也难以优化，成为一座“屎山”。

避免技术债务的积累，在流程与方法上除了执行相应的文档规范、定期代码审查、定期处理重构之外，最根本性的问题是，项目经理与开发人员，必须先对于技术债务有足够的警惕与认识。

2.1.2 对热闹驱动的架构要有清醒的认识

“热闹驱动的架构” ,即，未经踏实的研究和思考 ，就跟着大流，听从部分碎片化的微信文章， 什么新鲜热门就用什么， 跟着热闹走的去选择技术路线、组件。 在国内的环境中，因为客户也要追求新概念，亮点等，在总体技术架构等方面会要跟着一些热点。但技术团队特别是架构师角色，必须对热闹的技术组件或者概念，要有清醒的认识，不可盲目追新。

因为对于一个做企业业务的公司来说，软件的生命同期可能比原设想的要长，在维护期的成本，技术组件的生态环境成熟度，团队成员的能力，学习成本都是应当要考虑的。

2.1.3 可维护性、可读性高于一切

系统的可维护性是衡量一个系统的可修复(恢复)性和可改进性的难易程度。 所谓可修复性是指在系统发生故障后能够排除(或抑制)故障予以修复，并返回到原来正常运行状态的可能性。 而可改进性则是系统具有接受对现有功能的改进，增加新功能的可能性。可维护性、可读性，是对于代码编写实现的要求，也是对于技术栈选择的一个重要考量点。在软件系统的生命周期内，采用了不成熟的、不恰当的技术选型，在后续维护发展中，不能跟踪技术社区的发展，技术或者组件成为生僻的、小众化的东西，对未来的维护、改进工作也就带来了极大的困难。

2.1.4 持续改进，不断积累，开放共享

项目是为创建某一独特产品、服务或成果而临时进行的一次性努力。所以，单纯的项目驱动不利于技术成果的积累与持续改进，而软件的价值点又在于复用。因为必须有持续改进，不断积累，开放共享的观念。并通过项目的开发间隙期、以及持续性的定期总结 、积累，分享的工作。对公司所使用的技术栈，技术成果积累、改进，促进重用。

2.1.5 一切未提交配置库的工作成果都不算工作成果

配置库上看不到的文档、代码，都不算工作有成果输出。什么本地测试好了，文档本地写好了未提交，不能体现在配置库上的工作成果提交物，都是虚幻。

2.2 人才观

IT 公司最重要的资产是人，人才观，即我们需要什么样的人加入我们的团队? 技术人员的职能生涯如何能走得更远？

2.2.1 具备持续学习的能力

IT行业的特点决定的， 任何人，任何职位，都没有老本可吃。但是，基础性的，原理性的理论，目前仍然可以温故而知新。 因为 冯.诺伊曼 计算机体系结构仍然是那个结构，TCP 仍然是TCP，任何商业的基本逻辑也没有变。

2.2.2 有担当的职业道德

所谓担当，其低者，是对自己负责的事情，能做到让人放心，少让人帮忙擦屁股 ；其高者，是敢于挑战，承担更大的责任，挑战更高的要求。

2.2.3 交流理解能力比技术能力更重要

听得懂别人的意思，能清晰准备的表达自己的想法、诉求。所谓团队协作 ，无非就是团队内沟通顺畅，责任有担当。 在大分工协作的今天，交流理解能力，比单纯的技术能力更为重要。