George Yeo 網路自強號

美國五角大廈：可能以速戰、阻美干預、政治解決等方式攻台
2012-5-20 06:15| 發佈者: want-daily| 查看數: 4| 評論數: 0
美國國防部五角大廈，18日公布《2012年中國軍力發展年度報告》指出，雖然中國人民解放軍的使命擴大，包括執行遠離中國的任務，但準備發生於台灣海峽的緊急狀況，仍是中國軍事投資的主要焦點和動力。
據中評社報導，五角大廈評估，解放軍繼續建設自身能力，以阻遏台灣宣布獨立，阻止、拖延、拒絕美國在可能的台海衝突中進行有效干預，並在戰爭中打敗台灣部隊。
報告指出，自從馬英九2008年當選總統，兩岸關係好轉。在兩岸加強經濟和文化交往的同時，中國發展軍力試圖使之有能力按照自己的條件解決爭端，但北京目前還缺乏這種能力，並認識到爭端上升為衝突的代價和風險。

熱比婭竟捐款助日本購買釣魚島
2012-5-19 17:21| 發佈者: maganpower| 查看數: 229| 評論數: 0 |來自: 騰訊網
據英國廣播公司報導，反華分裂組織“世維會”頭目熱比婭，18日在東京向日右翼團體捐款，聲稱要協助東京都政府“購買”釣魚島。
報導說，18日，熱比婭在東京向“奮起日本”黨代表、國會議員平沼糾夫遞交了10萬日元現款，捐給正在募款“購買”釣魚島的東京都政府。
報導還稱，熱比婭還妄言“希望日本買下新疆”，這位元反華分裂組織頭目稱，“全世界無論哪里的領土，中國政府都主張‘歷史上是我國固有領土’”。

陸客來台怎麼都愛丟東西？
2012-5-20 06:15| 發佈者: want-daily| 查看數: 112| 評論數: 1 |原作者: （薛斐／北京）
怎麼這麼巧──韓寒來台灣，也把手機丟在計程車上！不用想也知道，肯定能找回來。我說巧，是因為常聽很多大陸的朋友來台灣，都有丟失東西又找回來的經歷。
拾金不昧的美德
我個人特別喜歡跟記者交朋友，跟玩文字的人交朋友，一是因為職業關係，二是我也有玩文字的愛好。我這個北京來的「台灣女婿」更喜歡以半個地主的身分跟大陸駐台記者交朋友。大家在一起，很容易就把話題轉到了自己什麼東西失而復得的故事。有的丟了照相機，這麼貴重的東西可以找回來。有的丟了採訪本，這麼不值錢的東西一樣也能找回來。

「腦囊蟲病」的駭人真相　大腦遭啃食像腐敗蘋果
ETtoday – 2012年5月18日 下午4:59
國際中心／綜合報導
「腦囊蟲病」(Neurocysticercosis)是一種寄生蟲疾病，通常因患者吃到未熟透的污染豬、牛肉而引起。根據《神經圖像》(Neuroimages)期刊最新一期照片，大腦遭到寄生後會形成許多囊狀物，看起來就像一顆被蟲蛀空的腐敗蘋果。
造成「腦囊蟲病」的罪魁禍首為豬肉絛蟲(Taenia solium)，牠們是一種人畜共通的寄生蟲。絛蟲幼蟲隨著豬的飼料進入體內，並且鑽入肌肉組織的血管內，附於血管壁上；如果人類吃下這些豬肉，而且沒有完全煮熟，幼蟲就會如法炮製，順著人類的血液旅行，最後在大腦內定居、長大成蟲。

