软件开发就找中鲁世纪，一站式服务，为企业提供软件开发，软件定制服务。
面向对象设计之所以更流行，是因为这种思想更符合人对事物的认知和定义，在思想表达和传递中更容易。
随着平台建设的推进，开发过程会遇到各种问题和挑战，如果能有这个认识，在处理可改可不改或者较小细节时，会对是否做调整也有帮助。
日常在做系统设计和方案选择时，有些开发可能会考虑代码量。
然而，代码量不应该成为设计好坏的标准。
如果代码量小而引入如下的问题，反而增加了系统复杂度和维护成本，系统的稳定性和开发效率也会受很大影响。
一个好的架构设计能规避掉日常容易遇到的问题，也能更好容纳突发剧增的系统访问，对临时的故障恢复也有很大帮助。
这些设计的优化，都是日常开发中应该注意的细节问题，只要在开发时稍微思考下很容易识别和做出选择，也不会增加开发难度。
【常识五：对接的外部系统是不可信的】
在一些业务规则相对固定、场景清晰的系统中，我们经常能看到比较老的系统，这些系统经历的长时间运行，且使用者习惯也固定了，当初开发该系统的人员有些可能都离职甚至退休了。
然而随着业务微小变动扰动原有的设计，特例越来越多，技术框架也在不断更新进步、团队成员变动等等，这一切都会使得系统慢慢的走向衰败，这和汽车保养是一样的。
如果在可见的未来两年、五年内，系统依然会服务于业务，研发就应该勇于做出系统重构，虽然短期看不到价值体现，然而优化的意义和价值却是长期存在的，这也促使了系统能够更长久的走下去。
【常识七：工程化是解决开发效率的**工具】
当拥有基于这样的认知时，在系统设计会有不同，比如创建一个新表时就会主动评估业务查询需求建立合适的索引、在设计系统容量时会考虑容量及达到容量后的循环覆盖策略、对于流量洪峰的削峰和控制都会在最初设计时考虑，等等。
如果系统必须依赖研发工程师不间断地维护和扶持才能运转，那就意味着隐藏着巨大的风险隐患。
【常识九：产品模型设计的好坏直接影响软件系统质量和效率】
测试是系统建设的重要组成部分，是系统的质量、安全等的重要保障，但当线上出现异常或故障时，测试却不应该成为责任人。
一个的系统建设，离不开良好的产品设计、健壮的系统架构、规范的代码等，这些是前提和基础。
故而研发应重视代码变更部分的逻辑和边界测试，而非依赖于测试人员。
【常识十一：偏业务的系统应具备完整独立的运营能力】