<?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/152/feed" rel="self" type="application/rss+xml" />
	<link>http://www.lifeparty.idv.tw/blog/archives/152</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; 不要被「我」給騙了</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/152/comment-page-1#comment-2476</link>
		<dc:creator>同人的生活派對 &#187; 不要被「我」給騙了</dc:creator>
		<pubDate>Sun, 03 Jun 2007 04:09:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/152#comment-2476</guid>
		<description>[...] 我很高興 Frances 引述了我在別的文章所提到的巧妙的「壞人」故事，至少代表他讀過了我的其他文章；可惜他並沒有弄懂我寫的巧妙的「壞人」故事之真正涵義，以為我這裡用的壞人有批判的意味。事實上，恰好相反，壞人故事並不是我創造的名詞，而是引用自《關鍵對話》，在使用這個名詞時，我並沒有是非價值的好惡批判，而只是單純地在陳述有些人在對一件事情賦予意義時可能會發生的情境－把對方當壞人，也就是把問題歸咎在對方的個性不好、基因太壞而往往忽略了情境因素，環境的影響，也就是心理學上所說的基本歸因錯誤。不落入巧妙的「壞人」故事所主導的陷阱中，就是不要把對方當壞人，要當正常人，才不會因為個人的偏見而導致對事情認知的偏差。很不幸地，「認為地球人實在是太壞了，所以&#8230;&#8230;」這種想法正巧就是巧妙的「壞人」故事所主導的情節，所以我不會認同這種看法[2]。 [...]</description>
		<content:encoded><![CDATA[<p>[...] 我很高興 Frances 引述了我在別的文章所提到的巧妙的「壞人」故事，至少代表他讀過了我的其他文章；可惜他並沒有弄懂我寫的巧妙的「壞人」故事之真正涵義，以為我這裡用的壞人有批判的意味。事實上，恰好相反，壞人故事並不是我創造的名詞，而是引用自《關鍵對話》，在使用這個名詞時，我並沒有是非價值的好惡批判，而只是單純地在陳述有些人在對一件事情賦予意義時可能會發生的情境－把對方當壞人，也就是把問題歸咎在對方的個性不好、基因太壞而往往忽略了情境因素，環境的影響，也就是心理學上所說的基本歸因錯誤。不落入巧妙的「壞人」故事所主導的陷阱中，就是不要把對方當壞人，要當正常人，才不會因為個人的偏見而導致對事情認知的偏差。很不幸地，「認為地球人實在是太壞了，所以&#8230;&#8230;」這種想法正巧就是巧妙的「壞人」故事所主導的情節，所以我不會認同這種看法[2]。 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：喲哪桑</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/152/comment-page-1#comment-1983</link>
		<dc:creator>喲哪桑</dc:creator>
		<pubDate>Sun, 20 May 2007 16:21:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/152#comment-1983</guid>
		<description>岔題一下, 我以為我也是從管理工程師的角度下手, 不是技術層面啊! 其實, 我已被人笑我的技術含量愈來愈低了, 有人說我從技術面分析, 我很高興呀! 因此我寫了篇&lt;a href=&quot;http://jonathanspeaking.blogspot.com/2007/05/blog-post_19.html&quot; rel=&quot;nofollow&quot;&gt;為了維護而設計&lt;/a&gt;, 技術含量高一些, 還請同人與Ming指教.

近來, Web Company 很蓬勃, 我也想提醒這些公司, 他們得要更重視網站一直run下去, 比之軟體公司, 維護對web company會是更重要的!</description>
		<content:encoded><![CDATA[<p>岔題一下, 我以為我也是從管理工程師的角度下手, 不是技術層面啊! 其實, 我已被人笑我的技術含量愈來愈低了, 有人說我從技術面分析, 我很高興呀! 因此我寫了篇<a href="http://jonathanspeaking.blogspot.com/2007/05/blog-post_19.html" rel="nofollow">為了維護而設計</a>, 技術含量高一些, 還請同人與Ming指教.</p>
<p>近來, Web Company 很蓬勃, 我也想提醒這些公司, 他們得要更重視網站一直run下去, 比之軟體公司, 維護對web company會是更重要的!</p>
]]></content:encoded>
	</item>
	<item>
		<title>由：Ming</title>
		<link>http://www.lifeparty.idv.tw/blog/archives/152/comment-page-1#comment-1968</link>
		<dc:creator>Ming</dc:creator>
		<pubDate>Sat, 19 May 2007 18:17:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.lifeparty.idv.tw/blog/archives/152#comment-1968</guid>
		<description>喲哪桑是站在比較偏技術層面看問題，同人是站在比較偏管理層面思考問題。兩人的看法並不是處於天平的兩端，只是程度上的差異。就技術層面來看，我也認同維護由當初的設計、開發人員維護是可以有效降低維護成本，然而基於種種客觀層面上的因素，是很難完全達成此一目標。因此，透過管理手段來降低軟體維護成本，才是根本性的解決之道。

同人點出一個在管理上很重要的課題：如何有效激勵開發人員在軟體設計、開發之際，就思考維護性問題。身為軟體從業人員都清楚，版本控制很重要，然而事實上，很多軟體的開發都還是處於土法煉鋼，到底問題是出在哪？依舊是管理人員並沒有有效的監督與控制開發人員的行為。這個現象並不是只發生在軟體業，各種行業都一樣，只是在軟體業上更形嚴重，且軟體本身不是開發完上線使用就沒事，產業型態與一般產品不同。

若是能在軟體設計、開發的過程中，透過某些機制將相關的「知識」保存下來，勢必可以降低維護面上的困難。這些都是屬於方法論，牽扯到的也都是管理性問題。我經常跟同事講，技術永遠不會是個問題，都可以被解決的，但是管理問題卻是最難克服的，因為一旦涉及人性的問題，複雜程度就不是單純的coding或design pattern那麼簡單。

另外一個寫程式的人沒能力維護自己的程式的原因在於，隨著時間的累積，參與的專案越多，在手邊的專案正在如火如荼的進行下，根本無力去維護以前的程式。就跟同人所說的，並不是他不願意，而是心有餘而力不足。更多的情況是，一個好用、有能力的人，老闆加諸的工作量只會多不會少，且老闆多半是重視「正在開發的專案」，也因此這樣的人通常都是被放在戰鬥模式，也就是開發模式，至於維護模式，就交給其他人吧！:-)</description>
		<content:encoded><![CDATA[<p>喲哪桑是站在比較偏技術層面看問題，同人是站在比較偏管理層面思考問題。兩人的看法並不是處於天平的兩端，只是程度上的差異。就技術層面來看，我也認同維護由當初的設計、開發人員維護是可以有效降低維護成本，然而基於種種客觀層面上的因素，是很難完全達成此一目標。因此，透過管理手段來降低軟體維護成本，才是根本性的解決之道。</p>
<p>同人點出一個在管理上很重要的課題：如何有效激勵開發人員在軟體設計、開發之際，就思考維護性問題。身為軟體從業人員都清楚，版本控制很重要，然而事實上，很多軟體的開發都還是處於土法煉鋼，到底問題是出在哪？依舊是管理人員並沒有有效的監督與控制開發人員的行為。這個現象並不是只發生在軟體業，各種行業都一樣，只是在軟體業上更形嚴重，且軟體本身不是開發完上線使用就沒事，產業型態與一般產品不同。</p>
<p>若是能在軟體設計、開發的過程中，透過某些機制將相關的「知識」保存下來，勢必可以降低維護面上的困難。這些都是屬於方法論，牽扯到的也都是管理性問題。我經常跟同事講，技術永遠不會是個問題，都可以被解決的，但是管理問題卻是最難克服的，因為一旦涉及人性的問題，複雜程度就不是單純的coding或design pattern那麼簡單。</p>
<p>另外一個寫程式的人沒能力維護自己的程式的原因在於，隨著時間的累積，參與的專案越多，在手邊的專案正在如火如荼的進行下，根本無力去維護以前的程式。就跟同人所說的，並不是他不願意，而是心有餘而力不足。更多的情況是，一個好用、有能力的人，老闆加諸的工作量只會多不會少，且老闆多半是重視「正在開發的專案」，也因此這樣的人通常都是被放在戰鬥模式，也就是開發模式，至於維護模式，就交給其他人吧！:-)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

