→ DrizztMon: 所以問題其實是人 好的人才能把概念落實到實務 07/25 16:23
→ DrizztMon: 上篇DrTech板友就指出來了 07/25 16:25
推 abccbaandy: 這行不就這樣，一陣子就有新東西，敏捷就剛好名稱取 07/25 16:34
→ abccbaandy: 個好，下一個猜是low code no code 07/25 16:35
→ abccbaandy: 的* 07/25 16:35
→ Lordaeron: 問題是人是一定的了，哪有一種法規是自己會執行的? 07/25 17:35
→ Lordaeron: 但重點是，這是兩位沒實績的人寫出來的東西。 07/25 17:36
→ shadow0326: low code我看是不行了啦 他要炒作的時機點剛好在GPT問 07/25 17:52
→ shadow0326: 市之前一點 GPT一出來聲量就沒救了 錯過炒作時機 07/25 17:53
噓 MoonCode: 07/25 19:47
→ yamagishi: 一個公司的共同 code style 跟老屁股告訴你有甚麼好用 07/25 21:14
→ yamagishi: 的共同方法庫之類的吧 07/25 21:14
→ yamagishi: 像是產 json 的方法那麼多，各自都用各自的方法的話有 07/25 21:17
→ yamagishi: 問題的時候又是一筆時間成本 07/25 21:17
→ Lordaeron: 用什麼framework 不是在案子開始時定好的? 07/25 21:25
→ Abbee: low code怎會不行,一堆搭上gpt的low code來推銷,似乎蠻好用 07/25 23:22
推 abccbaandy: 初看當然好用阿，但真的用下去就知道了... 07/26 00:20
推 crossdunk: 說到low code 之前的Dreamweaver算不算一種 07/26 08:33
推 Nitricacid: labview winform 算不算 low code== 07/26 08:39
推 MiracleShot: Code review當然是正確性優先啊！幫忙抓沒考慮到的ca 07/26 10:04
→ MiracleShot: se，還有是否有遵守共同的style ，其實最主要是互相 07/26 10:04
→ MiracleShot: 抓對方的blind spot 07/26 10:04
→ MiracleShot: 至於可讀性很主觀，但我通常會示範怎麼寫比較簡單易 07/26 10:04
→ MiracleShot: 懂，取得共識 07/26 10:04
推 hegemon: 很多人亂用資料結構，演算法亂寫，你用code scan tool上 07/26 11:27
→ hegemon: 找不出問題呀，這時候只能靠code review 07/26 11:27
→ hegemon: 你看過一堆人檢查是否存在用list在那邊contains 然後在那 07/26 11:29
→ hegemon: 邊納悶為什麼效能很差就會覺得需要code review 07/26 11:29
→ Lordaeron: 正確性，就需要讀需求，就是一份工作兩人分。至於 07/26 13:16
→ Lordaeron: 效能問題，嗯，台灣的問題不大。 07/26 13:17
推 abccbaandy: 你list都能放進APP了，效能能差到哪...又不是刷題 07/26 13:20
噓 hegemon: 你沒遇過有人把10萬個items放進list，然後用contains去找 07/26 13:39
→ hegemon: 新進來的有沒有在list內？還看過更神的還用for loop去做e 07/26 13:39
→ hegemon: quals比對找item?這樣效能不會有問題？ 07/26 13:39
→ Lordaeron: 以現在的PC來說，10萬不算數字。要能讓你明顯感覺到基 07/26 14:01
→ Lordaeron: 本是50萬起。再說contains 的行為和for loop 何異？ 07/26 14:03
→ Lordaeron: 另外，是否存在，別以為用hash 就一定快。哪還是取決 07/26 14:03
→ Lordaeron: 於你的key 的分佈如何。 07/26 14:04
噓 hegemon: 真的遇到再跟我說10萬不是數字吧，你的base跟要比對的量 07/26 14:21
→ hegemon: 都是10萬等級的還不是數字嗎？ 07/26 14:21
→ Lordaeron: er...真的遇到的是破千萬的，十萬的一直都不當回事。 07/26 14:48
→ Bencrie: 十萬跑 list 迭代很有感吧 07/26 14:58
→ Lordaeron: 你是寫C? java? C#? python? VBS? 07/26 15:19
→ Lordaeron: 好說也給個SAMPLE CODE 出來有感一下吧。 07/26 15:21
噓 Ghamu: 蠻猛的 怎麼現在連code review都要被翻桌了 07/26 22:46
→ Ghamu: 這不是基本常識嗎... 07/26 22:46
→ Ghamu: 沒人review 推一個叫做nbNumber的變數上去 你猜猜看是什麼 07/26 22:50
→ Ghamu: 意思^^ 07/26 22:50
→ Ghamu: openWheat() function huahaGift是啥^^ 07/26 22:50
→ Lordaeron: 哦,連變數命名都出來呢。真的是笑死人。 07/26 22:54
→ Lordaeron: 想必你對你做的案子的英文的名詞都非常熟，還能中英對 07/26 22:54
→ Lordaeron: 照呢. 07/26 22:54
→ Ghamu: review最基本要寫到第二個人能看得懂 接著確保基本正確性 07/26 22:57
→ Ghamu: 有時間可看有沒有更好的寫法能提出來 很多時候這個過程幫助 07/26 22:57
→ Ghamu: 產品更好 也是讓自己能進步的方式 因為其他成員可能有更好 07/26 22:57
→ Ghamu: 你沒想到的方法 教學相長也可以進步 07/26 22:57
→ Ghamu: 牛逼數字 開麥客風 豪華禮物 你答對了嗎^^ 07/26 22:58
推 Ghamu: review過的話這些垃圾就不會進去害人害己了 07/26 23:02
→ Lordaeron: 案子不趕，人力很多，高手很自信他的寫法更好。review! 07/26 23:19
推 Ghamu: 很趕的話喬一下review看重點正確性就好了 除非無法忍受的東 07/27 01:04
→ Ghamu: 西不然就別修 或是先註解之後再修也是一個方式 07/27 01:04
→ Ghamu: 之前書上也有講過了 很多時候寫程式寫都很快 但看會很久 因 07/27 01:06
→ Ghamu: 為寫太爛了 為了寫快寫一堆垃圾 幾週後出問題你回來看可能 07/27 01:06
→ Ghamu: 連你這跟親爹都認不得 最後還是功德迴向到自己身上 07/27 01:06
→ Lordaeron: 看別人的正確性，就是自己沒事做，專做這一塊. 07/27 09:08
→ Lordaeron: 就是人力過剩. 07/27 09:08
→ Lordaeron: 要不然,大家都有自己的要寫,誰有這命去批改作業,還吃 07/27 09:09
→ Lordaeron: 力不見得討好的. 正如,你認為你的寫法比較好, 07/27 09:10
→ Lordaeron: 我認為我的沒問題，就有人說10萬就很有感,我是無感. 07/27 09:10
→ Lordaeron: 這時誰來裁決? 有一位全部人都認同的大神來裁決? 07/27 09:11
→ Lordaeron: 還是就隨他去? 哪reviewer的不爽,改成reviewer的,則 07/27 09:12
→ Lordaeron: 原作不爽. 不然再花時間寫一個測試, 來評比? 07/27 09:12
→ Lordaeron: benchmarking 來一翻兩瞪眼, 時間太多? 07/27 09:13
→ Lordaeron: 不是週週要sprint? 這要不要加插進去sprint? 07/27 09:14
噓 s06yji3: 幫人家改作業沒必要。但是你是project owner不看的話都 07/27 10:29
→ s06yji3: 不怕人家塞什麼垃圾進去嗎？ 07/27 10:29
→ Lordaeron: 這麼怕就不要找這些人一起做囉。再說，我要是想做點什 07/27 11:19
→ Lordaeron: 你真的有本事找出來? 07/27 11:20
噓 s06yji3: Who knows :) 07/27 13:39
→ Lordaeron: 真的能回廢話，who knows 有什麼好合作的? 07/27 16:42
→ Burwei: code review確實花時間但利大於弊吧，除了正確性外，程式 07/27 17:41
→ Burwei: 碼品質好未來比較好維護，短空長多 07/27 17:41
→ Burwei: 但如果案子簡單以後也不負責維護，那為了搶快省略review感 07/27 17:41
→ Burwei: 覺也行 07/27 17:41
→ Ghamu: 總是有很多東西是你講一下別人會覺得合理就改變的事情吧... 07/27 18:19
→ Ghamu: 07/27 18:19
→ Ghamu: 萬事都要有一個主宰來訂定要聽誰的？ 我不認為多數時間就re 07/27 18:23
→ Ghamu: view個code分歧會到這麼大啦 真的不行也可以找leader來定奪 07/27 18:23
→ Ghamu: 除非你真的認為你的code就是你的code 永遠不會有第二人去 07/27 18:23
→ Ghamu: 做修改 07/27 18:23
→ Ghamu: 不太懂內 code review有這麼洪水猛獸嗎? 我真的蠻意外的 07/27 18:26
→ Lordaeron: 沒啊,人力問題,管理問題而已。說白了就是錢的問題. 07/27 19:06
→ Lordaeron: 再說, 我也不知什麼叫"程式碼品質好", 有比較基礎? 07/27 19:07
→ Lordaeron: 找個opensource 的project 為例吧. 07/27 19:07
→ Lordaeron: 還是又 是所胃的leader 說了算這種管理方式? 07/27 19:08
→ Lordaeron: 不知兩位大神, 看我的opensource code 有沒有要加強的. 07/27 19:17
噓 s06yji3: 你回覆我的也是廢話：）反正你沒在擔心。 07/27 21:01
→ Ghamu: 怪拐 你真的分不出好的程式碼跟壞的程式嗎？ 07/27 21:49
→ Ghamu: 算了 可能新手吧 那我無話可說了 07/27 21:54
→ Lordaeron: 我不知什麼叫好什麼叫壞，你給出來個定義。我是新手. 07/27 22:19
→ Lordaeron: 看一下我的PROJECT 吧,請你來評一評。 07/27 22:20
→ Ghamu: 有一本書叫做 clean code可以去看一下 design pattern 也可 07/27 22:25
→ Ghamu: 以了解一下 什麼情境用什麼pattern適合 還有基本的solid原 07/27 22:25
→ Ghamu: 則 07/27 22:25
→ Lordaeron: 你還是評一下我的project吧，好讓我學習學習你這位大神 07/27 22:37
→ Lordaeron: clean code 的作者，連是位軟體工程師這點都沒出處. 07/27 22:47
→ Lordaeron: 我看還是算了吧. 07/27 22:47
推 Litfal: code review的重點在角色轉換和權責劃分，你不覺得寫code 07/27 23:50
→ Litfal: 和看code的觀點不太一樣嗎？你要說成本的話，你覺得請一 07/27 23:50
→ Litfal: 堆資深並信任他們都能做好自己的事，和請一堆一般加一個 07/27 23:50
→ Litfal: 資深主管做review，哪個比較省？另外code review也有一點 07/27 23:50
→ Litfal: 訓練的意義在 07/27 23:50
→ Litfal: 再者，code review可以讓主管提早發現不同員工負責的模組 07/27 23:58
→ Litfal: 的之間的問題並及早解決，而不是到串接那天才發現兩人牛 07/27 23:58
→ Litfal: 頭不對馬嘴或跨過界 07/27 23:58
→ Lordaeron: 不就是,這位天才資深，要弄清楚所有的需求? 07/28 07:28