普亭又回鍋 難道俄國沒人了？
蘇盈貴 2012/05/16
對習慣於西方民主制度、價值體系與思考方式的人們來說，普亭是一個謎，俄羅斯之謎，到底俄國人在想什麼？為什麼普亭能三度獲選為總統？這真的是俄羅斯人的選擇？為什麼跟我們從西方媒體所獲得的印象差距有如此之大？
普亭崛起的時代背景（上）
2012年5月18、19日，華府，大衛營G8峰會，才就職第三任俄羅斯總統的普亭（Vladimir Putin 1952－），並未如其他各國領導人一般親自出席，而是派總理梅德韋傑夫（Dmitry Medvedev 1965－）代表與會。
這讓與會的各國領袖既失望又不解。
對習慣於西方民主制度、價值體系與思考方式的人們來說，普亭是一個謎，俄羅斯之謎，到底俄國人在想什麼？
為什麼普亭能三度獲選為總統？
這真的是俄羅斯人的選擇？
為什麼跟我們從西方媒體所獲得的印象差距有如此之大？
根據民調顯示，2007年11月，普亭的民意支持度曾經高達84%，位列世界第一。他的支持率，最早在擔任俄羅斯總理開始，1999年8月只有31%，但到了1999年11月時已達80%，從那之後，幾乎再也沒有跌過65%以下。
普亭在2012年3月4日舉行的俄羅斯總統選舉，整體投票率65.34%，普亭的得票率為63.6%。其他四位總統候選人中，共產黨的朱加諾夫得票率為 17.18%，自由民主黨的日里諾夫斯基6.22%，公正俄羅斯黨的米羅諾夫3.85%，獨立候選人普羅霍羅夫7.98%。
在西方國家聲望最高，形象最好的戈巴契夫（Mikhail Sergeyevich Gorbachev 1931年─），1996年參與俄羅斯總統選舉，得票率是1%。
2008年9月，77歲的戈巴契夫再度宣布復出，2011年戈巴契夫針對普亭與梅德韋傑夫輪流做總統總理，而由普亭出任2012年俄總統候選人一事，抨撃說這樣做太狂妄，簡直目中無人，難道俄國沒有人了？
但俄羅斯人民還是選擇支持普亭，而且是相當高支持度的選擇。顯然，俄羅斯人民作出與西方世界幾乎完全不同的選擇。對於俄羅斯人民的這個選擇，西方的看法是2012年5月普亭的就職，不止是他第三任總統的開始，更是他生涯結束的開始。
對5月18、19日G8峰會，這些強國領袖，普亭的拒絕與會，還是讓大家悵然若失，也想不通偉大的斯拉夫民族怎麼會支持這樣的領導人，特別是美國總統歐巴馬。
沒有經過那場波瀾壯濶、驚濤駭浪，幾乎是翻天覆地的大時代革命，永遠不會了解俄羅斯人民底蘊的想法。
我們其實都經過那個年代，只是，困於自身的生活，而無暇他顧，何況是對一個那麼遙遠又巨大的國家？
1985年3月11日，戈巴契夫當選為蘇聯最年青的總書記；1988年，戈巴契夫宣布蘇聯將放棄布魯茲涅夫主義，意味著蘇聯會減少甚至停止對東歐國家內政干涉以及武力干預。這個政策導致東歐在1989年內發生了一系列劇烈的政治地震，史稱東歐劇變。
這段時間（1985－1990）剛好也是普亭被KGB派駐東德時。
東歐劇變實際上結束了自1945年二戰後全世界長達四十餘年的冷戰格局。
為此，戈巴契夫在1990年10月15日獲諾貝爾和平獎。
那是他人生的顛峰，只是不瞬間，他就從這個顛峰跌下，而且摔進暗不見底的深坑。
戈巴契夫在1990年再度當選蘇聯民選總統，被勝選沖昏頭的他沒料到這會是他一生中最大的不幸。
1991年，戈巴契夫試圖將蘇聯改為鬆散的邦聯──蘇維埃主權共和國聯盟，引發黨內不滿，各加盟共和國的分離勢力大幅增長，局勢一發不可收拾，野心家聯合充滿理想的有志之士，為了挽救蘇共及蘇聯，便訴之以政變。
1991年8月19日，時任副總統的亞納耶夫（Gennady Yanayev 1937－2010）與國防部長亞佐夫（Dmitri T. Yazov 1923－）元帥以及KGB的頭子聯合發動著名的八一九事變，軟禁正在黑海克里米亞渡假的戈巴契夫，宣稱戈巴契夫因健康原因無法行使總統職權，成立緊急狀態委員會，下令武裝部隊接管國家政權。（未完待續）
【2012-05-16 聯合新聞網】
在抗議聲中就職？普亭實受歡迎
蘇盈貴 2012/05/16
「在抗議聲中就職」很明顯的是所謂的「西方觀點」，不論實情如何，那至少說明一件事──普亭，這個俄羅斯的「現代沙皇」，無論他多麼受俄羅斯人民歡迎，但是，他在以西歐及美國為首的西方世界是不受歡迎的。
普亭崛起的時代背景（下）
1999年8月18日，太陽系的九大行星，以地球為中心，排成一個正十字架形狀。在正十字的末端，分別是巨蟹、山羊、天秤、白羊等四個星座，這是自西元657年後，再次出現的天文異象，也是十六世紀預言家聖湯瑪斯所說的世界末日。
這個晚上，葉爾欽（Boris Yeltsin 1931－2007）回到官邸時，已經凌晨兩點了。
總統夫人奈娜（Naina）還在浴室裡卸妝。奈娜媳了燈出來，發現臥室的燈已經關了。
擔心吵到他休息，只得摸著黑過來，一腳卻踩在一雙皮鞋上，差點摔跤，床上忽然有人低聲的說：「別嚇著了，是我的鞋子。」
奈娜這才發現，葉爾欽竟然把皮鞋都穿進了臥房──他累壞了，但是又睡不著。
十六日，國會才勉強通過葉爾欽在這一年半不到，所提名的第五位總理人選，原先KGB情報頭子（1998年7月），普亭。
普亭登場──投票結果雖然是以233：84票的懸殊比數贊成通過。
但是說實在的，多數國會議員當時之所以支持普亭，是為了避免葉爾欽未來更多不可預期的動作──簡單的說，他們害怕葉爾欽藉機解散國會。
所以，在普亭登場，擔任俄羅斯總理的第一天，新的民調顯示，在1996年以52.3%過半優勢當選連任的葉爾欽總統，支持率竟然掉到個位數。這種支持率可笑的程度，在俄國史上只有一個人差堪比擬，那就是把偉大的蘇聯葬送掉的戈巴契夫。
為什麼轉變這麼大？葉爾欽怪罪在1998年所爆發的金融危機。
不過，俄羅斯人民的看法似乎不是這樣──他們把生活的艱苦，所有的帳都算到葉爾欽身上。
一直到現在，都還可以聽人民恨恨的說當時：被葉爾欽騙了！
因為在1998年金融風暴發生前，葉爾欽還上電視安撫民心，煞有其事的說：政府一定會全力穩定物價，盧布絕不會貶值。
結果呢？百物飇漲，回不來了。盧布不但貶值，更且貶值的幅度，高達75%。
所以嚴格來說，普亭是1999年八月正式躍上世界舞台的，世事難料，才不過三個多月，就在這年的年末，12月31日這天葉爾欽突然又丟出一顆震撼彈──以體弱多病為由，宣布辭職，並指定普亭以內閣總理代理總統。
※
2012年5月7日
全世界媒體的焦點，幾乎都集中在巴黎，沙克吉以微小差距失去政權。
這也是自密特朗（François Mitterrand 1981－1995担任法國總統，1916－1996）後，睽違多時的法國左派社會黨重返執政。
其實，這天還有另一件大事──雄踞歐亞，跨越十個時區，世界上幅員最大的國家──俄羅斯總統普亭「在抗議聲中就職，展開史無前例的第三次總統任期」。
「在抗議聲中就職」很明顯的是所謂的「西方觀點」，不論實情如何，那至少說明一件事──普亭，這個俄羅斯的「現代沙皇」，無論他多麼受俄羅斯人民歡迎，但是，他在以西歐及美國為首的西方世界是不受歡迎的。
這就是為什麼普亭會以必須留在國內完成內閣任命為由，婉拒美國總統歐巴馬（Barack Hussein Obama 1961－）的邀請，無法出席5月18、19日在華府北邊，馬里蘭鄉間的美國總統渡假勝地大衛營（Camp David）所舉行的美、英、法、德、日、義、加、俄八大工業國領袖會議（G8）。
【2012-05-16 聯合新聞網】
俄積極介入 東亞安全情勢複雜
2013-11-18 06:16| 發佈者: want-daily| 查看數: 21| 評論數: 0
美國亞太再平衡戰略的腳步，讓莫斯科感受到壓力。心懷大俄羅斯主義的普丁總統，未曾坐失美國財政窘困的機會，年來在亞太地區合縱連橫的外交布局，展現了重振俄羅斯大國地位和角色的雄心，但讓東亞安全情勢更趨複雜。
本月初，俄日史上首次舉行的2+2（外長暨防長）會談，俄日政治和解的可能性增高。普丁總統日前訪問越南和韓國，顯示俄羅斯介入東亞事務的企圖心。普丁訪問河內期間，雙方簽署了18項涉及軍事、能源、科技等領域的合作協議，達成建立全面性戰略夥伴關係的共識。俄羅斯與韓國則簽署了被外界稱為「鋼鐵絲綢之路」的《羅津─哈桑建設》諒解備忘錄，為南北韓改善關係及落實朴槿惠總統「歐亞倡議」的理念奠定基礎。
俄日2+2會談與普丁出訪東亞，表面上是例行性外交活動，實則是俄羅斯加強亞太的布局，帶給中俄、中日與中越關係發展難以預期的變數。安倍晉三或認為，日俄安全合作有利於北方四島談判進程，也有牽制中國軍事崛起的效果。然而，莫斯科針對日本媒體大肆炒作「俄日聯手圍堵中國」議題，以「中國是俄國戰略夥伴」的強烈語氣回應，北京外交部則重申「中俄全面戰略協作夥伴關係處於歷史最好水平」，隱喻日方不論出於何種目的，都不可能成功離間中俄關係。
俄日關係不易改善，關鍵在於北方四島歸屬問題。去年3月普丁就任總統後，曾提議歸還齒舞與色丹島（僅占四島總面積6%）換取締約，未獲日方同意。大國權力競逐與互動向來只根據自身利益需求，不可能遵循既定遊戲規則。安倍內閣若一心想對抗中國，甚至不惜犧牲日本利益，俄日就可能締結和平條約，屆時中俄聯手維護二戰後體制的承諾，必然受到考驗。
俄越關係提升至全面性戰略夥伴，自然會影響中國在南海的戰略布局。國際間試圖與朋友的對手緊密合作，保障自己無可厚非，但俄羅斯年來不斷售予越南戰機、潛艦與裝甲車等先進武器，又積極向菲律賓推銷最新改良型T-90MS坦克，直接挑動北京最敏感的神經。普丁訪越目的之一是參與俄製「基洛」636型改良式潛艦交接儀式，擺明了是想平衡東亞各方勢力。
俄羅斯售予越南大量先進武器，也提供巨額貸款協助其提升軍備。普丁此舉或著眼於商業利益，也可能為擴大俄羅斯在亞太的影響力，卻為日後南海可能爆發的軍事衝突預埋變數。
面對現實的考驗和挑戰，中國的外交展現沉著、自信而圓融的一面。年初迄今，北京各階層領導頻繁訪問越南，傳達北京解決南海爭端的誠意，期望以增進相互諒解、尊重與支持，避免未來武力相向。
中越緊張關係趨緩，固然是北京睦鄰外交的成果，但也可能是越南的緩兵之計。俄羅斯表面對北京示好，內心只想尋求中俄美間的戰略平衡。莫斯科政治上與北京結盟，軍事上又積極支持越南與印度，無助於俄國實現遠東地區的經濟繁榮。根據歷史經驗，中俄關係少爭端但互信有限，日俄關係有爭端卻不乏信任，其因多源於歷史與領土問題，也與中國經濟發展迅速，對俄國人造成無形壓力有關。
中俄關係長時間呈現「上熱下冷」現象，雙邊高層互動頻繁，領導階層間的私人友誼不斷深化，但兩國民間交流並不普及，相互認識不足，當中國成為經濟強權且國際地位大幅提升，俄羅斯的強權地位反逐漸弱化。普丁擔憂中國經濟與人口不斷擴張的結果可能反轉歷史。
21世紀是亞太世紀，更是東亞世紀。俄羅斯亞太布局的成敗，關鍵仍為妥善處理大國間關係。俄羅斯過分視能源與軍售為外交縱橫的工具，未必有助於維持強權間的戰略平衡，卻可能帶給東亞地區更多的混亂。
普京談前蘇聯時期：七十年裡面我們一直偏離文明大道
2014-04-18 國家人文歷史
在談到普京對蘇維埃時代的看法和態度時，有人認為他對那個時代是有感情的，說他有一種“蘇維埃情結”，甚至說他要回到蘇維埃時代去。實際上並不完全如此。
1999年12月30日，普京在當上代總統的前夕發表了一篇題為《世紀之交的俄羅斯》的綱領性文章。他在文章裡談到俄羅斯當時的困境時，不認為這是私有化方針和“休克療法”造成的，卻歸罪於蘇聯經濟制度本身，說什麼“這在許多方面是蘇聯式的經濟留下的爛攤子造成的結果”。他接著說，現在俄羅斯完成了經濟改革和政治改革的第一階段，“儘管有種種困難和失誤，我們開始走上了全人類都在走的主幹道”。也就是說，他認為過去蘇聯70餘年所走的道路是一條邪路。在總結俄羅斯的教訓時，他再次重複了這一看法，說道：在即將過去的世紀裡，俄羅斯有四分之三的時間都在為實行共產主義學說而努力。看不見甚至否認這一時期不容置疑的成就是錯誤的。而不認識到社會和人民在這一社會試驗中付出的巨大代價，那是更大的錯誤。主要的是，蘇維埃政權沒有使國家繁榮，社會蓬勃發展，人民得到自由。而且經濟的意識形態化使我們持續不斷地落後於發達國家。無論承認這一點有多麼痛苦，我們將近七十年都走在一條死胡同裡，偏離了文明大道。這裡普京像自由派人士一樣，完全無視在蘇維埃制度下俄羅斯改變了貧窮落後的面貌、成為擁有先進的工農業和科學文化的強國的歷史事實。這說明普京對蘇維埃時代基本上持否定的態度。不過他不知是真的那麼認為，還是出於某種考慮，口頭上承認“走在一條死胡同裡”的蘇聯還是取得了“不容置疑的成就”。儘管他這樣說是有矛盾的，但是這畢竟顯得與全盤否定的一般自由派有所不同。
2000年年底，俄羅斯曾發生一場關於國歌的爭論。普京支持左派的意見，同意採用原蘇聯國歌的旋律，另填新詞。一時有人認為這是普京肯定蘇聯的表現。這種看法並不完全符合事實。普京本人在接受加拿大電視臺記者採訪時對此事做了說明。他首先指出，在任何國家如果開展關於國家的象徵性標誌的討論，一定會發生熱烈的爭論，俄羅斯尤其是這樣，因為一方面，人們“還沒有忘記在蘇維埃時期發生的悲劇性事件，許多人的傷口還在流血，還記得史達林的勞改營的全部恐怖”；另一方面，如果認為“這個時期沒有任何能使人民引以自豪的東西，那是不幸的錯誤”，那時的許多成就是“與一定的象徵性標誌聯繫在一起的”，人們有權將其“帶到今天的生活裡”。普京贊成採用蘇聯國歌的旋律和採用紅旗作為軍旗，顯然主要是為了表示尊重那些肯定和懷念蘇維埃時代的人的意見和權利，以求得他們在政治上的支持。在這個問題上，他第一次公開頂撞了堅決反對採用蘇聯國歌旋律的葉利欽，說他事先知道葉利欽的態度，說葉利欽作為“主要的反共分子”把蘇聯國歌旋律與“整個共產主義遺產”聯繫起來加以反對的“合乎邏輯的和原則性立場”應該尊重，但是他“在這個問題上有另一種意見”。
與此同時，普京覺得也需要照顧那些否定蘇維埃時代的人的情緒，於是在這個問題上搞起平衡來。在2000年12月8日送交國家杜馬審議的關於國家的象徵性標誌的法律草案中，除了提出採用蘇聯國歌的旋律和採用紅旗為軍旗外，還提出採用三色旗為國旗，雙頭鷹圖案為國徽。這樣一來，在國家的這四項重要象徵性標誌中，沙皇時代和蘇維埃時代使用過的各占一半。這個法律草案儘管也還有人站在不同立場上加以反對，但是終於順利地通過了。因此，如果說在這個問題上普京與葉利欽有什麼不同的話，那主要是策略的不同。普京覺得他作為總統，不能單憑自己的好惡行事（上面說過，他對蘇維埃時代是沒有好感的），而要考慮和照顧各方面的意見和情緒。應該說，在運用策略上，他比葉利欽更勝一籌。
可是普京也有不這樣做的時候，在取消十月革命節的問題上就是如此。我們知道，在蘇維埃時代，11月7日（舊曆10月25日）這個爆發十月革命的日子被定為國慶日，法定7日和8日這兩天放假。1992年蘇聯解體後，假日減為7日一天。在葉利欽當政時期的1996年，這個節日更名為”和諧與和解日“。眾所周知，11月7日是當年兩個階級進行最後決戰和爆發武裝起義的日子，把它定為“和諧與和解日”，當然是可笑的。這個日子是俄羅斯走進他所說的“死胡同”的開端，普京當然是不願意把它當做節日來慶祝的。同時普京在《千年之交的俄羅斯》一文中作為教訓提出，在今天的俄羅斯，任何政治力量不應再呼籲進行一次革命，不管它們用的是什麼口號，也就是說，他認為應當完全告別革命。大概是為了使廣大群眾忘掉十月革命，忘掉昔日的崢嶸歲月和革命傳統，不再產生進行革命的“邪念”，2004年決定把節日挪到11月4日，並把它改名為“人民團結日”。11月4日是1612年波蘭佔領者撤出莫斯科和標誌著“亂世”結束的日子。有人認為把這一天定為節日是“尊重歷史”的表現。那麼這裡不禁要問：那些處心積慮要把11月7日這個具有偉大歷史意義的日子從人們記憶中抹掉的人為什麼不也尊重一下歷史呢？
眾所周知，在蘇維埃時代莫斯科紅場成為革命聖地，成為世界各國革命者嚮往的地方。紅場上的列寧陵墓和近旁的墓地是時代的象徵。自由派早就想遷葬列寧遺體，取消列寧陵墓。第一次提出這個問題是在1989年，當時因遭到許多人的反對而未成。蘇聯解體後，圍繞遷葬問題的爭論一直沒有間斷，由於意見分歧，這個問題被擱置起來。普京在2001年7月18日舉行的新聞記者招待會上就這個問題表了態。他反對遷葬，並講了反對的原因。他說：“我們國家七十年來生活在蘇共壟斷政權的條件下。這是整個一代人生活的時期。許多人把自己的一生與列寧的名字聯繫在一起。對他們來說，埋葬列寧將意味著他們崇奉了錯誤的價值觀念和給自己提出了錯誤的任務，意味著他們虛度了一生。我們這裡這樣的人很多。”普京再次避而不談他自己對列寧的看法和態度（從他對蘇維埃制度的評價來看，他對這個制度的創始人的態度應該說是很清楚的），只說應該考慮許多“把自己的一生與列寧的名字聯繫在一起”的人的情緒。他還說，社會剛剛開始穩定下來，應該珍惜，如果採取遷葬之類的行動，就有可能毀掉穩定的局面，妨礙俄羅斯實行現代化。
普京這話是在2001年7月講的。四年多後的2005年的9月，當俄羅斯的經濟有所回升、社會秩序穩定下來時，總統派駐聯邦中央區的全權代表波爾塔夫欽科在記者招待會上提出遷葬列寧遺體以及拆除紅場上的其他紀念性建築的問題。這不僅只是要遷葬列寧的遺體，而且要把紅場上克里姆林宮宮牆旁的400餘位蘇維埃時代著名活動家的靈柩和骨灰盒搬走。這400餘位活動家包括以史達林為首的黨和國家領導人、以朱可夫為代表的22位元帥、18位蘇聯英雄和14位兩次獲得此稱號的蘇聯英雄、加加林等5位宇航員以及柯洛廖夫和克爾德什等著名科學家，還有高爾基等著名文化界人士。他們是整個蘇維埃時代的象徵，挖掘他們的墳墓，實際上就是要否定這個偉大的時代。波爾塔夫欽科的提議得到了一些當權人物和知名人士的支援，在俄羅斯媒體上引發了一陣否定蘇維埃時代的喧囂。以俄共為代表的左派群眾表示堅決反對，他們舉行了各種形式的抗議活動，而且這些活動形成了一定的規模和聲勢。在這種情況下，普京通過他的發言人宣佈他的立場不變。2006年2月7日他又在西班牙記者提問時說，他將“力求做出能得到絕大多數公民支持的決定”，並且使這些決定“能促進民族的和解和團結，而不是導致分裂”。
這裡有一點值得注意：這次提出這個被人們稱為“侮辱性建議”的是政府高級官員，而且此人原在國家安全部門工作，受到普京的信任和重用。這種特殊關係說明他提出遷葬問題不只是反映他個人的意見。人們有理由認為，他的這一行為得到了上面的贊同，甚至懷疑這是上面指使的，目的是為了試探民意。久加諾夫在一次新聞記者招待會上指出，“普京實際上默默地支持他的全權代表波爾塔夫欽科挖掘墳墓的行為”。他還說：“普京在與蘇維埃時代的遺產做鬥爭的道路上實質上要比葉利欽走得遠得多。葉利欽不顧一切地蠻幹，毀掉碰到的一切。而普京則始終一貫地實行巧妙地褻瀆國家及其歷史的政策。”
為什麼從蘇聯解體以來當權者一而再地提出遷葬列寧遺體問題呢？已故著名哲學家和作家季諾維耶夫對這個問題做了這樣的解答：發生了反共政變，一切與蘇維埃共產主義時代相聯繫的東西都要進行歪曲和加以根除。陵墓中的列寧是時代的象徵，而象徵在歷史上起著巨大作用。只要陵墓還聳立在紅場上，事情就沒有結束。不管我們的當權者如何裝束自己，紅場上的列寧是他們的鮮亮新衣上的一個斑點。遷葬列寧遺體將意味著反共政變的合法化。因此，可以預料，今後當權者將不會放棄解決這個問題的努力。
也許是巧合，這時當年流亡國外並死在那裡的國內戰爭時期的白軍將領鄧尼金和哲學家伊林的遺骸被迎回國內安葬。根據上面提到的那位波爾塔夫欽科透露，迎回兩人遺骸的倡議得到了最高領導人俄羅斯總統普京的支持。順便提一下，普京尊重伊林這位“先賢”，曾在國情咨文中引用過他的話。
衛國戰爭是蘇聯歷史上的重大事件，蘇聯人民在這場打敗德國侵略者和使全人類免遭法西斯奴役的戰爭中建立了偉大的功勳，同時也作出了巨大的犧牲。普京對這場戰爭的正義性和取得的偉大勝利是肯定的。他在2001年6月22日衛國戰爭爆發60周年時發表的告人民書中反對歪曲事實真相，貶低和侮辱犧牲的烈士。他不同意把這場戰爭說成兩種極權主義思想爭奪世界霸權的戰爭，認為這是反對納粹主義的戰爭。不過他對戰爭是如何取得勝利的，有他自己的看法。他在2005年的國情咨文中，只說勝利既是靠武器的力量，也是靠人民的堅強意志和團結取得的，根本不提領導這場戰爭的布爾什維克黨和史達林所起的作用。他在同年5月舉行慶祝戰爭勝利60周年活動期間的幾次講話中也不提史達林的名字，彷彿這場戰爭是在沒有統帥指揮的情況下取得的。季諾維耶夫在逝世前發表的最後一次談話中氣憤地說：“這簡直荒唐透頂！”誠然，當西方記者把史達林與希特勒並提時普京也表示不能同意，可是他仍然認為史達林是“暴君”，強調“許多人稱他為罪犯”，沒有講一句正面肯定史達林的話。他在另一次談話中同樣閉口不談史達林的功績，卻特別指出史達林要為“造成戰爭頭一年或頭一年半失利的巨大過錯”承擔責任。普京的這些表現與葉利欽相比，甚至倒退了一步。記得1995年5月在慶祝衛國戰爭勝利50周年時，葉利欽在報告中提到了史達林與邱吉爾、羅斯福、戴高樂一起建立反希特勒聯盟的“偉大功績”。當時的總理切爾諾梅爾金在學術會議上作報告時也說：“不能貶低或不提史達林在偉大衛國戰爭中的功勳。否則是不公正的，也是不誠實的。”
談到衛國戰爭，就不能不提作為整個第二次世界大戰轉捩點的斯大林格勒保衛戰。這次著名的戰役使斯大林格勒這個英雄城市名揚全世界。1961年赫魯雪夫為了否定史達林，把斯大林格勒改名為伏爾加格勒。這個城市的居民早就希望恢復原名，多次提出這個要求。2002年，在斯大林格勒保衛戰揭開序幕60周年之際，當地各界人士再次提出恢復原名的問題。一批學者聯名給普京寫信，希望得到他的支持。而普京在12月中旬的電視談話中潑了冷水，他說：“今天恢復斯大林格勒這個名稱，會在我們國內產生某種猜疑，使人覺得我們要回到史達林主義時代去。這不會給我們大家帶來好處。”可是儘管普京表了態，伏爾加格勒州杜馬仍繼續進行恢復原名的努力，於2003年1月先後兩次向國家杜馬提出恢復斯大林格勒原名的議案。大概是因為普京已有言在先，這個議案未能通過。
可是到了2004年7月19日，普京簽署命令，決定把莫斯科亞歷山大花園無名烈士墓右側石墩上鐫刻的英雄城市名稱“伏爾加格勒”改為“斯大林格勒”，命令說，這是為了尊重斯大林格勒保衛者的英雄壯舉和忠實於俄羅斯國家的歷史。他這樣做的真實目的大概是為了緩和一下他反對恢復城市原名引起的不滿情緒。他的這一姿態給了那些力主恢復城市原名者以希望。他們積極開展活動，召開各種會議，做出要求恢復原名的決議，徵集簽名，到2005年4月，俄羅斯國內已有5200萬人表示支持。他們本來希望在紀念衛國戰爭60周年時解決這個問題，可是一向以尊重人民群眾意見自詡的普京毫無反應。結果直到今天，在俄羅斯地圖上仍然找不到英雄城市斯大林格勒。
2004年秋，俄羅斯教育部決定重印《聯共（布）黨史簡明教程》，將其作為高校歷史教學參考書。此事受到廣泛的注意並引起了某些猜測。眾所周知，這本書是史達林親自主持編寫的，其中有些章節是史達林的手筆。史達林逝世後，它一直遭到貶損和批判。現在尚未見到能夠說明此書的重印得到普京贊同和支援的材料，更沒有事實能夠證明普京對史達林的看法發生了變化。此事的出現大概與俄羅斯社會情緒的變化和史學界出現的重評史達林的思潮有關，普京至多只不過是默許罷了。
從以上列舉的事實可以看出，普京從總體上說對蘇維埃時代是持否定態度的。這就決定他對蘇聯的崩潰和解體的態度。上面提到過，他在《千年之交的俄羅斯》一文裡就說過，蘇維埃制度的覆滅，使俄羅斯走出了“死胡同”，“開始走上了全人類都在走的主幹道”。這就從發展的大方向上肯定蘇聯崩潰是件好事。在這之後，他多次談到這個問題，雖然具體說法和用詞有所不同，但是實質是一樣的。
（摘自《從赫魯雪夫到普京》，社會科學文獻出版社）
德國人甘苦參半的俄羅斯情懷
2014-04-21 國家人文歷史
許多德國人感到跟俄羅斯有一種特殊的關係。這就使烏克蘭危機對柏林來說特別危險，因為它提出了關於德國認同感的重要問題：我們真的如多數人相信的那樣深深紮根於西方嗎？
我的德國祖父曾是俄羅斯的戰俘，他能活命的唯一原因是有一副好歌喉。1944年，戰爭已進入尾聲，納粹將大多數強壯的男性徵召入伍。俄羅斯人在佈雷斯勞包圍戰中俘虜了他，將他帶到勞動集中營做伐木工。
那時候沒什麼吃的，他說人們像蒼蠅一樣死掉。集中營的炊事員不時給祖父加餐，一點稀飯或麵包，全因為他有一副好嗓子。夜裡，他在火邊唱歌，俄羅斯人也會圍坐在那裡，傳喝伏特加酒，歌聲讓他們感動得流淚——至少這是我家裡傳下來的說法。
直至今天，德國人與俄羅斯仍保持著一種特殊關係。這種紐帶深入德國人家庭的歷史，受到兩次世界大戰和存在了40年的東德的影響。德國人至今分享善良深情的俄羅斯人那些殘忍的故事。我們看不起俄羅斯人的粗鄙，卻推崇他們的文化和精神。
“說到德國人與俄羅斯人的關係，這是一場悠悠深情與深惡痛絕之間的拉鋸戰。”德國小說家伊戈•舒爾茨說。俄羅斯人有時被視為“恐怖伊萬”、異類、亞洲人。俄羅斯人令我們害怕，但我們也認為他們熱情好客。他們有遼闊的土地、深厚的靈魂和文化——那是一個出柴可夫斯基和托爾斯泰的國家。
圍繞俄羅斯在烏克蘭危機中所扮演角色的討論，比當前德國政治中任何其他問題都更加分化。對德國來說，烏克蘭不是像敘利亞或伊朗那樣遙遠的問題——它直抵德國認同問題的核心。對俄羅斯，我們站在什麼立場？以及相關的，我們德國人是誰？隨著東西方再度面臨衝突的危險，這個問題在德國重受關注，最終促使我們重新思考我們作為“西方國家”的定位。
最近幾周，德國上演一場激烈的爭論。一方是那些傾向於同情俄羅斯的人，另一方是主張對莫斯科強硬的人。立場很極端，爭議一個接著一個。一個主要指控是，歐盟和北約東擴怠慢了莫斯科。人人似乎都參與爭論——有政治人物、作家、前總理和科學家。讀者、聽眾和觀眾致信編輯、在網上論壇發帖，或打電話到電臺或電視臺，表達各自的看法。
對德國人與俄羅斯人之間的關係，有一些明顯的解釋：經濟利益、兩國都存在根深蒂固的反美情緒。但這只是表面上的回答——再深挖一些，你會找到其他兩個解釋：浪漫主義和戰爭。
戰爭的解釋與德國的負罪感不可分割。作為一個對俄羅斯人犯下滔天罪行的國家，我們有時覺得需要特別寬容，即便是處理俄羅斯人權侵犯的問題。因此，許多德國人覺得柏林應該緩和對俄羅斯的批評，在烏克蘭危機問題上採取溫和的立場。畢竟，德國曾經入侵蘇聯，在種族主義滅絕戰中打死2500萬人。
負罪感造成了德國人與俄羅斯之間的某種聯繫，但對俄羅斯人來說，戰爭一結束這個問題很快就消失了。與法國、北歐和荷蘭不同，俄羅斯人一般不會為了德國在佔領期間犯下的罪行指責德國人，讓德國人蒙羞。舒爾茨說：“俄羅斯人講的事情會讓你血液凝固，但他們從不對我們惡言惡語。”
然後，當然是德國人對俄羅斯的浪漫想法。這個國家總是被德國人理想化。當東西方緊張緩解，蘇聯引入改革時，沒有哪個國家比德國更加激動。最終，他們覺得，還是可以再愛上俄羅斯的。在戈巴契夫身上，德國人看到好的俄羅斯人回來了，覺得沒有理由繼續害怕俄羅斯。
在德國，政治精英與同情俄羅斯人之間的分歧日漸擴大。不久前民調機構Infratest dimap進行的調查顯示，接近一半的德國人希望在俄羅斯和西方之間採取中間立場。前東德的州中，認為德國應該充當特殊角色的人，是前西德州的兩倍。即便在西部州，認為德國應堅定站在北約和歐盟一邊的，也只是勉強達到多數。
我小時候生活在西德，我個人害怕俄羅斯人。夜裡我都睡不著覺，因為從技術上講，我們當時只是與蘇聯達成了停火協定，隨時會恢復衝突。幸運的是，我家裡總是充滿歌聲。祖父可能想要給我們一個重要的謀生手段——萬一俄羅斯人來的話。不論怎樣，為了生存而歌唱多年的祖父，從不對俄羅斯人假以辭色。
（據《青年參考》）

