※ 編輯: purin88 (111.241.90.24), 05/07/2016 20:24:21

---

我也是比較認同你做法,

不過說實話,code review本來就會出現這種狀況,

很多人在code review時,

是抱著去批評別人的態度在做的,

想著我比你利害,我方法比你好,你要改成我方法,

什麼寫法比較好其實已經不是問題了,

問題是你們這樣已經失去了code revew的意義,

搞到你們關系也會影響到,

現在電腦跑夠快了,

為了計較省記憶體或參數要怎麼丟而傷和氣這非常的傻,

等於是把小小且沒什麼影嚮的技術問題搞成人的問題,

你主管一直對你人身攻擊這個是不好的,

但你其實也不用太和主管硬碰硬,

尤其是這種小事....


在座大家很多人的工作經驗都很多,

遇過"不合理"的要求的經驗也很多人有吧,


你這個爭議點真的算很小了,


我隨便說說我遇過不合理的要求:

1.美術不想切圖,就要程式去切圖

2.連資料庫時,不準用sp和暫存表,一定要在client端把sql拼出來送,而且join只能用left

3.變數命名要求用a1,a2,a3...


至於被人身攻擊的經驗,

也多到我數不完,

最常被人身攻擊的點,

我相信90%的工程師也這樣被攻擊過,

那就是被批評為不懂使用者,

你主管的用詞我看是還好,

有人用詞更難聽,國罵都出來了,


所以看開點囉,

不要去在意這種小事,

因為有更多大事值得注意,

也不要和主管唱反調,

如果主管沒逼你一定要改成他寫法的話,

你就聽聽就好吧,

如果你主管逼你改的話,

你就聽你主管改看看,

改了有問題,影響到你做事的效率的話,

那麼就看你這公司想不想待,

不想待,忍不了的話就離開,好聚好散吧,

只是你可能要做好心理準備,

搞不好下個主管會更沒sense,

其實事情就是這麼簡單,

加油吧,別被小事打擊到,

你會寫這些,會想這些,你己經贏過很多人了,

也記得以後,

你當主管時,

要對別人code review時,也千萬不要去人身攻擊,

就算你覺得對方寫得很爛,也要保持尊重

※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: code review時，主管說暫存變數可省記憶體，不用一直建立變數佔記憶體，我就說重
: 構這本書作
: 者建議別這樣做，我就拿下面這個重構作者的網址
: https://sourcemaking.com/refactoring/split-temporary-variable
: 他就說這個作者有問題，說我跟他寫一樣出去別人
: 會笑我
: 接著，我程式有用簡單工廠模式，就像head first design patten的內容一樣建立pizza
: 店的工廠，他又
: 說為什麼要建立抽象的pizza店，建立A pizza加盟店，B pizza加盟店，我說每間pizza店
: 產生pizza囗味，方法不同，他又說建立A pizza店，B pizza店
: 產生物件浪費記憶體，為何不用switch case判定
: 是A或B，直接寫各店pizza的作法及口味，產生pizza的作法何必封
: 裝在A pizza物件，或B物件中，全寫在pizza這個程式中，寫一個類別靜態方法回傳pizza
: 一樣的，他沒看過design patten，也覺得四人幫在亂寫一通，建立物件是浪費記憶體
: https://rongli.gitbooks.io/design-pattern/content/chapter1.html
: https://dotblogs.com.tw/joysdw12/archive/2013/06/23/design-pattern-simple-fact
: ory-pattern.aspx
: 然後談到建立物件，我是用set get的方式設置參數，他就覺得為什麼不用建構子把好幾
: 個參數丟進去，我一樣拿出
: https://sourcemaking.com/refactoring/smells/long-parameter-list
: http://teddy-chen-tw.blogspot.tw/2014/04/3long-parameter-list-divergent-change
: .html?m=1
: 重構的作者是建議參數不用丟太多，建立一個物件，
: 設定物件的值，把物件丟進建構子，或方法參數中，然後我這樣跟我主管說，他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子，讓建構子去塞，即便
: 參數很多也沒關係，說我物件導向沒學好
: 反正一直在對我人身攻擊，即使我提到重構
: 設計模式，對他來說就是爛書，作者亂寫
: 請問我該如何是好？

--
while(me.isLonely){
        me.girlFriend = new girlFriend();
        me.isLonely = me.girlFriend.isReal?false:true;
}

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.94.92.41
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462632772.A.728.html

---

好熱睡不著回一下XD

其實你跟你主管兩個都沒錯

只是立足點不同而已

你使用的方式都是以方便維護為主要考量

你主管的方式則是盡可能榨出所有效能出來

兩個完全不同方向的怎麼吵也不會有結果

之前就遇過一個用 java 實作了類似 goto 方法的同事

成功之後他整個笑開懷 一整天心情都超爽的

說效能提升多少多少

之前要跑幾十分鐘現在只要幾分鐘

然後跟我說他寫程式的成就感就在調校這個部分

但聽完我只覺得三個月後可能沒人看得懂他在寫什麼...

可是有的時候就是需要犧牲維護性來追求那一點點的效能

因為當那段程式碼需要跑幾千萬次的時候

能提升一毫秒都是很大的進展了

拿比較簡單的寫資料庫來說

每次新增資料就是產生一次 insert statement

但如果一次要寫上萬筆呢

只好寫成 stored procedure

一個好維護 另一個速度快

但如果那個只是個 singleton 的物件初始化呢？

應該沒有主管會希望有人在這裡下太多功夫調校

可是如果說有一天你的程式碼要移到哪個有資源限制的地方

