好清談, C++, Mac, Window, Design Pattern, OO
工作一年多來內心的衝突與疑惑 是什麼？
有點難以形容, 比較大的衝突是完全不能接受所謂的軍隊教育文化,會懷疑是自己的問題, 還是那種東西對於想作創作方面的工作者, 真的只是一個Bull shit. 也許都有吧~Anyway, 總算見到真正成功的公司該怎麼經營他們的研發團隊.
我也不喜歡訂時程跟一些有的沒的，一來是天生的惰性，也有一些RD的自恃甚高(我作對的事情就是會全力以赴，你怎麼不信任我)。5)把工作分得很細9)把除錯時間排入時程10)把整合時間排入時程中12)絕對不要讓經理叫程式員縮減估計時間13)時程就像積木正確的作法，包含溝通到讓每個人都知道實際上應該怎麼作才不是在玩所謂的心理遊戲。攤開來透明化，clock其實有在朝這部分走，希望不會被濫用
另外感謝分享好文~ :p
"軟體人員面試教戰守則"裡所提及的"他們總是愛指出兩個根本不同的概念間的相似性。" 實在是太到位了!還有「錄取你，但是不能在我的團隊中」這一段裡頭，讓我對人才的看法有了新思維。
"無痛軟體時程"裡提到"部份原因是他們下了個自殺式的決定，把所有程式丟掉重頭開始。" 給我有點事後諸葛的感覺。 Apple的Mac OS X 不也把舊的Mac OS 丟掉(幾乎) 但我認為是成功的。
"走廊使用性(hallway usability)測試" in "約耳測試" 很有趣～ 有機會來試試看
"他們總是愛指出兩個根本不同的概念間的相似性。" <-- 超經典字句, 之前 paggy 還在的時候, 天天聽這個在上演.... XD
把程式整個丟掉再重作這個部份, 在不確定哪篇裡面有看到作者對於這個主題的一些具體看法:1. 他認為那些舊的 code, 儘管看起來很醜, 可是是經過了大量的測試與修正後的成果(Note 1). 而如果整個重寫, 新產生的問題, 不見得會比原本的少, 而且也需要大量的時間去修正新問題. 而這會讓產品推出時程一整個難以估計會 delay 多久.2. 由於開發人員的異動問題, 很常的情況下, 因為人員換了, 所以不會有所謂知識累積可以幫助下一次的整個改寫, 在知識無法累積的情況下, 很容易讓所有事情重蹈覆策.Note 1: 創造比理解簡單, 所以程式師很喜歡整個重來, 因為看懂別人的 code 事件不容易的事, 而這些不容易理解的 code 裡面, 存在著大量解決許多問題的細節.
的確我後來在同作者的其他文章有看到關於這點的深入討論，我非常同意(我之前算是斷章取義)，其中關鍵就是NJ常提到的Refactory。
欠~ 我如果在這個版面繼續 Refactor 的連載, 會不會洗版被檢舉阿? 不適合的話, 我再找找看其他地方~ XD
We are free to post anything except adult contents. (Adult contents, please mail to my personal mail box)
小心著作權就好 :P
著作權.....挖勒~ 那我之前那種抄寫法肯定被告爽爽.... 囧rz
工作一年多來內心的衝突與疑惑 是什麼？
回覆刪除有點難以形容, 比較大的衝突是完全不能接受所謂的軍隊教育文化,會懷疑是自己的問題, 還是那種東西對於想作創作方面的工作者, 真的只是一個Bull shit.
回覆刪除也許都有吧~
Anyway,
總算見到真正成功的公司該怎麼經營他們的研發團隊.
我也不喜歡訂時程跟一些有的沒的，一來是天生的惰性，也有一些RD的自恃甚高(我作對的事情就是會全力以赴，你怎麼不信任我)。
回覆刪除5)把工作分得很細
9)把除錯時間排入時程
10)把整合時間排入時程中
12)絕對不要讓經理叫程式員縮減估計時間
13)時程就像積木
正確的作法，包含溝通到讓每個人都知道實際上應該怎麼作才不是在玩所謂的心理遊戲。攤開來透明化，clock其實有在朝這部分走，希望不會被濫用
另外感謝分享好文~ :p
回覆刪除"軟體人員面試教戰守則"裡所提及的"他們總是愛指出兩個根本不同的概念間的相似性。" 實在是太到位了!
回覆刪除還有「錄取你，但是不能在我的團隊中」這一段裡頭，讓我對人才的看法有了新思維。
"無痛軟體時程"裡提到"部份原因是他們下了個自殺式的決定，把所有程式丟掉重頭開始。" 給我有點事後諸葛的感覺。 Apple的Mac OS X 不也把舊的Mac OS 丟掉(幾乎) 但我認為是成功的。
回覆刪除"走廊使用性(hallway usability)測試" in "約耳測試" 很有趣～ 有機會來試試看
回覆刪除"他們總是愛指出兩個根本不同的概念間的相似性。" <-- 超經典字句, 之前 paggy 還在的時候, 天天聽這個在上演.... XD
回覆刪除把程式整個丟掉再重作這個部份, 在不確定哪篇裡面有看到作者對於這個主題的一些具體看法:
回覆刪除1. 他認為那些舊的 code, 儘管看起來很醜, 可是是經過了大量的測試與修正後的成果(Note 1). 而如果整個重寫, 新產生的問題, 不見得會比原本的少, 而且也需要大量的時間去修正新問題. 而這會讓產品推出時程一整個難以估計會 delay 多久.
2. 由於開發人員的異動問題, 很常的情況下, 因為人員換了, 所以不會有所謂知識累積可以幫助下一次的整個改寫, 在知識無法累積的情況下, 很容易讓所有事情重蹈覆策.
Note 1: 創造比理解簡單, 所以程式師很喜歡整個重來, 因為看懂別人的 code 事件不容易的事, 而這些不容易理解的 code 裡面, 存在著大量解決許多問題的細節.
的確我後來在同作者的其他文章有看到關於這點的深入討論，我非常同意(我之前算是斷章取義)，其中關鍵就是NJ常提到的Refactory。
回覆刪除欠~ 我如果在這個版面繼續 Refactor 的連載, 會不會洗版被檢舉阿? 不適合的話, 我再找找看其他地方~ XD
回覆刪除We are free to post anything except adult contents. (Adult contents, please mail to my personal mail box)
回覆刪除小心著作權就好 :P
回覆刪除著作權.....挖勒~ 那我之前那種抄寫法肯定被告爽爽.... 囧rz
回覆刪除