馬就職典禮 五邦交國元首出席
自由時報 2012-5-18
〔記者范正祥／台北報導〕外交部昨宣布，邀請邦交國及友好國家元首、特使或政要出席五月二十日總統、副總統就職典禮，目前統計有四十一團、約二百三十人，並包括吉里巴斯、馬紹爾、諾魯、帛琉、巴拉圭等五個邦交國總統。
外交部指出，外交部長層級以上有十九團，分別為五個總統團、總督及代理總督團各一個、六個總理團、兩個副總統團、一個副總理團及三個外交部長團，教廷也循例指派教宗特使前來。非邦交國部分，則有美國、加拿大、新加坡等慶賀團，還有歐洲議會友台小組議員、英國、日本、韓國、印尼等國國會議員等。美國代表團今年由前白宮幕僚長戴利率領，日本則由日華議員懇談會長平沼赳夫率團。
總統就職大典實況 越語也通

不丹不幸福？ 開放現代擴貧富差距
TVBS – 2012年5月19日 下午1:38
說到幸福國家，或許很多人都會想到不丹，當年梁朝偉和劉嘉玲也選在這裡完婚，感受幸福氣氛，不丹在40多年前 首創國民幸福指數，曾經有高達97%的國民認為自己很幸福，不過一份最新調查的幸福指數報告，覺得自己幸福的不丹人，只剩下41%，主要就是現代化造成的貧富差距，造成幸福感驟降。
座落在喜馬拉雅山，帶有神秘色彩的不丹，這裡曾經號稱世界上最幸福的國家，影星梁朝偉和劉嘉玲當年也選在這裡結婚，感受幸福的氣息。
當地學童：「我認為幸福，應該是讓別人也覺得幸福。」