這時你的主管建議的方法就會有幫助了

寫程式就是一直不斷的判斷與選擇

有時 a 方法好 有時 b 方法適合

過了一陣子後 可能有文章表示 a, b 方法都爛透了

如果是我站在原 po 的立場要我選擇的話

程式是我在寫 維護的也是我

我才不管主管怎麼說咧

隨便應個 喔喔 好 我再找時間改

然後就不鳥他了啦

誰要跟你花時間在那邊開會啊

搞不好還會耽誤到我下班時間

不過記得千萬不要跟老闆頂撞

上次我這樣做 然後...

就寫了一封道歉信 很不方便

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.115.90.49
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462637927.A.A2C.html

---

   我的建議是，如果你沒有辦法說服你的老闆，那表示你也還沒有通透為什麼
   書上要這樣寫，也只是知其然不知其所以然，那就再努力點把更多細節搞懂，
   對你也不是壞事。

   比方說吧，建構子到底是要參數吃到飽還是分開寫get/set，跟他放在你整個
   架構的哪一層有很大的關係。跟將來維護的頻率也有很大的關係，不是一定
   哪個好哪個不好。

   把更多細節搞清楚也是未來溝通很重要的工具，你也許今天說服不了你老闆，
   輸了沒關係，卻可以讓你變得更強大。總有一天你會說服下一個老闆的。

   但是結論是，既然他是老闆，照他說的改吧。之後如果要維護改code，因為
   之前的彈性都沒了，現在時間要比較多，他也只能吞了。所以，記得發個
   email給老闆確認code review的結果，免得到時後到打一靶說，工程師亂寫...

※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: code review時，主管說暫存變數可省記憶體，不用一直建立變數佔記憶體，我就說重
: 構這本書作
: 者建議別這樣做，我就拿下面這個重構作者的網址
: https://sourcemaking.com/refactoring/split-temporary-variable
: 他就說這個作者有問題，說我跟他寫一樣出去別人
: 會笑我
: 接著，我程式有用簡單工廠模式，就像head first design patten的內容一樣建立pizza
: 店的工廠，他又
: 說為什麼要建立抽象的pizza店，建立A pizza加盟店，B pizza加盟店，我說每間pizza店
: 產生pizza囗味，方法不同，他又說建立A pizza店，B pizza店
: 產生物件浪費記憶體，為何不用switch case判定
: 是A或B，直接寫各店pizza的作法及口味，產生pizza的作法何必封
: 裝在A pizza物件，或B物件中，全寫在pizza這個程式中，寫一個類別靜態方法回傳pizza
: 一樣的，他沒看過design patten，也覺得四人幫在亂寫一通，建立物件是浪費記憶體
: https://rongli.gitbooks.io/design-pattern/content/chapter1.html
: https://dotblogs.com.tw/joysdw12/archive/2013/06/23/design-pattern-simple-fact
: ory-pattern.aspx
: 然後談到建立物件，我是用set get的方式設置參數，他就覺得為什麼不用建構子把好幾
: 個參數丟進去，我一樣拿出
: https://sourcemaking.com/refactoring/smells/long-parameter-list
: http://teddy-chen-tw.blogspot.tw/2014/04/3long-parameter-list-divergent-change
: .html?m=1
: 重構的作者是建議參數不用丟太多，建立一個物件，
: 設定物件的值，把物件丟進建構子，或方法參數中，然後我這樣跟我主管說，他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子，讓建構子去塞，即便
: 參數很多也沒關係，說我物件導向沒學好
: 反正一直在對我人身攻擊，即使我提到重構
: 設計模式，對他來說就是爛書，作者亂寫
: 請問我該如何是好？

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 75.17.244.220
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462639192.A.F90.html

---

推薦你看這本書，或許會對你有幫助：
無瑕的程式碼 番外篇：專業程式設計師的生存之道
http://www.books.com.tw/products/0010598217

裡面大概是在講身為一個Clean Coder，
在職場中如何處理「人」方面的問題。

---

從你的文章看起來，你對於所受到的質疑，
處理的方式好像是將參考資料直接丟給對方，
說服的理由上則是「因為大師們這麼建議」。

但Martin Fowler與Joshua Kerievsky，兩本重構著作的作者，
他們在書中大量提到的是「程式碼的壞味道」及其帶來的可能壞影響，
同時也提到不要過度設計、以及什麼樣的重構手法會帶來哪方面的trade-off。
有個很重要的觀念是，要根據你的程式、自己判斷是否真的適合某個重構手法。

以下分享我看重構相關書籍的一些心得，
並不是說你就有這些問題(因為文章中也看不完全)，
只是一些相關的心得分享～

 Inline Temp
暫時變數並不是個絕對要移除、或是絕對要保留的東西，
Martin Fowler在書中並沒建議你別用暫時變數，
而是「當你發現它妨礙你的其他重構手法時，則該移除它」。

暫時變數的問題在於，當你需要Extract Method時，
會因為它的存在而需要把它透過參數傳遞，
因而導致壞味道「過長的參數列」。

如果沒有這個問題(或其他的問題)，暫時變數並不是壞事。



適當的暫時變數，可以透過命名，提升程式碼的可讀性。
見Introduce Explaining Variable一章。
在這個場合下，引入暫時變數反而是比較好的做法，
有時甚至需要先Inline Temp、再Extract Method，最後再把Temp Extract回來。

至於記憶體議題要看場合，
以現在的硬體來說、應該大多都不需要擔心這個問題。
如果profiler的效能剖析真的指出效能瓶頸在這方面再來處理即可。

 工廠模式
head first design patten這本書就跟許多的設計模式書籍一樣，
容易看了之後就染上模式癖，忽略了有時可以用更簡單的解法處理問題。

在重構--向範式前進(Joshua Kerievsky)一書中，
就提到了如何透過許多重構手法往設計模式前進、但不過度設計的作法。

你主管說的作法，在某些情況下的確有可能是更好的作法。
工廠模式的優點在於程式碼分屬各自的class中、未來容易擴展，
但是也為程式帶來額外的複雜度。

如果某個地方的物件創造，未來不太會出現太多的類型變種，
的確是透過switch case+Creation Methods搞定就好了。
不需要特別引入工廠模式，帶來額外的複雜度。

 Introduce Parameter Object
「過長的參數列」的確是個明顯的壞味道，
這個壞味道在重構與Clean Code(Martin, Robert C.)兩本書中都有提到。

這個壞味道主要的問題在於：
1. 可閱讀性降低
2. 未來維護參數/Method不易


我看不太懂你文中的set get是什麼意思，
如果是以下寫法的話，在語意上會有點不一樣：

User user = new User("Jack");

User user = new User();
user.setName("Jack");

後面這種寫法雖然可以減少1個建構式參數，
但是語意上比較偏向是「將原本沒有名字的使用者改名為Jack」。
這方面比較見仁見智，只是稍微說一下可能會有這樣子的理解。



要消除過長的參數列這個壞味道，
手法在書中大概有提到了4個，包括：

1. Replace Parameter with Explicit Methods.
2. Replace Parameter with Method.
3. Introduce Parameter Object.
4. Preserve Whole Object.

你的文中最有著墨的Parameter Object與34比較有關，
也並不一定就是「建立一個物件」，
而是「將各自相關聯的參數以物件包裝起來」。

例如，假設在一個租書店的程式中有以下程式碼：

BookPreservation bookPreservation = new BookPreservation(
    "Jack", "1433717", "2016/5/8", "2016/8/8");

其中4個參數分別為 userName, userId, startTime, endTime，
比較好的作法是將各自相關聯的參數各自包裝，變成：

BookPreservation bookPreservation = new BookPreservation(
    new User("Jack", "1433717"), new TimePeriod("2016/5/8", "2016/8/8"));

這個重構手法能帶來的好處如下：
1. 提升可讀性
2. 未來維護簡單
3. 容易因此將相關功能移入新造的class中，改善程式碼分工



試著像這樣將原作法的壞處與新作法的好處跟主管說看看吧。或是塊陶。

※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: code review時，主管說暫存變數可省記憶體，不用一直建立變數佔記憶體，我就說重
: 構這本書作
: 者建議別這樣做，我就拿下面這個重構作者的網址
: https://sourcemaking.com/refactoring/split-temporary-variable
: 他就說這個作者有問題，說我跟他寫一樣出去別人
: 會笑我
: 接著，我程式有用簡單工廠模式，就像head first design patten的內容一樣建立pizza
: 店的工廠，他又
: 說為什麼要建立抽象的pizza店，建立A pizza加盟店，B pizza加盟店，我說每間pizza店
: 產生pizza囗味，方法不同，他又說建立A pizza店，B pizza店
: 產生物件浪費記憶體，為何不用switch case判定
: 是A或B，直接寫各店pizza的作法及口味，產生pizza的作法何必封
: 裝在A pizza物件，或B物件中，全寫在pizza這個程式中，寫一個類別靜態方法回傳pizza
: 一樣的，他沒看過design patten，也覺得四人幫在亂寫一通，建立物件是浪費記憶體
: https://rongli.gitbooks.io/design-pattern/content/chapter1.html
: https://dotblogs.com.tw/joysdw12/archive/2013/06/23/design-pattern-simple-fact
: ory-pattern.aspx
: 然後談到建立物件，我是用set get的方式設置參數，他就覺得為什麼不用建構子把好幾
: 個參數丟進去，我一樣拿出
: https://sourcemaking.com/refactoring/smells/long-parameter-list
: http://teddy-chen-tw.blogspot.tw/2014/04/3long-parameter-list-divergent-change
: .html?m=1
: 重構的作者是建議參數不用丟太多，建立一個物件，
: 設定物件的值，把物件丟進建構子，或方法參數中，然後我這樣跟我主管說，他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子，讓建構子去塞，即便
: 參數很多也沒關係，說我物件導向沒學好
: 反正一直在對我人身攻擊，即使我提到重構
: 設計模式，對他來說就是爛書，作者亂寫
: 請問我該如何是好？

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.166.119
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462640428.A.59D.html

---

