討論區快速選單
知識庫快速選單
網路投保旅行平安險 軟體開發過程中有哪些資安漏洞? 政府補助!學嵌入式+物聯網
[ 回上頁 ] [ 討論區發言規則 ]
與資深前輩的應對之道
更改我的閱讀文章字型大小
作者 : sakaeguchi(小栄;)
[ 貼文 11 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/20 上午 11:04:36
小弟算是新進工程師。之前工作常與一位資深的(小)主管合作。雖然他是主管,小公司人手不多還是需要寫程式。

小弟有個困擾,覺得他很多觀念還停留在十幾年前,但不知如何其齒。比如
- 函數都很長,新寫完就有50行 (bug修一修後就上百行了,再加新功能肥胖到近千行)
- 變數宣告全都放在函數最上面
- 常用struct, singleton, global variables,且struct裡面的變數都不少
- 即使是class也都很大,做很多雜七雜八的事,所以class名字常常有Manager這個字
- 寫出來的程式碼完全無法被單元測試,所以他也不寫單元測試
- 從不用smart pointer,常常有memory leak
- 貪圖方便,新加的程式碼與糟糕的舊程式碼同流合污,讓之前已經很亂的架構變更亂
...還有許多其它的例子。

全部加起來的結果是,bug量比我多好幾十倍,每個bug都很難纏,我需要加班幫忙修他的bug才能趕上進度。有時為了修一個bug,這裡改一行,其它很遠我以為鳥不拉屎的地方就突然生氣盎然出現許多新的bug。一開始小弟認為是我對他的程式碼不熟悉的問題,後來發現他自己修自己的程式時也很生氣盎然。

小弟試著想改變這情況。比如希望他能開始用std::unique_ptr(或std::shared_ptr),不要直接"return new Object;"。但他可能覺得,程式裡有memory leak, 有很多bug,或debug要花很多時間等等,都是理所當然的事。平常他也很忙,礙於時間限制,三兩句解釋總是敵不過他說的:「以前沒有用這些,還不是活得好好的?」。提到單元測試也是同樣的回應,還說真的需要的話,幫他寫不就好了?但一開始寫的時候沒有考慮到測試,事後跟本就寫不成,除非先大翻修,但翻修又怕一不小心新bug生生不息。

除此之外還有一件事,公司裡的人大都會中文,他英文也不是很好,不知為什麼他的email總是用英文。文法錯誤不說,句子不通順又詞不達意。我回信問他補充,結果他又回了更多沒幫助的英文。很希望他用中文寫,但我沒法耍笨說我看不懂英文,他知道我的英文很好。小弟總不可能直接說:「你英文很爛,請用中文」。

這問題也反應在他程式碼的註解。小弟常看了他的code頭暈後,忍不住去看註解結果變頭痛。猜他註解在寫什麼的時間比看程式碼還久,更不用說註解寫錯或是小弟猜錯,都白白浪費很多時間。

雖然他不是我直屬老闆,但我也不想語氣太強硬而得罪他。小弟想請較版大們,要如何以婉轉又兼顧面子的方式,對資深前輩+主管說:
1. 你寫出來的程式架構很亂,bug也很多 (而且有很多方法可以改善)
2. 你英文很差 (可以用中文回信。 而程式碼用心一點寫,不用註解就能讓人看得懂)
作者 : ice_emissary(燃燒的大地) 貼文超過200則
[ 貼文 408 | 人氣 0 | 評價 1890 | 評價/貼文 4.63 | 送出評價 18 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/20 下午 02:39:19
我也遇到類似的問題,

一個函式上百行,一個函式做很多不該是自己做的事情,一個 struct 有一堆成員。
我們的程式錯綜複雜,常常難以理解控制這一個小方塊的功能竟然是透過控制遠在天邊的另一個方塊達成。
整個程式就像一塊疊的亂七八糟的積木塔。

但最常聽見的意見是:這個亂七八糟的塔已經站立好多年,被證明可用而不會倒,所以千萬不要去動它。
作者 : nibabakaho(farastein)
[ 貼文 99 | 人氣 6635 | 評價 390 | 評價/貼文 3.94 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/20 下午 02:43:34
呵呵 我剛開始工作時候遇過
不過最後我屈服了 = =''
也跟著沉淪 Orz ....
我覺得上面兩位可以去找新創公司 or 部門
或許分的比較不是那麼多
但可以擺脫目前的困境
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/24 上午 09:51:09
小栄

個人是個老老前輩, 有些觀點可供您的參考.

軟體程式的價值在於合乎應用Domain的需求,, 舊的程式有其Domain的價值, 可能十多年或更久都無法撼動他原先的架構, 而必須將錯就錯地繼續原有模式維護下去. 在國外亦是如此.
你空有一些新技術, 卻無法發揮專長, 當然會鬱卒, 不過 Domain的專業還是 比技術 重要, 因為他才是軟體的重心所在.
 
對公司的建議是展現您的能力與智慧的方式之一, 但必須是以公司利益為出發點來看事情, 比較不會因此受傷害.

公司的文化也是要考慮的因素. 比較洋式的管理方式, 主管與組員是可以平等地位討論事情. 傳統的管理則是有其倫理與輩分之分, 需要對資深的前輩謙卑一些.
作者 : sakaeguchi(小栄;)
[ 貼文 11 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/25 下午 01:26:01
老老前輩:

小弟很高興有同樣是前輩的版大們回覆,讓小弟知道前輩的考量有所不同。

不過小弟無法接受您說我未以公司利益為出發點來看事情。

就是因為以公司利益為出發點,小弟注重設計、想辦法導入不同的方法,希望能減少bug量、縮短總體開發時程。我同意舊程式碼沒有必要不該隨便去更動。但新程式碼不該一開始就很糟、又讓全體架構變更亂,使程式越來越無法被維護。

小弟考慮到如果公司最重要的資產是建立在沒有人敢碰的程式碼,或是碰了後bug要修很久才能穩定下來,或是亂到難以加新功能,這樣子公司如何進步?如何應付快速變化的市場需求?

還是前輩覺得 公司最重要的程式碼資產變得沒有人敢碰、碰了後開發時間因無法穩定一拖再拖、加班因為太多bug 等等,都是理所當然的事,沒有必要去改變?

當然,小弟知道職場有「倫理與輩分之分」,不然就不會發這篇文章了。小弟的困擾是,想要導入不同方法時,總得先提出舊的方法哪裡不好,但如此會讓前輩覺得小弟不「謙卑」不「尊敬」。以前輩的角度,如何提出接受度最高?
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/25 下午 04:52:08
>
>不過小弟無法接受您說我未以公司利益為出發點來看事情。
>

小栄
您誤會了, 個人對您工作環境沒有完全理解, 不敢有任何批判的意見。 只是因為您是"新進工程師", 提供一些觀點供您參考, 避免您因對主管不瞭解而受傷害。

>
>當然,小弟知道職場有「倫理與輩分之分」,不然就不會發這篇文章了。小弟的困擾是,想要導入不同方法時,總得先提出舊的方法哪裡不好,但如此會讓前輩覺得小弟不「謙卑」不「尊敬」。以前輩的角度,如何提出接受度最高?

如果您是我的組員, 這樣的建議我不認為是不「謙卑」不「尊敬」(組織的文化使然)。 我想我會在不影響原有業務的進度下, 給您一些機會來表現。 但並不是所有的主管都能有此想法, 您對主管有多少瞭解只有您自己知道, 主管的雅量是關鍵, 個人無法給任何說法。 但建議"闢室密談"為上策, 以免有"當眾突槌" 的窘境。
作者 : daniel(冷眼)討論區板主 VC++優秀好手遊戲程式設計優秀好手DirectX優秀好手C++優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1564 | 人氣 84169 | 評價 6990 | 評價/貼文 4.47 | 送出評價 15 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/25 下午 04:59:07
茶~ 套軍中的話,因為你太菜了
每一個有理想有報負的有為程式設計師.都想下大刀~
大到文件規範,小到codeing style /變值的前綴符號 都要有標準 XD

但是
小的時候......你不能動.......因為出事你負不了責任..boss 不會讓你搞的
長大的時候..你也不能動...因為剛負責新專案,你沒時間可以搞的.
老的時候......你也不會動...因為你老了.動不了.沒法搞了.XD

Orz...最後你也沉淪了...


ps:從自己的源碼開始做吧.
     不然你老了後來同事也是會一樣說你的 @@||
作者 : doraemon(人稱阿牛)
[ 貼文 74 | 人氣 5056 | 評價 220 | 評價/貼文 2.97 | 送出評價 3 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/6/26 上午 11:16:03
那種土法煉鋼的程式碼就已經說明一切

花錢請你就是要請你按我的作法去做事

所謂良禽擇木而棲, 道不同不相為謀

or

http://www.programmer-club.com.tw/ShowSameTitleN/caseexp/2517.html
作者 : uuuiii00(uuuiii)
[ 貼文 5 | 人氣 3 | 評價 40 | 評價/貼文 8 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/7/24 上午 10:09:05
我在當菜鳥的時候也是遇過這種情形
Code 難維護、溝通無效
產品、系統已行之多年
平時工作量滿滿滿
大家都不願意多花心血改善
老闆不重視
或是沒能力等等
一年後我離職了

以我的經驗是
溝通、勸說、建議 效果都不大
最有效的是換環境吧
換到適合你的環境
作者 : feda(feda)
[ 貼文 5 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/3/12 上午 10:03:05
換環境是解決不了問題的.

我經常碰到我的member不滿先前公司留下的old code 的寫法,當然我也不滿意,

但是,要整個翻新是需要-----> 時間<------,站在我的立場(也就是公司的立場),很簡單

加一個新功能,是不會留時間給你翻新時間,所以如果要翻新整個架構,要用自己的時間

(而且要保證不能有BUG).

所以,一般我都會建議member,要改也要慢慢改,改完要給大家Review.





作者 : wallace_tsou(Wallace) 貼文超過200則
[ 貼文 262 | 人氣 314 | 評價 960 | 評價/貼文 3.66 | 送出評價 7 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2013/3/12 下午 11:46:07
了解就好。
若公司就以這樣的前輩為標桿,那就是不會再有成長的公司。
我待過的每一任主管在技術上都被我超越。
能接受的主管,算是有氣度,我就能做出比他還要好的東西。
不能接受的主管,最後會變成你發展的阻礙,最後結果,我想你一定知道。
 板主 : 葉雨心
 > 上班族的哈拉園地 - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - 上班族的哈拉園地 - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
上班族的哈拉園地
1 Jasper 880 
2 青衫 760 
3 ozzy 680 
4 Chelonia Mydas 510 
5 長長 370 
6 臭蟲 350 
7 冷眼 320 
8 HKLN.net 320 
9 BlueTulip 270 
10 DEMO999 260 
上班族的哈拉園地
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2019 程式設計俱樂部 http://www.programmer-club.com.tw/
0.078125