目前分類:【電腦】【人員觀念問題】 (15)

瀏覽方式: 標題列表 簡短摘要

轉載自: http://www.vcroad.net/ (棗子原創 wutao8@263.net)



從退伍以後就覺得自己想要走軟體這條路,後來前三年的工作跟軟體無關,轉職才又找到了可以說跟軟體有關的工作,幹了一年多的程式人員,後來就很少編程絕大多數都在做SA/SD的工作。
其實我還是喜歡寫程式,其實說真的寫程式沒有高手,文中談到的很多都是我們不斷的在犯錯的地方,尤其現在我希望公司同仁能在軟體流程上多加強一點,不然每次出版(Release)的軟體總是問題一堆品質不佳,能怪誰呢?
當然規劃趕不上變化,時間永遠不夠,但是一個好的程式人員還是要對的起自己交出來的品質,而不是東西出來就好。
我老不懂我們所謂的軟體程式人員應該如何稱呼?程式設計師、軟體工程師?
如果是程式設計,表示對於該語言有一個設計上的能力,那也不該無限上綱的表現個人不好的風格吧!!(如文中第七點所言)邏輯上不該出現的錯誤,遇到問題沒有追根究底的精神祇希望想個辦法避過就可以了。你這樣的設計能稱的上專業嗎?
軟體工程師,如果是軟體的工程師....那軟體工程該有的流程及步驟就不應該省略,也不應該抱怨才對,因為這是軟體該有的流程,好比軟體從業人員很喜歡拿軟體流程跟建築行業比較。如果是這樣那流程上的堅持是不是應該的呢?

還是搞程式的人員就如同對岸翻譯-編程人員-就是把程式編寫出來而已....聽起來有點類似一個文字輸入人員的感覺~~~如果你覺得你是這樣的人,那會不會對於花這麼多年學寫程式跟一個冷冰冰的電腦溝通,結果自己不過是一個外星語的打字人員而已。
寫程式如果只是你很不願意的工作或者混口飯吃,我們真的要說我們被替代的機會太高了。


看了下面的這篇文章,深有感觸,棗子碰到的問題也是我們大多數程式設計師的通病,也許我們大多數人都只是在做一些比較小型的軟件,對軟件運行的效率不在乎,就算對速度和效率在乎的也可能是一些在資料庫操作方面的。大家看完了,也許會有很多感想,但這只是我同意棗子的個人觀點。

做為一名大四的學生,我面試過不少的單位,有成功的也有失敗的,但是對我來說所有的失敗在某種意義上都是一種成功,特別是我下面寫的這些,寫這篇文章的時候,我已經簽了南京的一家軟件公司,但是想起今年 2 月 21 日我面試蘇州台灣的IT公司的經歷聯想到我們現在學習程式設計的一些情況我真的深有感觸,這次面試使我深深的體會到了失敗但也收穫了很多。

我要說的將分成三部分:

1.是我面試的具體經過
2.是由面試想到的
3.現今我應該做的

當然這些話很大程度上是我個人的意見,不可能完全得到大家的贊同,所以在某些觀點上如果哪位朋友覺得跟我的有很大出入,請不要介意,也不要對我攻擊,就當我沒有說過,歡迎和我聯繫共同探討這些問題!

1.面試經過

大約在年前我接到了台灣瑞晟 (Realtek) 蘇州公司的面試通知,通知我 2 月 21 日到蘇州工業園區面試,接到面試後的幾天我把一些專業課溫習了一遍,特別是 C++ 和數據結構,由於大學幾年裡,我一直專研這些方面,加上通過了高級程式設計師的考試,對於一些常用的算法我差不多也達到了爛熟於胸的地步,當時的感覺是如果問了我這些方面的問題我應該是沒有問題的!

21 日那天我被安排在 4:30 面試,由一位技術人員單獨給我面試,在問了一些簡單的問題之後他給我出了一道程式設計題目,題目是這樣的(由於具體面試的題目比較煩瑣,我將其核心思想提取出來分解成了兩個獨立的簡單的問題,有可能問題分解的不當,請大家見諒,實際面試了一個的問題但比其複雜很多,而且涉及一些高等數學變換):

1) 寫一個函數計算當參數為 n(n很大) 時的值 1-2+3-4+5-6+7......+n

哼,我的心裡冷笑一聲!沒想到這麼簡單,我有點緊張的心情頓時放鬆起來!於是很快我給出我的解法:

long fn(long n) { 

    long temp=0; 

    int i,flag=1; 

    if(n<=0) { 

        printf("error: n must > 0); 

        exit(1); 

    } 

    for(i=1;i<=n;i++) { 

        temp=temp+flag*i; 

        flag=(-1)*flag; 

    } 

    return temp; 




搞定!當我用期待的目光看著面試官的時候,他微笑著跟我說,執行結果肯定是沒有問題!但當 n 很大的時候我這個程式執行效率很低,在嵌入式系統的開發中,程式的運行效率很重要,能讓CPU少執行一條指令都是好的,他讓我看看這個程式還有什麼可以修改的地方,把程式優化一下!

聽了這些話,我的心情當時變的有點沉重,沒想到他的要求很嚴格,之後我對程式進行了嚴格的分析,給出了改進了的方案!

long fn(long n) { 

    long temp=0; 

    int j=1,i=1,flag=1; 

    if(n<=0) { 

        printf("error: n must > 0); 

        exit(1); 

    } 

    while(j<=n) { 

        temp=temp+i; 

        i=-i; 

        i>0?i++:i--; 

        j++; 

    } 

    return temp; 

}


雖然我不敢保證我這個算法是最優的,但是比起上一個程式,我將所有涉及到乘法指令的語句改為執行加法指令,既達到要題目的要求而且運算時間上縮短了很多!而代價僅僅是增加了一個整型變數!

但是我現在的信心已經受了一點打擊,我將信將疑的看者面試官,他還是微笑著跟我說:「不錯,這個程式確實在效率上有的很大的提高!」我心裡一陣暗喜!

但他接著說這個程式仍然不能達到他的要求,要我給出更優的方案!天啊!還有優化!我當時真的有點崩潰了,想了一會後,我請求他給出他的方案!然後他很爽快的給出了他的程式!

long fn(long n) { 

    if(n<=0) { 

        printf("error: n must > 0); 

        exit(1); 

    } 

    if(0==n%2) 

        return (n/2)*(-1); 

    else 

        return (n/2)*(-1)+n; 




搞笑,當時我目瞪口呆,沒想到他是這個意思,這麼簡單的代碼我真的不會寫嗎,但是我為什麼沒有往那方面上想呢!

他說的沒有錯,在 n 很大很大的時候這三個程式運行時間的差別簡直是天壤之別!

當我剛想開口說點什麼的時候,他卻先開口了:「不要認為 CPU 運算速度快就把所有的問題都推給它去做,程式設計師應該將代碼優化再優化,我們自己能做的決不要讓 CPU 做,因為 CPU 是為用戶服務的,不是為我們程式設計師服務的!」

多麼精闢的語言,我已經不想再說什麼了!

接著是第二個問題:

2) 他要求我用一種技巧性的程式設計方法來用一個函數實現兩個函數的功能 n 為如:fn1(n)=n/2!+n/3!+n/4!+n/5!+n/6!

fn2(n)=n/5!+n/6!+n/7!+n/8!+n/9! 現在用一個函數 fn(int n,int flag) 實現,當 flag 為 0 時,實現 fn1 功能,如果flag 為 1 時實現 fn2 功能!他的要求還是效率,效率,效率!

說實在話,如果我心情好的話我應該能給出一種比較好的算法,但我那時真的沒有什麼心思再想了,我在紙上胡亂畫了一些諸如 6!=6*5! 的公式後直截了當的跟他說要他給出他的答案!

面試官也沒有說什麼,給出了他的思路:

定義一個二維數組 float t[2][5] 存入 [2!,3!,4!,5!,6!],[5!,6!,7!,8!,9!] 然後給出一個循環:

for(i=0;i<6;i++) { 

    temp=temp+n/t[flag]; 




最後得到計算值!

呵呵,典型的空間換時間的算法!

這些總共花了 50 分鍾的時間,還有十分鍾我就跟他很隨意的聊聊天,聊了一些程式設計以及生活的問題,那時的我已經很放鬆了,因為我知道這次面試結果只有一個:失敗。

5:30 的時候面試官要我等通知,於是我離開了他們公司。這就是面試的整個經過!

2.由面試想到的

真的是很失敗啊!我記得那天下好大的雨,氣溫也很低,我邊走邊想,從 5:30 一直走到 7:30,全身都濕透了,又冷又餓,但是我只是一直走,腦子裡面充滿了疑惑,我也想讓雨把自己淋醒!看到這裡有些朋友可能覺得那些面試題目不算什麼如果讓自己做的話肯定能全部答對,我肯定相信你,因為我從未懷疑過中國程式設計師的能力,我認為中國有世界上最好的程式設計師,我也從未認為自己是高手,所以我做不出來不代表中國程式設計師比台灣或者別的地方的程式設計師差,所以我就從我的角度,我的所見所想來談一些感想:

不錯全世界都有優秀的程式設計師,中國也不例外,但是我疑惑的是:到底中國和台灣或者國外的優秀的程式設計師的比例到底是多少?台灣我不知道,中國 100 個程式設計師裡有幾個是優秀的呢?

我根本算不上,從上面的表現就足以說明一切了!是 1 個?5 個?10 個?50 個?這個數字我不敢亂猜,恐遭網友一頓痛罵,那麼我們國內有多少人學習計算機呢?拿我們學校來說,計算機 97 級 4 個班,98 級 5 個班,99 級 10 個班,2000 級 17 個班,人多了,老師怎麼辦?我們學校的做法是讓研究生上課,然後呢?補考一抓一大把,大把大把的補考費落入了學校的口袋,還說現在的學生素質低!

真是好笑,我都不知道學校這麼做是為了什麼,為國內培養大量的程式設計師嗎?學生們能真正學到計算機知識嗎?好了,我敢講,在我們學校學習程式設計學生和優秀程式設計師(注意我指的是優秀,只會編幾個糟爛程式的人算不上)的比例應該是 100:0.1。

在這種比例下雖然我們中國學習程式設計的人鋪天蓋地,但是想想有多少個人能真正為中國軟件業發展作出貢獻,有多少人能真正寫出優秀的程式名揚海外!

我從學習程式設計以來,不管是自學還是老師指導,從來都是解決問題就好,編出程式來就行,我的疑惑是:我們有真正的強調過程式的效率,程式的質量嗎?我們有仔細分析過我們寫的東西,看看有沒有可以改進的地方,看看有沒有簡單的方法來達到同樣的目的呢?

我捫心自問,我發現,我從來沒有對我寫出來的程式進行過優化,最多就是進行詳細的測試,然後 Debug,但是這就足夠了嗎?

這些天我偶爾發現我曾經寫過的一個遊戲,那是一年前我剛加入 www.vcroad.net 做為其中一員時候,感覺應該拿點東西出來,然後花了一個星期的時間寫出來的!

程式不算複雜,但是用到了不少數據結構的東西,也用到了一些精彩的算法,加上 windows 的界面和遊戲的可玩性,寫完後受到了不少好評,我當時真的很佩服自己!

但是現在看呢:沒有一句註釋,好多醜陋的函數名,比如:void chushihua(),好多沒有必要的變數,可以用簡單語句完成工作的我使用華麗的算法,大量使用全局變數...

說不好聽的話,六百多行的程式除了能運行之外就是一陀屎!

如果一年前我能聽到一些反面意見的話,大概我能早一點覺悟,但是自從原代碼在網站發佈以來聽到的都是讚美之詞,沒有一個人向我提出程式改進的意見,這又說明了一個什麼問題呢?很值得思考啊!

還有一個疑惑是:我們說的和做的真的一樣嗎?

我在學校的時候曾經受學院指派承辦過一個計算機大賽,請了一個老師出決賽的題目,主要是一些算法題目,這個老師可能是我上大學以來唯一敬佩的老師了,從程式調試到打分,對於每個程式都仔細分析其時間效率和空間效率,然後綜合打分,四十個人的卷子,老師從下午三點一直調試到晚上十點,在有些寫的精彩的語句後還加上批註。

我真是高興很遇到這樣的老師並且和他做深入的交流,但在事後,卻發生了一件不愉快的事,在比賽中獲得第二名的學生找到我,說他程式全部調試成功應該給他滿分,並且應該得第一,我說不過他,最後調出了他的原程式和第一名的原程式對比,不錯,兩個程式都運行的很好,這時,那個同學開口了:「我的程式寫的十分簡捷明瞭,僅僅數行就完成了題目要求,而他的卻寫了一大堆,為什麼給他的分多過給我的分。」

我當時很是氣憤,如果不是老師負責的話,那麼現在第一名和第二名的位置真的要互調了,拜託,不是程式的行數越少程式的質量就越高,我記得我跟他大談這方面的道理,最後說服他了!

哈哈,但是我,只能說說而已,我不知道還有多少人一樣,說起來頭頭是道,但心裡卻壓根就從未重視過它!

3.我打算做的

其實那天我想到的遠不止上面那麼多,但是我不想再說了,因為我猜想看這篇文章的網友大概都有一肚子的感想,一肚子的抱怨,借用這篇文章發洩可不是我想達到的目的,在上面我把自己罵的一文不值也不是妄自菲薄,但是在某些方面我真的做錯了,或者說是偏離了正確方向,現在是矯正方向和重整旗鼓的時候了,就像我前面說過的,我相信中國有世界上最好的程式設計師,我也相信我的水準不會一直保持現狀,我現在就收拾起牢騷真正的實幹起來!

真的很巧,就寫到這裡的時候我在網上偶爾發現了這篇手冊,我不知道這暗示著什麼,但是我想如果我照下面這個基本原則一直踏實做下去,我一定會實現我的理想 - 一名優秀的軟件設計師!

 


文章標籤

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

引述

下班不談公事
 
 
上班已經一年多了,時間真的過得好快呀,
今天主管跟我說,我從第一次來台北這邊,踏入外匯這個部門,也過了10個月,快一年了,
跟我在台中資訊室的時間差不多了。
 
回憶剛開始在台中學習維護系統、在台北學外匯的時期,其實壓力都滿大的,
畢竟新人什麼都不懂,那時真的是回家都在繼續寫程式、讀外匯的書,
甚至有時偷偷把工作帶回家做,或是跑到公司自動加班,
很希望自己快點進入狀況,跟資深的同事一樣,在維護系統上更有效率。
 
也許是台大畢業的,主管都有種莫名的期待,覺得很多事對我而言,
應該很EASY,我應該要做得比別人更快更好,所以....我們還是要努力點,

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

創意?!產品研發線

轉載自 : http://www.wretch.cc/blog/hercula/11214874

【建議】  命令你這麼做,可是又不想為你做出來的結果負責任時,就會說「我只是給你建議」。










幻紫芊芊 發表在 痞客邦 留言(0) 人氣()


資料來源:http://www.youtube.com/watch?v=5VASuaFxaew
   

覺得應該給大家看看。
不斷的變更需求,不去試著了解客戶到底要的是什麼?
,花費大量的時間成本去研發,錯失了他原有功能所要表達的目的及功能,
最後產出的只是無消費者會想要去購買使用的廢物產品。


幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

一個好玩的排行榜,就是當程式不會動或有問題的時候,通常程式設計師的回答如下:
  • 第 20 名:這很奇怪喔。
  • 第 19 名:以前從來不會這樣啊!
  • 第 18 名:昨天明明會動的啊!
  • 第 17 名:怎麼可能~
  • 第 16 名:這一定是機器的問題。
  • 第 15 名:你到底是打了什麼才讓程式當掉的?
  • 第 14 名:一定是你的資料有問題。
  • 第 13 名:我已經好幾個禮拜沒碰那一段程式了。
  • 第 12 名:你一定是用到舊版了。
  • 第 11 名:一定是巧合!為什麼這種壞運氣只讓你碰上。
  • 第 10 名:我不可能什麼功能都測試到吧,有 bug 是正常的!
  • 第 9 名:這個不可能是那個的原始碼!
  • 第 8 名:這程式應該是會動的,只是我寫好後還沒做測試。
  • 第 7 名:可惡!一定有人改了我的程式。
  • 第 6 名:你有檢查過你的電腦有沒有病毒嗎?
  • 第 5 名:儘管這功能還不能動啦,你覺得他如何?
  • 第 4 名:在你的系統不能用那一個版本的程式啦!
  • 第 3 名:你幹嘛要那樣操作,都是你的問題。
  • 第 2 名:程式發生問題時你在哪裡?
  • 第 1 名:在我的機器明明就可以動啊!
  • 萬用答案:電腦請重開,應該就會好了!

另外,工程師常說的話還有以下幾項,你也可以看看你常說哪幾項:

  • 25.都這樣了,還不work,搞什麼?
  • 24.你可能中毒了喔。
  • 23.一定是有人改了我的程式。
  • 22.已經可以了,不過還沒測試過喔。
  • 21.都好了啊,還沒測試過就是了。
  • 20.我不是已經修好了嗎?
  • 19.這個不能那個。(THIS can't do THAT.)
  • 18.我一個人又測不完!
  • 17.怎麼這麼衰!
  • 16.沒問題,馬上好!
  • 15.當然,當然,我再修一修就可以了。
  • 14.快好了,快好了。
  • 13.好啦,只不過一個小功能嘛!
  • 12.你拿錯執行檔了。
  • 11.可以,可以,來得及。
  • 10.我可沒動過這個模組喔!
  • 9.你的測試資料一定有錯!(我那邊不會啊!)
  • 8.不可以這樣操作的啦!
  • 7.你的作業系統(驅動程式)升級了沒有啊?
  • 6.機器好像壞了。
  • 5.怎麼可能?!
  • 4.哦,這程式還要改一下。
  • 3.昨天還好好的呀!
  • 2.我從來不知道有這種事。
  • 1.奇怪...
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • 最後,也是最常用的
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • .
  • 0.更

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

朋友分享給我的...
* 所謂理論,就是我們知道為什麼,但是什麼都行不通;
* 所謂實務,就是我們不知道為什麼,但是都行得通;
* 本公司理論與實務已經結合為一: 什麼事都行不通,而且沒有人知道為什麼。

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

 

引述

你的價值在哪裡?

分享一篇文章

------------------------------------

展現價值

RUN!PC 月刊 文/彭靖灝(K2.net大中華區技術總監)

 

最近公司為客戶執行一個專案,在這個案子中,負責執行的同事很努力的滿足客戶的要求,儘可能的做到隨叫隨到,不斷的加班好設計出客戶想要的功能。然而因為時間的延宕,讓我們對專案的執行方式產生質疑。在執行專案的過程中,我們曾不只一次提醒同事答應客戶的太多,時間是專案執行最寶貴的資源。在幾經波折之後,專案終於完成上線。

在系統上線之後,我們拜訪客戶,針對主要的承辦人和主管做了簡單的問卷調查。諮詢的結果,出乎大家的預期。雖然我們不斷的滿足客戶,儘可能的配合,但是客戶整體而言,對於執行者是不滿意的。客戶對於產品是認可的,對於專案最終上線的成果也是滿意的,惟獨對執行的人員表現不滿意,這確實是個直覺上不合常理,但卻一點也不令我意外的結果。

不意外的原因很簡單, 因為我們沒有做對事,沒有做到令客戶認可價值的事。當我們努力去滿足客戶的需求時,所有的念頭、主意都是客戶的。我們只是客戶想法下的執行者,從客戶的角度來看,他才是真正推動事情的人。但是客戶當初把專案交給我們,付出高於一般軟體專案的代價的原因,是期望我們能在整個過程中產生一些建設性的價值為他們的環境注入一些新的想法,帶入一些在別的企業中累積下來的最佳經驗

客戶端的高層主管在問卷中的一個反應是最值得注意的:「執行者並未提供我們太多建議,像個工程師,不像個顧問。」這句話一針見血的指出我們專案執行上的問題。從客戶的角度,他所付出的代價是為了換取專業顧問等級的價值,這個價值的展現不在於完全滿足客戶的需求,而在於能針對實務操作的情境,從商務的角度提供適當的建議供客戶思考並判斷。

最慘的是,我們的執行者原本就該展現身為顧問的價值,最後卻落得個只有工程師(這時候工程師三個字成為一種負面的字眼)價值的結果,是典型的「賠了夫人又折兵」。

做為一個IT人,要想工作愉快,一定要弄清楚自己的價值在那裡,並且努力展現價值。這個價值,不單是我們自己眼中的,也要考慮服務對象眼中的。因為IT行業本質就是個服務業,服務對象的感受才是自己的價值所在。

 

幻紫芊芊 發表在 痞客邦 留言(4) 人氣()

1.其實寫程式的要訣只有一個字,一字記之曰"心"..
 
2.寫程式的精華在於:
程式有多少寫多少、註解有多少放多少,
最好讓PM煩到不想看;
文字有多大用多大、class有多少丟多少,
最好讓PM多到不想翻;
 
3.我是中國程式人員訓練學院第105屆畢業生,我的程式寫得很好呢
 
4.【程式寫得好、要飯要到老】....
 
5.「給你們這幫笨蛋猜到,我還叫"程式人員"嗎?」
我真是猜不透你啊!"程式人員"……
太棒了, 程式人員好棒

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

小公司接專案,時程與成本(報價)是第一優先考量,之後才是品質,這樣講或者不好聽,但卻是現實的情況。不是說品質不重要,但是由於在報價階段,品質很難量化,所以比較不會被強調。而幾家叫的出名號的大公司可以用他們公司的品牌形象轉換成品質的實際價值,這點也是付出很多努力及很多時間才得到的成果。

品質的定義
品質指的是「Exactly」 what I expect,不是「More/Less」than what I expect。這裡舉兩個例子:

一個是一家印度外包軟體公司,承接台灣廠商的程式設計外包案,有一次,台灣這裡的系統分析師想確認印度公司的品質,便故意在規格裡寫了一個明顯的邏輯錯誤,看看印度公司會如何處理,結果,印度公司交付的程式碼,並沒有修正那個明顯的錯誤,而是完完全全的符合那個錯誤。這就是品質。

另一個例子是出口到日本的香蕉,日本從台灣進口香蕉,對於香蕉的外觀、大小…等等都有明確的規範,有一次有一批出口的香蕉全部被退回,原因是香蕉的大小,超過日本方面的規定,但問題是台灣方面並沒有提高售價,也就是說「用同樣的錢買到更大根的香蕉」,照一般常理應該日本方面會覺得「賺到」,但是卻被退回,為什麼呢?後來了解原因,日本方面要求的大小是經過研究之後日本人覺得的「一人份」大小,超過那個大小一點點,會導致「一個人吃太多,兩個人吃又太少」而影響到消費者購買意願(即使便宜也沒差),所以,所謂的品質不必然是「物美價廉」,而是「我願意出錢買剛好符合我的期待的東西」。

品質不是絕對
出廠的1000顆硬碟,買到其中990顆正常硬碟的人認為品質很好;而不幸買到那有問題的10顆硬碟的人就會覺得品質很差。到同樣一家餐廳吃飯,如果服務生老是幫A桌倒水,幫B桌上菜卻慢的可以,回去之後A桌客人對餐廳服務讚不絕口,而B桌客戶卻會將餐廳列為拒絕往來戶。

品質的入門與進階
入門者著重在「成果」的品質;進階者重在「過程」的品質。
=========================================================

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

英君分享-約耳談軟體(Joel on Software)》翻譯計畫
全球的熱心志願者們已經將《約耳談軟體》翻譯成超過三十種語言版本
http://local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81
有很多不錯的好書喔

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

葉木金 2008/02/21 05:00
http://www.zdnet.com.tw/enterprise/column/softwaredev/0,2000087962,20127698,00.htm
http://www.zdnet.com.tw/enterprise/column/softwaredev/0,2000087962,20127699,00.htm
客戶所知道的並不是軟體需求(requirements),他們對系統的觀點只能顯露出他們對系統的需要(needs)。需要是抽象而片斷的,本身是非結構化的,而可用的軟體需求卻必須是具體而完整一致的,具備結構化的特性。

因此,如果開發者沒有針對客戶需要分析他們的問題,設計解決方案,只是直接把客戶的想法直接轉成軟體規格的話,客戶心中想的那朵雲,隨時都會變幻出各種不同的形狀,需求不斷變動乃是必然。如果開發者沒做適切的分析及設計,只靠技術是很難滿足客戶多變的渴望與需要的。

事實上,軟體開發是知識與腦力密集的工作。自許為知識工作者,重要的不在於產出的數量,而在產出的品質。要讓產出具有足夠的品質,必須要在問題領域的分析投入足夠的時間,才可能為客戶設計出可以解決他們問題的軟體,為客戶創造價值;軟體也才能具備足夠彈性適應客戶千變萬化的需求,有效地降低開發風險。

正確的溝通

於是,當我們用以上的思路來看軟體開發時,縱使專案沒有足夠的開發時間,我們依然要會從客戶的立基點中去思考問題,並從中找出最可行的技術來創造客戶的最大價值。同時,在這樣的情況下,開發者展現了足夠的專業,客戶也會很自然地信任開發者誠意與專業,形成了良性的雙向溝通。

在這種客戶與開發者良性溝通的情況下,客戶可以決定了時程、成本、品質等限制條件,而專案範疇的限制條件則應該由開發者與客戶溝通後依業務需求及技術架構的取捨來決定。

也就是說,客戶提出他的問題、以及希望解決的時限及願意付出的成本。開發者則針對問題分析出需求規格、發展出技術架構,並據此實作出軟體後再交由客戶驗收。然後,客戶再依軟體實際使用狀況予以回饋,開發者再依照客戶的意見反覆地演化系統,使軟體更趨於完善。

理想狀態是,客戶應該優先提出最關鍵及最核心的業務問題,而開發者則必須針對這些問題分析,發展出軟體需求、找出解決問題應採用的技術與方法、優先將最高風險及最核心的架構與程式實作出來。如此客戶最重要的問題可以優先被解決,而開發者也可以針對客戶問題而設計,而不會浪費時間與成本在過度設計上,降低了軟體開發的風險與複雜性,使得產出與產能可以相互配合。

開發產出與產能相互平衡,才不會偏廢於需求面或技術面,使技術可以面對現實地解決客戶的問題。就算開發時間真的不夠,至少也可以用空間換取時間呀。無論如何,客戶至少都會擁有一個可用的系統,而不是一堆無法正常運行的程式碼與文件。

作者目前在某知名公司擔任架構設計工程師,擁有台科大MBA學位,曾參與國內大型專案,並具有專案管理專業證照 (PMP)。在此之前從事資訊科技工作20年,歷任不同IT領域,具有豐富軟體開發經驗。

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

作者:朱仲傑
http://www.zdnet.com.tw/enterprise/column/java/0,2000085699,20110335,00.htm
http://www.zdnet.com.tw/enterprise/column/java/0,2000085699,20110343,00.htm
你是「專業」的程式設計師嗎?什麼是專業?我自己的定義是「使用自己所擅長的程式語言,快速且正確地解決問題的程式設計師。」這句話裡有兩個重要的關鍵字:「快速」與「正確」。正確是絕對必要的,如果最後的結果不正確,那不管是用了什麼最新的技術,或是到底多短的時間就完成等,其它的因素都是白廢的。至於怎樣才叫快速?這個比較沒有量化的標準,而且快速還可以再細分成:你寫程式的速度和寫出的程式的執行效能。

想法才是效能的關鍵

在google code jam中,解題的速度很重要,程式執行的效能也不可缺。效能固然和花掉的CPU時間有關,但這個時間會依硬體效能的提升有些改變,我認為,程式設計人員在設計你的解法/演算法(algorithm)時的想法和態度,才是決定程式執行效能的關鍵。

舉個簡單的例子,請你設計一個程式,可以計算a加到b的總合(例如1加到100),你會怎麼寫?很直覺的,這種重覆性的工作,可以交給迴圈來解決。是的,用迴圈是可以正確的解決這個問題,但我認為這是最不專業的解法。我們就算數學不好,也聽過高斯小時候的故事;話說高斯從小就非常的聰明且頑皮,有一天上課時,老師為了讓他不搗蛋,出了一個難題給他,要他計算1加到100的總合。老師以為可以讓高斯安靜一下子,沒想到高斯沒幾分鐘就把答案算出來了。後來推導出所謂等差數列的功式,也就是首項加末項乘以項數再除以二,以這個例子來說就是(a+b)*(b-a+1)/2 。短短一行程式碼就解決的問題,為什麼要用迴圈寫成好幾行呢?當數字大時,使用數學功式的程式執行的速度絕對比用迴圈還快上很多!

寫程式的態度應該是,把你所學會的所有知識中,找出最好的解決方法,而不是程式正確會跑就好如果還有更好的方法是你還不會的,那就趕緊把它學會,日後好運用在你的程式裡。你也許會不以為然的說,解決這種小問題,幹嘛要計較這麼多。我不想在這討論程式該不該做最佳化的問題,網路上已經有太多類似的爭辯,不知大家有沒有聽過「格局決定結局,態度決定高度」這句話?設計程式的思維和邏輯也不是一朝一夕就能養成或是改變的,你想要成為頂尖專業的程式設計師,就要養成良好的思維習慣。(待續)

專業領域能力

除了態度之外,就是你如何去發揮、結合其它領域的專業知識。我以前教授青輔會電腦第二專長訓練班,來上課的學生都不是資工電腦相關本科系的(所以學電腦才是第二專長嘛),他們想學好程式設計,但大部份的人心中都有個疑惑:「我寫程式贏得過本科系的人嗎?」我鼓勵他們說:「單比寫程式,也許你們不一定贏得了,但你們在其它領域的專業知識,則是他們欠缺的!」我常說,學資工其實是最沒有用的,因為除了電腦之外,其它領域什麼也不會。寫一個股票系統不需要太高深的程式設計技巧,可是其中的分析、統計確需要專業的相關知識。就拿我來說好了,也許我很會寫程式,但我沒辦法寫出一個股票系統,因為我在那個領域裡完全不懂。這就是我想要表達的本科系無用論,所以本科系的人不需要太驕傲,而非本科系的人也不需要太悲觀,各自發揮你們在各個領域的專長,並深化你想要的domain know how,你就可以成為一位出色且專業的程式設計師。

創新

有人叫我大師、達人、高手(但照前面的定義來看,我還真不怎麼專業。)從開始學習BASIC語言(有行號的那種),一路走來Quick BASIC、Visual Basic、ASP到Java,算一算已經快二十年了,能夠支持我這樣一路走來最主要的動力是「熱情」,這點跟上次來台灣的兩位大師的觀點一樣:對寫程式的熱愛、對技術的熱情

要保持熱情並不容易,因為有很多外在的因素會迫使你放棄,例如經濟的壓力,在台灣,技術人員的薪水高不到哪去;無日無夜無條件的加班,對體力上可說是很大的考驗。台灣在硬體方面是世界首屈一指的,不論是代工組裝的品質、ODM、OEM ,甚至外型設計也屢獲大獎。可是為什麼在軟體的創新研發上,能在國際上叫得出名字的就只有那幾家?我們程式設計的功力比較差嗎?並不會啊!創新的能力我想是最主要的因素。

創造力或許是天生的,但學校教育的培養也相當重要。無奈的是,不論教改前或教改後,教育的目標還是沒有變:考上好的大學、好的研究所,你就能出人頭地。「把書讀好就對了,其它什麼事都不用管。」這一直是台灣許多父母的觀念,不好好念書幾乎就和不孝劃上等號了。從小「補、補、補」的教育,讓我們的創造力逐漸消失。反觀影響電腦界最深遠的兩個人--Microsoft的Bill Gates跟Apple的Steve Jobs--就是個最好的例子,他們都沒念完大學。你看過他們相關的傳記就知道,他們年輕時幹過多少在台灣社會下不被允許或不可能做的事。讀書固然重要,但重點在於能否激發創意的實現,否則就變成了死讀書、讀死書、然後讀書死。

如果你還是學生又想當專業的程式設計師,那恭喜你,你還有許多時間可以好好的改變你自己。如果你已經是個程式設計師,改變雖然需要勇氣和承擔很大的風險,但不改變你就永遠只是個程式設計師,要變專業成為頂尖的話,改變乃是不得不然的路。

作者於中正大學資訊工程研究所博士班肄業。專精Java技術開發,曾出任Java Two七屆講師。知名Java工具書作家,已發表著作包括Palm應用程式設計、Java2全方位學習等系列書籍。

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

這是比爾‧蓋茲對 "程式設計師" 的定義:

能夠同步接受新知識,能夠準確提出疑問,能在不同領域的知識中找出關聯性,擅長程式、看一眼就能理解程式碼,開車或吃飯也不時想著程式碼的熱誠,極高的專注力。

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()

先了解系統架構與行為模式,再細讀
倘若撰寫程式碼是程式人的重要技藝之一,那麼讀懂別人的程式碼、接著加以修改,也勢必是另一個重要的技藝。
如果你不能熟悉這項工作,不僅在遭逢你所不願面對的局面時,無法解決眼前接手他人程式碼的難題,更重要的是,當你看著眼前現成的程式碼,卻不知如何從中擷取自己所需,導致最後只能入寶山空手回,望之興嘆。
接觸他人的程式碼,大致上可以分為三種程度:一、了解,二、修改、擴充,三、抽取、提煉。
雖說是「閱讀」,但程式碼並不像文章或小說一樣,透過這種做法,便能夠獲得一定程度的了解。閱讀文章或小說時,幾乎都是循序地閱讀,你只消翻開第一頁,一行行閱讀下去即可。但是,有許多程式人在試著閱讀其他人的程式碼時,卻往往有不知如何讀起的困難。
或許找到系統的第一頁(也就是程式碼執行的啟始點)並不難,但是複雜度高的系統,有時十分龐大,有時千頭萬緒。
從程式碼的啟始點開始讀起,一來要循序讀完所有的程式碼曠日費時,二來透過這種方式來了解系統,很難在腦中構建出系統的面貌,進而了解到系統真正的行為。所以,閱讀程式碼的重點,不在於讀完每一行程式碼,而是在於有效率地透過探索及閱讀,從而了解系統的架構及行為模式。以便在你需要了解任何片段的細節實作時,能夠很快在腦上對映到具體的程式碼位置,直到那一刻,才是細讀的時機。

幻紫芊芊 發表在 痞客邦 留言(2) 人氣()

給學生與軟體業新進的十招

轉貼 程式設計俱樂部
作者 : bensontan(Benson)
 
 
莘莘學子與軟體業新進請聽聽在下的十招~對於這十招提供了一些
基本的解釋也希望能以詼諧的方式幫助各位加深印象~相信這十招
各位經過更多歷練後會有更多解釋~所以把這篇從原篇中獨立出來
,希望能方便讀者參考:

第一招:看到問題唸十次
 a. 確認你記得問題下次還記得
 b. 確認你瞭解問題,沒有漏掉什麼要求
 c. 確認你以後踫到類似問題,還會想到它
 d. 確認你連做夢都會想到它~悲慘的程式設計師宿命~

幻紫芊芊 發表在 痞客邦 留言(0) 人氣()