[思考] 設計第0步的對話

丫壹 這就是為什麼我要先做「設計」
Elaine 這裡怎麼設計
丫壹 這樣子下去，他所耗的時間都是白工
Elaine 在這裡我還是很不懂你那一天覺得我們已經在想SQL這件事情為什麼就已經在寫CODE了
Elaine 我自己昨天是稍微寫了一下，是按照那天你說的方式去寫
Elaine 確實很順。但我還是不明白
丫壹 重點在於
丫壹 你在接到需求時
丫壹 是在想你是要「哪些資料集合」，還是「哪一張表」
Elaine 我想的是哪一張表
Elaine 哪些表
Elaine 需要
丫壹 前面是抽象設計，後面實作設計
丫壹 如果你一個資料集合是好幾張表組合起來呢
Elaine 所以是哪些表我需要
丫壹 這樣就直接深入「實作」了丫
丫壹 如果code本來不是你寫的，你怎麼在那個時間知道哪一張表
Elaine 不知道，所以要找跟問
丫壹 那是不是變成你在規劃時，又要一邊確認一邊規劃
丫壹 那為何不先利用一些抽象的資料集合概念
丫壹 先知道總共需要哪些資料群
丫壹 這些資料群有什麼樣的關係，或是邏輯計算
Elaine 像是EMP資料，請假資料。這種資料群？
丫壹 對
丫壹 然後在把這個結果去對應到實際的表格之中
丫壹 這樣不是比較明確嗎
丫壹 簡單講一個原則
丫壹 只要你們不是從一個全面的抽象角度去思考
丫壹 而是一直要知道「實際的東西」在哪去才能思考
丫壹 那一 定會一直遇到問題，或是少東西
丫壹 因為你根本不知道全部應該要有多少東西
丫壹 最直接的一個舉例
丫壹 如果我們在拼圖時，不給最後拼圖來的全圖
丫壹 會發生什麼事
Elaine 不能拼阿
丫壹 但你們現在都在這樣子「拼圖」丫
丫壹 還拼的很開心呢
丫壹 ray 的這張報表
丫壹 是一個很基本的東西
丫壹 如果是寫「庫存報表」，你看看你怎麼用那麼細節的資訊來做
丫壹 如果功能是複雜到有關係，又有計算，上下筆資料也有關係的情況下
丫壹 有什麼方式去思考，會差距很多
丫壹 最直接會發生的狀況就是
Elaine 做出來的不是要的
丫壹 你們只能用程式碼去問問題
丫壹 哈，用硬來的也能用出個結果丫
Elaine 恩。以前寫的報表確實都會在程式面上來做最後處理
Elaine 因為sql寫不好～哈
丫壹 所以結論就是
Elaine 或是指能處理一部分
丫壹 你要用別的方式來補那個洞
丫壹 然後愈補又愈大洞
Elaine so trouble
丫壹 這點就是我跟你們在開發跟debug的速度差異最大的地方