Comments on: 程式設計師不可不注意的五件事 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/ 網路, 產業, 資訊, 觀察, 生活, 電影, 技術, 新知, 科技, 媒體, 趨勢, Web 2.0 Tue, 22 May 2012 16:11:00 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: 從來不吃人肉 » 今日連結 2007-03-13 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-9802 從來不吃人肉 » 今日連結 2007-03-13 Tue, 13 Mar 2007 10:12:10 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-9802 [...] 程式設計師不可不注意的五件事 [...] [...] 程式設計師不可不注意的五件事 [...]

]]> By: Mr. Friday http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-9801 Mr. Friday Tue, 13 Mar 2007 05:35:45 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-9801 感謝各位的見解, 針對每一個函式取一個清楚的名字當然有助於他人了解程式的"意圖". 不過如果今天user不只是要用這個函式, 而是要overriding時, 如果能有細節變數的描述會更有幫助. 當然, 不可能每支程式每個變數都會有詳細的說明, 這樣反而矯枉過正會讓其他人看不懂. 但是適當的在重要地方留下註解或提示(比如說...//add function here, 或是 // now add code to compute value), 我想這應該是每個入門者的基本功. 感謝各位的見解,
針對每一個函式取一個清楚的名字當然有助於他人了解程式的”意圖”. 不過如果今天user不只是要用這個函式, 而是要overriding時, 如果能有細節變數的描述會更有幫助. 當然, 不可能每支程式每個變數都會有詳細的說明, 這樣反而矯枉過正會讓其他人看不懂. 但是適當的在重要地方留下註解或提示(比如說…//add function here, 或是 // now add code to compute value), 我想這應該是每個入門者的基本功.

]]> By: Mr. Friday http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-79690 Mr. Friday Tue, 13 Mar 2007 05:35:00 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-79690 感謝各位的見解, 針對每一個函式取一個清楚的名字當然有助於他人了解程式的"意圖". 不過如果今天user不只是要用這個函式, 而是要overriding時, 如果能有細節變數的描述會更有幫助. 當然, 不可能每支程式每個變數都會有詳細的說明, 這樣反而矯枉過正會讓其他人看不懂. 但是適當的在重要地方留下註解或提示(比如說...//add function here, 或是 // now add code to compute value), 我想這應該是每個入門者的基本功. 感謝各位的見解,
針對每一個函式取一個清楚的名字當然有助於他人了解程式的”意圖”. 不過如果今天user不只是要用這個函式, 而是要overriding時, 如果能有細節變數的描述會更有幫助. 當然, 不可能每支程式每個變數都會有詳細的說明, 這樣反而矯枉過正會讓其他人看不懂. 但是適當的在重要地方留下註解或提示(比如說…//add function here, 或是 // now add code to compute value), 我想這應該是每個入門者的基本功.

]]> By: Chenhai http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-9800 Chenhai Tue, 13 Mar 2007 04:33:27 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-9800 關於第一點,另一個說法是: 如果你的程式需要註解,那你可能該考慮重新整理一下自己的程式. 其實這點我覺得與函式的命名習慣有關.以C/C++而言, 過去函式的名稱長度有其限制,另外注重的點也不同,所以造就了像"匈牙利命名法"這種習慣. 可是以今日的情況而言,針對每一函式,取一個清楚的名字,就可以在你的程式中,明確的表逹出演算法,用途,以及想法. 另外,文件也有很多種(依功能分別),Reference是絕對必要的,但國內的開發環璄,缺的不是Reference,而是Turtorial--這個程式,是怎麼運作的?要如何使用?關鍵點在那裡?彈性有多大?怎麼做Customize? 說白了就是,要時時想著自己的程式,"並不是只有自己會用到". 關於第一點,另一個說法是:
如果你的程式需要註解,那你可能該考慮重新整理一下自己的程式.
其實這點我覺得與函式的命名習慣有關.以C/C++而言,
過去函式的名稱長度有其限制,另外注重的點也不同,所以造就了像”匈牙利命名法”這種習慣.
可是以今日的情況而言,針對每一函式,取一個清楚的名字,就可以在你的程式中,明確的表逹出演算法,用途,以及想法.
另外,文件也有很多種(依功能分別),Reference是絕對必要的,但國內的開發環璄,缺的不是Reference,而是Turtorial–這個程式,是怎麼運作的?要如何使用?關鍵點在那裡?彈性有多大?怎麼做Customize?
說白了就是,要時時想著自己的程式,”並不是只有自己會用到”.

]]> By: Chenhai http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-79689 Chenhai Tue, 13 Mar 2007 04:33:00 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-79689 關於第一點,另一個說法是: 如果你的程式需要註解,那你可能該考慮重新整理一下自己的程式. 其實這點我覺得與函式的命名習慣有關.以C/C++而言, 過去函式的名稱長度有其限制,另外注重的點也不同,所以造就了像"匈牙利命名法"這種習慣. 可是以今日的情況而言,針對每一函式,取一個清楚的名字,就可以在你的程式中,明確的表逹出演算法,用途,以及想法. 另外,文件也有很多種(依功能分別),Reference是絕對必要的,但國內的開發環璄,缺的不是Reference,而是Turtorial--這個程式,是怎麼運作的?要如何使用?關鍵點在那裡?彈性有多大?怎麼做Customize? 說白了就是,要時時想著自己的程式,"並不是只有自己會用到". 關於第一點,另一個說法是:
如果你的程式需要註解,那你可能該考慮重新整理一下自己的程式.
其實這點我覺得與函式的命名習慣有關.以C/C++而言,
過去函式的名稱長度有其限制,另外注重的點也不同,所以造就了像”匈牙利命名法”這種習慣.
可是以今日的情況而言,針對每一函式,取一個清楚的名字,就可以在你的程式中,明確的表逹出演算法,用途,以及想法.
另外,文件也有很多種(依功能分別),Reference是絕對必要的,但國內的開發環璄,缺的不是Reference,而是Turtorial–這個程式,是怎麼運作的?要如何使用?關鍵點在那裡?彈性有多大?怎麼做Customize?
說白了就是,要時時想著自己的程式,”並不是只有自己會用到”.

]]> By: spart http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-9799 spart Sun, 11 Mar 2007 05:50:56 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-9799 mm~ thxs for Mr. Friday's sharing, this is my fist time to see ur article You must be good in computer programimg design!^^ The five principles are very helpful to me, I'll base on that when I'm coding, thank you :) mm~

