【原则一：可读性是代码风格的优先】 面向对象设计之所以更流行，是因为这种思想更符合人对事物的认知和定义，在思想表达和传递中更容易。
代码在系统运行之前可以当成一篇表达人对事物/系统描述的文章，所有的概念、定义、机制、边界都是系统建设者意识的描述，如果能像散文一样阅读代码，对于快速理解、简化系统、增加协作能力都有极大的帮助。
不同代码风格最终的运行结果是一样的，但是在写法、理解性、优化空间和健壮性上却可以有很大差异。
要写出易读的好的代码，规范和标准很重要，比如下面一个例子中，个if条件是反思维顺序的，阅读自然会别扭。
【常识二：新代码很快会被再次修改】 随着平台建设的推进，开发过程会遇到各种问题和挑战，如果能有这个认识，在处理可改可不改或者较小细节时，会对是否做调整也有帮助。
【常识三：代码量少并不一定能简化系统】日常在做系统设计和方案选择时，有些开发可能会考虑代码量。
然而，代码量不应该成为设计好坏的标准。
如果代码量小而引入如下的问题，反而增加了系统复杂度和维护成本，系统的稳定性和开发效率也会受很大影响。
【常识四：的架构设计会避开很多常规问题】 一个好的架构设计能规避掉日常容易遇到的问题，也能更好容纳突发剧增的系统访问，对临时的故障恢复也有很大帮助。
这些设计的优化，都是日常开发中应该注意的细节问题，只要在开发时稍微思考下很容易识别和做出选择，也不会增加开发难度。
【常识五：对接的外部系统是不可信的】 这种思想并不是去否定别人的系统或能力，而是站在自己系统的角度在做设计和细节处理时要能够多考虑一些，能多包容一些异常。
外部系统的质量和异常处理都不在我们的控制能力中，我们可以做的就是把自己的系统设计好，风险控制好，而不是别人系统崩溃我们的业务也无法进行，这种风险耦合是不可接受的。
【常识六：持续重构才能使系统绿树长青】
在一些业务规则相对固定、场景清晰的系统中，我们经常能看到比较老的系统，这些系统经历的长时间运行，且使用者习惯也固定了，当初开发该系统的人员有些可能都离职甚至退休了。
然而随着业务微小变动扰动原有的设计，特例越来越多，技术框架也在不断更新进步、团队成员变动等等，这一切都会使得系统慢慢的走向衰败，这和汽车保养是一样的。
如果在可见的未来两年、五年内，系统依然会服务于业务，研发就应该勇于做出系统重构，虽然短期看不到价值体现，然而优化的意义和价值却是长期存在的，这也促使了系统能够更长久的走下去。
【常识七：工程化是解决开发效率的**工具】工程学在各个领域都有广泛使用，比如生物、化学、物理、建筑、土木等，是解决团队协作和系统化执行的方法和科学。
软件开发也有大量的规范和标准需要遵循，也是工程化的体现，这对于解决团队协作中的执行效率、系统健壮都会有很大的作用。
【常识八：系统应能独立运行若干年】 当拥有基于这样的认知时，在系统设计会有不同，比如创建一个新表时就会主动评估业务查询需求建立合适的索引、在设计系统容量时会考虑容量及达到容量后的循环覆盖策略、对于流量洪峰的削峰和控制都会在最初设计时考虑，等等。
如果系统必须依赖研发工程师不间断地维护和扶持才能运转，那就意味着隐藏着巨大的风险隐患。
【常识九：产品模型设计的好坏直接影响软件系统质量和效率】产品经理在系统建设过程中是极其重要的角色，在团队内应是对业务最熟悉、和研发直接对接最多的。
在之后实现的平台中，大部分的概念名称、规则定义、操作规范等都来源其思想，也决定着代码中专业的字段名称、数据结构设计、接口设计等，所以产品经理对于系统建设的质量有决定性作用。
该角色要发挥其角色的价值，应将用户的不准确想法、不完整思路和前后的因果关系梳理都模型化为产品形态，甚至可以做出创造性的设计，以构建系统的逻辑性和可操作性。
【常识十：测试是系统质量的重要保障，但不为线上故障负责】 测试是系统建设的重要组成部分，是系统的质量、安全等的重要保障，但当线上出现异常或故障时，测试却不应该成为责任人。
一个的系统建设，离不开良好的产品设计、健壮的系统架构、规范的代码等，这些是前提和基础。
故而研发应重视代码变更部分的逻辑和边界测试，而非依赖于测试人员。
【常识十一：偏业务的系统应具备完整独立的运营能力】 良好的系统运营能力是业务发展和推进的重要支撑力量，在最初的系统设计时就应考虑到运营平台的建设，兼顾如下方面的能力覆盖，并对用户、产品和研发输出增益价值。
若非系统bug，当功能上线后就应属于业务交付，就可以尝试自主独立运营了。
软件开发就找中鲁世纪，一站式服务，为企业提供软件开发，软件定制服务。