魏德聖奔波 彼岸熱情回應
作者： 張士達╱綜合報導 | 中時電子報 – 2012年5月18日 上午5:30
《賽德克.巴萊》10日在大陸上映，因首周票房僅400萬人民幣（約1900萬台幣），讓戲院場次大減。但導演魏德聖在大江南北宣傳，感動不少影壇人士，有熱血戲院經理力挺，堅決加場。業者認為，行銷不及、盜版流竄、觀眾對「內地版」的誤解等因素，導致《賽》片票房低迷，但魏導的執著感人，為現今「唯票房是圖」的華語電影圈帶來正面啟示。
《賽》在一線城市的主要影院僅剩早場和晚上10點左右的場次，幾乎退出黃金時段，但萬達院線16日仍全線加場。昆明北辰財富中心影城總經理田再興也說一定堅持下去，希望有更多影院加入：「魏導謙卑敬業的精神讓我很感動。或許影院會輸了場次，但一定贏得靈魂。」另一位堅持加場的影城經理說：「魏德聖做這個片子太不容易了。什麼時候咱們遇到過這麼豁出命去做的電影？不支持實在說不過去。」
當大陸一窩蜂搶拍大片搶錢，品質卻每下愈況，大陸媒體也說希望《賽》能啟發大家不再只顧票房。一位被魏感動的媒體人說，他一直堅持為《賽》寫文章：「我的願望很簡單，希望好導演有下部片子可以拍，觀眾有好電影可以期盼。」

中國經濟奇蹟的祕密
2012-5-19 06:16| 發佈者: want-daily| 查看數: 24| 評論數: 0 |原作者: ■記者盧葦／整理
誠如人們已然感受到的那樣，財富爆炸只是中國鍍金時代前最為耀眼的那一部分，在它的另外一面，則是中國社會一幅灰暗的圖景。就像我已經指出的，中國的超低成本優勢乃是國家透過其行政權力將成本從企業及政府那裡轉移出來而一手塑造的。
然而，成本不會自動消失，它到哪裡去了？答案是：社會。或者更加準確地說，它進入中國絕大部分家庭的福利損益之中。
考察低成本優勢的方方面面，這種轉移幾乎無處不在。所以，在巨富不斷冒升的背後，是貧富差距的急劇擴大；在新的國營寡頭重新崛起的背後，是中小企業的利潤損失及家庭部門的福利損失；所以，在銀行巨頭攫取壟斷暴利的背後，是被迫忍受負利率的儲蓄者的財富縮水；在土地產業飛黃騰達的背後，是中國農民遭受的悲慘剝奪。

軟體設計的思維
林俊杰 著 Jul 17 15:33:32 1994
同【物件導向的天空】一文, 本文亦曾發表於「建中青年」刊物第 94 期。
(繼續)
第５．１節　程式語言
    程式語言依照年代和特性的先後可以分成四類。各代有各代的特色，也因此在軟體
設計方式上有不同的方法：
第一代 組合語言／機械語言
    最原始的程式只是一堆 CPU 所能瞭解的指令集，它們都是數字，不過實在很難瞭解，
像“23 EA 73 66”這樣的數字代表什意義呢？除了 CPU 和天才外，恐怕沒人能瞭解，
因此我們便用一些簡字符號來代表某個機械碼指令，例如 80X86 的 MOV、ADD 等等。
它的特點便是非結構化、極低階的運算方式、但執行速度極快，不過很難為人了解，因此
在設計上常常造成很多困難， 不過許多較好的編譯器都會提供巨集 MACRO，提供較佳的
設計途徑。
第二代 非結構化語言
    這代語言的黃金時期是在 1960 和 1970 年代。這時代的作業系統正在發展分時系統
，硬體環境相當嚴苛。BASIC、FORTRAN、COBOL.....都是這類語言的代表。他們的特色是
非結構化，也就是說 GOTO 用的很多，此外缺乏模組化的結構。大家可以看看 BASIC 是
什樣子的，大概也就差不多了。
第三代 結構化程式語言
    第三代程式語言起於 1960 年末。這代語言都具有嚴密的區塊結構、更抽象的資料
封包方式、結構化的語法結構、適當的資料形態、程序與函數的結構相當完整。Pascal
是最具代表性的程式語言，事實上它當初設計的目的便是指導人們以結構化的思考方式
來寫作程式，也因此成為研究計算機科學者必修的語言。Ｃ語言一直是我的最愛，它本來
是貝爾實驗室用來發展ＵＮＩＸ作業系統的，但目前許多應用軟體也用Ｃ語言來寫（例如
dBASE)。Ｃ語言不但具有像 Pascal 的結構，它本身具備了一些低階的特性，五十餘個
強有力的運算子，使得這個語言的結構更是完美。
    第三代語言還有兩種較特別的族類，一個是人工智慧 (AI) 用的程式語言，另一種是
物件導向程式語言 (Object Oriented Programming Language, OOPL)。人工智慧語言可以
用 LISP 和 PROLOG 為代表。這些語言的特點在於它們對符號處理能力很強，PROLOG 對於
階層性的串列還可以自動回溯。OOPL 則應以 SmallTalk 為代表。Smalltalk 和Ｃ一樣也
是貝爾實驗室的產品。它允許我們將有關的資料與程序（OOP 術語叫方法 METHOD）捆成
一包“物件 Object”，相類似的新物件可以經由“遺傳”舊物件而來。整個 Smalltalk
就有三四百個庫存的物件，一位 Smalltalk 的設計師只要遺傳這些物件就可以了。最近
漸趨熱門的 C++ 則是在這股 OOP 風潮下，由原先的Ｃ語言加強而成的。
第四代程式語言 ４ＧＬｓ
    第四代程式語言又較第三代來的高階並且更抽象化。以前程式設計師必需費時於設計
很多演算法。但經由第四代程式語言，設計師只要描述它所要的需求（requirement)，
就可以輕易地設計出程式來，例如 dBASE 等。不過目前大部份 4GL 都用在資料庫或商業
方面，並不易運用於其它的範圍，例如系統程式的設計。不過等將來人工智慧的技術發展
成熟了，相信 4GL 必然會成為主流。
    筆者強烈地推薦以第三代以後的語言來設計程式，第三代語言的好處在於它能夠很
簡單將各類演算法實作出來，並且又具有易於除錯和維護的優點。第四代語言則可以節省
大量的時間在細節的設計上。第二代語言如 BASIC 或 FORTRAN 要真和 Pascal 或Ｃ比起
來，實在是很可憐的。
第５．２節　考慮系統
    筆者認為有時真實世界的作業環境對於程式設計者常常會是一場夢魘。此話怎講？
因為我們常常看到教科書上不斷的提示說：降低程式對於電腦（機器）的依賴性。這句話
實在說得很曖昧。假如你今天設計一個在ＰＣ上使用的電動玩具，你將會發現各機器的差
異是如此的大，光顯示器常見就四、五種了，還有各家音效卡也不一樣，透過 BIOS 來作
繪圖的工作似乎是很愚笨的一件事，因為像 F-19 這類模擬飛行的遊戲玩起來將會像騎三
輪車一樣缺乏速度感！與系統的相依性越低，可能就必需降低不少效率！這真是一個讓人
傷腦筋的問題。我們實在不得不承認﹕一套軟體的發展的確受限於電腦硬體環境的限制。
筆者提出一些解決的參考方案：將與硬體高度相關的部份獨立成模組；在規劃程式的當初
最好考慮將要採取的系統或是周邊裝置。不過，仔細想想，大部份程式實在不是很有必要
依靠機器，頂多也是一部份罷了！
    另一個 PC 使用者常見的問題是在於『編譯器』的問題！特別常見於用ＴＣ的人身上
。雖然程式語言幾乎都有國際標準的語法（例如 ANSI, ISO 等），但移植到各種電腦、
作業系統、編譯器上就會出現『方言』，這導致程式原始碼（source code）的可攜性降
低。這就像是湖南老鄉見到山東大漢一樣，雖然講的都是中國話，但溝通上實在有困難。
解決這個問題有兩點建議：（一）當你開始寫程式時，就必需按標準來寫，即使有部份要
用到方言的語法，必須分開獨立並且要詳細的指明。（二）下定決心，將終身大事托付給
你的編譯器吧。
第６節  撰寫程式的風格
    程式設計本質上至少有一半具有藝術創作的特性，好的程式往往就是一件藝術品。
而你，電腦藝術家，具有你自己的風格，你自己的創意，因此你的作品將會處處顯露出
你獨特的個性。
    當然這麼說並不是要你將程式『畫』得像畢卡索的作品一樣，但至少你的程式應該
具備一些特性：明確的定義、詳盡正確的註解、善用縮格與空白等等。當然你可以培養出
你特殊的氣質，展現在你的程式中。
 註  解
 ───
    註解是說明程式碼內容的文字，明白而清晰的註解使得程式碼容易閱讀與瞭解，
很多人多懶於撰寫註解，他們常見的藉口不外：
    我的程式本來就很容易瞭解了
    我當然看得懂我自己寫的程式了
    諸如此類都不過是推拖之辭罷了！人們常常忘記一些瑣碎的問題，這當然也包括他們
自己的程式在內。到底這個函數的參數代表什麼意義呢？他的傳回值又是什麼？螢幕的
左上角是（０，０）還是（１，１）？　這些都應是註解的內容之一。但我們須要寫多少
的註解？註解的內容又該有多詳細呢？ Planger 說：『好的註解不能代替壞的編碼，
然而好的編碼是否就能夠取代註解，那就不得而知了。』爛的註解就像撒旦一樣，會給你
錯誤的指引。通常的規則是把註解分兩類來寫：前言性註解（prologue comments）和功能
註解（functional comments）。前言式的註解一般是放在模組的前端來指明該模組的技術
簡明資料，大概包含了：
（一）功能和目的
（二）介面說明
      A.  說明參數意義
      B.  說明傳回值的意義
      C.  所需參考到的模組