※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: code review時，主管說暫存變數可省記憶體，不用一直建立變數佔記憶體，我就說重
: 構這本書作
: 者建議別這樣做，我就拿下面這個重構作者的網址
: https://sourcemaking.com/refactoring/split-temporary-variable
: 他就說這個作者有問題，說我跟他寫一樣出去別人
: 會笑我
: 接著，我程式有用簡單工廠模式，就像head first design patten的內容一樣建立pizza
: 店的工廠，他又
: 說為什麼要建立抽象的pizza店，建立A pizza加盟店，B pizza加盟店，我說每間pizza店
: 產生pizza囗味，方法不同，他又說建立A pizza店，B pizza店
: 產生物件浪費記憶體，為何不用switch case判定
: 是A或B，直接寫各店pizza的作法及口味，產生pizza的作法何必封
: 裝在A pizza物件，或B物件中，全寫在pizza這個程式中，寫一個類別靜態方法回傳pizza
: 一樣的，他沒看過design patten，也覺得四人幫在亂寫一通，建立物件是浪費記憶體
: https://rongli.gitbooks.io/design-pattern/content/chapter1.html
: https://dotblogs.com.tw/joysdw12/archive/2013/06/23/design-pattern-simple-fact
: ory-pattern.aspx
: 然後談到建立物件，我是用set get的方式?
: 然後談到建立物件，我是用set get的方式設置參數，他就覺得為什麼不用建構子把好幾
: 個參數丟進去，我一樣拿出
: https://sourcemaking.com/refactoring/smells/long-parameter-list
: http://teddy-chen-tw.blogspot.tw/2014/04/3long-parameter-list-divergent-change
: .html?m=1
: 重構的作者是建議參數不用丟太多，建立一個物件，
: 設定物件的值，把物件丟進建構子，或方法參數中，然後我這樣跟我主管說，他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子，讓建構子去塞，即便
: 參數很多也沒關係，說我物件導向沒學好
: 反正一直在對我人身攻擊，即使我提到重構
: 設計模式，對他來說就是爛書，作者亂寫
: 請問我該如何是好？



我重構的方法是用樣板簡單工廠合併

1.模組由樣板實作

2.產品由工廠實作

在工廠階段通過參數switch決定要什麼樣板

並實作樣板內容

我認你老大要的是動態時期注入什麼方法
這的確在初期會減少記憶體，在測試上也比較彈性

再來我會開始定義領域物件，透過IResult泛型做統一回傳class，並定義該工廠的Reapon
se class裡面定義不同樣板Domain class，

重構以後程式結構大概如下


http://i.imgur.com/XSxp7Pv.jpg


我重構得前提是維持住現有的商務邏輯，透過封裝和釐清權責後再重構，先決定領域，將
相關的領域從原本大雜燴的程式抽離，將共同部份放到樣本主類別，子類別決定細節，工
廠階段則決定要何種子類別。

這樣閱讀性和效能說真的比原先好多

我重構也會找組長和長官討論多請益，基本上codereview前先討論，並能說明該方法好處
在哪，我想不會被刁難



--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.192.166.3
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462672912.A.E0B.html

---

以下不見得跟 Java 有關，純粹討論一點關於函數參數過多可能
導致的問題

1.難以閱讀、修改不容易

函數的參數越多，表示一個人要使用或是編輯的時候，需要判斷
斷詞 (想不到比較好的說法) 的地方就越多，也越容易失誤。

有些編輯軟體可能會幫你 highlight 你目前編輯到的參數，或是
提供額外彈出的提示 (如自動完成) ，但不是所有的都會。也有
方法在寫的時候讓他更明確，如一個參數放一行，但也不是每個人
都喜歡這樣的 coding style。而且十個參數就是十行，也占據了
不少版面。

參數多，漏給參數的機會也增大。如果好死不死有許多類似的函數
多載 (在建構子遇到的機會應該不小?) 且參數型態又一樣，是不是
很容易呼叫到不正確的建構子呢?

此外， C++ / Java 有 namespace / package 要寫，參數型態本身
就已經夠長到不好閱讀了。

2.效能 & 空間

我不確定其他高階程式語言怎麼實作，至少在 C / C++ 裡面，某些
平台上最前面幾個 (0~4, 看平台) 參數是用 register 傳，剩下的
要放在stack 上。通常編譯器做最佳化的時候已經會直接一次把需要
的空間留下來，效能上大概不會有差，因為編譯器可以安排運算指令
讓需要傳的資料事先存在對的位址。但是堆疊的空間仍然是需要的。

在多緒執行的程式裡面，程式堆疊不一定如大家預期的是可以一直
成長的。在一些系統裡面，程式堆疊是固定大小，且這個大小還會
影響到開新的執行緒的速度。


最後，寫程式很多選擇都是取捨。要知道一個方法取什麼捨什麼，
才能真的判斷當下用這個方法適不適合。或許你的主管有他的想法
他沒講清楚 (可能他認為你還 junior? 我無從得知)，也可能單純
是他鴨霸而已。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.112.30.76
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462674456.A.BE6.html

---

※ 引述《ADYex (寵物狼音樹)》之銘言：
: 例如，假設在一個租書店的程式中有以下程式碼：
: BookPreservation bookPreservation = new BookPreservation(
:     "Jack", "1433717", "2016/5/8", "2016/8/8");
: 其中4個參數分別為 userName, userId, startTime, endTime，
: 比較好的作法是將各自相關聯的參數各自包裝，變成：
: BookPreservation bookPreservation = new BookPreservation(
:     new User("Jack", "1433717"), new TimePeriod("2016/5/8", "2016/8/8"));
: 這個重構手法能帶來的好處如下：
: 1. 提升可讀性
: 2. 未來維護簡單
: 3. 容易因此將相關功能移入新造的class中，改善程式碼分工
: 試著像這樣將原作法的壞處與新作法的好處跟主管說看看吧。或是塊陶。
這個的話還需要看在用甚麼程式語言吧.

像在VB和C# v4+上也可以這樣寫:

            BookPreservation bookPreservation = new BookPreservation(
                userName: "Jack",
                userId: "1433717",
                startTime: "2016/05/08",
                endTime: "2016/08/08");

這樣寫比分拆成用property設定更好. 也是你之前說的「在初始化時設定」
和「先全部初始化成null, 在建構完成後再設定」的差別.

--

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.238.59.15
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462689836.A.F5A.html
※ 編輯: leicheong (61.238.59.15), 05/08/2016 14:44:55

