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

[ericwang1017 (Eric)]

看了很多板大的回文，我也來寫寫感想

1.150行與七個變數的問題的規定是十分合理的，書上都有寫這邊就不再贅述
  而過多的註解不見得是一件好事，反而是一件壞事
  所以註解包含在150行中也是很合理的

  如果150行稱作好的style, 難道151行就是差的嗎？為何定7參數的原因難道是8參數太多嗎？
  只不過很可惜的是上面的美意並沒有傳達到每個PG上，變得流於形式
  也許這部份要跟老闆溝通過才會有改善

2.上頭要求用bean是正確的決定，因為open出去的API若是因為參數的增加而改變
  會產生很多相容性問題
  很多原本可執行的code都會變得需要改變，到時會變得很麻煩

3.能有把垃圾山整理成國家公園的經驗是很有價值的，因為到處都是垃圾山

OO一點都不蠢，軟工的東西也不是空口說白話
會寫程式的人一狗票，有理論基礎的卻沒幾個，OCP, DSP,liskov...etc
甚至DP講出來不是沒人知道，就是被人笑

因為太多太多的資深/資淺 工程師會跟你說那東西沒用
資深的藉口會跟你說能動就是100分
資淺的會說手邊的工作就已經做不完了

"書上講的都是理論，根本不能在實務上..."，這句話常常出現在工程師討論中出現
不過講這句話的人多是不看書的人....



我不是專家，不專業的心得，看看就好


※ 引述《hegemon (hegemon)》之銘言：
: 最近公司開始雷厲風行地要求所有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: 118.160.236.231
推 costbook:如果把Java當成ANSI C來寫，就不用管OO啦～
→ costbook:不過即使是寫ANSI C，也是需要好的架構，除非程式開發完
→ costbook:就不要了、也不用維護，或是人力太多...
→ gname:如果多看幾本書就能完全把理論實現在專案上,我會看一卡車...
→ newjoy:光"看"當然沒用, 還得動手從小的練習起
→ newjoy:不過我的經驗是自己已經有點體會了之後, 再看書就全都通了
→ remmurds:CMMI表示: