---

※ 本文轉寄自 a1234957.bbs@ptt.cc

---

個人剛好最近在研究這個, 加上你又坐我旁邊

我就認真的回答一下, 順便當成我的教材

※ 引述《hegemon (hegemon)》之銘言：
: 最近公司開始雷厲風行地要求所有Java Code都要符合CheckStyle Plugin的標準.
: 連多年前老人留下來的東西也不例外. 最近做整個系統的檢查. 發現竟然有快二十萬個警告.
: 這還不打緊.裡面很多都是tab跟四個space,括號前後space,或是變數大小寫的問題. 那些都好解決
: 但是還有不少是啥...一個method不能超過一百五十行,或是一個method不能代入超過七個變數.
: 這兩個規定個人覺得十分不合理.

我看到method的行數跟參數的個數是7, 就覺得非常眼熟

最近剛好在看的<軟體建構之道>(code complete)裡面就有提到
"人腦所能掌握的物件個數大約在七個左右, 所以變數跟參數最好不要超過7"

所以我推測, 這些coding standard全部都是為了符合"書上"的規範


因為我不知道他把這些規矩定下來的真正原因是什麼, 但是你可以去問問看.
掌握設計時真正的想法, 才能循線把整個設計實作出來
設計師把衣服的設計圖畫好, 材質選好, ......然後送給中國大陸去製造
然後成品就整個毀了...
由於製作的工人完全不能體會設計者的用心, 作出來的成品自然參差不齊.

[技術面]

1. 關於參數個數為什麼是7 , 以及為什麼一個method不能超過 150行.

(理念)

原意是為了要讓coder寫出這種code的時候重新思考他的寫法是不是有問題?
是不是沒有符合OO的概念?

因為根據統計, 只要一個method超過這個行數, 可能就要思考一下另行的作法了
另一方面也是為了code可讀性的關係.

所以, 當參數個數太多的時候, 你可能要考慮一下是不是要把這些參數包成一個
private的class, 然後user看class name就大概能知道這裡面的參數是什麼用途.
ex :

菜刀
覘板
牛肉
鹽

的參數可以包在一個叫做"晚餐材料"的class裡面傳遞給method.

一個method 不能超過 150行, 也是為了怕沒經驗的coder把一堆有的沒的全部寫在
同一個method裡面, 造成可讀性&複用性差(而且會這樣通常是copy & paste造成的).
通常如果幾行code描述一件事, 那最好就用一個method把這件事包起來.
比如說 :

脫外褲;
脫內褲;
大便;
沖水;
穿內褲;
穿外褲;

看的人可能要一直讀到一個段落才能了解你的意思, 那乾脆就直接包成一個叫
"去上大號"的method, 清楚多了

(實際)

所以根據你所面對的實際狀況, 你絕對有足夠的理由拿著這些論點去據理...詢問
可以找另一個人一起壯膽(沒人的話也可以找我啦), 因為應該不是只有你遇到這個問題,
而且你一個人說的話只代表你自己,
多人一起表達同樣的意見的話代表這件事真的有點問題.

因為就你所說的情況, 很明顯是因為整個程式整體架構的問題,
現行有ORM比如引入Hibernate可以減少SQL行數的問題,
反正絕對不是幾個小coder敲敲鍵盤全手工打造 + check style
就能在一兩個月內解決的, (這是架構問題, 應該是project leader要解決的)
在沒整體修改架構前, 反而會為了要遵守這個check style而產生更多問題.

另外, 一支優秀的API, 註解比code多很多才能讓user用得很安心
這個150行的限制竟然包含註解絕對是錯的
這豈不是鼓勵大家為了就範而產生大量無註解的爛code嗎?

2. VB傳參數應該建一個class 扮演 model的角色, 把這些參數包起來傳
現在應該算是不得已得用String array在 VB <--> Java 間互傳
(因為物件不相通的關係, 有時候只能用Array)
apache 有提供一個叫 DynaBean的東西, 可以讓你動態產生Bean而不用去動那些
getter & setter (但是還要加上一些機制才能用得正確, 不是直接拿了就用, 會爆的)
http://yinhe2726.javaeye.com/blog/464504


//---

總的來說, 我覺得你的leader跟你在溝通上有點問題
他的想法並沒有完全套到你的腦子裡, 卻要你直接套用他的想法
不管是他不想教還是不會教, 你們之間還是要把想法溝通清楚.

因為現在看起來, 他似乎沒有把為什麼要150行跟7個參數的原因清楚的告訴你,
如果不清楚原因跟相對應的OO寫作技巧
而硬是要去遵守150行限制, 會產生一大堆沒有內聚力的
classA-1
classA-2
classA-3
這是OO典型的anti-pattern阿! 它本來是想解決code難以閱讀維護的問題,
但是方法沒用對, 反而造成更大的問題. (比全部寫在同一隻code還難trace)

換句話說, 也可以看成是他對你們的OO coding 作戰能力非常有信心...........
(但是SQL落落長那邊他不置一詞就定下這個規定, 我個人比較頃向是他
對project不熟悉造成的...)


這些規範本身用意是好的, 但是用數字去定死的話, 還需要人去"設計"嗎
這本來是應該需要人去code review的部份, 防止你寫出糟code 毒害整個系統.


[人際溝通面]

遇事抱怨固然是一定要的  不然人會憋死, 但是把抱怨包裝得好聽一點
加上一點點建議跟疑問去問主事者,  相信他們很樂意回答

我先問問, 你有問過 "為什麼要這樣做" 嗎?
看起來他也不像有回答過你 "一個method裡的 SQL超過 150行該怎麼做"
如果有, 而他不能給你滿意的回答 -- 是他不適任, 你自己皮繃緊點
或者是你聽起來他應該懂, 但是他不能解釋到你懂 -- 有知識落差, 再問其他人問到懂

要知道, geeker 講起話來通常是跩到會飛, 而他們只尊重聽得懂他話的人.

: 我們Java Code大多是在搞SQL.偏偏公司資料散在一堆tables裡面.所以每一串SQL都不是普通的長.
: 要在一百五十行內把一個SQL搞定已經很勉強了,如果這個method要用到多個SQL..保證破表.
: 至於一個method不能代入超過七個變數也很擾民.我們系統前端是VB.所以一堆變數都是從VB丟來.
: 偏偏USER又很喜歡在VB那邊加一堆comboBox,textBox之類的,這些全部都是單一SQL要用的條件.
: 上頭還要求不能用array的方式解決..要求的方法是...VB傳變數到Bean中,Bean新建一個Object.
: 然後把變數set進Object內,再丟入method中.這看起來是可行的做法.但是...卻完全沒考慮到method
: 的便利性和精簡度. 過去雖然變數多,但是註解寫好的話(其實看變數名稱就知道要怎麼用了...)
: 後面的人直接用就好了..現在卻還要先new一個Object.然後set變數,接著再丟進去method.
: method要用時,要先一個一個的get出來,然後再把這些變數弄進該用的地方.如果一個method要用到
: 不同條件的Object..光set,get就可以吃掉那一百五十行中的不少比例了.
: 適當的使用工具及規範來讓程設把Code寫乾淨我是很贊成,但是搞成這樣...根本就是擾民..
: 開始後悔到大公司上班了....
: 不知道各位對這有啥看法..


ps. 如果有問到為什麼要這樣做的原由, 可以請你站內信給我嗎? thx

--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.135.248.140
※ 編輯: newjoy          來自: 220.135.248.140      (03/30 22:30)
※ 編輯: newjoy          來自: 220.135.248.140      (03/30 22:31)


--