（三）資料的規格和限制
      變數的使用方式和範圍，例如標明螢幕左上端是 (1,1)....
（四）發展紀錄
      誰設計了這個模組，修改的日期和所修改的內容等等歷史資料
    功能性註解則是安插於程式碼中來說明某一區塊程式碼的功能。寫註解並不是寫文章
，不必寫的長篇大論，但也不要太簡略到用幾個簡字符號。有部份註解的內容可能是在
除錯時留下來的，這些註解最好在除錯完成後便去除，以免造成誤解。另外關於註解要用
英文還是中文來寫，筆者倒認為“易懂”才是重點，用中文不一定會比較爛。
 變數的命名
 ─────
    常常看許多人用了一些毫無意義的變數名稱，像 A,B,C,D,X,Y,Z,PP,SS,TT..
亂七八糟，而這種情況特別常見於初學者。這種習慣不是很好，甚至比那些沒寫註解的
差上一級，當然要是註解沒寫，變數名稱又亂寫的，真應該好好反省了。變數的命名應該
以明白易瞭解為主。許多人為什麼用無意義的符號來做為變數名稱的原因是因為嫌多打
幾個字太累，或是佔空間等等。不過還有一種是較誇張的行為，就是變數名稱寫的有夠長
，例如：AmountOfYear、KiloMeterPerSecond等等，的確是有點矯枉過正，不過還是比
那些用無意義簡字符號來的好。在為變數命名的當初，最好能建立一個『字典』來說明
縮寫與展開字的關係。例如：
       KM  = Kilo meter = 公里
       Sec = second     = 秒
       rec = record     = 紀錄
    當然最好能夠將該變數的意義附加在表格後面，建立一個『變數字典』，方便程式
設計工作的進行。
 縮  格
 ───
    在結構化的程式中，縮格可以很明顯的分別出每一個區塊，和各區塊間的關係。
    例如說：
       ....                            ....
       .....                           .....
       if 邏輯判斷 then                if 邏輯判斷 then
       begin                           begin
            ..... 敘述                 ..... 敘述
            ....                       ....
            .....                      .....
            for 迴圈控制               for 迴圈控制
            begin                      begin
                 .....                 .....
                 ....敘述              ....敘述
                 .....                 .....
                 .....                 .....
            end                        end
            ....                       ....
            ...敘述                    ...敘述
       end                             end
       ....                            ....
       .......                         .......
      有『鋸齒』狀的縮格            缺乏『鋸齒』狀的縮格
    縮格與不縮格的效果相當的明顯，你要縮多少格都沒啥關係，現代的編譯器都會自動
辨識，但是對於某些程式語言有『欄位』限制的，例如 FORTRAN 等等，會稍微麻煩點，
但可以盡量的作出這個效果來。另一個焦點是在於像 begin 和 end 這一類“標示區塊”
起迄點的位置。以Ｃ來說，它以｛ 表示 begin，以 ｝來象徵 end，結果筆者看到的寫法
就有一大堆：
┌───────┐┌──────┐┌───────────┐
│for (......) {││for (.....) ││for (.) { .... .... } │
│   .....      ││{           ││                      │
│   ......     ││   .....    ││                      │
│   ....       ││   .......  ││                      │
│}             ││}           ││                      │
└───────┘└──────┘└───────────┘
 ＜＜幾種Ｃ程式的縮格＞＞
    不勝枚舉啊！筆者是喜歡用中間那個方式，有些教科書則是用第一種，第三種則常見
於只有一行敘述的函數中，這種情況在Ｃ＋＋的教本中特別常見。用縮格時不要擔心這是
否影響整個原始碼的長度等等，這是多餘的。較長的原始碼不會導致程式的效率降低，
但亂七八糟的原始碼是鐵定會出問題的。
 運算式
 ───
    從兩個方面來看一個運算式的寫法﹕第一是運算式本質上的複雜度，第二是表示的
方法。以第一個角度來看，這樣的式子：
x = 26 * ( 22 + y * 7 ^ z + ( 164 / 64 mod 7 ) )
    實在不太理想，因為太多的括號和不明顯的本意讓人讀起來很辛苦，並且，沒有經過
最佳化處理的式子也會降低不少效率，例如說：
x = 2/3 + 5/3
    在這個式子中，電腦必需做兩次的浮點數（簡而言之就是帶小數）的計算，分別是
2/3=0.666666 和 5/3=1.666666，但如果你寫成 x = ( 2 + 5 ) / 3 ，只需做一次
7/3=2.333333 的浮點計算了，而電腦作整數計算遠較浮點計算快，這樣寫效率便提高了。
    第二個觀點是表示的方法。特別以Ｃ語言為例是因為它所有的運算符號是眾語言中
數一數二多的，例如以下的邏輯判別式來說實在有夠曖昧：
    !x == 3 && y != 6
但是加了括號後就明白多了：
   ( (!x) == 3 ) && ( y != 6)
善用括號和空白是很重要的！
第７節  除錯與測試
    除錯常常是設計師頭痛的來源。每個程式幾乎都不免有錯，不論是生手或老手的作品
都一樣。我們在設計程式之初總會有美麗的憧憬：當我作好規劃，然後編碼，再修改一些
『小錯誤』，這個程式就完成了！事實不然，或許你寫程式的速度的確很快，但你永遠也
無法知道你將會花多少時間和精力在除錯上，這真是一個可悲的事實！另一方面，『除錯
』這件工作即使是在科學昌明的今日，也缺乏一套好方法，和一些好工具來協助我們除錯
，雖然新的除錯工具不斷的在出現，但除錯依舊還是一件令人沮喪的工作。
    一般而言，錯誤被區分為語法上的錯誤和邏輯上的錯誤。語法錯誤的原因主要來自
打字錯誤或一些無意義的語法，較嚴重的可能是指令或變數名稱的誤用，不過這種錯誤
一般而言都不太麻煩，絕大多數語法上的錯誤都會由編譯器偵測出來。因此我們較關心
是邏輯上的錯誤。
    在講除錯前先說說測試。測試和除錯是兩碼子事，測試工作主要是在運用一些假設的
狀況，來查驗程式是正常或有錯誤，因此測試的方式和測試的樣本就很重要了，因為沒有
正確的發現程式有錯，問題將會在日後如山洪一樣的暴發出來。當測試工作一開始進行，
並不會斷然的立即測試一整個系統是不是正常，因為你一定會發現有錯，但找不出錯誤在
哪，因為程式實在太大了。一般我們會先進行模組測試，等一個個的模組都驗證無誤後，
系統或許也應該沒問題了。測試程式的方式有主要兩種策略：黑箱 (Black box) 和白箱
(White box) 兩種測試方法，互有利弊。
 白箱
 ──
    白箱測試的方式就好像拍攝模組的Ｘ光照片後，再仔細的分析。有四個主要的測試
方向：（一）至少將模組中所有的獨立路徑測試過一次。（二）測試所有邏輯判斷的流程
。（三）以『邊界值』來測試模組，例如對於位元組的資料型態，則以邊界值０和ｆｆｈ
來測。（四）測試內部所有的資料結構。簡而言之，白箱測試就是將模組的內容作執行
路徑的分析，因此模組就像是玻璃屋一樣，一覽無遺。理論上白箱測試應該每一條路徑
都須檢查，但實際上卻有遺漏的可能，特別是在大型的模組中，白箱測試的工作更是複
雜，不過白箱測試仍是必需的。
 黑箱
 ──
    黑箱測試用來判定程式是否正確的作了我們要它作的事情。經由這個測試程序，可以
驗證程式是否達到我們的要求。例如說我們要測試一臺“換鈔機”，你可以分別投入各種
幣值的鈔票，換出對應的零錢出來。這個時候，用來測試的數據就很重要了！因為你的
測試數據不可能包含將來所有可能發生的情況，但你卻要保證測試能找出所有的錯誤！當
然這似乎是不可能辦到的。所以我們可以拿以前真正實際應用時的數據，例如說拿百元鈔
換十元幣，五百元換五角等等。拿實際數據來測有個好處，就是常見的正確情況和常見的
錯誤情況都包含在裡面了，因此可以證明程式在真實情況下的可信度。當然你也可以產生
隨機資料，不過這些數據可能就不會常見了，例如說拿一億元換一角的情況並不太可能
發生。
    黑箱測試和白箱測試看來似乎是相反的測試方法，前者是藉由測試的資料和結果來
驗證，後者則是仔細的查驗程式中每一個步驟。兩種方法都有存在的價值，因此它們的
效用是互補而非互斥的。白箱測試通常應用於程式設計初期，黑箱測試則應用在軟體完成
後。
    錯誤是可以分類的，特別是可以用出現頻率來分別，一直發生，常常發生，偶而發生
，甚至發生過一次後就再也不發生的錯誤。而搜索錯誤的方式也有一些常見的方式：
暴力法、往前搜尋法、原因消除法。暴力法是最常見、最沒效率的方法，除錯的人總是
一步一步的從頭追蹤程式，把記憶體中的變數甚至檔案的內容都印出來，或是在程式中
很多地方顯示執行時的情況......當然這種方法可以找到錯誤，但需要很長的時間和很多
精力，不過我們還是會運用這個方法，特別是在一切都絕望的時候。
　　　
    往前搜尋法或許是較好的方案。從錯誤發生的地方往前找看看到底那裡不對勁。在
程式較小的場合或許管用，但程式太大了就困難了。最科學的當屬原因消去法。我們有
系統的去分析一個錯誤發生的原因，作一些可能的假設。就像是汽車發不動了，你不會
急忙的把車子支解，而是會想想看那些零件的故障會導致車輛無法發動，例如火星塞、
分電盤......。
    以上提的三種除錯的方法都有適當的軟體工具來配合，例如單步追蹤器，或中斷點
除錯......等。
    不可否認的，除錯的工作是一件令人痛苦而不耐的工作，特別是對於原程式設計者
而言，要他承認自己的程式有錯，真是一件丟臉的事，但事實就是如此，錯誤就在你的
程式中。因此從人性面來考量的話，除錯的工作或許該交由別人來做，但有誰會比設計者
本人更了解這個程式呢？話說至此，筆者還是認為設計師本身應該能夠坦誠的面對問題，
並且不要蓄意的去保留自己的秘密，這點應該是很重要的。
第八節  結語
    軟體設計是件高度創造性的工作，因此創意是不可缺的。但創意的實際化是否需要
一套方式來規範呢？或許僵硬的限制是扼殺創意的的元兇，但缺乏一套記錄、表示創意的
方法，將會讓創意白白的從指縫間流走。或許你看完這篇文章後會說：『我從來都不依照
這些法則來寫我的程式啊！』是的，許多人都是如此，但也因此他們程式的發展都有個
上界，這個上界可能是程式的大小或複雜度等等。當然真實的設計工作不會這麼死板，
你可以自由的運用這些軟體發展的策略，來設計你的程式，要知道，草率的設計和編碼
所導致的結果總是痛苦的除錯！
    很明顯的，限於篇幅，筆者不可能將程式設計的方式完全寫出來，讀者有興趣當作
更進一步的研究。不過累積自己的經驗是很重要的，這些實務上的經驗幾乎是很難從書本
上習得，特別是對我們中國人而言，很多設計的理論完全是國外研究出來的，但諸如中文
的處理，卻是完全本土化的一種東西，但國內真正在將技術本土化的人並不多。附帶一提
的，在模組化設計的方法中，有一個由 Stevens 所提出來分別模組緊密性的方法，這個
方式完全就是架構在英文文法上，對中文並不完全適合，因此筆者就捨棄不提了。
    對於創造完美的程式，永遠是設計師們追求的目標。你呢？

軟體設計的思維
林俊杰 著 Jul 17 15:33:32 1994
同【物件導向的天空】一文, 本文亦曾發表於「建中青年」刊物第 94 期。
第  １  節  前言
    常常有人問筆者：要學什麼程式語言比較好？同樣這批人在學會某種程式語言後，
