软件开发如何完成从编码阶段到设计阶段的过渡？

　　今天再谈下如何在软件开发和编码过程中逐步培养设计思维的话题。
　　对于软件工程，架构设计，编程思维等各个阶段的关键内容，我在前面的文章基本都谈到过。最近有感于最近招聘和面试的一些过程，发现大多数人虽然工作2到3年基本也没能有基础的设计思维，或者说最多还是停留在编码熟练阶段，离真正能够独立完成一个大系统开发的设计能力来说差距甚大。
　　那么如何在2到3年的时间，能够从基本的编码能力过渡到具备基础的设计思维和系统模块的设计能力，就是作为程序员必须要考虑的问题。软件开发中的设计思维概述
　　在前面我专门写过一篇编程思维的文章，里面谈到了部分设计思维的内容，因此在这里先对基本的设计思维做下总结。
　　从基本的编程思维谈起
　　对于软件程序，大家都比较容易理解是由算法数据结构组成的。编程本身也是完成现实世界到抽象模型世界的一个转换，即通过抽象的设计符号加上最终的代码实现来完成对现实世界问题域的描述。
　　对于编程思维来说，可以理解为两个方面内容的映射。
　　其一就是需要将现实世界的描述流程化，步骤化和可操作化，在这个过程中你需要处理考虑将重复的东西抽象为循环，将业务规则抽象为分支和判断等。
　　其二就是需要将现实世界问题域中的问题或对象抽象为具体的数据结构。
　　一个人编程能力本身的好坏，或者说编程思维能力，重点其实是体现在这种映射能力，也可以称这种映射能力为数学建模能力。
　　从编码到设计思想
　　当从编码到设计的时候，大家常说的是面向对象的分析和设计思想。而这个里面的关键可以理解为抽象。抽象即能否从不同的东西中找到共性的内容，抽象出共性的基础类或接口，抽象意识一方面是增加了你代码的可扩展性，这也是最基本的设计模式中谈到的意识。
　　抽象的思想不再是简单的自动化，而是形成了归纳演绎的逻辑。抽象不仅仅是解决了可重复的问题，同时解决了可复用的问题。
　　设计思想里面的第二个关键我将其理解为分而治之，其核心仍然是面对复杂问题的时候如何进行分解再集成的解决思路，里面的重点首先是分解，分解后再通过接口进行集成，同时组件和接口设计要满足常说的高内聚和松耦合思想。编码源代码就是设计
　　编码是一个技术活，需要大量的脑力活动，但是很多人却可以把编码做为一个体力活，我在这里想继续强调的是如果编码是一个完全的重复体力劳动的话，那么所有工作就一定是可以自动化掉的，在这个时候你原来所有的工作没有任何的价值体现而被完全替代。比如你现在的工作应该完全被类似低代码开发平台，人工智能所替代。
　　对于任何从事编码工作的，如果仅仅认为自己的工作是大量粘贴拷贝下重复的体力劳动下的码农的话，至少说明你已经不适合做一个程序员，更加不可能成为一个优秀的程序员。
　　对于开发人员来说，不是别人把你发展的路堵了，而是自我思维的约束，安于现状，没有一种探寻精神，对未知世界的强烈的求知欲望把你自己的路堵死了。态度是一方面，但是更加重要的是思维意识的转变。现在即使做一个农民都要考虑这一季如何避开竞争选择种植物，如何考虑成本效益产出，如何科学管理提高亩产量，作为一个体面的知识工作者的程序员，更加没有任何理由让自己陷入一种简单重复的体力活。
　　只有当你意识到该懒的时候需要懒，该自动化时候需要自动化的时候，你才可能逐步有抽象和复用的意识，逐步能够真正驾驭你手里面的工具和技术，而不是被工具领着鼻子走。
　　源代码就是设计，并不是说我们在软件实现过程中没有需求和设计环节，只是更加重点的再强调最终交付的产物源代码无处不再体现着你思考的逻辑性，设计的思路。一个再好的设计文档有的人也可以写出让你连Review一下都没有欲望的垃圾代码。一个没有任何文档介绍的开源软件源代码，往往可以让你读得拍手叫好，快速的梳理出内在的逻辑结构。
　　软件工程学角度始终都在找寻一种方法来实现代码部分的工作完全自动化，包括MDA模型驱动架构方法，各种快速的开发平台和建模平台。这对于一些模式固定的工单流程类应用可能适合，但是真正对于大型业务系统能够用起来的确相当少。
　　几年前我们就在做快速的开发平台，包括界面建模，数据建模，流程建模，规则建模各个方面的设计和实现。但是最后我们发现，为了实现更加复杂的场景往往引入了支持各种脚本语句，在引入了这个功能后发现，后续大量的复杂内容都需要通过脚本语句来实现，最终的编码部分内容又绕了一圈回到了脚本语句里面。这种大面积的脚本语句的维护和管理反而比原来更加困难。
　　对于复杂业务场景对应的系统，短期没有银弹。
　　编码没有速成，需要的是只有不断地练习和积累，对于各种类型的技术和设计思想的实践练习，到最后你就发现所有的技术最终万法归一，触类旁通。
　　在这个过程中还不仅仅是量的积累，更多的是量变到质变的转化。一个程序员如果长年累月都是拿来主义，都是粘贴拷贝，都是不断地做着增删改查的单功能点，那么时间再长也就那个水平。所以这实践里面更加重要的设计思想的消化，自动化和复用的意识，逐步对归纳后抽象的理解等，这些往往才是能否成为一个高水平的程序员的关键。
　　各种的软件技术类培训机构和学校，好像再告诉我们做一个编码人员如此的简单，在这里没有复杂的数据结构，没有算法，只有增删改查的一个个功能点。培训机构在一批批的按标准模式生产着代码工人，但是只有少数人能够真正成为一个合格的程序员。
　　我们需要写出具有良好可读性的代码，代码的可读性不是体现在大量的注释上，而是体现在代码本身的自解释上。代码的自解释体现在类的划分，接口的使用，方法和函数的抽取，逻辑的实现，调用的过程关系和交互，这些工具和技术不能帮你，我们很多时候是使用了面向对象的语言和成型的分层开发框架和技术，但是仍然是固有的非结构化和抽象的模式在写程序。该抽象提取接口的就提取，该复用的就复用，该拆分的就拆分，该内聚的规则就内聚，无疑就这些内容和思想，这些都搞不好更谈不上设计模式。
　　我们需要写出高健壮性的代码，一个功能增删改查的实现仅仅是最基础的基础，为了考虑各种边界和异常，考虑清楚每一个详细规则点的处理和扩展，你需要额外增加至少1倍的代码量可能才完成。一个健壮的程序会考虑到各种用户使用的场景，给用户犯错的机会，支持各种错误后的重试而不影响到整体的事务一致性等。一个健壮的程序会很少需要程序员后台去调整和修复数据，一个健壮的程序应该很好的控制和监控底层计算，内存，物理存储资源的使用。
　　我们需要写出高可维护性的代码，一个软件产品实现完成和上线不是最终的生命周期，而伴随的运维才是更加重要的一个阶段。在系统运行和使用过程中，随时可能出现某些不可预见的异常，这些异常我们不能完全的规避掉，但是更加重要的是当发生异常或错误的时候，我们能够快速的定位到具体的问题点并快速解决掉，这也是前面所说的异常和日志不可分的道理。另外一个高维护性的代码必定是具有很好的可读性，对于任何业务规则和逻辑的实现，数据的获取和存储我们可以快速的阅读代码和定位，以方便后面对各种需求变更的处理和实现。
　　我们需要写出高性能的代码，而不是将程序的高性能完全交给硬件能力的提升来解决。一个字符串的使用，一个集合类和数据结构的使用，数据库连接管理，各种逻辑实现中的循环，接口的使用，不合理的抽象层次，对内存的管理，缓存和事务一致性，前端js脚本优化，业务规则逻辑优化，数据库性能优化等各个方面都涉及到性能的提升。性能的问题要踏踏实实地做，从每一个细小点做起和注意，在编码过程中绝对不能因为简单省事而对已有的各种编码规则滥用，这才是一个程序员基本的负责任的态度。
　　最后引用下oz6大叔的说过的一段话。
　　总是有些浮躁的人在说，写代码没前途，到多少多少岁还写代价就更加没前途。我觉得这些人从开始就不应该写代码，并且他们写的代码我一行都不信任。当然他们有这样那样的理由，其实核心无非就是你越大就越不该写代码，而去从事一些什么更高尚的职务。这样的人就是去看厕所我都不信任，早就该被讨厌回家。当然回家也不能抱孩子，因为他们孩子也搞不好，因为这个在他们看来也肯定没前途。从编码到设计
　　首先说编码环节，当然是最基础和最重要的技能和经验积累阶段，一个好的架构师往往也是经过了多年编码积累后逐步提升出来了。在大量的编码过程中，一方面是编码习惯和编码规范方面的内容，一方面则是编码过程中的设计思维。
　　当前大量的开发人员仍然认为编码是属于比较低端的工作，我想了下这种想法存在的一个原因，即使当前来说很多常见的软件系统仍然是属于业务逻辑相当简单，底层领域对象和数据模型相当独立的系统，这种简单直接导致的一个现象就是很多功能确实就是简单的表单CRUD操作，再额外有一些业务规则代码，然后再挂接流程引擎，这已经成为了常见系统功能的定式，做多了自然觉得没太多的技术含量。
　　同时往往进入项目的新人，企业原来的开发框架和模式，公共技术组件积累已经完成，自己一进入团队往往就是基于比较成熟的框架开发独立的一个个表单功能，原来的代码框架还可以全部拷贝过来，自己再重新设计下界面，填错些业务规则就能做好。
　　种种这些都直接导致了给人的印象就是要熟练开发软件系统或功能相当简单，而且后面好像都是一些重复性的没有太多技术含量的工作，再加上后续自己如果不多思考多学习，那就会始终停留在这个阶段，工作再多年都没有用。一个常见的现象就是工作2，3年以后连常用的事务处理方法都还不清楚，或者说当软件性能出现问题后性能具体诊断方法和逻辑是如何的也无法应对，这些内容很可能也在他们的日常工作和生活里面就没有涉及到。
　　基础的编码能力一定不是体现在基本功能的完成上，而是体现在非功能性需求的实现上面，在这里面包括了异常，日志，安全，事务，性能，可扩展性多方面的内容。每个点每个细节都必须高度重视，从一开始就养成好的编码习惯和编码思维。如果进入的是一个原来软件过程比较成熟的团队，这些可能都已经有比较多的积累文档，那就需要好好学习和理解；如果是全新逐渐的团队，那就需要自己多学习多看外部的代码，开源的代码，多去学习他人的编码风格和规范。
　　源代码就是设计，一个好的源代码本身是具备自解释性的，代码本身的实现思路和逻辑，调用关系，复用抽取等都体现了编码者的设计思路。在一个软件团队里推codeReview最大的好处就是可以让他们看看你的代码，从一开始就评审出编码中的一些坏习惯并修正。包括当你拿到一份已经成型的编码规范时候，要多去想为何规范要如此要求，其背后的原因是什么？这些都要思考清楚。
　　如果仅仅在编码阶段谈设计思想的话，我们可以考虑下在编码实现的过程中每层的使用是否合理？逻辑层是否真正起到了承载逻辑的作用，公用的函数是否进行了抽取，共性内容是否进行了抽象？在面对一个冗长的代码段实现中是否通过理清阶段步骤后进行了内容分解？各层之间，各个类和方法之间的调用关系是否清晰？
　　以上都是可以考虑的内容。
　　在转到设计阶段后，首先最重要的还是数据库设计，由于当前有些应用相当简单导致你经常看到的数据库设计就是一个前台功能表单对应了后台数据库1到2张表。但是对于一个复杂完整的系统其数据库设计相当来说会更加复杂，数据库表之间的关联和依赖关系更加多，这个不是简单一个数据库设计遵循范式要求就能够说清楚的事情。更多的还是要理解和分析需求，从需求中识别和抽象出数据对象，然后再进一步根据业务交互来确定数据库对象间的关联和依赖关系，最后才是数据库表字段的细化定义。
　　不管是面向结构还是面对对象的方法，其核心最终都体现在实体和实体之间的关系上，这个理清楚了再考虑进一步的范式要求和反范式冗余。我们可以找一些比较复杂的产品化系统，然后分析其底层数据库，学习对方数据库设计的思路，类似的如电信的计费模型和资源模型，生产制造企业里面的产品结构和BOM数据库，配置报价模型等，这些都可以参考学习。
　　数据库设计清楚了可以说基本的业务理解就应该清楚了，因为最终的业务活动和操作最终都将持久化到底层的数据库和数据表中。业务活动中承载的主体是业务对象最终会对应到底层的数据库对象，当然业务活动中还有比较复杂的业务规则，这些业务规则往往也会对应更加复杂的业务规则数据表设计。
　　其次就是组件和模块怎么划分？如何保证划分出来的组件本身是松耦合的？我们看了太多的业务系统，最终的组件粒度不是太粗就是太细，这直接就体现了在上层组件划分上的随意性。如何划分组件前面也专门有文章谈在这里就不多说，其核心就是要保证组件之间尽量少的接口和交互，对于各个组件都依赖的内容能够有意识的下沉为底层共享技术组件或数据组件。
　　有时候我们简单的按照系统前台功能菜单分法去对应底层组件，这个方法本身存在不合理性，不能完全采用。组件划分清楚后才能够进一步分析组件间的接口，然后进行接口设计，接口在设计过程中可以遵循SOA的思想，多考虑接口本身的粗粒度和可复用性，尽量少暴露组件内部不需要暴露的内容以保证组件本身的高内聚。
　　组件划分清楚后，数据库应该归属到组件内部，即任何一个数据库表都有Owner组件，对于不是Owner的组件要尽量避免直接访问底层数据库表，只有这样才是一种完全可拆分的组件化架构。也可以防止虽然逻辑层进行了组件划分，但是到了数据库层仍然高度耦合而无法拆分的问题。这个本身也是当前微服务架构设计的一个重点内容。
　　组件划分清楚后，在进行完接口分析后，组件应该暴露哪些服务，如何进行服务的识别和设计就相当重要。在这里的一个关键点还是要意识到服务本身是粗粒度的，是到对象层面的，而不是底层数据库表CRUD接口方法的简单封装。组件层在设计和实现的过程中，应该逐步有领域驱动设计的思路，即多考虑领域对象和领域服务，从数据库表的思考转变到对实体操作的思考，这种转变完成后会看到原来贫血的逻辑层会逐步丰满，其既承担了领域对象的数据提供能力，也承载了跨领域对象或实体的业务逻辑提供能力。这个转变比较困难，难点就在我们要从原来一个个功能垂直相对独立，一个个做的方式转变为横向分层构建的模式，即数据库层到领域层，上层再来组装领域服务。这个思路本身也是朝SOA架构思路转变的一个基础。
　　组件在拆分的过程中，需要识别出可复用的共性组件，这在架构设计里面要关键可复用单元的识别，这也是设计中一个重要的思维。在设计中有两个重要的思维。一个就是分解》接口》集成；一个就是横向的数据库对象资源》服务》服务组合组装，这两个思维大家可以好好理解一下。
　　这些都考虑清楚后，你就会发现在你做前台功能实现的时候首先考虑的是调用底层组件里的服务接口能力而不是直接就想去操作数据库，其次你会发现会在你原来做单功能固定模式会生成出来的类文件的基础上会增加相关的组合类，增加相关的业务逻辑处理类。或者为了增加可扩展性以应对变化会进一步的增加上层抽象接口等。
　　前面说的这些基本就是比较重要的设计思想，这些内容不自己完整的参与一个大系统或大模块的设计开发很难逐步积累这些经验。同时在讲上面这些内容的时候我也比较少提及到UML或者说设计模式，其原因就是UML本身仅仅是形式化标识工具和方式，不是能够用UML就能做设计；而对于设计模式更多已经是前人经验高度抽象和积累，如果有设计思想和思维自然会考虑到不同场景下可能会用到哪些模式来解决问题，而不是生搬硬套的去套用模式。
　　设计是软件工程里面衔接需求和实现的重要桥梁，也是从现实世界需求到软件世界实现的重要一层抽象。设计的核心静态在底层模型，动态在业务驱动下的类和方法交互和调用机制。但是不论是动态还是静态，抽象和复用都是最基础的需要形成的设计思维。
　　欢迎关注人月聊IT分享云原生，信息化，IT规划，思维类知识，公众号同名，可以搜索关注，每一，三，五更新。