Re: [閒聊] Java的CheckStyle...

看板Soft_Job作者 (職業格鬥家)時間13年前 (2011/03/30 22:27), 編輯推噓13(13推 0噓 43→)
留言56則, 9人參與, 最新討論串5/7 (看更多)
個人剛好最近在研究這個, 加上你又坐我旁邊 我就認真的回答一下, 順便當成我的教材 ※ 引述《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)
推
03/30 22:31, , 1F
有問到理由呀..理由就是..上面的規定下來了.照辦
03/30 22:31, 1F
→
03/30 22:32, , 2F
SQL太長跟註解加入行數導致method爆長的問題沒有得到回應
03/30 22:32, 2F
→
03/30 22:34, , 3F
sad, 我不知道這個決策經過幾個人, 因為那些人都不適任
03/30 22:34, 3F
→
03/30 22:34, , 4F
checkstyle中規定一定要寫注解..但是又算在行數內
03/30 22:34, 4F
→
03/30 22:34, , 5F
訂規定的人8成是學院派的... 是我的話就拿實例打他的臉
03/30 22:34, 5F
→
03/30 22:35, , 6F
所以現在看到一堆同事為了躲過check..寫那種無意義的註解
03/30 22:35, 6F
→
03/30 22:35, , 7F
每個變數的註解就是...把變數名稱再抄一次....
03/30 22:35, 7F
→
03/30 22:36, , 8F
每個method的註解..就是把method的名稱再抄一次
03/30 22:36, 8F
→
03/30 22:36, , 9F
目前只爭取到超過七個變數暫緩修改..
03/30 22:36, 9F
→
03/30 22:37, , 10F
說錯..應該是超過七個代入參數....
03/30 22:37, 10F
→
03/30 22:38, , 11F
對軟體品質把關的事怎麼會交給checkstyle? 應該交給人阿..
03/30 22:38, 11F
→
03/30 22:39, , 12F
他們說這樣可以節省code review的時間跟人力....
03/30 22:39, 12F
→
03/30 22:39, , 13F
這種作法擺明了就是把寫code的全當傻子 (雖然以前有很多是)
03/30 22:39, 13F
→
03/30 22:40, , 14F
f**k,我還聽說有人code review是叫寫code的人念他的code的
03/30 22:40, 14F
→
03/30 22:40, , 15F
我是覺得..乾脆規定這麼多...乾脆也不要SD了....
03/30 22:40, 15F
→
03/30 22:40, , 16F
這才叫浪費時間...訂規定的人完全搞不清楚狀況...
03/30 22:40, 16F
→
03/30 22:42, , 17F
應該是人在用工具, 怎麼會是人去遷就checkstyle這工具
03/30 22:42, 17F
→
03/30 22:44, , 18F
會做這種決策的全是一群笨蛋 = ="
03/30 22:44, 18F
推
03/30 22:46, , 19F
應該是太久沒有實際寫code了
03/30 22:46, 19F
推
03/30 22:47, , 20F
該不會上面是想導什麼認證...
03/30 22:47, 20F
→
03/30 22:48, , 21F
更慘的是..出問題最大的那部分太老了..根本沒用ORM...
03/30 22:48, 21F
→
03/30 22:49, , 22F
聽說是..每年都要有個重點topic拿給上面做交代...
03/30 22:49, 22F
推
03/30 22:49, , 23F
不知道要花多少時間在改衣服上?
03/30 22:49, 23F
→
03/30 22:51, , 24F
今年主題 : [軟體品質既生產力改善] 作法 :
03/30 22:51, 24F
→
03/30 22:51, , 25F
把下這個決策的人全數轉去別的職位, 就完成了, ya~
03/30 22:51, 25F
推
03/30 22:51, , 26F
應該是不到一個月吧..加新功能的時候"順便"改舊的
03/30 22:51, 26F
→
03/30 22:52, , 27F
不過現在平台可能要翻掉..明年可能又要從頭架....
03/30 22:52, 27F
→
03/30 22:54, , 28F
遇到不合理的規定馬上去翻桌才是proj leader該做的
03/30 22:54, 28F
→
03/30 22:54, , 29F
喔~ 這樣每年才都會有點事可以做, 那我誤會他了.
03/30 22:54, 29F
推
03/30 22:56, , 30F
沒人敢吧..
03/30 22:56, 30F
→
03/30 22:56, , 31F
我們工作量都排到明年去了..怎麼會沒事做..
03/30 22:56, 31F
→
03/30 22:57, , 32F
leader不去翻難道SD翻嗎..一般來說可以他定他的我寫我的
03/30 22:57, 32F
→
03/30 22:58, , 33F
但是定成這樣跟叫人用滑鼠coding 有什麼兩樣
03/30 22:58, 33F
推
03/30 22:59, , 34F
一直有事做也好, 不用擔心一週只能來3天 (誤)
03/30 22:59, 34F
→
03/30 23:05, , 35F
嗯,我了,總之是有一個不事生產的單位 要提升我們的軟體品質
03/30 23:05, 35F
→
03/30 23:06, , 36F
但是這是質化的東西 沒法量化他們的考績
03/30 23:06, 36F
→
03/30 23:08, , 37F
叫人去做code review不能當他們的烤雞, 那只好搞點事了...
03/30 23:08, 37F
→
03/31 02:33, , 38F
經典: 你真的是離開前線太久了, 連少了子彈的槍重都感覺不出來
03/31 02:33, 38F
→
03/31 05:43, , 39F
樓上那是即刻救援的台詞XD 看到這篇的推文就像看到前公司
03/31 05:43, 39F
→
03/31 05:45, , 40F
一樣~重視Domain Know How~幾乎把技術放一邊~總以為有個很
03/31 05:45, 40F
→
03/31 05:47, , 41F
強的開發元件部門搞個程式碼產生器和檢查CheckStyle的程式
03/31 05:47, 41F
→
03/31 05:50, , 42F
上傳機制就可以什麼都不管了~正是h大說的"他們認為這樣可
03/31 05:50, 42F
→
03/31 05:51, , 43F
以節省Review Code的時間和人力"→這不正是把Design Patte
03/31 05:51, 43F
→
03/31 05:55, , 44F
rn踩在腳底下~不屑一顧的意思?
03/31 05:55, 44F
推
03/31 06:07, , 45F
原提問的h大也真是幸運~還有個公司的前輩上來說明~我之前
03/31 06:07, 45F
→
03/31 06:08, , 46F
可是誰都沒說~更別提有人會跟你討論怎樣設計才叫OO
03/31 06:08, 46F
→
04/01 22:52, , 47F
悲哀的是, 很多人聽都沒聽過design pattern
04/01 22:52, 47F
推
04/02 00:54, , 48F
推！
04/02 00:54, 48F
推
04/02 10:28, , 49F
先推一下了，這陣子在複習Code Complete也有看到
04/02 10:28, 49F
→
04/02 10:28, , 50F
150行是因為統計上，sub-routine在這範圍內bug發生率最少
04/02 10:28, 50F
→
04/02 10:29, , 51F
7個參數則是跟人腦有關，很久以前看心理學的書也有談到
04/02 10:29, 51F
→
04/02 10:29, , 52F
就像電話號碼通常也在7碼內，超過就很容易被忘記。
04/02 10:29, 52F
推
04/02 10:33, , 53F
所以書上也說了，超過7個，建議用stuct或simple obj封裝
04/02 10:33, 53F
推
04/02 10:38, , 54F
struct... 打錯 @@"
04/02 10:38, 54F
推
04/02 14:29, , 55F
我突然注意到 大便沒擦屁股 !
04/02 14:29, 55F
→
04/02 21:23, , 56F
靠! 竟然被reviewer抓到了@@!
04/02 21:23, 56F
‣ 更多 newjoy 的文章
文章代碼(AID): #1DaptNJ4 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 5 之 7 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 newjoy 的文章
文章代碼(AID): #1DaptNJ4 (Soft_Job)