PTT職涯區 / Soft_Job (軟體人)

[閒聊] 被主管的新政策搞得有點倦勤....

看板Soft_Job (軟體人)作者 (hegemon)時間13年前 (2013/01/12 03:51), 編輯推噓11(11推 0噓 46→)
留言57則, 15人參與, 最新討論串1/1
最近主管不知道是受到啥刺激.引進了Sonar.(http://www.sonarsource.org/) 主要是在設定的時間點自動bulid Java code, 跑一些Unit Test及尋找違反規定程式碼的系統. 還訂下了規定, 每天都要完整run一次(除非沒有新code進版本控管,) 不能有fail的Unit Test Case, 新code涵蓋率要>80%, 重複的code不能占5%以上, 而且不能有新增的違反規定程式碼. 但是.問題來了, 如果你有動到老人的code, 這樣子系統就會判定那段code是你的. 於是那段code既存的所有問題就會全部丟到你身上.. 管你是挪動位置, 刪個空格, 加個換行, 通通都要你吃下來. 而且限當天解掉. 如果隔天沒解掉就會收到主管奪命連環call..再拖久一點就找你去泡茶. (有些真的是...小問題..我不太相信變數名稱改個大小寫, 或是把沒用到的import拿掉有需要兩小時內寄四五封信來催) 但是問題又來了, 為了解這些東西, 有時要花時間去研究, 還要花時間測試. 如果剛好碰到正在測試階段的東西, 好死不死要動的地方SA跟Tester已經測完. 馬上會被罵到臭頭....(他們經常抱怨為啥要為這種事情改code..害他們要重測) 再來就是經常改規定, 常發生睡一覺起來突然多一堆要改的東西. 然後原本當天要做的事情馬上被打亂, 要優先改這些冒出來的碗糕. . . . . 這除了增加我們的工作量以外, 也嚴重影響到我們enhance code的意願. 原本我們遇到剛好要改的地方可以enhance時, 會去找最適合的寫法改進. 現在我們只會把要加的功能加一加, 原本的爛code就繼續沿用吧.. 更造成團隊的氣氛有點差, 原本我們在戰況緊急時會相互支援, 現在我們開始會斤斤計較, 能不碰的工作就不碰. . . . . 現在每天坐在辦公室裡面都覺得氣氛很不好,改code時要閃東閃西, 大家為了誰要改code而斤斤計較, 為了抓出是誰的責任而做大量的版本比對. 除了原本Sonar內建的rule還要應付三不五時隨主管高興新增的rule. 請問其他公司會搞這些碗糕嗎? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.171.231.194
推
01/12 07:05, , 1F
我主管以前用過Visual Studio的Code Analysis
01/12 07:05, 1F
→
01/12 07:06, , 2F
開發團隊裡面的資深工程師都不太爽
01/12 07:06, 2F
→
01/12 07:48, , 3F
動code->fail 目前多數軟體的設計都會通知最近動過code的人
01/12 07:48, 3F
→
01/12 07:48, , 4F
也就是說有code owner, 跟讓fail發生的人這兩種概念
01/12 07:48, 4F
→
01/12 07:49, , 5F
覺得第一個要做的是跟主管溝通這種check多久跑一次跟修正時
01/12 07:49, 5F
→
01/12 07:50, , 6F
間長度..讓主管知道實務上做不到....另外測試工程師的觀念沒
01/12 07:50, 6F
→
01/12 07:51, , 7F
錯阿 有動 就要重測..."正規"做法是在flow上面要修正防止~~
01/12 07:51, 7F
→
01/12 07:52, , 8F
daily -> all unit test, weekly-> code analyzer
01/12 07:52, 8F
→
01/12 10:53, , 9F
現在是每天跑...全部的項目
01/12 10:53, 9F
→
01/12 10:55, , 10F
主管只會看是誰改的,不會看是誰造成的
01/12 10:55, 10F
→
01/12 11:19, , 11F
另一個很嚴重的問題點是:時常更改需求。這點沒改進~有什麼
01/12 11:19, 11F
→
01/12 11:20, , 12F
再強大的工具都沒屁用~如果是事前規劃時漏掉~那還情有可原
01/12 11:20, 12F
→
01/12 11:21, , 13F
偏偏很多都是事後自我感覺良好想翻掉...
01/12 11:21, 13F
→
01/12 11:23, , 14F
不好意思~應該說是:"臨時"更改需求。改需求當然OK~但總要
01/12 11:23, 14F
→
01/12 11:23, , 15F
先定個里程碑~做到再說~除非...是整個翻掉...Orz
01/12 11:23, 15F
推
01/12 11:36, , 16F
姑且不論中間是否有管理上的問題; 不過引進新的[東西]本來就
01/12 11:36, 16F
→
01/12 11:38, , 17F
會造成衝擊,初期磨合問題比較多,就組織管理而言,這是正常的,
01/12 11:38, 17F
→
01/12 11:38, , 18F
等上了軌道後,組織就脫胎換骨了(理論上)
01/12 11:38, 18F
→
01/12 11:48, , 19F
應該是主管就脫胎換骨了..有東西可以跟其他單位吹噓
01/12 11:48, 19F
→
01/12 13:24, , 20F
要是我遇到, 會和你有一樣的想法。
01/12 13:24, 20F
→
01/12 13:25, , 21F
不會把心力放在 code 上, 只會想辦法應付這個系統。
01/12 13:25, 21F
推
01/12 16:08, , 22F
code改了不重測 你晚上睡的著喔
01/12 16:08, 22F
→
01/12 17:16, , 23F
磨合是個問題~合理性也是個問題~所以有的公司雖然推行了~
01/12 17:16, 23F
→
01/12 17:16, , 24F
卻也有一堆人想盡辦法鑽漏洞...
01/12 17:16, 24F
→
01/12 17:38, , 25F
是人都會鑽漏洞, 用硬規則管理本來就是行不通的...
01/12 17:38, 25F
→
01/12 19:35, , 26F
又花一堆時間在不會賺錢的地方，白痴，貨真價實的白痴。
01/12 19:35, 26F
→
01/12 19:35, , 27F
你有看過麥當勞拼命改善餐點拿錯的問題嗎? 沒有啊........
01/12 19:35, 27F
→
01/12 19:37, , 28F
程式不會看不懂，不會跑出要你命的bug就夠了.........
01/12 19:37, 28F
→
01/12 19:37, , 29F
其他一堆改善都只是主管在看數據在爽而已，沒用的......
01/12 19:37, 29F
推
01/12 20:18, , 30F
如果麥當勞因為拿錯餐點導致東西重做、翻桌率下降，你看
01/12 20:18, 30F
→
01/12 20:19, , 31F
麥當勞會不會花錢改善拿錯餐點的這個"小"問題，更何況，
01/12 20:19, 31F
→
01/12 20:19, , 32F
你怎麼知道麥當勞現在的點餐流程不是已經改進過的結果？
01/12 20:19, 32F
推
01/12 20:43, , 33F
這不會是白癡政策,也不要高層想得那麼白癡;人家都能管理公司
01/12 20:43, 33F
→
01/12 20:44, , 34F
了,怎可能是白癡?白癡一詞通常是底下搞不懂狀況的氣話罷了
01/12 20:44, 34F
→
01/12 20:46, , 35F
日本式管理光是個辦公室日光燈管汰換率的改善都要研究老半天
01/12 20:46, 35F
→
01/12 20:46, , 36F
了,更何況這種悠關公司生產力的流程改善?
01/12 20:46, 36F
→
01/12 20:48, , 37F
應該是品質管理才對
01/12 20:48, 37F
推
01/12 21:25, , 38F
這位主管的問題是試圖在家庭作坊推動工業化標準,這不容易
01/12 21:25, 38F
→
01/12 21:54, , 39F
麥當勞有在改善拿錯的問題吧，那堆抬頭顯示器20年前有嗎?
01/12 21:54, 39F
→
01/12 22:41, , 40F
高層白不白癡我不知道~但我知道很多翻需求翻來翻去~翻得連
01/12 22:41, 40F
→
01/12 22:41, , 41F
白癡都在笑的不少...
01/12 22:41, 41F
→
01/13 01:37, , 42F
真正的重點是,那些code根本不需要改,是為了讓報告好看而改
01/13 01:37, 42F
→
01/13 01:37, , 43F
跟功能一點關係都沒有.
01/13 01:37, 43F
→
01/13 01:38, , 44F
或是為了要通過check,要求我們把已經測過的code改掉.
01/13 01:38, 44F
→
01/13 01:38, , 45F
這樣子難道真的比較有效率?
01/13 01:38, 45F
推
01/13 10:29, , 46F
原po的問題應該可以在工作會報上提出來,看主管怎麼答?
01/13 10:29, 46F
推
01/13 18:29, , 47F
這是正確的事啊，初期會痛很正常
01/13 18:29, 47F
推
01/13 18:31, , 48F
那些check，在我看來就像是compile warning。build的過
01/13 18:31, 48F
→
01/13 18:32, , 49F
也測過，但有一天會出問題
01/13 18:32, 49F
→
01/13 18:32, , 50F
java我沒有很熟，但我想這道理應該是一樣的
01/13 18:32, 50F
推
01/14 09:30, , 51F
這種制度算是品質管理的一種，我們公司也要求coder要做
01/14 09:30, 51F
→
01/14 09:31, , 52F
extended syntax check，讓程式品質更上一層，extended
01/14 09:31, 52F
→
01/14 09:32, , 53F
syntax check也就是額外檢查coding style。做完後要重做
01/14 09:32, 53F
→
01/14 09:33, , 54F
單元測試。最後兩種檢查都通過才交付QA做整合測試。
01/14 09:33, 54F
→
01/14 09:36, , 55F
不過舊程式做這種check會滿江紅，這算是陣痛期。
01/14 09:36, 55F
推
01/15 16:37, , 56F
這個應該要新專案一開始的時候做 舊專案就算了吧
01/15 16:37, 56F
→
01/15 16:37, , 57F
不然全部工程師全部去改code就好了...
01/15 16:37, 57F
‣ 更多 hegemon 的文章
文章代碼(AID): #1Gy6r55h (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 hegemon 的文章
文章代碼(AID): #1Gy6r55h (Soft_Job)