---

我覺得在台灣跟別人code review常常會有三種結果

第一種是覺得我以前這樣寫都沒問題

幹麻還要用另外一種寫法

第二種是物件導向、重構、設計模式洗三小

書上的東西不能拿來現實中用

我只知道硬幹一樣可以解決問題啦!

第三種就是可能知道物件導向、重構、設計模式洗三小

但也沒說到精通的地步

可是你一跟他討論就一副老子就是要跟你戰到贏的姿態

第一種最容易在主管身上出現

第三種最容易在還在coding階段的工程師身上出現

第二種則是資深工程師跟資深主管最容易出現



我覺得code review除了可以知道自己程式哪裡寫的不好

同時也是可以知道自己哪裡不足

或是還有哪些招式可以用的最好時機

因為每種解法都代表著每種不同的思維

但也許是台灣教育從小缺乏批判性的思考與自省

所以有些工程師從一開始寫程式就是硬幹硬幹硬幹

從來沒考慮過是否還有更彈性更好的寫法

然後只要稍微要改需求就整個崩潰

只要出現一個bug就要加班好幾天

以為寫程式本來就會有bug

所以硬幹就對了有bug再說

然後整天靠北當軟體工程師好苦天天都要加班

明明就是自己造孽的結果

一種就是我講的還沒討論之前他就已經認為他已經是對的

遇到這種我覺得最靠北

這種人偏偏又似懂非懂

像是我遇過國內前三大資工畢業的

看到我的SQL有用join居然問我用join的效率不是很差嘛

當下我是還滿想酸難道要像現在一樣所有欄位都用子查詢

同一個talbe每一個欄位要取對應的資料就全部查一次效率才好?

不過這問題太…超乎我的程度我直接轉移話題懶的去澄清

有些人則是在討論的時候狂攻擊你的論點

然後你用另外一個回答反駁的時候他又繼續找下一個問題攻擊你

反正不管怎樣他的結論就是「你錯了」

這些人基本上我都能避免跟他們討論就避免

因為除了浪費時間外

可能因為你砍站不夠、不夠資深就覺得你一定是錯的

這種想法也是很狹隘

良性的互戰可以從溝通中攻擊對方論點的不足

以及被對方攻擊自己的論點

尤其是自己的論點被攻擊時

也代表著也許你對這事物的觀念還有你似懂非懂的地方

這時就是可以進步的地方就可以讓自己越戰越強(誤)

也可以反芻自己所學過的東西

但可惜我看到的很多還是重點不是在討論而是怎麼戰贏對方

最後對方不爽

自己也沒發現自己觀點缺陷的地方變成雙輸的局面



回到原PO的問題

我相信原PO也是求道之人

也是希望程式能寫的更好才會去翻那些書學那些技巧

但有的時候你真的無法跟夏蟲語冰

效能跟可讀性有時本來就要有所取捨

但現在硬體設備越來越強大的情況下

除非真的系統有超級高效能需求或是嵌入是系統資源少到靠北

否則還是應該要以可讀性為主

縱使會犧牲一點效能(不影響使用者體驗的情況)

也許你主管那時代就是對效能斤斤計較

現在他幹主管了還是那一套思維

你也知道台灣一狗票人當主管後

程度、知識水平就停在他離開工程師職位的那一瞬間了甚至還倒退

這種情況下勸你還是少費唇舌說服他

因為從你的內容來看他已經有「你一定是錯的」主觀意識了

所以你怎樣講都沒用

尤其他現在可能也不寫程式了

摔坑的人也不是他

所以他更難體會可讀性是三小這回事了



結論

如果你真的很在意你想的是精進自己程式功力

那就離職吧

我認為無腦的東西也不會因為你寫過一萬次就變得有腦

面試時其實就可以多問問公司內部開發上有沒有相關的觀念

沒觀念也沒關係

至少主管不要來亂就好


※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: code review時，主管說暫存變數可省記憶體，不用一直建立變數佔記憶體，我就說重
: 構這本書作
: 者建議別這樣做，我就拿下面這個重構作者的網址
: https://sourcemaking.com/refactoring/split-temporary-variable
: 他就說這個作者有問題，說我跟他寫一樣出去別人
: 會笑我
: 接著，我程式有用簡單工廠模式，就像head first design patten的內容一樣建立pizza
: 店的工廠，他又
: 說為什麼要建立抽象的pizza店，建立A pizza加盟店，B pizza加盟店，我說每間pizza店
: 產生pizza囗味，方法不同，他又說建立A pizza店，B pizza店
: 產生物件浪費記憶體，為何不用switch case判定
: 是A或B，直接寫各店pizza的作法及口味，產生pizza的作法何必封
: 裝在A pizza物件，或B物件中，全寫在pizza這個程式中，寫一個類別靜態方法回傳pizza
: 一樣的，他沒看過design patten，也覺得四人幫在亂寫一通，建立物件是浪費記憶體
: https://rongli.gitbooks.io/design-pattern/content/chapter1.html
: https://dotblogs.com.tw/joysdw12/archive/2013/06/23/design-pattern-simple-fact
: ory-pattern.aspx
: 然後談到建立物件，我是用set get的方式設置參數，他就覺得為什麼不用建構子把好幾
: 個參數丟進去，我一樣拿出
: https://sourcemaking.com/refactoring/smells/long-parameter-list
: http://teddy-chen-tw.blogspot.tw/2014/04/3long-parameter-list-divergent-change
: .html?m=1
: 重構的作者是建議參數不用丟太多，建立一個物件，
: 設定物件的值，把物件丟進建構子，或方法參數中，然後我這樣跟我主管說，他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子，讓建構子去塞，即便
: 參數很多也沒關係，說我物件導向沒學好
: 反正一直在對我人身攻擊，即使我提到重構
: 設計模式，對他來說就是爛書，作者亂寫
: 請問我該如何是好？

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.44.10.232
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462690172.A.0B3.html

