靈修分享:亞略巴古的演講

亞略巴古的演說是使徒行傳一篇非常著名的講道。基督徒往往用這段經文來說明上帝的屬性,同時也會參考這段經文作為和外邦人互動的一個參考方式。最近因為團契查經查到這一段,重新思想後看到了以前沒有考慮過的面向,在這邊記錄一下。

徒17:16-34保羅在雅典等候他們的時候,看見滿城都是偶像,就心裏着急;於是在會堂裏與猶太人和虔敬的人,並每日在市上所遇見的人,辯論。還有伊壁鳩魯和斯多亞兩門的學士,與他爭論。有的說:「這胡言亂語的要說甚麼?」有的說:「他似乎是傳說外邦鬼神的。」這話是因保羅傳講耶穌與復活的道。他們就把他帶到亞略‧巴古,說:「你所講的這新道,我們也可以知道嗎?因為你有些奇怪的事傳到我們耳中,我們願意知道這些事是甚麼意思。」(雅典人和住在那裏的客人都不顧別的事,只將新聞說說聽聽。)
保羅站在亞略‧巴古當中,說:「眾位雅典人哪,我看你們凡事很敬畏鬼神。我遊行的時候,觀看你們所敬拜的,遇見一座壇,上面寫着『未識之神』。你們所不認識而敬拜的,我現在告訴你們。創造宇宙和其中萬物的神,既是天地的主,就不住人手所造的殿,也不用人手服事,好像缺少甚麼;自己倒將生命、氣息、萬物,賜給萬人。他從一本本:有古卷是血脈造出萬族的人,住在全地上,並且預先定準他們的年限和所住的疆界,要叫他們尋求神,或者可以揣摩而得,其實他離我們各人不遠;我們生活、動作、存留,都在乎他。就如你們作詩的,有人說:『我們也是他所生的。』我們既是神所生的,就不當以為神的神性像人用手藝、心思所雕刻的金、銀、石。世人蒙昧無知的時候,神並不監察,如今卻吩咐各處的人都要悔改。因為他已經定了日子,要藉着他所設立的人按公義審判天下,並且叫他從死裏復活,給萬人作可信的憑據。」
眾人聽見從死裏復活的話,就有譏誚他的;又有人說:「我們再聽你講這個吧!」於是保羅從他們當中出去了。 但有幾個人貼近他,信了主,其中有亞略‧巴古的官丟尼修,並一個婦人,名叫大馬哩,還有別人一同信從。

對基督徒來說,保羅這篇講道講的真好,不但講出了上帝的超越性(像是不住人手所造的殿、也不是金銀石的彫刻),也帶出了耶穌基督復活的大能。但最近我才注意到眾人的反應:「眾人聽見從死裏復活的話,就有譏誚他的;又有人說:「我們再聽你講這個吧!」」不曉得你看到這一段有什麼感想?可能我是玻璃心吧,如果我是保羅,我大概會非常非常的難過,看起來似乎沒有人理會這個福音、這篇講道。這篇被基督…

改程式的掙扎

在工作上,如果遇到前人所留下的難看程式,到底該怎麼辦?

所謂的難看程式,指的是會動,能正常運作,但是架構混亂、難以閱讀,甚至還很容易隱藏潛在的危機。本來嘛,這種程式不動它也就是了,可是偏偏又要在上面提供新的功能,這時候,身為接手人員,到底應該怎麼做呢?是大破大立,還是在危樓上持續建造呢?

目前在資策會工作這兩年,總共遇過兩次(其實也才遇過兩年,也就是一年一次囉)。這兩次,我的作法都是~砍掉重練。第一年,因為是科專計畫,只要呈現給長官和經濟部的官員看,再加上整個計畫的人力不過三個,在達成一致決議後,花了幾個月的時間將東西完工。雖然做的沒有很出色,但穩定性已經大幅提昇(當然是跟之前的東西比),而且也在過程中學到了不少東西(感謝當初的另外兩位同仁)。去年的計畫,我也做了同樣的決定,但這次不一樣了...這次不但是科專的呈現,還有廠商的產品要交付,互通性測試要通過,無止盡的「死線」...而且整天還要面對測試人員的壓力。對測試人員來說,他們不會看到程式碼,他們只在乎外在的功能,他們在意功能是否完善,特殊的CASE是否能安然度過,新的功能運作如何,但卻不會在意程式的維護性如何、還有程式內有多少的隱藏危機...

打掉重建,我自認將程式改的更容易閱讀,也更容易維護或是加上新功能,但是這段改程式的陣痛期,卻是測試人員所無法瞭解的(當然了,他們也有自己的時程壓力)。反而,原先會動的功能,可能因為程式重建過程中一些粗心大意的疏漏(還不少),反而會無法運作。他們只會無法理解的問說:「為什麼?為什麼要這樣改,這樣怎麼測試?」。還好,因為另外一個團對正好再進行大規模的更動,我獲得喘息的機會...今天,大部分的問題已經解決了...甚下就是開始進行新功能的加添、原有 BUG 的修正,還有客制化的動作。但我一直在問我自己,如果時間往前推幾個月,我會做出這樣的決定嗎?

幾個禮拜以前,我到簽約廠商那裡,進行程式碼的講解。講解的程式碼,是舊的那一份。坦白說,我講得很膽戰心驚。我一向不害怕報告,但是我害怕報告自己都無法理解的東西。原有的程式碼,其實架構設計的很...我很擔心廠商問我架構的問題,以及這樣設計的緣由,所以我隨便找了一個理由就帶過去了,好險他們似乎只要東西會動就好(感覺他們根本沒在研究那一塊程式,看來他們的產品出貨後,有可能會被一堆客戶罵吧)交那樣的程式過去,我很羞愧,而且因為接手了,還要掛我的名字...

再來一次,我會怎麼選擇?在難看的架構,也不是不能維護、更新,只要能動(不要太快陣亡),撐過這段期間,之後再交給下一個可憐的學弟接手就好了。這樣也是一種策略...很吸引人,畢竟我只要東補西補,不要翻修,勉強過去即可。測試人員也不會圍在我的周圍催促(畢竟大部分的東西之前都測過了,應該說,東補西補過了)之後,想辦法脫手...我還可以專心研究自己想研究的東西...

到底該怎麼選擇呢?

「徘徊在利與義的邊緣,天、你怎麼還不說話? 」(火鳳燎原)

用這句話來說好像太誇張了,不過我真的陷入了思考...

聽說前幾年,我的一位離職同事跟我幹過同樣的事,不過還更嚴重,將整個 stacking protocol 翻掉重新設計(這樣說應該就知道是誰了吧),當然他的工作比我還要複雜,他的時間也比我還多的感覺(除了交付廠商外沒什麼一堆外加的任務),「昔人日已遠,典範在夙昔」,我又陷入思考了...

以程式設計師來說,我的經驗很淺,設計的架構也不怎麼樣(所以很佩服一些同事的經驗),但起碼,我希望我能做到逐漸進步,將自己的程式碼越修越穩定。這是第一次,我想要當上位決策者,給予開發人員審視程式碼的時間,擋掉一些多餘額外的負擔跟壓力...又或是,乾脆離開這種環境,回到學術界呢...

Next time, I think I will make the same decision~

留言

這個網誌中的熱門文章

如何將Linux打造成OpenFlow Switch:Openvswitch

我弟家的新居感恩禮拜分享:善頌善禱

如何利用 Wireshark 來監聽 IEEE 802.11 的管理封包