thxs for Mr. Friday’s sharing, this is my fist time to see ur article

You must be good in computer programimg design!^^

The five principles are very helpful to me, I’ll base on that when I’m coding, thank you :)

]]> By: spart http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-79688 spart Sun, 11 Mar 2007 05:50:00 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-79688 mm~ thxs for Mr. Friday's sharing, this is my fist time to see ur article You must be good in computer programimg design!^^ The five principles are very helpful to me, I'll base on that when I'm coding, thank you :) mm~

thxs for Mr. Friday’s sharing, this is my fist time to see ur article

You must be good in computer programimg design!^^

The five principles are very helpful to me, I’ll base on that when I’m coding, thank you :)

]]> By: Victor http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-9798 Victor Sun, 11 Mar 2007 05:07:45 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-9798 我忘記在哪裡看過，有人說百分之...忘了多少的文件，到最後都會遺失，所以有人就將文件寫在code裡面，Doxygen就是為此發明的，以註解寫文件，還可以產生各種格式的文件 http://www.stack.nl/~dimitri/doxygen/doxygen_intro_cn.html 關於遠見 http://vic-lin.blogspot.com/2007/02/blog-post_19.html 這是我的一點看法 至於Y2K的問題，我是這樣認為，對於那個年代，每個Bit可能都是很重要的，也許沒有人敢浪費任何的一個Bit，因為那些機器都是價值連城的東西，為了四十年後去花費那多出來的兩位，可能會被老闆開除，而且誰能夠誇口，我的程式能夠活著過2000年呢? 我想應該沒有，很多細節，都不是在規劃時可以想得到的，是必須等東西開始Run才會發現的問題，因為規劃常常會假設每個環節都是完美的，但是現實卻不然，那些不完美的細節，常常是你想也想不到的。 四十年前為了Y2K的事情煩腦，我可以肯定的說，這是幻想，不是遠見.... 二十年前為了Y2K的事情煩腦，這還是太遠了些 十年前為了Y2K的事情煩腦，哦...那的確會發生，但....你的程式十年後還存在嗎? 五年前為了Y2K的事情煩腦，嗯...也許你真的該這麼做 幻想和遠見如果沒有分清楚，很容易的就會陷入做太多不必要的事情的無限迴圈，所以對於將來的擔心必須拿捏得剛剛好，保持一定的彈性是必要的，但過多的彈性真的有那個需要嗎? 我認為這就得好好想一想，程式能夠在未來存活，再來做修改，以程式的存活率來看，過度的擔心通常都是多餘的。 不過在台灣情況似乎又有點不太一樣，因為台灣幾乎沒有軟體的生產，大部份都只是零零落落的Case在進行，因此...彈性對於接Case的Team來說，幾乎沒有什麼價值....，東西寫完了交出去就完事了，當這個Case須要做修改時，通常已經不是原來的人或Team在做的工作了....，所以...在台灣程式的生存週期更是低得可憐 這個人寫的軟體開發的相關文章我覺得很不錯 http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81 關於程式重寫 http://local.joelonsoftware.com/mediawiki/index.php/The_Joel_on_Software_Translation_Project:%E4%BD%A0%E7%B5%95%E5%B0%8D%E4%B8%8D%E6%87%89%E8%A9%B2%E5%81%9A%E7%9A%84%E4%BA%8B 我忘記在哪裡看過，有人說百分之…忘了多少的文件，到最後都會遺失，所以有人就將文件寫在code裡面，Doxygen就是為此發明的，以註解寫文件，還可以產生各種格式的文件
http://www.stack.nl/~dimitri/doxygen/doxygen_intro_cn.html

