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

看板Soft_Job作者 (null)時間13年前 (2011/03/30 23:34), 編輯推噓6(6028)
留言34則, 9人參與, 最新討論串6/7 (看更多)
從原PO的感受來看,這整件事是個詭局:使用 CheckStyle 來提昇程式的品質。 但最終很可能是使用 CheckStyle 達成形式上的品質提昇。 (熟稔規避 CheckStyle 的方法) 花下去的是時間,跟埋下未有完整測試計劃而產生的 Bug。 改善程式碼品質的活動,廣義來說就是重構。 重構的ABC就是:撰寫測試、改善品質、驗證結果,三者的循環。 回到程式碼的品質這件事,該提昇的不是程式碼本身。 而是透過 Code Review 讓開發者來學會新思維,跟認識潛在的錯誤類型。 而條件制約式的要求,只會讓人想快點解除那狂叫的蜂鳴器。 品質這件事是需要經過內省與再吸收的。 我們可以很輕易地寫出很多類別,並且每個方法在150內,參數少於7個。 但靜態分析工具無法告訴我們, 哪些不符合單一責任原則、哪些設計不符合開放封閉的結構。 這些對於品質審美觀有益的『眼光』訓練是得傳承的。 當決策者決定將大筆的預算(人力成本=薪水, 工時) 指向陳舊不再有變動需求的程式碼時,就是損失的開始。 因為這根本無法有理由能支持,這項決策會帶來優點。 (多出來的Bug,可能還得再花很多時間找出來) 我也認同推文建議的, 以最實在的 Code Review 提昇共同工作伙伴的能力, 才是最佳的投資,也是最廉價的教育訓練,並感染寫作共識。 品質這回事並不是看已經犯了多少錯,或做對了多少。 而是加快好產出的速度,減低壞產出的速度。 正所謂:不怕神一般的對手,只怕豬一樣的隊友。 ※ 引述《newjoy (職業格鬥家)》之銘言: : 個人剛好最近在研究這個, 加上你又坐我旁邊 : 我就認真的回答一下, 順便當成我的教材 : ※ 引述《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: 61.231.49.77

03/30 23:38, , 1F
我對"單一責任原則"及"開閉原則" 的解釋有點小問題
03/30 23:38, 1F

03/30 23:39, , 2F
因為用抽象的表達方式慣了, 一時之間不知道怎麼翻譯給coder
03/30 23:39, 2F

03/30 23:39, , 3F
聽得懂的語言 "不遵守單一責任的話,你的code會變成怎樣.."
03/30 23:39, 3F

03/30 23:41, , 4F
這可以配合重構的 bad smell 型錄來看 :)
03/30 23:41, 4F

03/30 23:43, , 5F
目前因為checkstyle而變動的code都有做test..
03/30 23:43, 5F

03/30 23:44, , 6F
不過花下去的時間不少..還把test team拖下水...
03/30 23:44, 6F

03/30 23:46, , 7F
真是大手筆啊. 這樣人事成本不就....沒用在比較好的方向
03/30 23:46, 7F

03/30 23:54, , 8F
作這種變動的test真是冤, 有改得更好就算了..偏偏沒有
03/30 23:54, 8F

03/30 23:59, , 9F
OCP我的理解是,不因新需求而修改程式碼(close for modify
03/30 23:59, 9F

03/31 00:01, , 10F
但可透過其他方式增加或改變行為(open for extension)
03/31 00:01, 10F

03/31 00:02, , 11F
BTW,不遵守單一責任的話應該會出現神之物件!?
03/31 00:02, 11F

03/31 00:15, , 12F
這些OO語言大家都會講, 但是要翻譯給新手coder聽不懂
03/31 00:15, 12F

03/31 00:15, , 13F
要轉成"不這樣的話你的程式遇到什麼變動時會怎樣怎樣" 才行
03/31 00:15, 13F

03/31 00:18, , 14F
OCP我的理解是,你沒空時很自然會選擇的做法 XD
03/31 00:18, 14F

03/31 00:45, , 15F
寫一個Compiler把舊的code compile成通過CheckStyle的檢查.
03/31 00:45, 15F

03/31 08:48, , 16F
那應該就變成神了
03/31 08:48, 16F

03/31 11:44, , 17F
也許可以畫圖或說故事解釋!?
03/31 11:44, 17F

04/01 11:24, , 18F
只有我覺得七個變數是很正常的限制嗎? ...
04/01 11:24, 18F

04/01 23:06, , 19F
code review也有個盲點...就是萬一review的人也...
04/01 23:06, 19F

04/01 23:08, , 20F
即使review的人程度平平 , code review還是會有收穫的 .
04/01 23:08, 20F

04/01 23:35, , 21F
code reviewer程度可以平平, 但是至少要看得出啥是爛code
04/01 23:35, 21F

04/01 23:39, , 22F
只要他能夠提出另一種solution,就有機會透過討論進步。
04/01 23:39, 22F

04/01 23:39, , 23F
沒有所謂絕對的爛code,只有相對的爛code。
04/01 23:39, 23F

04/01 23:40, , 24F
但是如果有兩個以上的解法 就值得討論那個解法比較適合,可
04/01 23:40, 24F

04/01 23:40, , 25F
從中去瞭解不同觀點的設計與論點,這些都很有幫助。
04/01 23:40, 25F

04/01 23:40, , 26F
這比較接近 pair 了,pair 反而不適合技術落差太大,這樣另
04/01 23:40, 26F

04/01 23:40, , 27F
一個人就只能被動的接受訊息,而非透過討論而進步。
04/01 23:40, 27F

04/01 23:41, , 28F
其實問題不在程度,而在討論。比較大的問題是拒絕討論,而是
04/01 23:41, 28F

04/01 23:41, , 29F
單方的堅持自己的實做,或者是單方的要求對方接受自己的想法
04/01 23:41, 29F

04/01 23:42, , 30F
只要能夠有好的互動,程度至少在相同的水平上,就很夠了。
04/01 23:42, 30F

04/01 23:43, , 31F
而且,code review至少有人幫你複核你的邏輯是可行的,有些
04/01 23:43, 31F

04/01 23:43, , 32F
時候人總是思緒不清楚的,有些條件沒判斷到什麼的。code
04/01 23:43, 32F

04/01 23:43, , 33F
review 對這種事情也特別有幫助。
04/01 23:43, 33F

04/02 00:23, , 34F
不過review有時也挺累的,常常要花很久時間解釋邏輯
04/02 00:23, 34F
文章代碼(AID): #1Daqs6K4 (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1Daqs6K4 (Soft_Job)