這就是莫明其妙的點，兩位沒啥實績的人，出了一本書，胡鄒一個方法。
然後一群人拿來當聖經在拜。
這就是外國的和尚會唸經的概念，要是像人月神話的作者這種有實績就算了。
偏偏沒有還當神，就是一堆不沒開發過軟體的人，拿來唬人用，然後病毒式傳開。
說實在的，還真的跟紅衛兵沒兩樣。
至於code review，這個也是一個很妙的妙論。
是review 什麼? 格式/style? framework/pattern? 正確性?
還是說，科舉的殿試，皇上出題，大家來寫，皇上來評?
不然，誰有這種美國時間來評?
格式，有formatter。
有沒有用OOXX 無敵framework，還是有沒有design pattern一下? 啊你能call 不就好了
正確性? 哪要K 他的SPEC? 不會吧。
anything else?

所以問題其實是人 好的人才能把概念落實到實務上篇DrTech板友就指出來了

這行不就這樣，一陣子就有新東西，敏捷就剛好名稱取個好，下一個猜是low code no code的*

問題是人是一定的了，哪有一種法規是自己會執行的?但重點是，這是兩位沒實績的人寫出來的東西。

low code我看是不行了啦 他要炒作的時機點剛好在GPT問市之前一點 GPT一出來聲量就沒救了 錯過炒作時機

一個公司的共同 code style 跟老屁股告訴你有甚麼好用的共同方法庫之類的吧像是產 json 的方法那麼多，各自都用各自的方法的話有問題的時候又是一筆時間成本

用什麼framework 不是在案子開始時定好的?

low code怎會不行,一堆搭上gpt的low code來推銷,似乎蠻好用

初看當然好用阿，但真的用下去就知道了...

說到low code 之前的Dreamweaver算不算一種

labview winform 算不算 low code==

Code review當然是正確性優先啊！幫忙抓沒考慮到的case，還有是否有遵守共同的style ，其實最主要是互相抓對方的blind spot至於可讀性很主觀，但我通常會示範怎麼寫比較簡單易懂，取得共識

很多人亂用資料結構，演算法亂寫，你用code scan tool上找不出問題呀，這時候只能靠code review你看過一堆人檢查是否存在用list在那邊contains 然後在那邊納悶為什麼效能很差就會覺得需要code review

正確性，就需要讀需求，就是一份工作兩人分。至於效能問題，嗯，台灣的問題不大。

你list都能放進APP了，效能能差到哪...又不是刷題

你沒遇過有人把10萬個items放進list，然後用contains去找新進來的有沒有在list內？還看過更神的還用for loop去做equals比對找item?這樣效能不會有問題？

以現在的PC來說，10萬不算數字。要能讓你明顯感覺到基本是50萬起。再說contains 的行為和for loop 何異？另外，是否存在，別以為用hash 就一定快。哪還是取決於你的key 的分佈如何。

真的遇到再跟我說10萬不是數字吧，你的base跟要比對的量都是10萬等級的還不是數字嗎？

er...真的遇到的是破千萬的，十萬的一直都不當回事。

十萬跑 list 迭代很有感吧

你是寫C? java? C#? python? VBS?好說也給個SAMPLE CODE 出來有感一下吧。

蠻猛的 怎麼現在連code review都要被翻桌了這不是基本常識嗎...沒人review 推一個叫做nbNumber的變數上去 你猜猜看是什麼意思^^openWheat() function huahaGift是啥^^

哦,連變數命名都出來呢。真的是笑死人。想必你對你做的案子的英文的名詞都非常熟，還能中英對照呢.

review最基本要寫到第二個人能看得懂 接著確保基本正確性有時間可看有沒有更好的寫法能提出來 很多時候這個過程幫助產品更好 也是讓自己能進步的方式 因為其他成員可能有更好你沒想到的方法 教學相長也可以進步牛逼數字 開麥客風 豪華禮物 你答對了嗎^^review過的話這些垃圾就不會進去害人害己了

案子不趕，人力很多，高手很自信他的寫法更好。review!

很趕的話喬一下review看重點正確性就好了 除非無法忍受的東西不然就別修 或是先註解之後再修也是一個方式之前書上也有講過了 很多時候寫程式寫都很快 但看會很久 因為寫太爛了 為了寫快寫一堆垃圾 幾週後出問題你回來看可能連你這跟親爹都認不得 最後還是功德迴向到自己身上

看別人的正確性，就是自己沒事做，專做這一塊.就是人力過剩.要不然,大家都有自己的要寫,誰有這命去批改作業,還吃力不見得討好的. 正如,你認為你的寫法比較好,我認為我的沒問題，就有人說10萬就很有感,我是無感.這時誰來裁決? 有一位全部人都認同的大神來裁決?還是就隨他去? 哪reviewer的不爽,改成reviewer的,則原作不爽. 不然再花時間寫一個測試, 來評比?benchmarking 來一翻兩瞪眼, 時間太多?不是週週要sprint? 這要不要加插進去sprint?

幫人家改作業沒必要。但是你是project owner不看的話都不怕人家塞什麼垃圾進去嗎？

這麼怕就不要找這些人一起做囉。再說，我要是想做點什你真的有本事找出來?

Who knows :)

真的能回廢話，who knows 有什麼好合作的?

code review確實花時間但利大於弊吧，除了正確性外，程式碼品質好未來比較好維護，短空長多但如果案子簡單以後也不負責維護，那為了搶快省略review感覺也行

總是有很多東西是你講一下別人會覺得合理就改變的事情吧...萬事都要有一個主宰來訂定要聽誰的？ 我不認為多數時間就review個code分歧會到這麼大啦 真的不行也可以找leader來定奪除非你真的認為你的code就是你的code 永遠不會有第二人去做修改不太懂內 code review有這麼洪水猛獸嗎? 我真的蠻意外的

沒啊,人力問題,管理問題而已。說白了就是錢的問題.再說, 我也不知什麼叫"程式碼品質好", 有比較基礎?找個opensource 的project 為例吧.還是又 是所胃的leader 說了算這種管理方式?不知兩位大神, 看我的opensource code 有沒有要加強的.

你回覆我的也是廢話：）反正你沒在擔心。

怪拐 你真的分不出好的程式碼跟壞的程式嗎？算了 可能新手吧 那我無話可說了

我不知什麼叫好什麼叫壞，你給出來個定義。我是新手.看一下我的PROJECT 吧,請你來評一評。

有一本書叫做 clean code可以去看一下 design pattern 也可以了解一下 什麼情境用什麼pattern適合 還有基本的solid原則

你還是評一下我的project吧，好讓我學習學習你這位大神clean code 的作者，連是位軟體工程師這點都沒出處.我看還是算了吧.

code review的重點在角色轉換和權責劃分，你不覺得寫code和看code的觀點不太一樣嗎？你要說成本的話，你覺得請一堆資深並信任他們都能做好自己的事，和請一堆一般加一個資深主管做review，哪個比較省？另外code review也有一點訓練的意義在再者，code review可以讓主管提早發現不同員工負責的模組的之間的問題並及早解決，而不是到串接那天才發現兩人牛頭不對馬嘴或跨過界

不就是,這位天才資深，要弄清楚所有的需求?