關於遠見
http://vic-lin.blogspot.com/2007/02/blog-post_19.html
這是我的一點看法

至於Y2K的問題，我是這樣認為，對於那個年代，每個Bit可能都是很重要的，也許沒有人敢浪費任何的一個Bit，因為那些機器都是價值連城的東西，為了四十年後去花費那多出來的兩位，可能會被老闆開除，而且誰能夠誇口，我的程式能夠活著過2000年呢? 我想應該沒有，很多細節，都不是在規劃時可以想得到的，是必須等東西開始Run才會發現的問題，因為規劃常常會假設每個環節都是完美的，但是現實卻不然，那些不完美的細節，常常是你想也想不到的。

四十年前為了Y2K的事情煩腦，我可以肯定的說，這是幻想，不是遠見….
二十年前為了Y2K的事情煩腦，這還是太遠了些
十年前為了Y2K的事情煩腦，哦…那的確會發生，但….你的程式十年後還存在嗎?
五年前為了Y2K的事情煩腦，嗯…也許你真的該這麼做

幻想和遠見如果沒有分清楚，很容易的就會陷入做太多不必要的事情的無限迴圈，所以對於將來的擔心必須拿捏得剛剛好，保持一定的彈性是必要的，但過多的彈性真的有那個需要嗎? 我認為這就得好好想一想，程式能夠在未來存活，再來做修改，以程式的存活率來看，過度的擔心通常都是多餘的。

不過在台灣情況似乎又有點不太一樣，因為台灣幾乎沒有軟體的生產，大部份都只是零零落落的Case在進行，因此…彈性對於接Case的Team來說，幾乎沒有什麼價值….，東西寫完了交出去就完事了，當這個Case須要做修改時，通常已經不是原來的人或Team在做的工作了….，所以…在台灣程式的生存週期更是低得可憐

這個人寫的軟體開發的相關文章我覺得很不錯
http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81

