程式員為什麼不喜歡低代碼
因為答應要去做這個演講 程式師為什麼不喜歡低代碼
被迫總結輸出一下提綱。 總體上是兩個大方向：
- 好的工程實踐是有原因的，不會因為"低代碼"了，之前的工程實踐都不再適用
- 低代碼不是純技術能實現的目標，需要產品和技術一起努力
工程實踐角度
比如說
- 版本管理
- 發佈變更流程
- 單元測試
- 自動化測試
- 調試器
- 代碼提示
- 出錯提示，代碼行號定位
- common reuse principle 等依賴管理原則
- ...
我們把低代碼換個說法叫「最終用戶程式設計」。。 然後把最終使用者看成一個開發團隊。 那低代碼也是一種軟體開發的形式，只是把最終使用者這個軟體開發團隊引入到了軟體開發過程之中了。 傳統的最佳工程實踐都是有價值的，有必要在低代碼這個語境下一一考量一下其意義。
這裡投入不足，很大程度是因為做這些東西成本巨大。 這裡又牽涉到了，什麼情況下值得弄個低代碼出來，多少收益才能抵消成本。
產品和技術協作角度
低代碼建立在「預製件」的基礎上的，但是低代碼沒有說明這些「預製件」是從哪裡來的。 兩種可能：
- 先有具象的需求，然後逐步歸納出預製件
- 先有預製件，然後把需求往裡面套
當使用低代碼是純技術行為的時候，技術側就會非常難受。 因為低代碼希望的是需求內在有規範有規律，可以被壓縮成預製件。 但是需求是啥樣，那是產品經理說了算的。
無論是歸納出預製件，還是先有預製件再用預製件表達需求，可能都走得通。 但是都不能是靠技術側去推動產品側，而是一起協作來搞，得有組織和流程的保障。
用 c 語言很難精確寄存器，用java很難控制記憶體，用 vue 很難高頻率刷新 DOM 實現動畫，一項技術總是有其代價。 低代碼也一樣，總是會喪失一些適用範圍和場合。 技術選型的事情應該由解決問題的人，根據問題本身的需求選擇技術方案，而不是被指手畫腳。 使用還是不使用低代碼做為技術方案，應該像其他技術選型一樣讓解決問題的人根據需求來決定。 先有需求，再有解決方案。
有時候不是把所有相似的代碼都歸納成一個函數，就一定就能提效的。 比如搞一個 DSL 解決介面元件聯動問題。 這樣的 DSL 弄出來也就是一個 javascript 的變種。 預製件不是你說那裡可以弄一個出來，就一定可以弄一個出來的。 壓縮是建立在有規律，有冗餘的基礎上的。 如果原來的表述方式已經足夠精簡了，就沒有多少壓縮空間。
程式師提效
我們可以從實現低代碼的技術里尋找提效的手段，但不要把任何提效的努力都打上低代碼的標籤。
所見即所得的可視化編輯。 修改了配置，立即生效。 這樣的低延遲的反饋週期是很好的開發者體驗，值得借鑒過來。 如果程式師所有的修改都可以不經過幾十秒的編譯構建就立即看到反饋，顯然能提升效率。 但這不意味著一定要做動態化解釋執行。 弄一個 JSON 出來解釋執行，渲染介面，不意味著就提效了。 恰恰相反，因為引入了動態化，運行時執行的過程會更複雜，整體的代碼量會變大。
代碼生成是常見的所謂model driven方案的特點。 但是代碼生成相對抽取函數的優點是什麼有沒有想過？ 函數要求自己在一個進程內執行（不能跨進程遷移局部變數），也不能執行太長時間（不能持久化下來，過幾天載入回去接著執行）。 函數同時也是一個編輯時的單元，把相關的邏輯合併到了一個總的索引下。 當我們要把跨進程的邏輯合併到一個編輯時單元下的時候，就沒有辦法使用抽取函數的辦法了。 所以"代碼生成"這個技術，或者"DSL"這個技術，允許的是更大的組織邏輯，分類整理的自由度。
另外一個代碼生成的好處是如果用抽取函數的方式，函數的所有分支都要被閱讀才能知道其行為，而代碼生成可以僅僅關注生成后的代碼實際是啥，而忽略生成器的複雜邏輯。
預製件的願景讓產品需求能夠更有內在一致性。 當程式師和產品經理都認同這幾個功能都應該用預製件拼裝出來的時候，就可以從源頭上減少不必要的產品不一致性導致的額外工作量。 所有的提效手段，最管用的還是砍需求。
如何做出讓程式師喜歡的低代碼
- 別讓程式師用。 低代碼的用戶應該是 end-user，程式師提效有無數種辦法，別啥都叫低代碼
- 工程實踐該加的都得有
- 管控預期，不是什麼需求都可以實現的
- 讓程式師提供低代碼支援最終用戶程式設計，需要組織和流程保障（對內的低代碼），或者需要商業模式支援（對外的低代碼）
大概提綱就是這樣了，然後就是補充各種例子了
