ABAP开发中的画蛇添足现象

1、NUMBER_GET_NEXT取流水码的时候加锁

好家伙，NUMBER_GET_NEXT为了高并发想尽了各种办法，这一个锁把所有的并发可能性都给堵死了。
NUMBER_RANGE_ENQUEUE调用的是函数ENQUEUE_ESNRIV，这个锁函数是在修改Number Range Object的编号范围的时候加的锁，你用到每一次取号的时候你觉着合适吗？

2、SMOD做完增强后再弄一个CMOD

有些项目出于管理的原因要求在SMOD增强后再定义一个CMOD，这个也纯粹是脱裤子放屁多此一举，为什么这么说呢？因为一个SMOD增强里面可能是好几个流程的逻辑，因为不像是BADI可以定义多个实施，所有流程的增强都得写到一个Function里面，这就决定了一个SMOD不可能统一的激活/取消激活，也就不可能放到CMOD里面统一开关。而且一个SMOD只能放到一个CMOD里面，不可以交叉。

3、报表程序先定义TYPE再定义DATA

说实话这个学院派的做法我一直不知道有啥用处，为啥要弄一个TYPE，这个倒是没有什么明显的坏处，只是我不明白为啥非要这么做。

4、报表使用END-OF-SELECTION事件

你随便抓10个喜欢用这个事件的ABAPer，问他这个事件是什么时候触发，得有9个回答是取数完就会触发。这个回答是错误的，其实这个事件最早是逻辑数据库使用，在关键字GET结束后触发END-OF-SELECTION，OPEN SQL并不会触发这个事件。后来LDB已经极少使用了，除了HR模块在不讲究性能的ABAPer手里还偶尔用一点。

如果程序没有使用LDB，则START-OF-SELECTION事件结束就会触发END-OF-SELECTION，跟START-OF-SELECTION没有区别，所以毫无使用的必要了。

5、普通报表开发中的所谓的CLASS思想

这是一个涉及政治正确的问题，大炮打蚊子也能打死蚊子，但是没有必要。这个问题让AI回答吧：

使用CLASS进行ABAP报表开发会增加代码的复杂性。CLASS是面向对象编程的基础，它包含了数据和方法的封装。虽然这种封装可以局部提高代码的可读性和可维护性，但是在ABAP报表开发中，这种复杂性是不必要的，因为报表通常只需要简单的数据处理和展示。而且，使用CLASS进行报表开发可能会增加开发时间。使用CLASS进行编程需要定义类，实例化对象，调用方法等步骤，这些步骤都需要时间。而在报表开发中，时间通常是非常重要的因素。使用更简单的编程结构，如子程序或函数，可以更快地完成报表开发。再有，使用CLASS可能会增加代码的错误率。在ABAP中，使用CLASS进行编程需要更多的编程知识和技能。如果开发者对面向对象编程的理解不够深入，可能会导致错误的使用CLASS，从而增加代码的错误率。故，在ABAP报表开发中，由于其复杂性，开发时间和错误率的原因，可能不是最佳的选择。

时间有限，先写这么多吧，下次再补充。