---

繼續占版面分享少許心得。

在Python中也有類似直接指定參數的寫法，如：
book_preservation = BookPreservation(user_name="Jack",...)

如果這些參數只是單純指定進去當作fields的話，
的確這樣的寫法就夠用了：）

下面分享一下這個重構手法的第3個好處：
3. 容易因此將相關功能移入新造的class中，改善程式碼分工



假設在我們的租書店程式中，在caller端有以下程式碼：

class PreservationChecker{
    void checkPreservation(
        String userName, String userId, String startTime, String endTime){
        BookPreservation bookPreservation = new BookPreservation(
            "Jack", "1433717", "2016/5/8", "2016/8/8");

        if(!isInTime(
             bookPreservation.getStartTime(),
             bookPreservation.getEndTime())){
            return;
        }

        // 其他動作
    }

    boolean isInTime(String startTime, String endTime){
        Calendar calendar = Calendar.getInstance();
        // 檢查過程
        return result;
    }

    // 其他 methods
}


透過上一篇文章中提到的重構手法，我們可以得到以下程式碼：

class PreservationChecker{
    void checkPreservation(
        String userName, String userId, String startTime, String endTime){

        TimePeriod timePeriod = new TimePeriod("2016/5/8", "2016/8/8");
        BookPreservation bookPreservation = new BookPreservation(
            new User("Jack", "1433717"), timePeriod);

        if(!isInTime(
             timePeriod.getStartTime(),
             timePeriod.getEndTime())){
            return;
        }

        // 其他動作
    }

    boolean isInTime(String startTime, String endTime){
        Calendar calendar = Calendar.getInstance();
        // 檢查過程
        return result;
    }

    // 其他methods
}

以及2個根據參數關係所分離出來的class: User與TimePeriod。



接下來，因為caller端的程式碼可能已經太多了，
或是在其他地方也有使用到TimePeriod的時間檢查，

好比說、可能另外有個租書店用來舉辦活動的程式碼，
用來檢查今天是不是應該給客人30元優惠：

class FesCoupon{
    private String startTime;
    private String endTime;

    double getCouponAmount(){
        if(!isInTime(
             this.getStartTime(),
             this.getEndTime())){
            return 0;
        }

        return 30;
    }

    // 以下是重複碼
    boolean isInTime(String startTime, String endTime){
        Calendar calendar = Calendar.getInstance();
        // 檢查過程
        return result;
    }
}



因為我們先前把BookPreservation的2個時間相關參數，
透過Extract Class，得到了TimePeriod這個class，
我們現在就可以把重複碼isInTime()放進去，得到：

class TimePeriod{
    private String startTime;
    private String endTIme;

    boolean isInTime(){
        Calendar calendar = Calendar.getInstance();
        // 檢查過程
        return result;
    }
}

然後、上述兩個引用點就可以精簡為：

class PreservationChecker{
    void checkPreservation(
        String userName, String userId, String startTime, String endTime){

        TimePeriod timePeriod = new TimePeriod("2016/5/8", "2016/8/8");
        BookPreservation bookPreservation = new BookPreservation(
            new User("Jack", "1433717"), timePeriod);

        if(!timePeriod.isInTime()){
            return;
        }

        // 其他動作
    }

    // 其他methods
}

class FesCoupon{
    private TimePeriod timePeriod;

    double getCouponAmount(){
        if(!timePeriod.isInTime()){
            return 0;
        }

        return 30;
    }
}

如此，
 不僅消除了2個caller class當中的重複碼，
 也將isInTime()這個methods放到了與最相關的class當中(也就是TimePeriod)。

即使在支援直接指定參數寫法的語言，如Python中，
也能因為這個重構手法，而獲得以上2個改善的好處。

※ 引述《leicheong (睡魔)》之銘言：
: ※ 引述《ADYex (寵物狼音樹)》之銘言：
: : 例如，假設在一個租書店的程式中有以下程式碼：
: : BookPreservation bookPreservation = new BookPreservation(
: :     "Jack", "1433717", "2016/5/8", "2016/8/8");
: : 其中4個參數分別為 userName, userId, startTime, endTime，
: : 比較好的作法是將各自相關聯的參數各自包裝，變成：
: : BookPreservation bookPreservation = new BookPreservation(
: :     new User("Jack", "1433717"), new TimePeriod("2016/5/8", "2016/8/8"));
: : 這個重構手法能帶來的好處如下：
: : 1. 提升可讀性
: : 2. 未來維護簡單
: : 3. 容易因此將相關功能移入新造的class中，改善程式碼分工
: : 試著像這樣將原作法的壞處與新作法的好處跟主管說看看吧。或是塊陶。
: 這個的話還需要看在用甚麼程式語言吧.
: 像在VB和C# v4+上也可以這樣寫:
:             BookPreservation bookPreservation = new BookPreservation(
:                 userName: "Jack",
:                 userId: "1433717",
:                 startTime: "2016/05/08",
:                 endTime: "2016/08/08");
: 這樣寫比分拆成用property設定更好. 也是你之前說的「在初始化時設定」
: 和「先全部初始化成null, 在建構完成後再設定」的差別.

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.166.119
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462703532.A.A73.html

---

