Conversation
MontyPan
left a comment
MontyPan
left a comment
There was a problem hiding this comment.
你這個版本實在太樸實無華且枯燥了，但是你不是有錢人，所以我不接受。
Must FIX
就算是我能接受這個版本，也得把ii拔掉，實在太多餘了- 我們通常不會在 for-loop 裡頭搞兩個以上的 index 值，這會讓程式很難讀，寧願改用 while-loop。
- 請生出更厲害的版本（開始 v2 / v3 吧...... 😱 ）
MontyPan
left a comment
MontyPan
left a comment
There was a problem hiding this comment.
Must FIX
我在 這個 comment 已經講了，這裡就不再贅述。以後給這種程度的「不同版本」是無效的，更別說有些改完之後還更爛 [扶額]。
請砍掉 v2 / v3，重新再搞一個版本，而且要更好而不是更差的。
瘟腥洨蹄擤：請善用前提。
還有，（不只這個 PR）該是你 resolve 的 conversation 請自動自發... 😪
|
不知道這樣改有沒有比較好= =+ 另外請問您指的比較厲害的版本，是主要要求 簡短 易讀 好理解 這點嗎？ |
|
你要暗示我業障重，貼這張圖就可以了，不要搞一個國王的 commit 來要我點評。 至於「什麼叫做比較厲害的版本」這個問題，既然你問了，那倒是挺值得回答的。 通常我們判斷一個程式的厲害與否，大概是這幾個面向：
彈性跟 robust 你現在寫的程式可能碰不到（這個 issue 完全碰不到），要說的話 #11 的 optional question 算是起點。 比較慘的是，在 94.87% 的情況下，這幾個面向是互斥、很難全部滿足。像「精簡」跟「可讀性」就很難 這也是我一開始只用「厲害」這種模糊形容詞的原因，算是自由發揮、看你能搞出什麼名堂這樣。當然，如果你仔細思考的話，這個 issue（或說這類的題目）通常只會在意其中一個面向。 anyway... 我想現在的重點是，不管哪個面向，都很難說你目前的 v2 / v3 有比 v1 好...... 😱 |
MontyPan
left a comment
MontyPan
left a comment
There was a problem hiding this comment.
我真的不知道該說什麼了，所以只好把問題丟回去給你。
Must Answer
請說明為什麼你會覺得 v4 有比 v1 好？
Must FIX
請改出「更」厲害的 v5
當初認為以 隨著 forLoop 運行次數而往 data 後方遞增的 ii ， |
OK，我接受這個答案，不過不是因為內容正確性與否（而且坦白說我看不太懂， 我不是很想仔細探究 v4（因為實在很可怕），我簡單提出一個觀點：你在 v1 用了四個變數、你在 v4 也還是用了四個變數，然後你在 v4 裡頭少了一個改變的變數 counter，但我其實看不太出來 counter 跟 i 有什麼決定性的差異。 你的意思應該是說在 v1 的話 counter 是一定會改變，但是到了 v4 的話是符合條件才改變，所以 v4 比 v1 好？ OK，這的確有道理，但實際上我們會忽略這種... 量級（這個詞不太好，但是我找不到其他的詞）的優化，因為那不是必然發生。 倒是 v4 的缺點非常顯而易見，光 L45 / L48 的重複就散發著濃烈的壞味道。 我不知道你是又忘了按 re-request 還是怎麼的，只是這兩天我沒什麼耐心，所以我直接把 v5 也說一說。你的 v5 是有 bug 的，請找出來（我懷疑不只一個但是我沒有證據）。然後這有沒有比 v1 好可能很難定論（我個人是覺得半斤八兩），不過可以肯定的是，你沒有妥善用到前提假設，所以沒辦法製造出很明顯的改善。 |
|
畢竟是公開 repo 然後你講了一些個人隱私的事情，所以上一個 comment 我先砍了 |
|
目前找到兩個 v5 的 Bug：
對於前提假設（已經排序過、數字不會亂跳、相同數字靠在一起的 array） 不小心把原本 untracked file 也加進去了= =+ |
MontyPan
left a comment
MontyPan
left a comment
There was a problem hiding this comment.
Must FIX
你 不小心 把 Issue16 給弄上來，然後因為有規定說不能作 force update 那也就算了，那你 至少也設法補救 阿幹，不然是要我 accept 那個 Issue16？
Requirement Change
我沒有很正式地導入 testing 的概念（一方面是我的確很少在實務上搞 testing...... 😱，二方面是也不要一次塞太多東西 ），不過既然都到這個地步，你都炸了 bug 而且你也找到了 bug，那應該是要針對你發現的 bug 搞個 test case，不然怎麼知道你有沒有改正確 & 以前的 test case 有沒有炸掉？
然後 test case 一多還要用肉眼去校正就會很阿雜，所以程式設計師應該想辦法偷懶，這裡先隨便舉個例子：
private static boolean test(int[] value, int[] answer) {
return value[0] == answer[0] && value[1] == answer[1];
}
test(longest(data1), answer1);
test(longest(data2), answer2);當然，這仔細看會覺得還是有點蠢，不過目前你手邊的工具就只能作到這樣 XD，但即便如此還是會爽上一點？
請試試看（甚至你要補強上面的 test() 都行）然後補上你發現的 bug 的 test case。
murmur
我還是有點懷疑你的 v6 有 bug（至少味道不太好，第一次迴圈根本無意義阿，有需要用到四個變數？），但是我真的沒有證據...... 💃
目前看起來你是擠不出什麼新鮮東西了，請把上面的 requirement change 改完（然後他 X 的不要忘記 must fix）然後先去作 #16 吧....
ps.1 我的確沒發現 v1 版本有 bug，這也佐證了 testing 很多時候比 code review 還實在
ps.2 程式設計師要偷懶，是在作法上偷懶，而不是在想法上偷懶。
MontyPan
left a comment
MontyPan
left a comment
There was a problem hiding this comment.
這個 task 我想就比照 task-0 就先在這裡告一段落但是不 close，如果你哪天頓悟了有新的想法也可以回來 try 一下。
Bewared
- 刪除檔案應該要獨立一個 commit（基本上你之前也常常有應該拆成兩個 commit 但是卻擠在一起，不過那還有商量的空間，現在這個就沒得商量了）
- 通常我們不會留修正前的程式啦（commit 都有阿），目標是讓 test case 都 pass 而不是印出一堆東西來（哪有時間看）。
- 萬一你還有回頭來改這個 task 的話再砍砍掉吧
好的！我也覺得過段時間回頭想，很有可能會有新的思考邏輯出現。 |
|
結果過了好一陣子了還是想不出個新想法= =+ 關於 瘟腥洨蹄擤，我對於前提的解讀是 數值從小排到大。 |
|
我就當上面那個 comment 是 request review 了... 我先承認，v7 我懶得看..... 倒是你的 L118 不用仔細看也知道有 94.87% 的機率是沒意義 or 可以取代的。 至於你「懷疑溫馨小提醒」的段落，說實在我完全不懂你在講啥。有哪裡會讓你覺得「傳入的陣列，最後一個 element 一定 會遠大於前面 element」的錯覺？就算會好了，那又能怎麼樣？ 有鑑於你似乎變不出什麼新把戲了，所以你可以先不用再製造新的版本，改思考這個問題吧！ Must Answer你是依照 好的，我當初故意埋了一個哏在裡頭，有可能 會產生問題，請試著找出問題是什麼？ 💃 （謎之聲：WTF... 總共也才幾個字為什麼以能埋哏阿阿阿阿....） |
|
|
=.= 請不要修改前提假設，前提假設就是會傳給 callee 一個已經排序過的 array。 我倒是比較好奇你是基於什麼回答「可能會被打亂或著修改」...... |
|
用平常不會覺得他是問題的角度找梗到底在哪裡Q_Q |
|
＝＝" 還好我用中性的問句，所以問出了一些驚人的事實（？） 就字面上來說，「有可能會被打亂或者修改」的確是我們在寫程式要考慮的點，主要是 caller 要預防，callee 要按耐住不要惡搞。在 #21 那個 try-try-see 的問題解答其實就是這句。完整的版本是：
所以你在 #21 就會有可能發生「程式莫名其妙出現 bug 但是怎麼查也查不出來」的狀況，因為就結果來說，caller 可以改變你的 stack 值（失去封裝的保護） 這邊你先看過有個印象即可，有緣我們再來回頭講這個（因為需要蠻多基礎知識）。 回歸主題（？）：
|
2 participants
No description provided.