又常會問說：接下來要學什麼程式語言呢？為什麼學會電腦語言卻又寫不出程式來呢？
相信讀者中必然也有不少人有類似的問題，但可能找不到適當的答案。因此你這時你
不禁會懷疑：電腦到底可以幹啥？
    基本上這源自於一個很簡單的誤解，因為不少初學者認為除了瞭解鍵盤如何使用、
電源如何起動外，學電腦最主要的目的是要學會如何寫程式！而不是用來處理資料、
編輯文書......。當然啦！如果有心人想對電腦科學做更深入的研究，當然是樂觀其成
的，但可惜的是入門者常常是在走錯路後才恍然大誤。這不但浪費時間，也相對的浪費
金錢。有鑑於此，筆者希望能透過這篇文章，讓有心大眾能少走些冤枉路，而加速邁向
成功的終點。
第  ２  節  你要電腦為你做什麼
    為什麼需要寫程式呢？理由很簡單，就是因為你對電腦有所求！希望它能為你作些
事。點子（計畫）的來源可能是前夜周公來托夢，或者是因應他人的需要（例如朋友、
客戶、或是自己）而產生的。你應該詳細的思考一下你對電腦的要求，你希望它作些什麼
事，程式必須有何功能？輸入資料的型式（是圖片、文字敘述、電話號碼......）？輸出
的結果？型式？......越週詳的考慮，對於往後的工作進行會有越佳的幫助。
    一般而言，這些雜七雜八的要求可能會顯得十分混亂，特別是由那些不懂電腦的所
開出的規格，更是匪夷所思，摸不著頭緒。而身為工程師的您，你的工作便是分析出程式
的功能。這有點像是室內設計師的工作，你的客戶只可能會告訴你，這裏要擺張桌子，
但不告訴你尺寸；他可能會突然想到椅子上必需要鑲入珠寶，但卻不會去考慮椅子是紅
還是黑的......。因此，充份的溝通是有必要的，軟體工作者應該充份的了解客戶的需要
。當然這點做起來可能很難，特別是當你的客戶是暴發戶型的大老板時，那麼此時必需要
以心理醫師的方法慢慢的誘導出你所要知道的細節。
    如果你寫程式的原因是要交作業的話，盡可能的弄清楚文字說明的意義，該達到的
目標一點都不可少，與主題無觀的應予拋開。想一想下面這個問題（這題是七十九年度
程式設計比賽校內初賽的一個問題）：
    “設計一程式，以之判讀一般之中序算術式，是否為有效或無效之運算式。
    式子中所涉及的運算元暫定為由Ａ到Ｚ或ａ到ｚ的單一字元，可為使用之
    運算子則包括加、減、乘、除及括號與次方。程式的輸入為一中序的運算式，
    而其輸出為一判讀之結果。”
    這邊要特別解釋一下：中序運算式指的是我們一般所列的式子，例如 1+2=3 。
題目就這麼多，條件也說的很明白了。讓我們來整理分析一下它到底要作什麼。
    關鍵字句在於“判讀一般之中序算術式，是否為有效或無效之運算式”，說得清楚些
，就是說判斷一個式子是否正確，例如 1 + 2 是對的, 但 1 +* 3 就不對了。另外，
我們必需知道哪些符號是合法的，由“加、減、乘、除及括號與次方”此句中我們知道
可以用“＋”、“－”、“＊”、“／”、“（”、“）”、及“次方”。前面的符號
都沒問題了，但“次方”就麻煩了，因此電腦的符號系中似乎沒有強制限定次方符號，
例如 BASIC  是以 ^ 為次方符號，FORTRAN 是以 **，甚至Ｃ語言根本就沒次方這回事。
此時，儘可能的與試務人員交換意見，或者明白的在你的說明文件中定義次方符號。但
因為這場比賽是以 BASIC 撰寫的，因此便以 BASIC的 ^ 表示了。接著，在“運算元暫定
為由Ａ到Ｚ或ａ到ｚ的單一字元”此句中我們知道一個算式必需以英文符號代入運算，
例如 x=y+z，但相對的，23+12 就是不合語法的了。並且，題目中只要我們辨別出運算式
是否正確即可，不必畫蛇添足，算出到底是多少來。另外題目中並未提到“運算式的來源
”，究竟是經鍵盤輸入或是由檔案中取出呢？但經瞭解後是由鍵盤輸入。而以上就是對
有限條件題目的分析。
    在你仔細的分析完這個問題後，你可能會發現解決這個問題對你而言可能是力不可及
，或者是所需時日甚多，無法如期完成，或是有現成的套裝軟體可以立刻解決此需求的...
... 而無論如何，這就是我們所以要分析定義問題的緣故。
第  ３  節  仔細的思考軟體的結構
    經過一番努力後，你已經定出一套完整的規格，此時你大概也有個譜了。然而這只是
第一步罷了，系統結構尚未建立呢！因此別興奮的太早，接下來你應該要把夢想落實，
一步一步的具體化。規劃的目的除了在描繪具體的軟體結構外，重點是要進行模組的建立
，資料格式的規劃，模組間的通訊協定（Protocol）等工作。
    關於規畫軟體，有很多理論上的設計方法。但有諺曰：『一圖勝過千言萬語』。畫圖
是幫助我們規畫程式的最佳方法。幾個比較著名的方法，例如流程圖、拿西－尼得門圖
 (Nassi-Shneiderman)、及下面要談的 DFD 圖。
第３．１節　ＤＦＤ圖
    一般的軟體，最基本上可分為“輸入”、“處理”、“輸出”三部份；所謂的“資訊
”，其實所指的就是經過處理後的“資料”，因此ＤＦＤ圖便應運而生了。ＤＦＤ圖的
精神就在於資料流程的規劃、各處理單元的動作、並且可以作更深一步的切分。ＤＦＤ圖
有幾個符號，介紹給大家認識一下：
   ┌──┐
   │    │      外界個體    系統輸入的起點或輸出的終點
   └──┘
    ╭─╮
    │  │       轉換程序    執行輸入資料處理轉換成輸出資料的單元
    ╰─╯
 ╭───→      資料流      用以連接不同的程序，以表示資料傳送的方向
 ──╮ ╭─→
     ↓ │       資料儲存所  資料儲存的地方，箭頭表示資料的來源及輸出的方向
 ═══════
舉一個銀行自動櫃員機的 DFD 圖：
 ┌────┐ 提款卡密碼    ╭───╮ 付款訊息    ┌──┐
 │ 終端機 │──────→ │櫃員機│ ────→  │點鈔│
 │  鍵盤  │──────→ │ 系統 │             │付款│
 └────┘  提款金額     ╰───╯             └──┘
                    《第 A 層次的 DFD 圖》
    這是最初步的，未經細部規劃的。但一個雛型已經產生了。下一步工作是逐步的將
DFD 圖分解成細節。
  ┌────┐ 提款卡密碼 ╭───╮    帳戶資料
  │ 終端機 │─────→│總行電│←─────╮
  │  鍵盤  │──┬──→│腦查核│────╮  │
  └────┘    │      ╰─┬─╯   帳戶 │  │
                  │提款      │查核        │  │
                  │金額      │結果        ↓  │
                  │          ↓          ══════
                  │      ╭───╮      銀行的輔助除存裝置
                  ╰──→│櫃員機│      例如磁帶機
                          │ 電腦 │
                          ╰─┬─╯
                              │    付款訊息  ┌──┐
                              ╰──────→│點鈔│
                                              │付款│
                                              └──┘
                  《第 B 層次的 DFD 圖》
┌────┐ 提款卡密碼    ╭───╮ 付款訊息    ┌──┐
│ 終端機 │──────→ │櫃員機│ ────→  │點鈔│
│  鍵盤  │──────→ │ 系統 │    :        │付款│
└────┘  提款金額     ╰───╯    :        └──┘
               .                         ...
              .                            ...
             .                                ....
            .                                    :.
           .      ╭───╮    帳戶資料           .
      提款卡密碼  │銀行電│←─────╮          .
      ─────→│腦查核│────╮  │           .
      ─────→╰─┬─╯   帳戶 │  │            .
       提款金額       │查核        │  │             .
        .             │結果        ↓  │              .
        .             ↓          ══════           .
        .         ╭───╮      銀行的輔助除存裝置     .
        .         │櫃員機│      例如磁帶機             .
        .         │ 電腦 │                            .
                  ╰─┬─╯                           .
                      │        付款訊息             .
                      ╰─────────→
                      《資料流程的分解》
第３．２節　由上而下的程式設計 (TOP-DOWN DESIGN)
    由上而下的設計哲學，是一種逐步細緻化的設計概念。就像你寫生時，必然是先打
草稿，既而以大號畫筆勾勒輪廓，再用更細些的筆描繪出細部構造。很少有人是拿細筆
一筆一筆刻劃的，即使有，也不容易畫得好。可能的結果是畫虎反類犬。有個人找了位
建築師幫它設計一幢洋房；數週後，他去找建築師看看設計圖。於是建築師便拿了張圖
告訴他說：“讓我們來看看廁所屋頂的水管設計圖”。“可是我還不知道房子到底是什麼
樣呢？”顧客說。誠所謂綱舉目張，當結構設計好之後，細節就可一一浮現了。並且，
由上而下的方式，不僅運用於初期的規劃，也應用於編碼 (CODING)、測試時。
    一般而言，一個完整的程式是具有“層次性”的。大部份看來就像例圖這般：
（當然實際情況會複雜多了）
                   ┌───┐
                   │主程式│
                   └─┬─┘
                       │
           ┌─────┼──────┐
           │      　  │    　      │
           │      　　│    　      │
           │      　  │    　      │
   ┌───┴─┐  ┌─┴───┐┌─┴───┐
   │主要模組Ａ│  │主要模組Ｂ││主要模組Ｃ│ ．．．．．
   └─────┘  └──┬──┘└─────┘
                         │
                 ┌───┴┬─────┐
                 │        │          │
                 │        │          │
             ┌─┴───┐
             │次要模組Ｄ│．．．．．．．．．．．
             └─────┘
（模組在下一節介紹）
    因此我們對一個程式的結構應該是由頂端主程式開始思考，再逐步的往下深入，像
蓋房子要先打地基，再建一樓，再建......如此一層層的堆上的。在作由上而下設計時，
要避免“向下思考”，也就是說先不要考慮下一層模組的工作。並且也不要在規劃時期就
急著編碼。不然何必先規劃呢？
    同樣的，當程式在編碼 coding 時，則能夠先寫上層的模組，再繼續往下寫。寫好
一個上層模組後，可以先進行模擬測試，完成後再繼續下一步驟的工作。
    不過由上而下的設計、編碼、測試都只是大原則罷了。一個專業的設計師真正在工作
時可能也會由下而上的設計、編碼、測試。為什麼呢？因為我們可能會須要一些低階的
副程式，例如視窗副程式、繪圖驅動程式、通訊程式等等，不過要注意的是，這種由下
而上的寫作方式依然還是得在由上而下的訂定整體結構後才實行，不然常常會發生上下
模組無法銜接的情況，這就像開挖隧道一樣，你可以分兩組人馬分別從兩端開挖，但精密
的測量和協調絕對是必需的，否則將會出現兩條隧道......。
第３．２節  結構化的程式設計
    將到結構化，很多人便會想到“ｇｏｔｏ”敘述的存廢問題。理想中我們的確不希望
見到ｇｏｔｏ的存在，但對於那些老舊的程式語言而言 (BASIC, FORTRAN, COBOL...)，
去除 GOTO 敘述是幾近不可能的！
    那麼到底結構化程式設計的本質是什麼呢？在結構化設計的理論中，任何一個程式的
