用脚本构建的程序是怎么保持后期重构的健壮性的？
程序员文章站
2022-05-28 19:02:14
...
我一般使用的是强类型语言，比如java或者c++。但是我知道很多系统是用弱类型的脚本语言，比如豆瓣。
我尝试过弱类型开发，但是后期很难维护，具体表现是几乎无法重构。
是不是会有别的什么办法可以避免这个问题，或者可以支持到健壮的重构？
我一直对动态语言构建系统的维护方式比较好奇，求大神赐教！
——————————
看到很多大神都提到单元测试，确实是可以保证系统重构之后的稳定性
但是我写程序喜欢一边写一边微调程序结构(微重构)，几乎很少单元测试，所以需要类型安全来做随时错误检测。 不知道这个是不是什么好习惯？
一个API看起来会返回一个A，没人敢保证不会有1%的机会返回个null，再有0.01%的机会返回个B。一个小改动要往下看n层代码才放心，结果commit上去还是挂了。
Facebook就知道错了，搞了个Hack抢救一下…… 不管是什么语言，重构要保持健壮性靠的都是大量的单元测试。这不是脚本独有的问题。 无他，大量可回归的单元测试，集成测试。 多回复一点,其实 @vczh前面说的没错,但是却是个悖论.因为很多时候,人们用脚本语言就是图的开发速度,现在为了让它健壮还得尽可能的单元测试覆盖,老实说,脚本多用在业务逻辑多且变化频率大的领域,单元测试写起来实在蛋疼.
这就好比,本身你用A是为了好处B,但是为了弥补A的缺陷又不得不做一些事情要牺牲好处B.
所以说,个人认为单元测试覆盖对脚本语言开发的项目是个悖论.
我的想法是自己权衡吧,想快赶紧上的时候就脚本,后面不行了再慢慢改回编译型.
鱼和熊掌,不可兼得也. 脚本就是这样啊, 火葬场了之后爬出来, 赶快来个热更新就是了.
上帝给你堵住了一扇门, 还会给你开一道窗子 系统的健壮性更多的时候取决于其架构，如何隔离错误。比如 Chrome 用多进程架构避免渲染引擎和插件的崩溃，Python Web Server 利用异常捕捉隔离独立 HTTP 请求的业务错误。
系统的可维护性取决于如何设计系统的模块划分，如何规范模块的外部接口和模块间的通讯，如何降低模块间的耦合度，以使重构影响更少的模块。
设计实践是编译器检查不出来的。 首先，看起来你想说的是静态／动态语言而不是强弱类型的问题，类型强弱跟是否编译语言没有绝对关系，也跟是动态还是静态语言是两回事儿。其次，我其实是 @vczh 这个萝莉控的敌对阵营，但是为啥老是想给他点赞呢？ 前期设计再棒也是无法抵消后期代码熵增的。
java 这样的强类型语言，只能说在IDE的帮助下进行变量/方法重命名，方法提取……等基础重构策略时，比较容易操作。
我们可以把类型检查视为它的内建约束。这些内建约束只能缓解一部分问题。许多需要大规模重构的场景，强类型语言和弱类型语言面临的问题没有差异。
反而是许多弱类型语言，以 ruby 为例，在 ducktype 机制的作用下，逻辑编写十分灵活，许多场景下代码反而是更易维护。
综合来说，解决之道唯有进行严格的测试驱动开发。
测试是很好的手段，能按照自己的想法在各个层面去为代码添加约束。而不是仅仅依赖所谓的类型检查。
测试驱动开发，而不是开发完了再去用所谓单元测试检查扫尾。
这是完全不一样的两种开发思路。
前者会导致代码设计的持续改进。是后者不能比拟的。
用测试去尽可能覆盖需求。进行bugfix时也使用测试驱动。
在持续的代码提交中，逐步提高测试覆盖率。
架设CI服务，如果是github上的项目可以用 https://travis-ci.org/
掌握撰写测试的方法，形成写测试的思想，在此基础上花时间积极重构。
别无他法。 测试脚本：单元测试、接受性测试、压力测试，如果想东西靠谱，一个都不能少。TDD、BDD之说有效的。至于覆盖率的问题，可以后续完善，但必须要由，测试脚本和财富一样是需要积累的。
CI：前面 @宋亮 提到持续集成，这个是也必须的。重复的事情必须要交给机器，人负责创造性的东西。
前提：业务不能重构，否则测试用例和脚本就得重来。
盲区：前端自动自动化测试，主要是浏览器渲染走样的问题。貌似*上有人提过原型图片像素比对的方式做断言，但没实践过。 最初设计的时候应该也是分了模块的，接口也应该设计好了的
重构的使用范围应该限定在模块内部的实现，而即使模块内部的改动即使对模块来说也应该不是太大的吧。
我尝试过弱类型开发，但是后期很难维护，具体表现是几乎无法重构。
是不是会有别的什么办法可以避免这个问题，或者可以支持到健壮的重构？
我一直对动态语言构建系统的维护方式比较好奇，求大神赐教！
——————————
看到很多大神都提到单元测试，确实是可以保证系统重构之后的稳定性
但是我写程序喜欢一边写一边微调程序结构(微重构)，几乎很少单元测试，所以需要类型安全来做随时错误检测。 不知道这个是不是什么好习惯？
回复内容：
动态类型一时爽，项目大了人多了，维护起来都要命，别说重构了。一个API看起来会返回一个A，没人敢保证不会有1%的机会返回个null，再有0.01%的机会返回个B。一个小改动要往下看n层代码才放心，结果commit上去还是挂了。
Facebook就知道错了，搞了个Hack抢救一下…… 不管是什么语言，重构要保持健壮性靠的都是大量的单元测试。这不是脚本独有的问题。 无他，大量可回归的单元测试，集成测试。 多回复一点,其实 @vczh前面说的没错,但是却是个悖论.因为很多时候,人们用脚本语言就是图的开发速度,现在为了让它健壮还得尽可能的单元测试覆盖,老实说,脚本多用在业务逻辑多且变化频率大的领域,单元测试写起来实在蛋疼.
这就好比,本身你用A是为了好处B,但是为了弥补A的缺陷又不得不做一些事情要牺牲好处B.
所以说,个人认为单元测试覆盖对脚本语言开发的项目是个悖论.
我的想法是自己权衡吧,想快赶紧上的时候就脚本,后面不行了再慢慢改回编译型.
鱼和熊掌,不可兼得也. 脚本就是这样啊, 火葬场了之后爬出来, 赶快来个热更新就是了.
上帝给你堵住了一扇门, 还会给你开一道窗子 系统的健壮性更多的时候取决于其架构，如何隔离错误。比如 Chrome 用多进程架构避免渲染引擎和插件的崩溃，Python Web Server 利用异常捕捉隔离独立 HTTP 请求的业务错误。
系统的可维护性取决于如何设计系统的模块划分，如何规范模块的外部接口和模块间的通讯，如何降低模块间的耦合度，以使重构影响更少的模块。
设计实践是编译器检查不出来的。 首先，看起来你想说的是静态／动态语言而不是强弱类型的问题，类型强弱跟是否编译语言没有绝对关系，也跟是动态还是静态语言是两回事儿。其次，我其实是 @vczh 这个萝莉控的敌对阵营，但是为啥老是想给他点赞呢？ 前期设计再棒也是无法抵消后期代码熵增的。
java 这样的强类型语言，只能说在IDE的帮助下进行变量/方法重命名，方法提取……等基础重构策略时，比较容易操作。
我们可以把类型检查视为它的内建约束。这些内建约束只能缓解一部分问题。许多需要大规模重构的场景，强类型语言和弱类型语言面临的问题没有差异。
反而是许多弱类型语言，以 ruby 为例，在 ducktype 机制的作用下，逻辑编写十分灵活，许多场景下代码反而是更易维护。
综合来说，解决之道唯有进行严格的测试驱动开发。
测试是很好的手段，能按照自己的想法在各个层面去为代码添加约束。而不是仅仅依赖所谓的类型检查。
测试驱动开发，而不是开发完了再去用所谓单元测试检查扫尾。
这是完全不一样的两种开发思路。
前者会导致代码设计的持续改进。是后者不能比拟的。
用测试去尽可能覆盖需求。进行bugfix时也使用测试驱动。
在持续的代码提交中，逐步提高测试覆盖率。
架设CI服务，如果是github上的项目可以用 https://travis-ci.org/
掌握撰写测试的方法，形成写测试的思想，在此基础上花时间积极重构。
别无他法。 测试脚本：单元测试、接受性测试、压力测试，如果想东西靠谱，一个都不能少。TDD、BDD之说有效的。至于覆盖率的问题，可以后续完善，但必须要由，测试脚本和财富一样是需要积累的。
CI：前面 @宋亮 提到持续集成，这个是也必须的。重复的事情必须要交给机器，人负责创造性的东西。
前提：业务不能重构，否则测试用例和脚本就得重来。
盲区：前端自动自动化测试，主要是浏览器渲染走样的问题。貌似*上有人提过原型图片像素比对的方式做断言，但没实践过。 最初设计的时候应该也是分了模块的，接口也应该设计好了的
重构的使用范围应该限定在模块内部的实现，而即使模块内部的改动即使对模块来说也应该不是太大的吧。