Fw: [請益] CURD開發時間推估

看板Soft_Job作者 (飄飄渺渺所為誰)時間4年前 (2019/07/12 12:31), 編輯推噓16(17推 1噓 76→)
留言94則, 17人參與, 4年前最新討論串1/1
※ [本文轉錄自 Programming 看板 #1TA0j_Vb ] 作者: howardgj94 (飄飄渺渺所為誰) 看板: Programming 標題: [閒聊] CURD開發時間推估 時間: Fri Jul 12 12:24:29 2019 大家好， 本人算算，畢業後踏入職場也邁入第二年了， 回想大學專題做影音系統，負責後台資料處理（HADOOP）的部份， 研究所做資料科學的研究， 進入職場後，從資料科學轉做系統開發。 因為在財團法人，只要系統出的來，對於開發環境有很大的自由度， 所以每次開發時，都會想辦法去接觸新的框架跟軟工架構。 （財團法人的缺點，只要看成果，但希望在當兵這三年，可以把這缺點化成優勢， 於是在這一年多來，只要接臅新的案子，就想多學一點不同架構） 這一年來，陸續碰過原生的php開發、cordova、 學寫phpunit測試、laravel MVC架構、 vue與laravel的集成架構、java spring MVC架構、junit測試、 react + redux + react-route前端架構等。 因為研究所boss是軟工專常的關係，我踏入職場後，對軟體架構的要求比較高， 例如開發時盡量遵守TDD開發原則、repository模式將資料庫邏輯分開、資料庫使用 orm 或 entity framework，而不直接操作sql語句、又或者是前端使用redux模式 將action 跟 view盡量抽離等。 老實說，這些東西以我目前看到，至少在唉唉唉裡面，是不太重視這些東西的。 最近在開發新的案子，資料庫架構設計完，開始投入app撰寫。寫了一陣子，被一個 同事說，「覺得你開發速度太慢了，這東西我xx（時間）就開發完了，不須要這麼久。 於是我根據git記錄開始追溯我的開發時間， 發現以普通不太過複雜的資料庫crud撰寫來看， 從unit test撰寫、repository設計、mvc test撰寫，controller設計、 到前端畫面設計、串連api，debug，這整個動作做完 平均大概要花費一到兩個工作天。 以成效來看，似乎真的不是很有效率。 當然這次使用redux react跟java spring都算新東西，要算學習成本進去， 但以我git紀錄來看，一個crud前後台完成，大約就是一到兩個工作天。 好奇大家在開發crud時，大概會花多久時間呢？ 現在有自動生成crud的工具，但似乎彈性不夠大，也不夠好用，所以我沒接觸。 如果能把crud時間縮短，整個開發時程可以縮很多。 另外，tdd drive的開發模式，在目前台灣軟體業界流行嗎，財團法人有點太學校了，感 覺接觸的不一定是業界目前的流行。如果可以的話，未來希望自己還能碰一些CI/CD的工 具。 另外題外話，tdd drive的好處是，你必須在寫程式前就先把架構想好，而且為了做到 unit test，程式必須解耦合，也就是說，如果測試寫的好，基本上設計出來的程式會非 常的符合SOLID原則，當然這是最理想的狀況。 剛開始摸redux時，並沒有想到給前台也寫測試，當時看到redux官方給的todo範例時就非 常不解，為什麼要把畫面分成component跟container。後來開始思考如何寫測試時才發現 ，分開畫面跟動作的原因，是為了能夠撰寫unit test，另外這樣寫才能讓前端的action 跟view能夠真正的分離。 不過目前我的前端是還沒有撰寫test，前端對我來說，光要把畫面調好、設計畫面就花 太多功了，現在如果還要加上test的話，估計crud就要花兩個工作天或以上了. -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.92.18.246 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Programming/M.1562905471.A.7E5.html ※ 發信站: 批踢踢實業坊(ptt.cc) ※ 轉錄者: howardgj94 (140.92.18.246 臺灣), 07/12/2019 12:31:27
→
07/12 12:43, 4年前 , 1F
他快只考慮MVP吧 要寫測試就是會拉長開發時間
07/12 12:43, 1F
→
07/12 12:46, 4年前 , 2F
有測試 長時間下來是好的 但如果專案很快就結束就...呵呵
07/12 12:46, 2F
→
07/12 12:49, 4年前 , 3F
看性質考慮要寫成可不可測,好不好維護等 但感覺你是一條龍
07/12 12:49, 3F
→
07/12 13:13, 4年前 , 4F
我的案子都是個人或雙人案子，我的確以前堅持用tdd模
07/12 13:13, 4F
→
07/12 13:13, 4年前 , 5F
式一條龍，最近工具會多了才開始思考時間成本的問題
07/12 13:13, 5F
推
07/12 13:17, 4年前 , 6F
外面87%都是功能能動就好，test都沒寫了還TDD XDD
07/12 13:17, 6F
推
07/12 13:53, 4年前 , 7F
現實是你要這樣幹就去外商搞大部份多的是隨便弄求過就好
07/12 13:53, 7F
推
07/12 14:21, 4年前 , 8F
看是長期產品，還是 poc 而已?
07/12 14:21, 8F
→
07/12 14:22, 4年前 , 9F
概念驗證的案子，用做長期產品的思維太浪費時間
07/12 14:22, 9F
→
07/12 14:22, 4年前 , 10F
外面程式還沒寫到一半,需求就不知調過幾次了,TDD是啥?
07/12 14:22, 10F
推
07/12 15:59, 4年前 , 11F
III不同部門差很多的樣子
07/12 15:59, 11F
推
07/12 17:04, 4年前 , 12F
接案建議不要用TDD模式去開發 根本不可能如你所意..
07/12 17:04, 12F
推
07/12 17:39, 4年前 , 13F
如果主管不懂tdd 就會覺得你做事慢，然後就黑掉
07/12 17:39, 13F
→
07/12 18:22, 4年前 , 14F
肯花時間寫測試就要痛哭流涕了
07/12 18:22, 14F
推
07/12 18:31, 4年前 , 15F
堅持下去 你是對的
07/12 18:31, 15F
→
07/12 18:51, 4年前 , 16F
先學會分辨你的同事雷不雷，不然意見也是聽一半就好 他所謂
07/12 18:51, 16F
→
07/12 18:51, 4年前 , 17F
的快，要是留下一堆技術債你只是不知道
07/12 18:51, 17F
→
07/12 20:06, 4年前 , 18F
同事要說的話，從大學開始開發系統，到現在有五年多的
07/12 20:06, 18F
→
07/12 20:06, 4年前 , 19F
開發經驗，研究所幫老師寫公司系統.我自己評價，他可
07/12 20:06, 19F
→
07/12 20:06, 4年前 , 20F
以以很短的時間完成任務，品質也還ok，風格有自己一套
07/12 20:06, 20F
→
07/12 20:06, 4年前 , 21F
，但不著重軟工架構
07/12 20:06, 21F
→
07/12 20:08, 4年前 , 22F
大概就mvp寫很好的人吧，畢竟他們boss跟在唉唉唉開發
07/12 20:08, 22F
→
07/12 20:08, 4年前 , 23F
的系統都算概念系統，無法判斷真實上線的維護問題
07/12 20:08, 23F
推
07/12 22:20, 4年前 , 24F
時程及專案週期和專案性質都是重要考量因素，如果接案性質
07/12 22:20, 24F
→
07/12 22:20, 4年前 , 25F
的，通常專案週期比較短，而需求變動速度可能也很快，連測
07/12 22:20, 25F
→
07/12 22:20, 4年前 , 26F
試都不寫了別說TDD。後來有長期專案，但專案初期在時程壓
07/12 22:20, 26F
→
07/12 22:20, 4年前 , 27F
力下完成MVP，測試碼就變成後補，有些地方寫的很臭XD，目
07/12 22:20, 27F
→
07/12 22:20, 4年前 , 28F
前專案算比較穩定，所以開始補上測試+重構程式
07/12 22:20, 28F
→
07/13 00:42, 4年前 , 29F
以一個過來人的經驗跟你分享：讓自己作到TDD開發
07/13 00:42, 29F
→
07/13 00:42, 4年前 , 30F
比他們不寫測試還快，他們就會閉嘴了。
07/13 00:42, 30F
→
07/13 00:43, 4年前 , 31F
老闆向來不在乎大家是不是TDD，只要你能又快、又好
07/13 00:43, 31F
→
07/13 00:45, 4年前 , 32F
分享我最近在客戶那邊的戰果：http://bit.ly/2YOxPY0
07/13 00:45, 32F
→
07/13 00:45, 4年前 , 33F
3人的mob-programming, TDD, 三地開發, agile/scrum
07/13 00:45, 33F
→
07/13 00:46, 4年前 , 34F
三天進度over deliver一個sprint的進度
07/13 00:46, 34F
→
07/13 00:46, 4年前 , 35F
老闆跟PO顯得非常滿意，更別說我們順手把舊的架構整理好
07/13 00:46, 35F
推
07/13 01:57, 4年前 , 36F
樓上大概沒待過那種，需求早上講完下午就變了一套，然
07/13 01:57, 36F
→
07/13 01:57, 4年前 , 37F
後隔天問你寫得如何的公司...
07/13 01:57, 37F
→
07/13 02:10, 4年前 , 38F
那就讓你自己擁有選擇公司的能力，這是最直接的解決方式
07/13 02:10, 38F
→
07/13 02:11, 4年前 , 39F
不過誰都會碰到時程問題，就看你怎麼解決時程的問題
07/13 02:11, 39F
推
07/13 02:17, 4年前 , 40F
果然還是逃嗎XD 我只能說台灣有很大一部分公司都推不
07/13 02:17, 40F
→
07/13 02:18, 4年前 , 41F
了你說的東西，就算叫TDD之父來也一樣，這就是現實
07/13 02:18, 41F
→
07/13 02:19, 4年前 , 42F
逃？我只是覺得待在一個環境裡面自怨自艾，很浪費人生
07/13 02:19, 42F
→
07/13 02:20, 4年前 , 43F
可能台灣其他部份的公司都願意找我去幫忙吧 :P
07/13 02:20, 43F
→
07/13 02:20, 4年前 , 44F
我倒是覺得先不要管推不推，先看自己做不做得到比較實際
07/13 02:20, 44F
推
07/13 02:25, 4年前 , 45F
也是啦，自己先學會，等哪天有機會就能派上用場了
07/13 02:25, 45F
→
07/13 02:27, 4年前 , 46F
總會有需要你能力的地方，所以不要原地踏步被糟蹋了
07/13 02:27, 46F
推
07/13 02:28, 4年前 , 47F
倒是好奇台灣哪些公司真的有導這些東西的阿？
07/13 02:28, 47F
→
07/13 02:29, 4年前 , 48F
每次面試都講得很完整，進去各種台式敏捷+ 0 test
07/13 02:29, 48F
→
07/13 02:29, 4年前 , 49F
在台灣的外商算嗎？XD 不過我都不推薦大家「導」TDD
07/13 02:29, 49F
→
07/13 02:31, 4年前 , 50F
其實老闆真的不在乎你怎麼寫，他們只要結果又快又好
07/13 02:31, 50F
→
07/13 02:31, 4年前 , 51F
但如果你們作到又快又好，而需要他們一些support, 他們
07/13 02:31, 51F
→
07/13 02:31, 4年前 , 52F
會很樂意提供你協助的，只要你能作到他們要的
07/13 02:31, 52F
→
07/13 02:32, 4年前 , 53F
現在的鈦坦、Line裡面的工法素質都很不錯
07/13 02:32, 53F
→
07/13 02:33, 4年前 , 54F
QA/QE/SDET 比較完整的，就趨勢跟 KKBOX
07/13 02:33, 54F
→
07/13 02:33, 4年前 , 55F
我之前在yahoo的幾個團隊也做得挺扎實的
07/13 02:33, 55F
→
07/13 02:34, 4年前 , 56F
如果我有能力，老闆願意相信我，他們沒有測試其實挺好的
07/13 02:34, 56F
→
07/13 02:34, 4年前 , 57F
這不就是貢獻自我價值的舞台嗎？
07/13 02:34, 57F
推
07/13 02:39, 4年前 , 58F
導 test 看老闆/技術主管本身有沒有被雷包痛到過，痛過幾次
07/13 02:39, 58F
→
07/13 02:39, 4年前 , 59F
然後又是執行重要專案/長期維護產品就會導入了
07/13 02:39, 59F
→
07/13 02:40, 4年前 , 60F
我長期維護EC平台，第一年後端不是我寫，同事雖然資深但就是
07/13 02:40, 60F
→
07/13 02:40, 4年前 , 61F
不肯導入任一 test 去驗證他的程式沒問題
07/13 02:40, 61F
→
07/13 02:41, 4年前 , 62F
結果花了一年的時間在那裡修各種問題修到差點還要賠錢
07/13 02:41, 62F
推
07/13 02:41, 4年前 , 63F
看起來不是大公司就是外商呢...
07/13 02:41, 63F
→
07/13 02:42, 4年前 , 64F
次年我接手專案的後端去寫了v2 因為該語言/框架其實我不熟
07/13 02:42, 64F
→
07/13 02:42, 4年前 , 65F
但是開發經驗有 而且該框架的測試環境算很成熟
07/13 02:42, 65F
→
07/13 02:43, 4年前 , 66F
我花了大概半年多的時間整個把全部的功能重寫
07/13 02:43, 66F
→
07/13 02:43, 4年前 , 67F
客戶也願意付錢等 因為他們被雷到怕了
07/13 02:43, 67F
→
07/13 02:44, 4年前 , 68F
現在每次加工能或是做前端什麼的 完全不用擔心會炸掉還是出
07/13 02:44, 68F
→
07/13 02:44, 4年前 , 69F
現例外狀況的問題
07/13 02:44, 69F
→
07/13 02:45, 4年前 , 70F
甚至連其他第三方系統沒事偷改規格或調整都可以測的到
07/13 02:45, 70F
→
07/13 02:46, 4年前 , 71F
那種過程就是真的只有一個字能形容 就是他媽的很爽 不用沒
07/13 02:46, 71F
→
07/13 02:46, 4年前 , 72F
把握說程式部署到好幾台主機後可能有問題之類的
07/13 02:46, 72F
→
07/13 02:47, 4年前 , 73F
像我自己會在前端的程式利用GA用事件跟傳送例外錯誤訊息，然
07/13 02:47, 73F
→
07/13 02:47, 4年前 , 74F
後用自訂報表去彙整這些資料
07/13 02:47, 74F
推
07/13 02:48, 4年前 , 75F
同感，這種真的是被炸過才會重視，甚至還會幫你排時間
07/13 02:48, 75F
→
07/13 02:48, 4年前 , 76F
當你一個重大新介面的改版上線後，一整個禮拜都沒有錯誤時
07/13 02:48, 76F
→
07/13 02:48, 4年前 , 77F
那種感覺真的很好
07/13 02:48, 77F
→
07/13 02:48, 4年前 , 78F
"開發"這塊XD
07/13 02:48, 78F
→
07/13 02:49, 4年前 , 79F
為什麼 因為我那個平台一天的營業額很高 你炸掉還是什麼就是
07/13 02:49, 79F
→
07/13 02:49, 4年前 , 80F
影響到人家的公司
07/13 02:49, 80F
→
07/13 02:49, 4年前 , 81F
我一個朋友也是做EC的 不過他也是有做營運
07/13 02:49, 81F
→
07/13 02:50, 4年前 , 82F
某一天動了資料庫 結果不慎搞毀資料 花了不少時間救回 雖然
07/13 02:50, 82F
→
07/13 02:50, 4年前 , 83F
說只掛了一點時間 但噴了十幾萬去賠客戶
07/13 02:50, 83F
→
07/13 02:51, 4年前 , 84F
我只能說 真的有些東西值得細心去處理 但前提是 你待地方知
07/13 02:51, 84F
→
07/13 02:51, 4年前 , 85F
道那個價值
07/13 02:51, 85F
→
07/13 02:54, 4年前 , 86F
是說 其實寫測試也不會太慢 只是一開始會卡比較久這麼設計
07/13 02:54, 86F
→
07/13 02:54, 4年前 , 87F
做久了其實很多東西也是差不多那樣
07/13 02:54, 87F
→
07/13 02:55, 4年前 , 88F
因為你不寫 你手動反覆調適也累 我覺得要多利用工具做自動
07/13 02:55, 88F
→
07/13 02:55, 4年前 , 89F
化來省時間
07/13 02:55, 89F
噓
07/13 21:10, 4年前 , 90F
錯字好多
07/13 21:10, 90F
推
07/15 18:47, 4年前 , 91F
可以玩玩 laravel nova
07/15 18:47, 91F
推
07/19 08:46, 4年前 , 92F
單表crud 一小時吧
07/19 08:46, 92F
→
07/19 08:46, 4年前 , 93F
重點是背後邏輯要清楚
07/19 08:46, 93F
→
07/19 08:47, 4年前 , 94F
一小時包含測試code
07/19 08:47, 94F
‣ 更多 howardgj94 的文章
文章代碼(AID): #1TA0qWxu (Soft_Job)