流程都可以被分類為三種形態：循序、二元分歧、迴圈。也就是說經由這三類的基本指令
就可以構成一整個程式。
  　
      │                  │                        │
      │                  │                        │
      ↓                  ↓                        ↓
 ┌────┐            ／＼                      ／＼
 │ 處理   │          ／    ＼                  ／    ＼
 │   方塊 │        〈  判別  〉          ┌→〈        〉
 └────┘          ＼  　／            │    ＼  　／
      │                 ＼／ if           │      ＼／
      │                  │               │       │
      ↓                  │               │       │
                    ┌──┴──┐         │       ↓
               then │          │ else    │  ┌────┐
                    │          │         └─┤        │
                    ↓          ↓             │        │
                                               └────┘
 循序結構              選擇結構                  迴圈結構
    另外，整個程式的流程是極順暢的由起點到終點，而不是用 goto 指令改變程式的
流程。結構化的程式在閱讀上十分容易，因為閱讀者不必跳來跳去閱讀，而是一目瞭然
的！下面附的是一個用Ｃ＋＋所寫的範例，讀者可以感受一下她的優美性：
int main( int argc, char *argv[] )
{
    if ( argc != 2 )
    {
        cerr << "Usage:  lookup classname\n"
        return 1;
    }
    Dictionary& classDefinitions = *( new Dictionary );
    for ( int i = 0; i < CLASSDEFINITIONS; i++ )
    {
        String& className = *( new String(classNames[i]));
        String& classDef = *( new String( classDefs[i] ) );
        Association& entry =
                   *(new Association(className,classDef));
        classDefinitions.add( entry );
    } // end for all class definitions
    Association& definition =
      classDefinitions.lookup( *(new String ( argv[1] ) ));
    if ( definition == NOOBJECT )
    {
        cout  <<  "A definition for " << argv[1] <<
                　"  was not found in the dictionary.\n"
    }
    else
    {
        cout << definition;
    }
} // End Function main //
第３．３節　模組化程式設計
    模組是一套功能獨立的程序，這麼說或許有點籠統，現實中來講，一件單一的工作
可以說是一個模組。例如我們可能會需要一個“管理檔案”的模組，來做一些建檔、開檔
、讀檔、寫檔、關檔、刪檔的工作。而很明顯的，一個大模組可能還包含幾個小模組，說
『包含』可能不適合，但我們或許可以認為一個大模組是架構在小模組上的，就像“管理
檔案”的模組底下還有建擋、開檔....這些次要模組。一個模組內部具備了程序及資料
變數，因此像是一個“獨立王國”似的。模組和模組間經由“呼叫”的方式以達成資料的
交換、工作的轉換。因此一個程式的結構或可以看成很多模組的組合。
┌程式──────────────────────────┐
│                                ┌模組Ｂ───────┐│
│    ┌模組Ａ────────┐  │                    ││
│    │                      │  │        ┌模組┐    ││
│    │  ┌模組A-1 ────┐│  └────┼ Ｄ ┼──┘│
│    │  │    ┌模組A-1-1 ││  ┌模組Ｃ─┼    ┼┐    │
│    │  │    │        │││  │        └──┘│    │
│    │  │    │        │││  │                │    │
│    │  │    └────┘││  │  ┌模組C-1 ┐  │    │
│    │  └────────┘│  │  │        │  │    │
│    │  ┌模組A-2 ───┐  │  │  │        │  │    │
│    │  │              │  │  │  │        │  │    │
│    │  │              │  │  │  │        │  │    │
│    │  │              │  │  │  │        │  │    │
│    │  └───────┘  │  │  └────┘  │    │
│    │                      │  │                │    │
│    └───────────┘  │                │    │
│                                └────────┘    │
│                                                        │
└────────────────────────────┘
    你可以把上圖看成一間房子，裡頭有三個大房間，大房間裡又有小房間，小房間裡
有小櫃子......。以模組Ａ來講，他又包含了Ａ－１和－２模組，此時我們可以發現一個
現象﹕整個模組 A 的公共變數資料，模組 A-1 和 A-2 都可以用得到，因為這並未超過
它的有效範圍，反之模組 A-1 的變數並不能對模組 A 及模組 A-2 發生影響，但卻可以
影響 A-1-1 模組。不過在大部份情況下，各個模組還有自己的私有變數值。另一種模組
的組合情況會和模組Ｄ一樣，是一個共用的模組。這就像是 PRINT 這種模組一樣，大家
都要用的。
    另一個我們關心的問題是模組間參數的傳遞。除了某些語言先天上的限制外，模組間
訊息的傳遞應該盡可能的不要經由“公共變數”來傳遞，否則一些公用變數的意外改變，
其副作用是很難預料的。一般而言，一次所傳遞的參數個數不要超過七個！為什麼是“七
”呢？這不是明牌號碼，是由心理學家所研究出來的結果。因為一般正常人同一時間內
大概能注意七件事情，當然會有所差異，不過其範圍總在７±２之間。也就是說超過這個
範圍的，可能較難為人所瞭解。不過若真有需要，可以考慮傳遞整個資料聚合體，例如
Pascal 的 RECORD，或Ｃ的結構......等。
    一個模組該有多大？筆者認為實在沒有什麼好限制的，而且也沒什麼標準可以用來
明確的告訴我們模組該有多大多小。當然了，在某些軟體專案裡可能會用長度來限制模組
大小，以達到模組化的目的，但設計師仍然可以投機取巧，先撰寫好他的程式，再依一定
長度來切，不過以這種方式所產生的模組大概都不會是很好的模組罷了。那麼我們要如何
衡量某個模組是不是太大，該減肥了呢？讀者應該可由後面提到衡量模組緊密性的觀點
來看。但不可否認的，太長的模組不僅不易了解及偵錯，它本身或許還能再被細分成更小
的模組。
    基於模組的性質，我們必需從兩方面來討論它。第一點是由模組本身“內部”的內容
來看，分析其內容的『緊密性』，這就像一個工廠的生產線，其工作內容是否相關，可能
某些工人的工作是在鍛造鋼板，有些是在焊結鋼板，這些都算是蠻密切的關係，但如果有
些工人作的事是織布，這之間的關係就小了。第二點是由模組與模組間的『關聯性』，
這就像一棟大廈中的住戶間的關係，或許有的是親戚，有的是朋友或同事，但也可能毫無
關係。
 緊密性
 ───
偶然緊密性：一個單一模組或許做了幾件工作，但這幾件工作都沒什關聯，充其量只是
            一種隨機的組合。讀者若搞不懂的，請將『緊密』那兩個字遮起來不要看，
            因為這個緊密不是一個形容詞。這種情況有點像是一家百貨公司，東西賣得
            很多，不過彼此實在沒什關聯。
邏輯緊密性：相對於偶然緊密性。一個模組裡的工作是有關係的。這就像是“美食街”
            這類餐館一樣，賣的都是食物，是要填飽肚子的。
時間緊密性：如果一個模組裡的工作必需在同一段時間內執行，便具有此特性。例如
            開門鎖這件工作一樣，在你轉動鑰匙的當時，還要用手轉動門把才行。
程序緊密性：如一模組內的單一工作有一定的執行順序，便稱為具備了程序緊密性。
            好比說你必需先打開電源，才能用電腦一樣。
溝通緊密性：如一模組內的工作集中的存取某一些特定的相同資料，例如你和班上的
            同學為了交老師的報告，必需參考一些資料，但相信不少人，甚至大部份人
            都會找同一本書來參考。
順序緊密性：如果一個模組內的“很多”工作有先後的順序，和程序緊密性的“單一”
            不同。例如你先得爬上二樓，才能上三樓，然後再上五樓。
功能緊密性：假如一個模組的工作都是相同的話。例如某個模組的功能就僅僅是作兩整數
            Ａ與Ｂ的相加而已。
 偶然緊密性     時間緊密性           溝通緊密性        功能緊密性
   │               │                   │                │
   │   邏輯緊密性  │    程序緊密性     │  順序緊密性    │
   │       │      │        │         │      │        │
   │       │      │        │         │      │        │
   │       │      │        │         │      │        │
   ↓       ↓      ↓        ↓         ↓      ↓        ↓
 │←（低）─────── ＜＜緊密度＞＞ ──────（高）→│
 關聯性
 ───
缺乏關聯性：這由字面上就知道，模組和模組間毫無瓜葛。
資料關聯性：模組之間傳遞的資料是一個一個參數。
記號關聯性：模組與模組間傳遞資料的方式不是傳遞一個個單一的參數列，而是整個
            資料結構（資料的聚合體）。就像你寫信給某人，寄的不是一張張的信紙，
            而是一本書加上幾盒磁片，或許還有油畫......。
控制關聯性：模組間所傳遞的資料若不是”單純的資料“，而是一些控制的旗號。這就像
            美國總統下給駐波斯灣官兵的命令不是一本厚厚的攻擊計劃，而只是攻擊的
            代碼而已。這樣海珊就不知道布希要宰他了。
外界關聯性：模組與模組共同運用一個特定的 IO 裝置。
共同關聯性：模組與模組之間共用同一部份的資料。就像薪資模組和出席模組共用人事
            資料一樣。
內容關聯性：若一個模組會用到另一個模組的控制資料，或者可以從另一模組中間開始
            執行。這種情況必需盡力避免。
 缺乏關聯性       記號關聯性           外界關聯性      內容關聯性
     │               │                   │              │
     │  資料關聯性   │     控制關聯性    │  共同關聯性  │
     │      │       │         │        │      │      │
     │      │       │         │        │      │      │
     │      │       │         │        │      │      │
     ↓      ↓       ↓         ↓        ↓      ↓      ↓
  │←（低）─────── ＜＜關聯度＞＞ ──────（高）→│
    一般而言，我們希望模組內的緊密度越高越好，而模組間的關聯度越低越好。不過
這只是希望如此罷了，真實的程式絕對不可能是如此，但設計師還是可以用這些標準去
衡量模組化的程度。
    透過模組化的設計方式，我們可以一步步的建立通用性的程式庫 (libaries)，也
可以引用過去所建立好的程式庫。當然寫作一個通用性的模組並不會是一件很容易的工作
，因為該模組的功能在不同的情況下必須滿足不同的需求。例如一個輸出副程式，可能
早期是寫給單色顯示系統的，但時代的進步，使得程式也必須支援彩色顯示系統了，此時
程式庫便須要修改了。這點就成為軟體維護上的一個問題了。
第  ４  節  資料結構與演算法
    最近看到不少人都在參加〞電腦擇友〞的活動。參加這活動的男男女女將條件填在
表格上，寄給主辦單位的電腦，處理後將形成〞最佳〞的配對資料。但筆者要偷偷的告訴
你們，要換成是筆者，就根本不會期待這個結果是正確的！當然啦！如果有人因此而陷入
熱戀，那我們應當祝福他們，但請不要告訴他們說：有個姓林的電腦狂說電腦擇友是唬人
的！
    諸如電腦如何由眾人中依條件找出配對的方法，或是電腦鼠走迷宮，事實上都是按照
一套已經預先建立好的方法來進行，此便稱為演算法。廣義的演算法解釋是這樣的：凡是
一個程式的執行，必然是按照一定的規則步驟去進行。整個程式的流程便是一個演算法，
但一個大的演算法可以是（或必然是）許多演算法個體的結合。但通常我們常常會討論
一些特殊用途的方法，例如剛剛舉的電腦擇友，數字從小到大的依序排列，乃至於計算機
的微分解法，都可歸類為狹義的演算法。而資料結構與演算法則是一體的兩面。正確來說
是密不可分的，更保守來講演算法就是資料結構，資料結構就是演算法！但若要筆者來分
的話，筆者則將資料結構定義為一個“資料的抽象描述方式”，而演算法則是“處理資料
的方法”。
    “條條大路通羅馬”這句話可以說是程式設計千古不朽的銘言啊！因為解決一個問題
的方法必然不會是唯一的，舉例說從台灣到美國，你可以考慮坐飛機，也可以搭船，當然
啦，如果你自願游泳渡過太平洋筆者也不反對。但是“效率”與“實行成功性”便成為
我們必需好好考慮的要素。坐飛機無疑是最有效率的選擇，但卻不適合大量貨物的運送，
因此此時你便得考慮船運。如果你沒錢買機票或船票，那麼游泳可能便是你最後的抉擇了
......。選擇正確的演算法，會使程式的效率大為提高，並且可以確保程式是否能正確
完美的執行。並且對於某些特殊問題的解答將會獲致意想不到的效果。
    其實整個資訊科學可以分成兩大類別﹕一是實務派，也就是真正投入工業生產的，