看完後這整件事情其實都不是在技術上，都是在人身上，主管與員工的相處

組員一直頂撞主管，先不論主管組員的技術與知識

1. 對組員而言，是希望往好維護方向前進

2. 對主管而言，效能效能效能，我才是強者....

好了，其實有一種主管就是，他甚麼都覺得自己最強，照他的做，不要頂嘴
(你這次考績已經黑了)

有一種組員就是程式我在維護的，我當然是寫好維護的

反正就是人生的道路上你們兩個是衝突的。

你今天上來講這件事情，或許想解決這個問題，或許也只是討拍文

我是覺得寫程式沒有甚麼對錯，可以跑出正確結果就是對的

程式只能比執行速度跟有無bug，好不好維護都是"人"的問題

(今天要新增功能，好維護有可能開發速度快，但是，是人開發的速度
對客戶而言，你時間內可以把程式交出來就好，對主管而言，他只要掌控Dead line就好)

大家立場不同，如果你不想離職，先想想看往後遇到同樣Case要怎麼應付

如果想要離職，也不用想後續結果了，做自己開心的。

可以對技術執著，但是不要鑽牛角尖，寫程式是快樂的，不要把自己逼到這種地步。

分享你可以分享在網路上面，認同或者被你幫助的人自然會把你的理念再繼續散發出去




※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: code review時，主管說暫存變數可省記憶體，不用一直建立變數佔記憶體，我就說重
: 構這本書作
: 者建議別這樣做，我就拿下面這個重構作者的網址
: https://sourcemaking.com/refactoring/split-temporary-variable
: 他就說這個作者有問題，說我跟他寫一樣出去別人
: 會笑我
: 接著，我程式有用簡單工廠模式，就像head first design patten的內容一樣建立pizza
: 店的工廠，他又
: 說為什麼要建立抽象的pizza店，建立A pizza加盟店，B pizza加盟店，我說每間pizza店
: 產生pizza囗味，方法不同，他又說建立A pizza店，B pizza店
: 產生物件浪費記憶體，為何不用switch case判定
: 是A或B，直接寫各店pizza的作法及口味，產生pizza的作法何必封
: 裝在A pizza物件，或B物件中，全寫在pizza這個程式中，寫一個類別靜態方法回傳pizza
: 一樣的，他沒看過design patten，也覺得四人幫在亂寫一通，建立物件是浪費記憶體
: https://rongli.gitbooks.io/design-pattern/content/chapter1.html
: https://dotblogs.com.tw/joysdw12/archive/2013/06/23/design-pattern-simple-fact
: ory-pattern.aspx
: 然後談到建立物件，我是用set get的方式設置參數，他就覺得為什麼不用建構子把好幾
: 個參數丟進去，我一樣拿出
: https://sourcemaking.com/refactoring/smells/long-parameter-list
: http://teddy-chen-tw.blogspot.tw/2014/04/3long-parameter-list-divergent-change
: .html?m=1
: 重構的作者是建議參數不用丟太多，建立一個物件，
: 設定物件的值，把物件丟進建構子，或方法參數中，然後我這樣跟我主管說，他又說我沒
: 腦袋嗎
: 沒辦法判定這個作者有問題
: 參數本來就全丟給建構子，讓建構子去塞，即便
: 參數很多也沒關係，說我物件導向沒學好
: 反正一直在對我人身攻擊，即使我提到重構
: 設計模式，對他來說就是爛書，作者亂寫
: 請問我該如何是好？

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 218.166.145.9
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462730066.A.78F.html

---

個人是半路出家,去資策會閉關半年入這行的
不學無術先請別見怪
以我自己來說,從來不覺得程式寫法有甚麼優劣,程式是幫客戶解決問題的
只要能達到目的,效能可以達到,維護不困難
沒必要在那裏鼓吹什麼手法

當然或許是因為我做過很久的維運
個人反而不喜歡一堆抽象化的手法
當客戶火燒屁股電話追殺的時候
我還必須要追到抽象的類別或介面,然後判斷到底產生的是啥鳥物件
到底幹了那些好事
那開發者你還不如每一個類別乖乖地用複製貼上,我還比較好追

每個人都有自己立場
開發的人覺得自己的程式寫得很"優美",不重複
後頭維運的人如果技術層次跟不上
只有兩種可能,想辦法跟上,或是把問題踢回給你自己處理

另外像我有一個傾向
就是一個專案只要開始做,大家決定用甚麼技術後
不管有甚麼新的了不起技術
開會只要有人要用新東西,個人一概反對到底
除非不用無法解決現行問題,不然不管多沒水準還是一律要用一開始律定的技術
這是開發的紀律,要用請用在別的案子

很簡單,專案不是給你練功夫的
你懂別人不懂
不代表你厲害,只代表你"搖屁股",替"隊友"製造麻煩而已
像我就遇過很有進取心的同事
每一個功能,只要有進化的可能,他都要做點小修改
然後最初的功能跟最後寫的差很大...
等到他走了
接手他的功能,大家幹到沒力!

老兄,你還不如每個功能都一樣寫法!

以RD來說,這當然是有點不進取,我也承認啦
不過就像前面說的
個人維運做很久
有時候必須想的不全然只有自己的立場

抱歉以上得罪諸多高手之處,再一次致上歉意

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.112.125.79
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462763041.A.66F.html

---

我只能說多數人很容易陷入以為全世界就是自己看的那樣

以成語來說大概就是以管窺天吧

你說每個類別都乖乖複製貼上

你有沒有遇過一次改版要改全部系統

然後你那些貼上的地方要一個一個改的情況?

