 |
 |
 |
62. 同人 於 2007/08/10 13:42 回應
我的女兒當然比在座的各位都要年輕，她只有七個月大呀。不過年齡並不代表什麼，just do it。
讚? 0 個人喜歡這個留言
|
|
|
 |
|
|
|
61. LUKE 於 2007/08/10 13:01 回應
呵呵,有機會到我的BLOG看看囉! 是的;我是提出了一些想法,我們也在試圖改變自己,這篇文章的觀點並非抱怨而是指出事實,事實上;我們常問自己,"寫程式"這個工作,我能夠做到幾歲(可能你已離開寫程式這個領域),這個思維正是業界不尊重專業的寫照(我在BLOG內也寫到類似的觀點),但在此同時我們應該反思,我們自己的專業在哪裡,應該要重新開始重視課堂上的那些基礎工作,當我重新靠近學術殿堂,我發現我找到了答案,寫程式是可以寫到終老的,即使比你虛長幾歲(看照片我應該比你老,呵呵...),我相信我對這個領域還像當初一樣懷抱夢想,但是築夢必須踏實,只有這些基礎的東西應該能夠讓技術人員更踏實才是
管理與技能都重要,但管理不是本質上的問題,能夠先把本質上的問題解決,管理才能有效;前文第三段提到的觀點完全同意,但是請思考一個問題,當你沒有好的技術能力產出產品(專案)時,根本不會有所謂的"市場及客戶的觀點",這恰好與之前的問題定義與條件成立的順序相關論述相互輝映,事實上只靠管理 業務或是行銷是沒有辦法讓一個不堪使用的東西變成有用的,這些除了技術本體以外的部分都重要,但是得要先有一個強壯且穩固的東西,才能做出加乘的效果,自己做的東西總要先講求不傷身體是吧!總不會是做越多罵越多,那麼再好的管理都將失效
讚?0 個人喜歡這個留言
|
|
|
|
|
|
|
60. 同人 於 2007/08/10 11:52 回應
同人從學校畢業後就在軟體產業一直堅持到現在，很能理解大多數的開發者對大環境的抱怨與失望，我可以體會他們說的，但我更相信”如果對現狀不滿意，改變它，但別抱怨”。
很多技術人都非常有想法，但卻沒有勇氣實現理想（見同人在cnet投稿的另一篇文章：〈羅馬不是一天造成的〉），好的設計概念與技術只會在茶餘飯後的閒聊中言及，同時伴隨對公司或產業的抱怨，頗有懷才不遇之嘆。
但換個角度想一想，你認為技術專業很重要，但有沒有思考過市場及客戶的觀點，專業管理最重要的是整合及快速回應的能力，如果技術者掌握的技術無法整合至業務及客戶面，這個技術並不是專業而負擔。
態度沒有用嗎？我不認為如此。態度決定一個人的成功，而非成功後才改變態度。如果開發者缺少面對現實的態度，技術就不可能與業務或客戶面適當著周旋，管理者也一樣，少了面對現實態度，只會做出無效的管理行為，因為他不知道技術、業務與客戶面如何達到平衡。所以堅持態度是最重要的，態度上堅持做對的事才是真正的專業。
寫這篇文章，不願偏向管理者或開發者的角度看事情，有些讀者以為我在批判開發者，但上篇我對管理者的批判也不少呀！管理者與技術者關切的事物不同，但唯有充分整合，尋求平衡之道，這才是真正的專業，這也是本篇文章真正的旨趣。
讚?0 個人喜歡這個留言
|
|
|
|
|
|
|
59. LUKE 於 2007/08/10 10:26 回應
事實上我們一直都在使用臆測未證實的資訊來解決問題,我們的科學一直假設一些我們自己未證實的已知,不知道這是不是也被稱為道聽塗說? 不過這有點扯遠了
歐!原來當在談邏輯/functional(理論)時被視為不懂imperative language或是沒開發過大型系統或是與實務脫節?? 呵呵...理論與實務應該要並重,技術也該博而廣之最後才是深耕,學術上的東西本來就可以務實的應用在現實的環境裡,只是大部分的人訴諸高閣,在業界有很多工程師,一開始就不重視演算法不重視理論視為無物;很多做系統整合的公司,只有一項技能那就是委外,只有一項法寶,那就是培養了一堆很棒的專案管理師,而現實情況下有半數的工程師只懂怎摩用sql寫程式,事實上他們只懂得sql語法,或是只知道如何使用元件接收rs232 rs458的訊號,其他就是拉拉畫面...現在的工具真的讓程式看起來像是個大玩具,而大型專案卻不是一個玩具,這是絕大部份專案失敗的主要理由之一,也是本質上的問題,管理當然也是問題;但是,管理沒辦法解決團隊中本質的的問題,管理可以提升軟體品質,但你沒有辦法透過管理讓每個工程師突破他所面臨的技術問題,或是透過管理讓一個新手變成真正的熟手,再好的專案管理也抵擋不了人事上的異動,因此;文中提到"開發者深入了解問題之後，選擇可用的技術，並加以不斷的調適、熟練的過程" 這一段寫的正確,但是卻沒意義,當本質上技術人員的技術水準低落,那麼它能選擇使用的技術就只有那麼少數幾種,產生問題的機率就大增了,而且專案的過程通常都沒有練兵的機會,很多工程師一開始 槍沒拿穩就上戰場(這是公司的成本考量?),所以他們是在戰場上才真正學會使用槍隻,在戰場上才看到大砲,等武器都能正確使用回首已百年身,那麼專案的成功機率有多高?可能一開始用看的就能評估出來,不過這可能又是一場什麼是專案與什麼是產品的論戰,可能是個人見識淺薄基本上我沒看過成功的專案,只看過 "最後" 能work的專案,那些不正確的邏輯與bugs,最後是被其他人或是高手重構擬平了,但是卻是千瘡百孔,由這裡莫名的跳到那裡;一堆的flag 與註解說明當初未何這樣又那樣,但再也沒人敢碰那些高超的技能,於是看起來是能work,但是流竄在程式碼裡的毒瘤,不知道哪一天會以另一種形式爆發,整個維護的門檻變的很高,呵呵這又正中下懷,因為這樣只有一家軟體公司堪稱有資格承接系統維護的業務,其實發表這麼多的觀點,我想表達的只有一件事,先重視那些被遺忘的 最基本 的東西,再配合管理上的議題,可以讓專案做的更好,讓專業的問題回到專業;認同與尊重專業,情況可能會比公司拿到任何認證重要的多(請注意!這個意思不是說公司的認證制度不重要),總結! 高鐵的問題是台灣整個軟體發展的縮影,這並不是某個公司的問題,而是本質上從業人員的素質與大環境的問題,不管寫程式工藝或工程,寫程式是不是就是寫證明,假設問題是不是等於猜問題...理論與實務同等重要,偏廢一方最後只會淪落如是結果
讚?0 個人喜歡這個留言
|
|
|
|
|
|
|
58. 同人 於 2007/08/09 23:23 回應
同人相信，知之為知之，不知為不知，是知也。
我聽過很多道聽途說，也大概知道問題可能在那一方面，但個人不喜歡臆測未證實的消息，而且那也不是本篇文章的目的，高鐵售票系統的問題已漸漸收斂了，而且網路訂票也正在進行當中。
至於本篇文章及我所回應的都不是純理論的學術，而是個人實務心得與體會，其實軟體開發本來就是實務中的理論呀，單談理論不會深入，而是要有實務經驗加以支持呀。
讚?0 個人喜歡這個留言
|
|
|
|
|
|
|
55.匿名 於 2007/08/08 17:37 回應
恩! 你說的這幾個語言都比較偏重商業上使用的語言(不能這麼形容),但是我不知道該怎麼形容,其實我剛剛說的是比較像proof language (Coq...) 或是functional language,恩!lisp 有那麼一點味道,其實我沒碰過lisp,他應該也不屬於functional language???(這是打問號的,記憶中好像是又好像不是,抱歉!我真的忘了),如果你熟ML 或是haskell 這類的東西,可能你會更有感覺???(也許吧),不過這裡面多了很多問號,如果你對那句話有興趣;可能要探究的就是這些問號裡的隻字片語囉
讚?0 個人喜歡這個留言
|
|
|
|
|
|
|
54. 同人 於 2007/08/08 17:20 回應
接觸 coding 近 20 年，該用過的程式語言都用過了，除了BASIC, C/C++, PASCAL, FORTRAN, COBOL 外，包括 lisp 及 prolog 等語言也摸過一點。其實程式語言這種東西，一段時間沒用就會忘記它的語法，但觀念是相通的，事實上，程式語言我當它是實作的工具，只要有 concept 就有方法可以實作，當然證明本身就是一種 concept，我不是質疑證明這檔事，而是傾向於程式語言在解決問題的抽象化思考。
讚?0 個人喜歡這個留言
|
|
|
|
|
|
|
52.匿名 於 2007/08/08 17:04 回應
其實有很多語言是可以在裡面寫證明,然後由証明推倒結果的,比如: 一些語言可以在程式內,先證明(a+b)+c=a+(b+c) 然後在應用這個證明,事實上寫一個程式就像是寫一個證明,這無庸置疑阿!不對!這個觀念看似簡單,但是似乎不太容易證明,我不會證明寫程式就像是寫證明這個邏輯讓你明白,我的功力還不到那邊,所以只能描述這個結果,而這個問題本身是可以證明的,如果你熟悉functional language...實務上你可以找到例子,邏輯上這是可以證明這個觀點,我想你們比較熟悉的可能是java 或是.net 這類的東西,可惜這類的東西可能比較感覺不出來邏輯與語言的關係
讚?0 個人喜歡這個留言
|
|
|
|
|
|
|
|
|
|
|
| 