把演算法實際“實作”的﹔另外一類是學術派的，他們的工作主要是研究規劃特定的演算
法，但兩者並非相衝突的。一位好的程式設計師通常也應該是一位好的演算法設計者，
否則他也必需要會正確的引用已知的特定演算法。但很多〞玩家〞倒不重視這些了，他們
總以為程式會跑就好了！這是一個很危險的想法，也是不正確的（但這也是專家和玩家的
分野）。理由就像上面所講的。
    不但設計演算法是一們學問，實作演算法（編碼）更是一門大學問！一個好的編碼
結果必然會有較佳的執行效率，例如“壓縮程式”（像 LHARC, PKZIP, PKARC 啦...）
其實大部分用的都是相同的演算法，但其壓縮後的縮減比例和計算速度卻都有很大的差別
，因此演算法實作的重要性自然不在話下。
    由於這篇文章不是討論資料結構與演算法的專書，筆者的目的是在給各位讀者一個
演算法上的概念。但相信藉由舉一些著名的演算法為實例必然可以引起讀者較高的興趣。
 排序
 ──
    排序法幾乎是每一位學電腦的必修的項目。方法很多，筆者舉兩個極端的例子，它們
分別是“泡沫排序法”和“快速排序法”。假定有一堆散亂無序的數字：（由小而大排）
                    23,64,2,73
    若是用泡沫排序法來解決的話，它會這麼做：依次比較一對數字，如果後者大於前者
，則互換排列；用這個方式從頭到尾循環進行，直到沒有交換的情況發生才算完成。
執行過程：
 ┌──┬──────────────────────┐
 │步驟│排列情況                                    │
 ├──┼──────────────────────┤
 │  １│23,64,2,73 第一回合                         │
 │    │^^ ^^                                       │
 ├──┼──────────────────────┤
 │  ２│23,2,64,73                                  │
 │    │   ^ ^^ 大小互換                            │
 ├──┼──────────────────────┤
 │  ３│23,2,64,73 因為發生過交換，所以必須繼續執行 │
 │    │     ^^ ^^                                  │
 ├──┼──────────────────────┤
 │  ４│2,23,64,73 第二回合                         │
 │    │^ ^^                                        │
 ├──┼──────────────────────┤
 │  ５│2,23,64,73                                  │
 │    │  ^^ ^^                                     │
 ├──┼──────────────────────┤
 │  ６│2,23,64,73 並未發生交換                     │
 │    │     ^^ ^^                                  │
 └──┴──────────────────────┘
    另一個解決排序問題的方法是“快速排序法  Quick Sort“，相對於泡泡排序法，
Quick 的效率有明顯的改善。假定有 n 個數字等待排序，若以泡泡排序解決，理論上須
費時 n 平方的基本時間單位，如果用快速排序法來做，理論上所花費的時間大約是 n 的
1.2 次方左右的基本單位時間。當然實作時會有很大的出入，不過，事實很明顯，採用
快速排序法的確能節省較多的時間。快速排序法是如何動作的呢？以一個較簡單的概念
來解釋，同樣是 23,64,2,73 這個數列，Quick 的作法是這樣的：
  (A)
      取一個數 m 為基準，使得剩下的數字可分為兩堆，第一堆的任一個數字都小於
      等於 m，另一個數列中的任一數字都大於 m。
  (B)
      將 (A) 步驟所分離出的兩個新數列分別再以同樣的方法分割，直到不能再分割
      為止。
    也就是說，QUICK 採用的方法是一個“各個擊破”的方式。
第４．１節　選擇適當的方法
    如前面所提到的，QUICK SORT 的效率高於泡泡排序，但這便表示我們在各種需要
排序資料的場合都應毫不考慮的應用 QUICK SORT 嗎？答案並非肯定的，很簡單的道理：
如果它真是那麼沒用的，它並沒有存在的需要！換句話說，泡泡排序在某些場合可能有用
。而這也是本節討論的重點：適時、適地的選擇適當的演算法。
    設計程式時常常必需要分析我們所要處理資料的特性，而採取適當的演算法，換句話
說，程式設計師應該要瞭解資料與演算法的特性。就以上述的泡泡與快速排序的問題來看
，泡泡排序的執行時間與資料個數的關係呈現出一個指數圖形，而快速排序則呈現一個
對數的關係。如圖所示：
       ︿     　           ︿
   時間│    +         時間│        ********
       │    +             │    ***
       │   +              │  **
       │  +               │ *
       │++                │*
       └──────>     └───────>
                 個數ｎ               個數ｎ
         泡泡排序法            快速排序法
    這表示：當要待排序的資料個數ｎ小於某個範圍時，泡泡排序的效率可能會較快速
排序來得快。例如以統計學生成績來講，統計一個班的成績便適用泡泡排序法，因為通常
學生都在五十人上下；但統計一整個年級的成績就適用快速排序了，因為數量極大。
    由上例我們便知道演算法對程式執行效率的影響。在電腦科學界中，有一個最廣為
人知的定理便是『空間與時間』的相對關係。在一個理想的環境中，當你在選擇演算法及
資料結構時，便需考慮到：到底是花多一點時間來處理資料還是用較多的記憶空間來爭取
較快的速度呢？舉一個明顯的例子，就以『串列』來說，單向串列的每一個節點僅須要
記住指向下一個節點的位址值（當然也可以指向前一個），而雙向串列則須記住前後兩個
節點的位址，因此雙向串列便較單向串列需要更多額外的記憶體。但有得必有所失，雙向
串列在做“巡視（TRAVEL）”動作時較單向串列便要快了。理由是因為“回溯（reverse）
”節點時，必需從頭計算前一個節點的位址。另一個則可舉前面所提的排序法，做“遞迴
式快速排序”時要耗去不少堆疊的空間，甚至有可能造成堆疊過滿的情況，當然解決的
方式不會是採用泡泡排序的，通常我們都會應用非遞迴的 quick sort 來作。另一個在
生活中常見的實例便是發生在碟式中文系統上，你要是設定較少的字型緩衝區，相對主
記憶體會有較多空間可用，但顯示或列印速度便被犧牲了；反之設定較多的緩衝區供中文
應用，顯示速度固然加快了，但剩餘的可用空間反而少了，這個結果常常導致很多套裝
軟體無法執行。
    因此在設計程式時應該考慮將重點放在節省時間還是節省記憶體上。假定你設計一個
在中文系統下執行的軟體，那你可能必需要盡力的節省記憶體了，因為碟式中文系統常要
花去不少記憶空間。但假使你正在設計一個飛機場的航管系統，那便務必求快，否則空難
的發生將會是家常便飯的事......。
    另一個選擇演算法所要考慮的要件是“可讀性”的問題。固然選擇又快又小的演算法
是我們的目標，但各種演算法中，不乏高度數學化、不易為人瞭解的方法。例如字串的
搜索法就難倒不少工程師了。想從這篇文章中找出『演算法』這個字串有什方法呢？一般
人類直覺上會先比較第一個字，相符後再比第二個字......重覆這樣的步驟。這種很笨拙
的『暴力法』的確不太好。有個方法叫 K.M.P., Kunth - Morris - Pratt 法，它的工作
方式是將要比對的字串中每個字元的相對位置，再決定比較失敗時要從那裡繼續工作。
另外還有 BM 法、RK 法，說實話並不容易了解，況且效率不會說有很高的差異（其中
ＲＫ法要用到大量記憶體）。因此很多工程師便乾脆繼續用他的暴力法，而捨棄快、但
不易瞭解的方法。理由是因為這些方法可能造成測試上的困難。另外要程式設計師對於
一個不瞭解的演算法加以實作，可能不能得到很好的編碼（當然這和設計師的經驗有關）
。所以便有人認為寫程式應該採取 KISS 的規則來，KISS 是 Keep It Simple and Stupid
之簡稱，而不是 kiss 的意思，就是讓程式的流程簡單而且“樸拙”，這點和我們的校訓
『勤樸誠勇』好像是相通的。
第４．２節　效率的考量
    提到演算法，就不得不讓我們考慮到效率的問題。一般對效率的定義是指完成某件
工作所需的時間、空間比。我們可以從幾個方面來討論。
（一）與機器的影響
    程式的執行效果在不同電腦上的執行成果，差異是顯而易見的，而改善硬體環境則是
提升軟體效率最明顯的途徑。這也是人類為什麼致力於製造更高速的電腦。例如氣象局
便需要超級電腦，因為明天的天氣總不能等到後天才算出來吧！無論如何，軟體還是應該
盡力地提升本身的效率，而不能依恃硬體的進步。否則仍無法發揮整體應有的效能，甚而
形成系統的浪費。
（二）與程式語言的差異
    程式語言對於軟體效率甚至目標的可行性究竟有多大影響呢？這點在計算機科學界
一直爭論不休。但一般而言，在同樣的結構、相同的演算法，用不同的程式語言所編出的
程式大概會有１５％～２０％的影響。這是不是說用組合語言寫出的作品會有較高的效率
呢？非也非也。良好的計劃直接影響了編碼的品質。同樣的模組若同時以組合語言和高階
結構化語言撰寫，一般的結果通常告訴我們採取組合語言實作將發生悲劇！組合語言通常
會多出１／３的花費（花費指的是用了多少記憶體和時間）。科學家發現“編譯程式”的
好壞才是整個問題的關鍵。現今結構化的編譯器對於“最佳化”的處理已經是相當的優秀
了。各位如果手邊有 Turbo C 2.0 和 MSC 6.0 編譯器的話，不妨自己做個比較，你便會
有驚人的發現。同樣的你也可以要求編譯器產生組合語言程式碼，看看編譯器的處理手法
是不是比你用組合語言撰寫來的高明。但專業的應用上，我們常是用高階語言寫好原始
程式，再用組合語言作低階的最佳化，例如繪圖函式這類對速度要求極高的部份。
    但考慮一下“維護”與“除錯”，結構化程式便較非結構化程式語言甚至組合語言
來得容易的多了！況且，每個程式必然都會發生錯誤！如果因為求一部份模組的“技巧性
”，而導致整體工程的延宕，是很划不來的。
（三）與演算法的影響
    事實上，演算法對於整個程式才具有真正決定性的效率影響，理由在上一節就說過了
，為了避免讀者忘記，請再參考前面的理由。
（四）與軟體結構的影響
    與其說是與軟體結構的影響，倒不如看成整個系統流程的合理性。事實上整個資訊
科學所關心的，不僅僅只是程式該怎麼寫，系統運作的方式也是我們所關心的。因為我們
或是一些機關在處理事情的流程和做法上，常常有重覆而不合理的地方。這種情形或許在
人工作業時期可以諒解，但在電腦化的時代只是多餘的浪費罷了。例如說圖書館的書目
管理，一本書至少須要書名卡、作者卡，還有書籍本身的出借紀錄，而借書人的借書證上
還要登記這個人借書的紀錄。各種資料實在有夠多也有夠雜，但如果在電腦上，你還用
這種方法來為每一本書建立各種檔案，真是浪費記憶體的行為。事實上書籍只要一個資料
檔就可以解決了（理想中），借閱人要查詢資料的程序也簡單多了；借書證上也不必填
一堆東西，一切都是由電腦來整理歸類資料。換句話說，系統的合理性，是影響整個軟體
最基本的變因。

这个世界怎么了？新世纪的二十一条...还敢再丧权辱国一点吗？（妈妈说标题要起的长）
来源： 刘辰的日志
注： FTA=FreeTradeAgreement=自由贸易协定       
　　1、互相将所有的市场全面开放，政府保护的产业，必须也要降低保护，例外的项目也要明确表示。
　　2、一旦开放进口，则不得以任何原因再度禁止进口（即使美国牛肉有疯牛病也不得禁止）