<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>「軟體開發者不應該自廢武功!!」的迴響</title>
	<atom:link href="http://www.lifeparty.idv.tw/blog/archives/262/feed" rel="self" type="application/rss+xml" />
	<link>http://www.lifeparty.idv.tw/blog/archives/262</link>
	<description>君子學以聚之,問以辨之,寬以居之,仁以行之</description>
	<lastBuildDate>Sat, 14 Jan 2012 03:40:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
	<item>
		<title>由：同人的生活派對 &#187; 開發者的 common sense</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/262/comment-page-1#comment-8716</link>
		<dc:creator>同人的生活派對 &#187; 開發者的 common sense</dc:creator>
		<pubDate>Fri, 23 Jan 2009 07:45:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/262#comment-8716</guid>
		<description>[...] 如果該欄位是必要欄位，那訊息中此欄位出現空白就應該認定資料錯誤；但如果它並不是必要欄位，那麼就應該定義訊息此欄位為非必要欄位。而在前者的狀況下，我們應該增加一條業務邏輯來檢核必要欄位不可為空白，否則將拋出異常的回應。如此就非常簡單解決問題，而不該採取自廢武功的作為，因此那只會顯露出開發者缺乏抽象化思考的 common sense 呀。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 如果該欄位是必要欄位，那訊息中此欄位出現空白就應該認定資料錯誤；但如果它並不是必要欄位，那麼就應該定義訊息此欄位為非必要欄位。而在前者的狀況下，我們應該增加一條業務邏輯來檢核必要欄位不可為空白，否則將拋出異常的回應。如此就非常簡單解決問題，而不該採取自廢武功的作為，因此那只會顯露出開發者缺乏抽象化思考的 common sense 呀。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：同人的生活派對 &#187; 軟體缺陷的信用創造</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/262/comment-page-1#comment-8472</link>
		<dc:creator>同人的生活派對 &#187; 軟體缺陷的信用創造</dc:creator>
		<pubDate>Fri, 24 Oct 2008 03:31:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/262#comment-8472</guid>
		<description>[...] 顯然這將會讓專案團隊陷入了以短支長的窘境，而且對軟體缺陷，沒有「早期發現，早期治療」的結果，是必須付出龐大的代價。例如工程師在眼前問題緊迫的情況下，選擇自廢武功，因而降低軟體的結構性使得 bug 愈改愈多，更不用說工程師的士氣與能力的低落了。等到工程師負擔不起龐大的 bug 負債時，信心崩潰就出現了，這時乙方的 feature request 就不會再被甲方所信任而接受了，就如如同人在〈專案不確定感的焦慮與迷思〉所舉的真實案例。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 顯然這將會讓專案團隊陷入了以短支長的窘境，而且對軟體缺陷，沒有「早期發現，早期治療」的結果，是必須付出龐大的代價。例如工程師在眼前問題緊迫的情況下，選擇自廢武功，因而降低軟體的結構性使得 bug 愈改愈多，更不用說工程師的士氣與能力的低落了。等到工程師負擔不起龐大的 bug 負債時，信心崩潰就出現了，這時乙方的 feature request 就不會再被甲方所信任而接受了，就如如同人在〈專案不確定感的焦慮與迷思〉所舉的真實案例。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：阿倫</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/262/comment-page-1#comment-8409</link>
		<dc:creator>阿倫</dc:creator>
		<pubDate>Fri, 10 Oct 2008 17:38:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/262#comment-8409</guid>
		<description>感謝你ㄉ分享資料！</description>
		<content:encoded><![CDATA[<p>感謝你ㄉ分享資料！</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：同人的生活派對 &#187; 當軟體專案計劃趕不上變化時</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/262/comment-page-1#comment-4203</link>
		<dc:creator>同人的生活派對 &#187; 當軟體專案計劃趕不上變化時</dc:creator>
		<pubDate>Tue, 11 Dec 2007 04:48:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/262#comment-4203</guid>
		<description>[...] 問題並不在於軟體功能無法說加就加，說改就改，而是在收尾巴的過程中自廢武功。不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計怎麼會有足夠的空間來容納新功能？就好像想在堆滿東西的房間中，還要硬塞一些東西進去，這樣的結果當然很容易會讓我們在這房間中跌倒。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 問題並不在於軟體功能無法說加就加，說改就改，而是在收尾巴的過程中自廢武功。不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計怎麼會有足夠的空間來容納新功能？就好像想在堆滿東西的房間中，還要硬塞一些東西進去，這樣的結果當然很容易會讓我們在這房間中跌倒。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：同人的生活派對 &#187; 成就自己的不凡</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/262/comment-page-1#comment-4071</link>
		<dc:creator>同人的生活派對 &#187; 成就自己的不凡</dc:creator>
		<pubDate>Fri, 23 Nov 2007 03:52:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/262#comment-4071</guid>
		<description>[...] 所以，勇敢地去落實理念，我們就會獲得更多，停留在原地只會失去成長的機會，同時態度也會愈變愈消極。當然，追尋之路看起來人總是不多，就像在〈軟體開發者不應該自廢武功〉的迴響中，monsta 提到了： 愈是想快刀斬亂麻的解決，就表示處事者愈沒有進入 Groan Zone 的膽識而已~但願意進入 Groan Zone 的人，都了解慢慢來比較快的道理，偏偏這種人是少之又少~ [...]</description>
		<content:encoded><![CDATA[<p>[...] 所以，勇敢地去落實理念，我們就會獲得更多，停留在原地只會失去成長的機會，同時態度也會愈變愈消極。當然，追尋之路看起來人總是不多，就像在〈軟體開發者不應該自廢武功〉的迴響中，monsta 提到了： 愈是想快刀斬亂麻的解決，就表示處事者愈沒有進入 Groan Zone 的膽識而已~但願意進入 Groan Zone 的人，都了解慢慢來比較快的道理，偏偏這種人是少之又少~ [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：monsta</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/262/comment-page-1#comment-4070</link>
		<dc:creator>monsta</dc:creator>
		<pubDate>Thu, 22 Nov 2007 16:59:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/262#comment-4070</guid>
		<description>同意，需求變更不是簡單的無法拒絕就接受或無法接受就想辦法拒絕這麼簡單，供需雙方願意去溝通並找出問題背後真正的solution是很重要的，愈是想快刀斬亂麻的解決，就表示處事者愈沒有進入Groan Zone的膽識而已~

但願意進入Groan Zone的人，都了解慢慢來比較快的道理，偏偏這種人是少之又少~</description>
		<content:encoded><![CDATA[<p>同意，需求變更不是簡單的無法拒絕就接受或無法接受就想辦法拒絕這麼簡單，供需雙方願意去溝通並找出問題背後真正的solution是很重要的，愈是想快刀斬亂麻的解決，就表示處事者愈沒有進入Groan Zone的膽識而已~</p>
<p>但願意進入Groan Zone的人，都了解慢慢來比較快的道理，偏偏這種人是少之又少~</p>
]]></content:encoded>
	</item>
</channel>
</rss>

