请问在软件开发过程中如何避免使用硬编码

专注研发ERP低代码开发平台 2015-03-16 04:16:07

请问一下大家，我现在这个项目的逻辑层中经常会出现硬编码的代码，比如像下面：
if(SourceType=="项目验收单")
{}
但现在逻辑层和表现层是两个程序员写的，很难保证他们之间都把SourceType都叫统一了，有时候，负责界面编写的人传过来的值叫"项目验收"，处理逻辑的人又硬编码写成"项目验收单"。请问大家，除了用文档把这些变量名规定死外，要怎么处理这类问题比较好呢？

...全文

773 21 打赏收藏转发到动态举报

写回复

用AI写文章

21 条回复

切换为时间正序

请发表友善的回复…

发表回复

weishaolin13x 2016-05-30

打赏
举报

如果硬编码保存在配置文件里，程序里一定要有默认值，如果配置文件被误删或误改，还可以用默认值恢复回去，

weishaolin13x 2016-05-30

打赏
举报

硬编码还包括数据逻辑和业务逻辑，所以像OA干脆连流程都可以自定义，而不是硬编码逻辑..

huaneramn 2015-03-18

打赏
举报

代码还有软硬之分啊

冷月孤峰 2015-03-18

打赏
举报

这种情况用枚举比较简单方便，记得多沟通

software_artisan 2015-03-17

打赏
举报

引用 15 楼 wggfcusmq 的回复:

[quote=引用 14 楼 sp1234 的回复:] [quote=引用 5 楼 wggfcusmq 的回复:] 我也觉的不靠谱，总觉的会出问题，不安全，界面上的改动性太大了。现在这样子也没有规范，编码的人起什么名就起什么名了。

进行架构修改工作要在你有足够准备的时候，而且要确实必要时才修改可能影响很多人、很多代码的设计规范。不要动不动就“抖一下机灵”去告诉程序员把以前的代码推倒重写。有些东西不一定是多大事儿，不要动不动就搞成了是非，先把进度保持高速，过几十天在合适的时候进行真正的重构。[/quote] 上个项目也是因为全是这样的硬编码，造成了很多bug。有时候需求改变了，或者老总的强制要求，有些名称不得不改，这个地方改了，可能其它很多地方并没有同步改过来，硬编码的代码，编译时又不会报错，所以往往是一个地方改了，引发了很多bug出来。现在这个项目，也算是半道接手的项目，同样存在这个问题，我的经验又有限，只能是尽自己能力了，多请教，边学习边改了。[/quote] 这种硬编码造成的BUG虽然编译器发现不了，但是他们是显性的，很容易发现和修复的。就不用太在意了。再说，修改硬编码的内容时，不能用工程或项目替换功能么？这样该改的地方一个也漏不掉啊。好吧，我自己就经常这样干。因为这样干很省事，即使出点问题，也不是什么难以解决的问题。综合起来，性价比还是比较高的。

专注研发ERP低代码开发平台 2015-03-16

打赏
举报

引用 14 楼 sp1234 的回复:

[quote=引用 5 楼 wggfcusmq 的回复:] 我也觉的不靠谱，总觉的会出问题，不安全，界面上的改动性太大了。现在这样子也没有规范，编码的人起什么名就起什么名了。

进行架构修改工作要在你有足够准备的时候，而且要确实必要时才修改可能影响很多人、很多代码的设计规范。不要动不动就“抖一下机灵”去告诉程序员把以前的代码推倒重写。有些东西不一定是多大事儿，不要动不动就搞成了是非，先把进度保持高速，过几十天在合适的时候进行真正的重构。[/quote] ”把进度保持高速“这个真的很认同啊，以前经常也是因为有代码洁癖，总纠结一些代码片断，比如变量的命名，代码的排版，废弃不用的类和方法一定要删除，还总想套用一些设计模式进去，结果项目经常性拖进度。

专注研发ERP低代码开发平台 2015-03-16

打赏
举报

引用 14 楼 sp1234 的回复:

[quote=引用 5 楼 wggfcusmq 的回复:] 我也觉的不靠谱，总觉的会出问题，不安全，界面上的改动性太大了。现在这样子也没有规范，编码的人起什么名就起什么名了。

以专业开发人员为伍 2015-03-16

打赏
举报

引用 5 楼 wggfcusmq 的回复:

我也觉的不靠谱，总觉的会出问题，不安全，界面上的改动性太大了。现在这样子也没有规范，编码的人起什么名就起什么名了。

进行架构修改工作要在你有足够准备的时候，而且要确实必要时才修改可能影响很多人、很多代码的设计规范。不要动不动就“抖一下机灵”去告诉程序员把以前的代码推倒重写。有些东西不一定是多大事儿，不要动不动就搞成了是非，先把进度保持高速，过几十天在合适的时候进行真正的重构。

专注研发ERP低代码开发平台 2015-03-16

打赏
举报

引用 11 楼 sp1234 的回复:

代码不是编程的目的，更不能用前期垃圾文档作为验收的标准。标准应该是基于验收测试过程，而不是代码或者前期文档（前期文档应该勇于放弃）。如果说规定要每天自动走50遍流程，让“项目验收”自动进入系统、触发操作、验证结果，如果结果正确，那么人家写“项目验收单”你就随他去写好了。你只要问“为什么‘项目验收’条目通不过测试”就行了。你可以先不要对他写“项目验收单”说三道四，这样就能少引起程序员反感。接下来，当需要收拢你的权利的时候，你可以要求“删除多余的代码”。如果一个代码被删除了也照样能够通过产品验收测试，那么就应该删除。这样人家自然就有人喜欢把“项目验收单“给删除掉了。不要用“洁癖”来要求程序员，不要事后才对人家说三道四，要允许有“灰色”的个人爱好。你只要问对方“为什么‘项目验收’走不通”就行了，不要问对方为什么喜欢加一个“单”字。

多谢指导，对不同程序员不同的编码习惯有时候真的很无语，有些人喜欢一段代码后面加两个换行，有些加一个换行，有些甚至不换行，有些人起变量名就起个abc类的，不好要求。

以专业开发人员为伍 2015-03-16

打赏
举报

引用 8 楼 wggfcusmq 的回复:

多谢大家，我用枚举将所有表单类型都枚举出来，让大家直接引用枚举吧。

除非一个管理者自己身先士卒写每一行代码，否则种事后诸葛亮的方式，你重复不了多少遍的。你把代码弄成某个人事先写好、个人拥有了，不一定就能真正解决效率问题。真正引起争议的，可能是管理者总是指责别人、总想用什么“重新推到重来制定新规范”来卡程序员，而不是引导程序员。

以专业开发人员为伍 2015-03-16

打赏
举报

代码不是编程的目的，更不能用前期垃圾文档作为验收的标准。标准应该是基于验收测试过程，而不是代码或者前期文档（前期文档应该勇于放弃）。如果说规定要每天自动走50遍流程，让“项目验收”自动进入系统、触发操作、验证结果，如果结果正确，那么人家写“项目验收单”你就随他去写好了。你只要问“为什么‘项目验收’条目通不过测试”就行了。你可以先不要对他写“项目验收单”说三道四，这样就能少引起程序员反感。接下来，当需要收拢你的权利的时候，你可以要求“删除多余的代码”。如果一个代码被删除了也照样能够通过产品验收测试，那么就应该删除。这样人家自然就有人喜欢把“项目验收单“给删除掉了。不要用“洁癖”来要求程序员，不要事后才对人家说三道四，要允许有“灰色”的个人爱好。你只要问对方“为什么‘项目验收’走不通”就行了，不要问对方为什么喜欢加一个“单”字。