有没有办法预处理 ruby 代码并找出运行时会发生的错误?
Is there a way to preprocess ruby code and find errors that would occur runtime?
我们拥有庞大的代码库,我们正在生成一些问题,这些问题本可以在 Java 等类型语言的编译时发现,但直到 运行 时间 [=26] 才发现它们=].这很糟糕,因为我们生成的 bug 大多数时候是拼写错误或重构留下一些无效代码。
示例:
def mysuperfunc
# some code goes here
# this was a valid call but not anymore since enforcesecurity
# signature changed
@system.enforcesecurity
end
我的意思是,IDEs 可以做到,但有些人使用 ATOM 或 sublime,所以我们需要一些东西 "compile" 并报告这类问题,这样他们就无法部署。你一直在用什么?
这会生成我们的错误报告的一小部分,但由于我们被迫以荒谬的速度生成,因此我们没有 100% 的代码覆盖率。如果没有工具可以提供帮助,我将确保每个人都使用 IDE 和 运行 报告以及 Rubymine.
等工具。
我们的堆栈包括 rspec、minitest、SimpleCov。我们强制执行代码审查、多堆栈部署(开发、质量检查、预生产、沙箱、生产)。还有一些问题达到了更高的水平,让我们程序员看起来很糟糕。我不是在寻找魔法,只是希望有一点自动化可能会有所帮助。
我不知道你想要什么。但是,有一些 gem 可以分析代码并警告您一些错误 and/or 不良做法。试试这些:
有一个叫做 guard 的 ruby gem 做自动化测试。您可以设置自己的自定义规则。
例如,您可以在任何时候修改某些文件,测试框架会自动运行。
这是link guard
FLAY
https://rubygems.org/gems/flay
通过回购 https://github.com/seattlerb/flay:
DESCRIPTION:
Flay analyzes code for structural similarities. Differences in literal
values, variable, class, method names, whitespace, programming style,
braces vs do/end, etc are all ignored. Making this totally rad.
[FEATURES:]
- Reports differences at any level of code.
- Adds a score multiplier to identical nodes.
- Differences in literal values, variable, class, and method names are ignored.
- Differences in whitespace, programming style, braces vs do/end, etc are ignored.
- Works across files.
- Add the flay-persistent plugin to work across large/many projects.
- Run
--diff
to see an N-way diff of the code.
- Provides conservative (default) and
--liberal
pruning options.
- Provides
--fuzzy
duplication detection.
- Language independent: Plugin system allows other languages to be flayed.
- Ships with
.rb
and .erb
.
- javascript and others will be
available separately.
- Includes
FlayTask
for Rakefiles.
- Uses
path_expander
, so you can use:
dir_arg
-- expand a directory automatically
@file_of_args
-- persist arguments in a file
-path_to_subtract
-- ignore intersecting subsets of
files/directories
- Skips files matched via patterns in
.flayignore
(subset format of .gitignore
).
- Totally rad.
FLOG
https://rubygems.org/gems/flog
通过回购 https://github.com/seattlerb/flog:
DESCRIPTION:
Flog reports the most tortured code in an easy to read pain report.
The higher the score, the more pain the code is in.
[FEATURES:]
- Easy to read reporting of complexity/pain.
- Uses
path_expander
, so you can use:
dir_arg
– expand a directory automatically
@file_of_args
– persist arguments in a file
-path_to_subtract
– ignore intersecting subsets of files/directories
SYNOPSIS:
% ./bin/flog -g lib
Total Flog = 1097.2 (17.4 flog / method)
323.8: Flog total
85.3: Flog#output_details
61.9: Flog#process_iter
53.7: Flog#parse_options
...
不幸的是,停机问题、赖斯定理以及所有其他不可判定性和不可计算性结果告诉我们,在一般情况下根本不可能静态确定 any "interesting" 属性 关于程序的运行时行为。我们甚至不能静态地确定像 "will it halt" 这样简单的东西,那么我们将如何确定 "is bug-free"?
某些东西可以 静态确定,并且有某些受限程序可以静态确定一些有趣的属性,但在很大程度上,这是不可能的。甚至在很小的程度上 是 可能的,它通常需要专门设计的语言以便于静态分析(Ruby 不是)。
也就是说,有些工具包含某些 启发式方法 以指出 可能 有问题的代码。某些编码标准可能有助于避免错误,并且有一些工具可以强制执行这些编码标准。要搜索的关键字是 "code quality tools"、"linter"、"static analyzer" 等。您已经在其他答案和评论中给出了示例,并且给出了这些示例和这些关键字,您可能会找到更多。
不过,我也想讨论一下你写的东西:
we are forced to produce at a ridiculous pace we don't have 100% code coverage
这是一个问题,必须从两个方面来解决:
- 练习,练习,再练习。您需要练习测试和编写高质量的代码,直到它 so 对您来说很自然 not 实际上最终变得更难和更慢。它应该成为你的第二天性,这样当你的大脑一片空白时,在压力下,唯一你知道的事情就是编写测试并编写设计良好、结构合理、质量高的测试代码。注意:我说的是刻意练习,意思是留出时间真正练习……而练习就是练习,这不是工作,不是乐趣,不是爱好,写完代码不马上删除,你不是在练习,你是在工作。
- 可持续的步伐。你应该 永远不会 开发速度超过你可以无限期维持的速度,同时仍然生产经过良好测试、精心设计、结构合理的高质量代码,拥有充实的社交生活,没有压力, 大量的空闲时间等。这是管理层必须支持和理解的事情。
我们拥有庞大的代码库,我们正在生成一些问题,这些问题本可以在 Java 等类型语言的编译时发现,但直到 运行 时间 [=26] 才发现它们=].这很糟糕,因为我们生成的 bug 大多数时候是拼写错误或重构留下一些无效代码。
示例:
def mysuperfunc
# some code goes here
# this was a valid call but not anymore since enforcesecurity
# signature changed
@system.enforcesecurity
end
我的意思是,IDEs 可以做到,但有些人使用 ATOM 或 sublime,所以我们需要一些东西 "compile" 并报告这类问题,这样他们就无法部署。你一直在用什么?
这会生成我们的错误报告的一小部分,但由于我们被迫以荒谬的速度生成,因此我们没有 100% 的代码覆盖率。如果没有工具可以提供帮助,我将确保每个人都使用 IDE 和 运行 报告以及 Rubymine.
等工具。我们的堆栈包括 rspec、minitest、SimpleCov。我们强制执行代码审查、多堆栈部署(开发、质量检查、预生产、沙箱、生产)。还有一些问题达到了更高的水平,让我们程序员看起来很糟糕。我不是在寻找魔法,只是希望有一点自动化可能会有所帮助。
我不知道你想要什么。但是,有一些 gem 可以分析代码并警告您一些错误 and/or 不良做法。试试这些:
有一个叫做 guard 的 ruby gem 做自动化测试。您可以设置自己的自定义规则。
例如,您可以在任何时候修改某些文件,测试框架会自动运行。
这是link guard
FLAY
https://rubygems.org/gems/flay
通过回购 https://github.com/seattlerb/flay:
DESCRIPTION:
Flay analyzes code for structural similarities. Differences in literal values, variable, class, method names, whitespace, programming style, braces vs do/end, etc are all ignored. Making this totally rad.
[FEATURES:]
- Reports differences at any level of code.
- Adds a score multiplier to identical nodes.
- Differences in literal values, variable, class, and method names are ignored.
- Differences in whitespace, programming style, braces vs do/end, etc are ignored.
- Works across files.
- Add the flay-persistent plugin to work across large/many projects.
- Run
--diff
to see an N-way diff of the code.- Provides conservative (default) and
--liberal
pruning options.- Provides
--fuzzy
duplication detection.- Language independent: Plugin system allows other languages to be flayed.
- Ships with
.rb
and.erb
.- javascript and others will be available separately.
- Includes
FlayTask
for Rakefiles.- Uses
path_expander
, so you can use:
dir_arg
-- expand a directory automatically@file_of_args
-- persist arguments in a file-path_to_subtract
-- ignore intersecting subsets of files/directories- Skips files matched via patterns in
.flayignore
(subset format of.gitignore
).- Totally rad.
FLOG
https://rubygems.org/gems/flog
通过回购 https://github.com/seattlerb/flog:
DESCRIPTION:
Flog reports the most tortured code in an easy to read pain report. The higher the score, the more pain the code is in.
[FEATURES:]
- Easy to read reporting of complexity/pain.
- Uses
path_expander
, so you can use:
dir_arg
– expand a directory automatically@file_of_args
– persist arguments in a file-path_to_subtract
– ignore intersecting subsets of files/directoriesSYNOPSIS:
% ./bin/flog -g lib Total Flog = 1097.2 (17.4 flog / method) 323.8: Flog total 85.3: Flog#output_details 61.9: Flog#process_iter 53.7: Flog#parse_options ...
不幸的是,停机问题、赖斯定理以及所有其他不可判定性和不可计算性结果告诉我们,在一般情况下根本不可能静态确定 any "interesting" 属性 关于程序的运行时行为。我们甚至不能静态地确定像 "will it halt" 这样简单的东西,那么我们将如何确定 "is bug-free"?
某些东西可以 静态确定,并且有某些受限程序可以静态确定一些有趣的属性,但在很大程度上,这是不可能的。甚至在很小的程度上 是 可能的,它通常需要专门设计的语言以便于静态分析(Ruby 不是)。
也就是说,有些工具包含某些 启发式方法 以指出 可能 有问题的代码。某些编码标准可能有助于避免错误,并且有一些工具可以强制执行这些编码标准。要搜索的关键字是 "code quality tools"、"linter"、"static analyzer" 等。您已经在其他答案和评论中给出了示例,并且给出了这些示例和这些关键字,您可能会找到更多。
不过,我也想讨论一下你写的东西:
we are forced to produce at a ridiculous pace we don't have 100% code coverage
这是一个问题,必须从两个方面来解决:
- 练习,练习,再练习。您需要练习测试和编写高质量的代码,直到它 so 对您来说很自然 not 实际上最终变得更难和更慢。它应该成为你的第二天性,这样当你的大脑一片空白时,在压力下,唯一你知道的事情就是编写测试并编写设计良好、结构合理、质量高的测试代码。注意:我说的是刻意练习,意思是留出时间真正练习……而练习就是练习,这不是工作,不是乐趣,不是爱好,写完代码不马上删除,你不是在练习,你是在工作。
- 可持续的步伐。你应该 永远不会 开发速度超过你可以无限期维持的速度,同时仍然生产经过良好测试、精心设计、结构合理的高质量代码,拥有充实的社交生活,没有压力, 大量的空闲时间等。这是管理层必须支持和理解的事情。