要回答這個問題，首先要明確啥程度算“零編碼”？
以 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. 高性能
直接簡化數據準備的工作還不夠，實現再簡單跑不快也不行。所以，還要高性能，至少不能比原來跑的慢吧，大家都是講道理的人；
以上是我認爲數據準備工具必備的能力，其他還有一些能力不是特別重要，但如果有最好了。包括：
* 有沒有易用的編輯調試環境，可以很方便地調試算法；
* 爲了更快能不能並行計算
* 有沒有標準接口可以讓其他程序或工具調用
等等，實際要用的時候照着這些特點去找就行了，有益無害。
說了這麼多，總結來說，“零編碼製作報表”的確更像一句口號，沒法真正做到，但可以不斷努力接近這個目標，求其上得其中嘛。