要回答这个问题，首先要明确啥程度算“零编码”？
以 Excel 为例，如果把写 Excel 公式（包括复杂一些的）看做零编码；而把写 Excel VBA 看做编码的话，
报表开发是可以零编码的！
但是，这有个前提：在数据（集）准备好的情况下才可以零编码！
为什么这么说？
我们知道报表开发主要分两个阶段：
第一阶段是为报表准备数据，也就是把原始数据通过 SQL/ 存储过程加工成数据集；
第二阶段是使用已准备的数据编写表达式做报表呈现。在报表工具提供的 IDE 里可视化地画出报表样式，然后再填入一些把数据和单元格绑定的表达式就可以完成报表呈现了，虽然表达式可能比较复杂，但相对硬编码要简单得多（Excel 公式和 VBA 的关系）。所以说这个阶段是能做到“零编码”的。
那报表数据准备怎么办？
很遗憾，这个阶段没法零编码，一直以来只能硬编码，想想我们报表里写的嵌套 SQL、存储过程、JAVA 程序就知道了。为什么报表工具发展这么多年报表呈现已经完全工具化而报表数据准备的手段还这样原始呢？因为这个阶段太复杂了，不仅涉及计算逻辑的算法实现，还涉及报表性能（要知道大部分报表性能问题都是数据准备阶段引起的）。
那报表数据准备是不是没办法了呢？
虽然不能做到零编码，但可以朝着简单化的方向努力，将数据准备阶段也工具化，这样可以使用工具提供的便利来简化报表数据准备阶段的工作，从而进一步简化报表的开发。
那怎么实现报表数据准备工具化？
要实现这个目标并不容易，像上面提到要考虑的内容有点多，大体来说数据准备工具至少要满足这几方面：
1. 具备完备的计算能力
说的有点拗口，掰开了其实在说既然在工具里做数据计算，那得让我什么都能算吧，不能原来 SQL/JAVA 写的放到这里就不行了，该有的计算方法和类库都应该有，最好用起来还比较简单（比原来硬编码难就没意义了），专业的说法叫：计算体系是完备的；
2. 支持热切换
这点是相对 JAVA 来说的，通过数据准备工具生成的算法应该是解释执行的，不能每次改完报表还要重启应用，即时修改即时生效；
3. 具备多源混算能力
通过数据准备工具可以同时连接多种数据源（RDBMS、NoSQL、TXT、Excel、Hadoop、HTTP、ES、Kafka 等等）进行计算，混合计算，这个数据源读个表、那个数据源加载个文件，两部分数据可以 join 到一起混算。现在我们的数据源太多了，报表常常会跨数据源取数，支持了异构源混算以后，原来还要考虑诸如数据是不是先入到一个库里的事情就不用管了，那叫一个清爽；
4. 高性能
直接简化数据准备的工作还不够，实现再简单跑不快也不行。所以，还要高性能，至少不能比原来跑的慢吧，大家都是讲道理的人；
以上是我认为数据准备工具必备的能力，其他还有一些能力不是特别重要，但如果有最好了。包括：
* 有没有易用的编辑调试环境，可以很方便地调试算法；
* 为了更快能不能并行计算
* 有没有标准接口可以让其他程序或工具调用
等等，实际要用的时候照着这些特点去找就行了，有益无害。
说了这么多，总结来说，“零编码制作报表”的确更像一句口号，没法真正做到，但可以不断努力接近这个目标，求其上得其中嘛。