關於程式重寫
http://local.joelonsoftware.com/mediawiki/index.php/The_Joel_on_Software_Translation_Project:%E4%BD%A0%E7%B5%95%E5%B0%8D%E4%B8%8D%E6%87%89%E8%A9%B2%E5%81%9A%E7%9A%84%E4%BA%8B

]]> By: Victor http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/comment-page-1/#comment-79687 Victor Sun, 11 Mar 2007 05:07:00 +0000 http://mmdays.com/2007/03/10/%e4%b8%80%e5%80%8b%e5%b9%b3%e5%87%a1%e9%9b%bb%e8%85%a6%e5%b7%a5%e7%a8%8b%e5%b8%ab%e7%9a%84%e7%a2%8e%e7%a2%8e%e5%bf%b5/#comment-79687 我忘記在哪裡看過，有人說百分之...忘了多少的文件，到最後都會遺失，所以有人就將文件寫在code裡面，Doxygen就是為此發明的，以註解寫文件，還可以產生各種格式的文件 http://www.stack.nl/~dimitri/doxygen/doxygen_intro_cn.html 關於遠見 http://vic-lin.blogspot.com/2007/02/blog-post_19.html 這是我的一點看法 至於Y2K的問題，我是這樣認為，對於那個年代，每個Bit可能都是很重要的，也許沒有人敢浪費任何的一個Bit，因為那些機器都是價值連城的東西，為了四十年後去花費那多出來的兩位，可能會被老闆開除，而且誰能夠誇口，我的程式能夠活著過2000年呢? 我想應該沒有，很多細節，都不是在規劃時可以想得到的，是必須等東西開始Run才會發現的問題，因為規劃常常會假設每個環節都是完美的，但是現實卻不然，那些不完美的細節，常常是你想也想不到的。 四十年前為了Y2K的事情煩腦，我可以肯定的說，這是幻想，不是遠見.... 二十年前為了Y2K的事情煩腦，這還是太遠了些 十年前為了Y2K的事情煩腦，哦...那的確會發生，但....你的程式十年後還存在嗎? 五年前為了Y2K的事情煩腦，嗯...也許你真的該這麼做 幻想和遠見如果沒有分清楚，很容易的就會陷入做太多不必要的事情的無限迴圈，所以對於將來的擔心必須拿捏得剛剛好，保持一定的彈性是必要的，但過多的彈性真的有那個需要嗎? 我認為這就得好好想一想，程式能夠在未來存活，再來做修改，以程式的存活率來看，過度的擔心通常都是多餘的。 不過在台灣情況似乎又有點不太一樣，因為台灣幾乎沒有軟體的生產，大部份都只是零零落落的Case在進行，因此...彈性對於接Case的Team來說，幾乎沒有什麼價值....，東西寫完了交出去就完事了，當這個Case須要做修改時，通常已經不是原來的人或Team在做的工作了....，所以...在台灣程式的生存週期更是低得可憐 這個人寫的軟體開發的相關文章我覺得很不錯 http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81 關於程式重寫 http://local.joelonsoftware.com/mediawiki/index.php/The_Joel_on_Software_Translation_Project:%E4%BD%A0%E7%B5%95%E5%B0%8D%E4%B8%8D%E6%87%89%E8%A9%B2%E5%81%9A%E7%9A%84%E4%BA%8B 我忘記在哪裡看過，有人說百分之…忘了多少的文件，到最後都會遺失，所以有人就將文件寫在code裡面，Doxygen就是為此發明的，以註解寫文件，還可以產生各種格式的文件
http://www.stack.nl/~dimitri/doxygen/doxygen_intro_cn.html

關於遠見
http://vic-lin.blogspot.com/2007/02/blog-post_19.html
這是我的一點看法

至於Y2K的問題，我是這樣認為，對於那個年代，每個Bit可能都是很重要的，也許沒有人敢浪費任何的一個Bit，因為那些機器都是價值連城的東西，為了四十年後去花費那多出來的兩位，可能會被老闆開除，而且誰能夠誇口，我的程式能夠活著過2000年呢? 我想應該沒有，很多細節，都不是在規劃時可以想得到的，是必須等東西開始Run才會發現的問題，因為規劃常常會假設每個環節都是完美的，但是現實卻不然，那些不完美的細節，常常是你想也想不到的。

四十年前為了Y2K的事情煩腦，我可以肯定的說，這是幻想，不是遠見….
二十年前為了Y2K的事情煩腦，這還是太遠了些
十年前為了Y2K的事情煩腦，哦…那的確會發生，但….你的程式十年後還存在嗎?
五年前為了Y2K的事情煩腦，嗯…也許你真的該這麼做

幻想和遠見如果沒有分清楚，很容易的就會陷入做太多不必要的事情的無限迴圈，所以對於將來的擔心必須拿捏得剛剛好，保持一定的彈性是必要的，但過多的彈性真的有那個需要嗎? 我認為這就得好好想一想，程式能夠在未來存活，再來做修改，以程式的存活率來看，過度的擔心通常都是多餘的。

不過在台灣情況似乎又有點不太一樣，因為台灣幾乎沒有軟體的生產，大部份都只是零零落落的Case在進行，因此…彈性對於接Case的Team來說，幾乎沒有什麼價值….，東西寫完了交出去就完事了，當這個Case須要做修改時，通常已經不是原來的人或Team在做的工作了….，所以…在台灣程式的生存週期更是低得可憐

這個人寫的軟體開發的相關文章我覺得很不錯
http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81

關於程式重寫
http://local.joelonsoftware.com/mediawiki/index.php/The_Joel_on_Software_Translation_Project:%E4%BD%A0%E7%B5%95%E5%B0%8D%E4%B8%8D%E6%87%89%E8%A9%B2%E5%81%9A%E7%9A%84%E4%BA%8B

]]>