软件开发的逻辑问题(6个问题帮你构建逻辑，了解软件开发中的重要模式)

　　对很多初学者来说，编码就是编写if else的语句，试图弄清楚如何运行代码的过程。在这一过程中，编码就变成了一个令人费解的庞然大物，其出人意料的曲折情节堪比《权力的游戏》。

　　代码越多并不意味着代码越好。当然，在写代码的时候还是很有意义的——直到回过头来，解开无意中创造的神秘小说，才发现不明确的方向、结构和主要情节的漏洞阻碍着线性发展。

　　当开发人员不了解某些知识时，就会出现错误，这些错误主要是源于不了解代码中高效的模式。哪怕生成的代码已经运行了，结构遗忘的喜悦仍在持续。但随着时间的推移，事情过于混乱带来的挫折感也就随之而来。

　　以下问题有助于你构建逻辑，了解软件开发中的重要模式。

　　函数式编程如何？

　　尽管大家非常喜欢面向对象模式的理念，但函数也存在于类和方法中。函数式编程基于给定情况处理数据，强烈厌恶依赖性。

　　依赖关系并不是坏事，但太多的依赖关系会导致不必要的蜘蛛网。

　　依赖项引入所导致的连锁效应会降低代码的模块性。依赖前一项正常工作，创建一个串联电路效果。

　　函数式编程模式可将代码转换为独立存在的一系列并行状态，增加了模块化——这是隔离和构建清晰逻辑域的方法。代码模块化时，崩溃不会频繁出现。

　　依赖关系也可存在于函数本身，即使创建了逻辑隔离，也仍会产生冗余，通常以不同名称下的重复值、循环中的循环或嵌套逻辑的形式出现。如果出现这种情况，最快的修复方法是压缩逻辑并将其抽象出来。

　　是否需要公开？

　　并不是一切都必须是全局状态或作为公共功能存在。有时，代码隐私是件好事;可以防止范围蔓延，提高变量安全。

　　将所有内容公之于众很容易，但这不是可访问范围的重点。

　　当内容都公开时，服务和工厂内部的代码很容易受到外部可变性的影响，会增加变更范围，超出潜在预期情况。

　　在JavaScript中，技术层面上，所有变量、函数都是全局可被访问的。但随着TypeScript的出现、增长和广泛使用，公共变量和私有变量有了明显的区别，函数使得代码能够抵抗不必要的访问和更改。

　　过度抽象还是不够抽象？

　　编写业务需求时可能会忘乎所以，沉迷于模块化的概念或过度专注于捕捉一个复杂的想法。

　　试图使代码过度模块化时，就会导致过度抽象，因为我们总是被告知这就是做事的方式。面临一组复杂规则，还未能搞清楚如何进行简化时，就会导致不够抽象。练习到抽象实在是太耗脑力无法重构或已经没有时间了。

　　那么，怎么的度才是合适的呢？

　　抽象是为了提取出可重复代码的明确边界。不过度计划潜在使用，或不在不同的范围空间中反复编写相同逻辑时，抽象的度就是合适的。

　　通常，嵌套是不够抽象的第一个标志。多次注入和调用多个外部函数是过度抽象的关键标志。

　　名称真的实用吗？

　　谈及代码时，并不是代码越复杂越有吸引力，不要企图通过炫耀自己的方式来获得未来开发人员对所编写内容的青睐。

　　冗长的名称会造成不必要的代码干扰。简短的首字母缩写对缺乏经验的人来说简直就是末日灾难，因为意思实在太过模糊，而这些意思取决于那些即将离开公司再也见不到或联系不上的人。

　　于任何文明而言，遗失知识只需要一代人。只要一个开发人员离开公司，就会丢失tracusboo函数所表示的隐含信息。

　　所以还是写些实用的名称吧。如果名称太长，则意味着试图捕获的信息太多，需要对内容进行抽象。代码不是好莱坞的“黑客帝国”屏幕，所以不要像那样子编写代码。

　　之前编写过吗？

　　有些代码周而复始反复出现。有时，识别代码中的模式时会意识到之前已经编写过了，但是是在另一个函数、类或方法中编写的。

　　也可能是别人在别处编写的，这也就是为维护代码的内聚性和防止重复而要进行抽象和重构的地方。

　　如果它看起来很眼熟，很可能是因为你已经在其他地方写过相同的模式了。重构就是重构代码的行为和过程，以满足代码库的增长，维持内聚执行的长期稳定性。

　　重构本身并不需要很大规模，编写代码并将俘获的业务逻辑过程中的低效变得高效时，微重构就在运行中出现了。

　　究竟是在试图捕捉什么？

　　代码总是有目的的，它的存在是为了代表某种东西。问题是，你的代码究竟代表什么?

　　预计输出是多少？怎么样才能达到预计输出？名称和功能流程中的含糊其辞会使得脆弱的代码没有明确的边界或存在目的。

　　在业务中添加新元素时，增长就会引起变化。这种增长会破坏原有组件吗?或者它是否足够独立，有明确的界限将影响最小化?

　　灵活的代码不在于能覆盖的范围，关键在于对变化的适应力有多大。知道预期输出是什么，就更容易通过单一职责原则来进行保护。

　　结语

　　只有不断的实践才能编写出一致、简洁的代码。清理得越多，就越容易认识到有缺陷的模式和习惯。

　　有时需要学习新知识，克服阻碍才能编写出简洁但可能脆弱的代码。我们总是倾向于熟悉的事物，但并不意味着它是最好的方法和模式。