我還真的有遇過而且才剛結束

有時候我真的很好奇是不是有公司用程式碼長度來算薪水的?

明明就是一樣的東西一樣的動作

就是有人不喜歡抽離成一個工具方法

然後每一個地方都複製貼上

最後如果要改版就得全部挖出來一個一個改

然後改的時候還要確認是不是有跟其他複製的地方不一樣

這樣有比較爽嘛?



我認為寫程式所謂的優美

指的是程式簡潔好讀

這不是什麼潔癖

而是為了讓你能準時下班的必備coding style

我名言就是「偷懶的最好方法就是一次把程式寫好」

一次寫好抽離能抽離的部份使之能改到最少

你程式問題少user也就少來靠北

你能準時下班的機會就多

一堆人寫出來的程式耦合性強到靠北

然後要改的時候就跟玩疊疊樂一樣

可能抽一塊積木就整個垮了

這時候也只能加班收拾自己造的孽不然還能幹麻?

然後因為耦合性太強太難改就會想一堆奇奇怪怪的解決方法

最後終於長成四不像的怪獸天天浪費自己甚至下一個接手人的生命

而且就我觀察

這種人幾乎都是覺得寫程式就是這樣阿

也不會再去思考是否有更好的解決方案

每次聽到有人在那邊大放厥詞說什麼物件導向、重構、設計模式沒用我就心裡偷笑

這跟公開大聲跟大家說「老子實力弱到連物件導向的好處都體會不到」一樣意思

這種東西你本來就是要會遇到你才知道他的好

沒有實際遇過你跟講一百遍你還是無法體會

寫過好幾年程式還不能體會這些好處

那我只能說什麼樣的人就會待在什麼樣等級的地方

這是我幹過駐點待過公司看過一堆人之後的心得

也是我給自己最大的警惕

※ 引述《allenxxx (fufuxxx)》之銘言：
: 個人是半路出家,去資策會閉關半年入這行的
: 不學無術先請別見怪
: 以我自己來說,從來不覺得程式寫法有甚麼優劣,程式是幫客戶解決問題的
: 只要能達到目的,效能可以達到,維護不困難
: 沒必要在那裏鼓吹什麼手法
: 當然或許是因為我做過很久的維運
: 個人反而不喜歡一堆抽象化的手法
: 當客戶火燒屁股電話追殺的時候
: 我還必須要追到抽象的類別或介面,然後判斷到底產生的是啥鳥物件
: 到底幹了那些好事
: 那開發者你還不如每一個類別乖乖地用複製貼上,我還比較好追
: 每個人都有自己立場
: 開發的人覺得自己的程式寫得很"優美",不重複
: 後頭維運的人如果技術層次跟不上
: 只有兩種可能,想辦法跟上,或是把問題踢回給你自己處理
: 另外像我有一個傾向
: 就是一個專案只要開始做,大家決定用甚麼技術後
: 不管有甚麼新的了不起技術
: 開會只要有人要用新東西,個人一概反對到底
: 除非不用無法解決現行問題,不然不管多沒水準還是一律要用一開始律定的技術
: 這是開發的紀律,要用請用在別的案子
: 很簡單,專案不是給你練功夫的
: 你懂別人不懂
: 不代表你厲害,只代表你"搖屁股",替"隊友"製造麻煩而已
: 像我就遇過很有進取心的同事
: 每一個功能,只要有進化的可能,他都要做點小修改
: 然後最初的功能跟最後寫的差很大...
: 等到他走了
: 接手他的功能,大家幹到沒力!
: 老兄,你還不如每個功能都一樣寫法!
: 以RD來說,這當然是有點不進取,我也承認啦
: 不過就像前面說的
: 個人維運做很久
: 有時候必須想的不全然只有自己的立場
: 抱歉以上得罪諸多高手之處,再一次致上歉意

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.42.229.138
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462797038.A.76A.html

簡潔的確在軟體中有很多含意

在這我的確指的是邏輯易讀好懂

像是code會有點髒但比較好讀跟簡潔但不好讀的寫法

我同常還是會選擇前者


我只黑特拖我下班時間的打字工(根本就不是工程師好嗎！！！)
※ 編輯: aoksc (114.42.229.138), 05/09/2016 21:50:30

也沒那麼神

也是有人濫用搞到最後我還是要多花時間去處理的例子

技術的好壞最後還是操之於實現的人



還好啦

至少我都嘴的有所本

不服的話我也很歡迎來討戰…喔是討論


受教了

我會再思考看看什麼情況用複製貼上是最好解法

但我看過的Code幾乎都是為了複製貼上而複製貼上…

※ 編輯: aoksc (114.42.229.138), 05/09/2016 23:18:43
※ 編輯: aoksc (114.42.229.138), 05/09/2016 23:22:22

---

原原PO令我想起我之前遇過一間公司也很奇葩

他們公司有訂coding style

然後你空格空錯主管就會用一種你殺他父母一樣的口氣吼你

吼到整間辨公室都知道你空格空錯 你程式有漏洞他們都還沒這麼兇

重點是我寫的是PHP 不是PYTHON那種空格有嚴格要求的程式

我勸他們用code formatter他們也不要

他們說"code formatter會安插程式碼在你的程式裡"

最好笑的話他們公司裡老屁股最大

我寫jquery時用了trigger這個function

他們就說"這個function在我們公司沒人用過 所以你不能用"

覺得他們太奇葩 就離職了

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.121.218.99
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462972853.A.B77.html


--
※ 作者: terievv 時間: 2016-05-15 08:27:27