Re: [討論] 需求重要?技術重要?

看板Soft_Job作者 (幻想的魚)時間12年前 (2012/01/16 20:31), 編輯推噓5(5022)
留言27則, 7人參與, 最新討論串3/9 (看更多)
: ----------------------------------- : 回到標題,技術重要?需求重要? : 我認為的是「都重要」,而且雙方都應該把彼此放在心裡, : 比例孰輕孰重,依照不同環境跟情形會有不同的需求。 : 當比例過度偏重一邊時難免會引起反彈, : 但也不要過度的敵視另一邊,畢竟雙方需要的是合作,不是對立。 : 大家對這個議題有什麼看法或經驗呢? 下班吃飽飯回家 =^= 看到這篇心有戚戚焉。在碩班的時候因為程式碼大多是自己一個人寫的,雖然有接手國科 會計畫,但是改動的幅度真的不大。上班以後開始接手既有的系統以後會發現不同程式設 計師寫出來的程式碼都各有風格。 有些程式碼你會很欽佩他怎麼可以寫得這麼的帥氣,目前的我看不懂,我也改不了。 我只能用我的程度去把這段Func.包裝起來試著轉化成我可以使用的東西。 EX:我需要讀取某個list。但是前輩在基底函示庫只有讀取element,沒有寫出讀取list 的Func.。我改不動該函示庫,只好把他變成這樣。 foreach(var aaa in bbb) { bool temp = ddd(aaa.ee); } 其實高手只要看得懂其實可以直接這樣的 bool temp2 = ddd(bbb); 只要重構該程式碼即可。 ================================================== 老實說,我很欽佩前輩們,他們設計了一個很漂亮的方式去架構出這個系統。在我看懂 了整個架構以後,我很喜歡這個設計。 但是聽說高手前輩去別的專案支援以後,來接手這個系統的人都遇到了很大的困難。 <看不懂程式碼> 然後有人就憤而離職了../冏\ 一個程式到底要寫得漂亮,還是要寫的簡單易了。這真是一個很難去弄的平衡的問題.. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.37.103.51

01/16 20:50, , 1F
用物件存取好處在於你之後的維護更簡易
01/16 20:50, 1F

01/16 20:52, , 2F
資料庫的資料撈出來後將list型態透過物件轉型你只要get
01/16 20:52, 2F

01/16 20:53, , 3F
管理跟維護上相對於你去很多地方改sql更加簡易
01/16 20:53, 3F

01/16 20:54, , 4F
以前遇過寫超過5年以上的老鳥但寫程式很令人不敢恭維
01/16 20:54, 4F

01/16 20:54, , 5F
光是要去維護那種雜亂無章的程式碼就會吐血
01/16 20:54, 5F

01/16 20:57, , 6F
以前我在撈10張資料表關聯有時寫滿版的sql就寫到1千多行
01/16 20:57, 6F

01/16 20:59, , 7F
現在透過物件處理沒有sql code在裡面100行內搞定
01/16 20:59, 7F

01/16 20:59, , 8F
需求變更需要異動資料時也只要將物件改掉幾行就可以work
01/16 20:59, 8F

01/16 21:03, , 9F
多多善用 UnitTest可以觀察code的品質跟效能差異
01/16 21:03, 9F

01/16 22:49, , 10F
其實可以理解為什麼只有讀取element,改天你除了list
01/16 22:49, 10F

01/16 22:49, , 11F
還有其他要做的話,其實你都可以自己兜...
01/16 22:49, 11F

01/17 00:18, , 12F
只作讀取的意義,可以再講白話一點嗎,我想了解一下,不太懂
01/17 00:18, 12F

01/17 07:19, , 13F
寫成針對讀element 沒意外就是想寫成基本工具 方便以後直接
01/17 07:19, 13F

01/17 07:20, , 14F
應用來建立目標而已 所以你使用的方法反而是合對方意
01/17 07:20, 14F

01/17 09:52, , 15F
我覺得這是團隊素質落差太大的問題,高手團隊有高手團隊的
01/17 09:52, 15F

01/17 09:52, , 16F
效率,如果你都拿剛出社會的白紙來接高手團隊的東西,
01/17 09:52, 16F

01/17 09:52, , 17F
那為了這些人你必須降低你團對的效率跟水準去遷就他們。
01/17 09:52, 17F

01/17 09:53, , 18F
那個損失其實更大,所以我覺得這是公司在專案交接跟人力技能
01/17 09:53, 18F

01/17 09:53, , 19F
上沒有把人用好,無法掌握code base的人要嘛就是給他時間,
01/17 09:53, 19F

01/17 09:53, , 20F
要嘛根本就是不該把人派到位置上。但問題是,對不重視技術的
01/17 09:53, 20F

01/17 09:54, , 21F
管理層跟user,自然不會管你技術能力問題,有人在就補坑。
01/17 09:54, 21F

01/17 10:02, , 22F
如果你本來就打算用低階的作法做,那一開始可能就不需要找
01/17 10:02, 22F

01/17 10:02, , 23F
高手,而直接用同等級的人做比較實際也比較好銜接。
01/17 10:02, 23F

01/17 10:03, , 24F
但是如果碰到技術的天花板就會很囧。
01/17 10:03, 24F

01/17 21:29, , 25F
高手不會寫bbb好嗎
01/17 21:29, 25F

01/21 17:07, , 26F
對高手而言Code的擴充性要強,在公司而言,code要讓人家看
01/21 17:07, 26F

01/21 17:07, , 27F
不懂加上改不了才強
01/21 17:07, 27F
文章代碼(AID): #1F51YuAq (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1F51YuAq (Soft_Job)