引述
在桌面時鐘旁邊加上自己名字的小秘訣
想在桌面時鐘旁加上自己名字就跟著做吧!
1:開始/控制台/按地區及語言選項
2:按區域語言選擇
3:按自訂
4:按時間
5:把上午符號(M)欄和下午符號(P)欄 換上自己名字
6:在時間格式欄加上tt
(tt h:mm:ss 名字在左邊 / h:mm:ss tt 名字在右邊)
酷哦!果然跟別人不一樣了
酷哦!果然跟別人不一樣了
有德之人必是有福之人,這世界之所以會有太多的爭執與鬥爭都是因為人們太過於自我為中心,若能拋卻自我相信這個社會會變的更加和諧。
因此,如果開發者沒有針對客戶需要分析他們的問題,設計解決方案,只是直接把客戶的想法直接轉成軟體規格的話,客戶心中想的那朵雲,隨時都會變幻出各種不同的形狀,需求不斷變動乃是必然。如果開發者沒做適切的分析及設計,只靠技術是很難滿足客戶多變的渴望與需要的。
事實上,軟體開發是知識與腦力密集的工作。自許為知識工作者,重要的不在於產出的數量,而在產出的品質。要讓產出具有足夠的品質,必須要在問題領域的分析投入足夠的時間,才可能為客戶設計出可以解決他們問題的軟體,為客戶創造價值;軟體也才能具備足夠彈性適應客戶千變萬化的需求,有效地降低開發風險。
正確的溝通
於是,當我們用以上的思路來看軟體開發時,縱使專案沒有足夠的開發時間,我們依然要會從客戶的立基點中去思考問題,並從中找出最可行的技術來創造客戶的最大價值。同時,在這樣的情況下,開發者展現了足夠的專業,客戶也會很自然地信任開發者誠意與專業,形成了良性的雙向溝通。
在這種客戶與開發者良性溝通的情況下,客戶可以決定了時程、成本、品質等限制條件,而專案範疇的限制條件則應該由開發者與客戶溝通後依業務需求及技術架構的取捨來決定。
也就是說,客戶提出他的問題、以及希望解決的時限及願意付出的成本。開發者則針對問題分析出需求規格、發展出技術架構,並據此實作出軟體後再交由客戶驗收。然後,客戶再依軟體實際使用狀況予以回饋,開發者再依照客戶的意見反覆地演化系統,使軟體更趨於完善。
理想狀態是,客戶應該優先提出最關鍵及最核心的業務問題,而開發者則必須針對這些問題分析,發展出軟體需求、找出解決問題應採用的技術與方法、優先將最高風險及最核心的架構與程式實作出來。如此客戶最重要的問題可以優先被解決,而開發者也可以針對客戶問題而設計,而不會浪費時間與成本在過度設計上,降低了軟體開發的風險與複雜性,使得產出與產能可以相互配合。
開發產出與產能相互平衡,才不會偏廢於需求面或技術面,使技術可以面對現實地解決客戶的問題。就算開發時間真的不夠,至少也可以用空間換取時間呀。無論如何,客戶至少都會擁有一個可用的系統,而不是一堆無法正常運行的程式碼與文件。
想法才是效能的關鍵
在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--就是個最好的例子,他們都沒念完大學。你看過他們相關的傳記就知道,他們年輕時幹過多少在台灣社會下不被允許或不可能做的事。讀書固然重要,但重點在於能否激發創意的實現,否則就變成了死讀書、讀死書、然後讀書死。
如果你還是學生又想當專業的程式設計師,那恭喜你,你還有許多時間可以好好的改變你自己。如果你已經是個程式設計師,改變雖然需要勇氣和承擔很大的風險,但不改變你就永遠只是個程式設計師,要變專業成為頂尖的話,改變乃是不得不然的路。