[閒聊] Java的CheckStyle...

看板Soft_Job作者 (hegemon)時間13年前 (2011/03/28 22:45), 編輯推噓11(11推 0噓 29→)
留言40則, 15人參與, 最新討論串1/7 (看更多)
最近公司開始雷厲風行地要求所有Java Code都要符合CheckStyle Plugin的標準. 連多年前老人留下來的東西也不例外. 最近做整個系統的檢查. 發現竟然有快二十萬個警告. 這還不打緊.裡面很多都是tab跟四個space,括號前後space,或是變數大小寫的問題. 那些都好解決 但是還有不少是啥...一個method不能超過一百五十行,或是一個method不能代入超過七個變數. 這兩個規定個人覺得十分不合理. 我們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寫乾淨我是很贊成,但是搞成這樣...根本就是擾民.. 開始後悔到大公司上班了.... 不知道各位對這有啥看法.. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.43.189.108 ※ 編輯: hegemon 來自: 114.43.189.108 (03/28 22:45)
推
03/28 22:56, , 1F
退伍啦?
03/28 22:56, 1F
→
03/28 23:02, , 2F
沒有當兵..一畢業就上班了
03/28 23:02, 2F
推
03/28 23:03, , 3F
免役嗎?
03/28 23:03, 3F
→
03/28 23:11, , 4F
有夠麻煩的 ..
03/28 23:11, 4F
→
03/28 23:19, , 5F
免役
03/28 23:19, 5F
→
03/28 23:21, , 6F
架構問題 程式撰寫方式也問題 問題太多 只好用蠢方式
03/28 23:21, 6F
→
03/28 23:21, , 7F
但結果仍然是愚蠢的...付出的成本也是愚蠢的
03/28 23:21, 7F
推
03/28 23:25, , 8F
拿人家的薪水..做吧
03/28 23:25, 8F
推
03/29 00:24, , 9F
這個軟體還會改版嗎? 會的話就哭著做了不會的話改是白痴
03/29 00:24, 9F
→
03/29 00:24, , 10F
搬石頭砸自己的腳大概就是這樣，只是砸得值不值得.....
03/29 00:24, 10F
→
03/29 00:26, , 11F
這個系統以後會轉往Netweaver..所以會大改
03/29 00:26, 11F
→
03/29 00:26, , 12F
話說公司閒到沒有可以賺錢的事做了嗎? ........
03/29 00:26, 12F
→
03/29 00:27, , 13F
前人搬石頭砸後人的腳...或是上面的搬石頭砸下面的腳
03/29 00:27, 13F
推
03/29 00:58, , 14F
以前被要求過 當時還有註解結尾一定要加. 超嚴格XD
03/29 00:58, 14F
→
03/29 01:38, , 15F
我覺得人家給你薪水就做啊，在很多公司你想作這種整理程式碼
03/29 01:38, 15F
→
03/29 01:38, , 16F
的練習人家還嫌你浪費時間。這種事情值得不值得交給主管去考
03/29 01:38, 16F
→
03/29 01:39, , 17F
量吧。至少以身為一個開發者而言，這件事對提昇技能有很大幫
03/29 01:39, 17F
→
03/29 01:39, , 18F
助。
03/29 01:39, 18F
→
03/29 01:41, , 19F
當然，修改完後不可能是 bug-free 的，一定會跟著噴一堆錯誤
03/29 01:41, 19F
→
03/29 01:41, , 20F
只要先確定公司有這個心臟去改他，剩下的說真的我覺得這算是
03/29 01:41, 20F
→
03/29 01:42, , 21F
件好事，對磨練個人技能來講。以我的觀點來看，問題出在架構
03/29 01:42, 21F
→
03/29 01:43, , 22F
，而不是SQL一定要這麼多參數。
03/29 01:43, 22F
→
03/29 01:44, , 23F
param object 也只是解決這個問題的其中一招，而非唯一一招
03/29 01:44, 23F
→
03/29 01:44, , 24F
*而不是組SQL 一定要傳很多參數才直覺
03/29 01:44, 24F
→
03/29 07:01, , 25F
問題出在架構+1 之所以限制行數~是要提醒pg在撰寫時是否有
03/29 07:01, 25F
→
03/29 07:02, , 26F
考慮到設計的問題~如果沒有~自然很容易超過~而物件導向設
03/29 07:02, 26F
→
03/29 07:04, , 27F
計的寫法雖然看起來繁雜~但會比較好維護~如果說有遇到兩個
03/29 07:04, 27F
→
03/29 07:06, , 28F
不同的物件要塞進同一個table~一個欄位卻有不同的意義~其
03/29 07:06, 28F
→
03/29 07:07, , 29F
它欄位又大同小異時~直接傳參數可能會讓接手的人更混亂
03/29 07:07, 29F
→
03/29 07:08, , 30F
CheckStyle也不是Java的專利~應該是所有寫程式的人都該考
03/29 07:08, 30F
→
03/29 07:09, , 31F
慮到的東西~是直接一磚一瓦蓋~還是打好地基再漸漸上去...
03/29 07:09, 31F
→
03/29 07:31, , 32F
就好像程式好好的~它幹嘛分MVC~為得不就是讓各個部份單純
03/29 07:31, 32F
→
03/29 07:33, , 33F
化~更有彈性~也更具維護性~要不然大家都一道指令下到資料
03/29 07:33, 33F
→
03/29 07:34, , 34F
庫去~就可以拍拍屁股回家了(然後越改越多越晚回家Orz)
03/29 07:34, 34F
推
03/29 10:48, , 35F
程式設計時盡可能符合這些精神 出來的Code應該好維護很多
03/29 10:48, 35F
推
03/29 13:43, , 36F
麻煩是一時,方便維護是一輩子
03/29 13:43, 36F
推
03/29 22:17, , 37F
不要按enter....全部擠在同一行跟他拼
03/29 22:17, 37F
推
03/30 00:26, , 38F
一個method不能用超過七個變數，豈不是叫人建一堆function...
03/30 00:26, 38F
推
03/30 01:11, , 39F
樓上讓我想到default value...也豈不是要人建一堆func.
03/30 01:11, 39F
推
04/05 15:06, , 40F
一個METHOD超過150行 後人不好接手維護
04/05 15:06, 40F
‣ 更多 hegemon 的文章
文章代碼(AID): #1Da9yB8A (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 7 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 hegemon 的文章
文章代碼(AID): #1Da9yB8A (Soft_Job)