※ 引述《a12345x (一隻小浣熊)》之銘言：
: ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.171.53.143
: ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1549048423.A.89A.html
: 推 kurtsgm: 看了只能幫QQ了 真慘 外部被人凹 內部搞不定 02/02 03:20
: 推 iamshiao: 是不是你以為他厲害，其實他廢到有找只是擅長打高空？ 02/02 03:24
: → iamshiao: 我很難相信協調性、耐性、規劃能力跟效率都這麼差的人 02/02 03:24
: → iamshiao: 程式能寫的好到哪去 02/02 03:24
: 資工課程每科甚至碩士課程都能快90
: 跟同學1上課感想就是怎麼每個題目你都會寫
: 剛開始建立db時候是同學1覺得架構不夠正規化
: 因此他提出他的架構叫我把改成這樣
: 這次開放語言也是他教我怎麼起手 之前小弟都沒碰過
: db改版雖然使demo失敗但是他將10欄位y/n用2進位儲存縮減成1個欄位
: 使的後續開發變快
: 他說資料庫上課有教過
: 這樣可以將課堂融會貫通
: 小弟在這方面只能佩服
題外話, 如果你們做的是企業應用系統,
而且會有其他IT接手維運並擴展, 那這樣搞其實不太適合.
實務上如果做到BCNF或以上,
則table會過於分散, 一方面是做報表組資料麻煩, 也可能因為SQL不熟拖慢效能
另一方面是測試功能時會造成自己的困擾, 測一個新功能要從頭造資料到尾浪費時間.
最後, 有可能因為table關聯性已不太明顯, 造成某些功能又要開暫存表來收資料,
那就失去原本高度正規化的優點.
另外, 將狀態欄位使用各種代號縮減到只存在一個欄位,
並不直覺且會造成接手人員維護上的困擾,
除非你們編輯詳盡的代號對應文件.
那又產生一個問題, 未來要投入人力同時維護文件?
若沒有其他衍生問題, 則單純狀態欄位留在該主表並無不妥,
若是多狀態欄位, ex:表單進退關, 再另建表維護.
實務上內部系統開發人力只占整個系統成本的一小部分,
後面維護/擴增要投入的人力才是最大宗.
你同學看來實力非常堅強, 不過他的作法比較適合需要最佳化的產品RD.
: ※ 編輯: a12345x (1.171.53.143), 02/02/2019 03:35:00
: 推 anandydy529: 有一種人是很會用嘴寫程式，讓你遇到了 02/02 03:34
: 推 eeyellow: 你的"Team"從一開始就失控了，一定要先把規則都定好 02/02 03:42
: 推 eeyellow: 錢最重要先說，你親戚先墊錢就不對了，建議先10~20頭款 02/02 03:49
: → eeyellow: 每次Demo過了就再發放一定比例，最後拿到案子才給尾款 02/02 03:50
: → eeyellow: 而且沒合約情況特殊，尾款比例一定要高。像你親戚這麼 02/02 03:51
: → eeyellow: 敢的乙方還真少見 02/02 03:51
: 推 eeyellow: 團隊最怕自以為高手不合群的人 02/02 03:54
: → eeyellow: 你同學這樣獨斷變更Schema，浪費其他人時間 02/02 03:56
: → eeyellow: 不管在哪個公司都會被黑到不行，還敢自稱高手= = 02/02 03:57
: → eeyellow: 最後你補充的那些...是在反串同學是讀死書嗎？ 02/02 03:59
: → eeyellow: 功能沒做出來，案子沒拿到，就先做最佳化...嗯嗯... 02/02 04:00
: 推 alihue: 其實1說的也沒錯，課程顧好效益遠大於這個沒人帶的案子。 02/02 06:51
: → alihue: 雖然是拿來打電動 02/02 06:51
: → testPtt: 協作一定要開spec 口頭講的大家到時候都說當初講得不一樣 02/02 07:06
: 推 vn509942: 類似這種外包臨時約 本身風險就異常高 02/02 09:12
: 推 vn509942: 急件處理一定是找有信譽的老司機（煙 02/02 09:15
: 推 heru: 開會各種不到 工作不照進度自己亂砍DB 光這2點就該踢掉他了 02/02 09:37
: → heru: 有去開會都能產生認知落差了 何況全靠轉述 02/02 09:40
: → x000032001: 一點軟體工程概念都沒有 版控也不用 談需求訂規格也不 02/02 09:41
: → x000032001: 到 再高分有什麼用 02/02 09:41