Re: [心得] 如何向別人證明自己寫的是好code?

[ijeCorp (1/28一個天使離開的日子)]

※ 引述《taroson (想想)》之銘言：
: ※ 引述《ijeCorp (1/28一個天使離開的日子)》之銘言：
: : 資訊業Software研發工程師是良心事業。
: : 你有這樣的想法是沒有錯的，但有些事情不要強求。
: 我想這跟強求未必有絕對關係 真的做過project就會知道了.

  就是做過Project才知道，這些都是強求。

: : 很多人都很會寫程式，但是寫出來的程式只能用一次。
: 也許你不相信, 只可以跑一次的程式, 往往比所謂可重複使用的程式
: bug更少, 更好maintain.
　我相信那是一個賣了再也不管的系統。所以也不太需要維護。

　反正賣了收到錢了，管他客戶怎樣罵??

  做專案說穿了就是寫寫寫，然後搞定收工(靠著業務打腫臉把自己的信用都賠掉了)。

  在台灣只可以跑一次的程式，要就是一兩年內需求變動就say goodbye了。

  要不就是重新再來過，新的專案又導入。so 惡性循環?

  對於

  "只可以跑一次的程式, 往往比所謂可重複使用的程式bug更少, 更好maintain."

  你說這句話? 有沒有什麼 "調查數據可以證明" 還是只是用你的所謂經驗談。

: : 自以為會寫程式的工程師了不起就是寫寫一個模組幾千行到上萬行的程式。
: : 系統需求如果有改動，就開始貼貼補補。
: : 你如果是寫新系統或新的模組，你願意的話可以好好的構思(如果有時間的話)。
: 話說一間國際大公司M, 他有自己的midleware APIs, 你不能隨意改變他,
: 可是現實上你專案需求那些介面就是不夠, 怎麼辦? work around, 這樣的code
: 讓你看到了也會哇哇叫吧, 改API嗎？, 可以因為牽扯太廣, 所以請將需求
: sumit到負責制訂的group審核, 曠日廢時, 請問project schedule要不要
: follow？

  誰討論到要改這種大公司的midleware APIs?

  改動本來就是一個耗費成本的工作，沒人願意隨意改變他。

  我文中並沒有提到一定要去改一個舊有的系統。

  API既然是API就是可以拿來做基本的擴充，難道就只會用API不懂得利用現有API

  做擴充嗎?那微軟出的那些API跟昇陽出的API，你們公司都不用的嗎?

  還是你們都只會用API有的功能，不懂得利用API擴充功能?

  請注意我文中所提到的--時間許可下請構思好的設計--。

: : 什麼叫做Design Pattern ? 一堆工程師聽都沒聽過。
: 做project對客戶都有每個階段的milestone, 你以為那些寫code沒將你所謂
: 的design pattern apply上去的人是因為不懂嗎? 最好是做每一個project
: 都有時間慢慢想, 將每個可以用到的pattern都用上來展現software engineering
: 的功力.

  沒有人說為了展現工程師的功力去用pattern。

  pattern是用來解決類似問題的一種設計，不是絕對的選擇，

  好的架構設計就是一種好的pattern。

: : 你跟他解釋半天，他會回你:XXX的搞這麼麻煩幹麻?你這樣設計我不會寫了啦。
: : Refactory?對他們而言，不懂的人就是覺得你在找麻煩。
: : 他們會覺得可以動的程式碼，你改他做啥?
: 你知道每個行業有每個行業的特性, 有些是非常保守的, 例如電信局端業者,
: 可以動, 沒大問題的東西對他們才是有價值的, 他們買一個設備不是買了就
: deploy到個個局端, 而是要經過很長時間的測試, 都沒有問題了才會全面使用,
: 你說改可以跑的程式就改, 誰可以承受這樣額外的測試?

  所以我說了，新的架構新的系統可以考慮用好的做法。

  我從頭到尾就沒有強調 '沒事看不順眼'就去動一套舊系統。

  何況你的論點一整個有問題，買一個設備跟寫軟體專案有什麼關係?

  難道你們寫的軟體是放在這套設備上?

  像是大型ISP業者，就是要求穩定，電信產業也應該是一樣。

  寫一次就好的系統會放在這種電信產業上面???

  請你告訴我是哪一家電信產業 台x大??遠大x??x華大?

: : 對這些工程師而言，他們頂多寫出幾萬行程式碼能夠動就很了不起了。
: 我知道人外有人, 但是我很好奇到底是什麼公司, 會有一個RD寫幾萬行的程式?
: 那麼一各團隊下來不就將近百萬行了？

  一個團隊寫出百萬行程式有很了不起嗎? 寫軟體產品的團隊這有什麼?

: : 你要他們維護純後端程式一個十幾二十萬行以上的程式碼，他可能會辭職比較快。
: : 程式碼寫得好很難證明，特別是在幾千行到幾萬行的程式碼的領域裡面。
: : 說穿了就只是幾千行到幾萬行，爛的工程師花點時間還是可以修修補補。
: 這點我很同意你的說法, 真的很難證明..
: : 過個一兩年，問題會越來越多然後大家都走人了，倒楣還是那家公司(倒閉?寫新系統?)
: : 我給你一個建議是: "韜光養晦"。
: : 就算自己能力很強，也絕對不要在一群不懂你想法的團隊裡面出頭。
: : 如果只是一直堅持下去，你會讓自己陷入困境。
: 所謂團隊想法也不光是coding吧, business也要考慮進去, 不然乾脆回學校,
: 想怎麼做都可以完全可以不考慮商業上的議題.

  如果是一個研發軟體團隊就是要讓一個軟體系統維持高穩定度和可維護性。

  要只是每天要談那種專案幹完就收錢，

  那當然可以不用理，反正倒楣的永遠是公司的客戶跟業務。

  如果你要跟我談整個公司團隊，那我們在另開話題來談這個問題。

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 122.116.173.41
推 taroson:小弟不才 剛剛好待過電信業 也待過網通大廠
→ taroson:很多code就是真的寫一次
推 taroson:到也不至於不去維護 你言重了
→ taroson:軟體業有你這種熱誠是好事 但事實就是這樣 說無奈也算是吧
→ taroson:還有你可能不知道有embedded這東西 為什麼設備跟
→ taroson:軟體會沒有關係 還是說只是我們chennel不同
→ ijeCorp:Embedded 的確是跟硬體設備有關,但就可以這樣搞嗎?
→ ijeCorp:寫這種設備的軟體很多都是用套件+改linux kernel
推 taroson:說到API 我就是M公司員工 不是你想改想擴充就擴充
→ ijeCorp:有多少是你們自己全新開發的? 頂多是一兩個小模組
→ taroson:要照規矩流程來的 這就是現實
→ ijeCorp:這種系統的確是寫一次就ok了,只是問題我看也不會太少.
→ ijeCorp:protocol規格書RFC大家都會念,你們又實作出什麼?
推 taroson:其實我蠻喜歡你的 有沒有興趣來我們公司呀