不告訴別人～還是偷

不管到哪一個工作，總是會有一個現象，主管要求你『偷』東西。

自從open source的概念興盛於這個世界後，你隨便上網都可以找到一大推不用錢又好用的軟體，很多甚至連程式原始碼都給你下載，當然使用上不需要付錢，但～～要求你必須承認你使用人家的軟體。台灣（或許是世界上都這樣吧～～我只是一個台灣土包子工程師）的很多公司都有一個不好的文化：喜歡拿open source的project來更改一下，然後開始號稱自己的研發能力很強，產品很快就可以做出來。

記得以前一個業務的朋友跟我說『我們可以找到這些project來改也是我們的實力呀』，這話其實聽了很悲哀，因為這跟實力一點關係都沒有，這是一種基本的誠實問題。工程師通常會面臨一個嚴重的挑戰，現在的老闆通常知道有open source這種東西（儘管他們自己都用付費軟體～～歐，原來～～沒付費呀～～ㄏㄏ），所以老闆通常會給工程師一個難題：『你拿這些來改很快可以有產品，不然你同樣時間寫出來我就不管』。因此～～軟體工程師開始墮落、開始閉上眼睛。

其實長久以來慢慢的發現這些偷來的專案慢慢的也會消失，因為主要是別人的『智慧』，除非你願意花時間完整去了解整個程式，否則只是一種應付的心態，自然遇到後期的困難越來越多，也就越凸顯對於程式的無知，而後期的時間壓力更大。當然我不否認現在很多企業跟open source合作的很好，也都儘量遵守open source license的規範，但我們也必須承認的是，依然有許多公司會用偷的。（至少我就遇到很多間）

今天老闆還是要求我去找一個軟體來偷放在我們的機器上，我需要找一個類似小畫家的軟體，其實根本上我不覺得這種軟體在我們小小的3吋顯示螢幕上有何用處（每個icon都已經小到要有很準確的螢幕點取能力～～ㄏㄏ），當然老闆想要的原因也很簡單～～因為競爭對手有。這樣的開發心態其實存在很多的專案，記得看過使用者介面設計的文章有提過：不要在乎使用者說的需求，要去觀察使用者應該如何完成工作。

在這樣充滿各種eye-candy的產品的時代，使用者已經習慣要求各種美麗的第一印象，但是往往買完才會發現自己根本用不到這些功能，更慘的是～～有時候還會發現自己要的功能不足。所以一個負責任的產品設計應該著重於使用者的操作，而不是使用者的眼睛，當然設計者也應該避免寵物理論（就是把使用者當成寵物，覺得你可以訓練他的操作行為），重點是研究使用者如何完成他的工作，然後設計出符合這樣操作流程的好用介面。

我們習慣告訴小孩～～不能偷拿別人的東西，但～～～～這樣的法則似乎不存在於商業的世界。

工程師的創世紀

當軟體工程師久了慢慢的也接觸過不少專案，有一些專案是從頭開始的，通常一個從頭開始的專案會不會成功，一開始就看得出端倪。

或許現在視覺化的工具太多，因此很多工程師都每天忙著畫使用者介面，當然一個程式要有互動性，使用者介面是很重要的，但～～它該是一個專案的創世紀篇嗎？不少時候專案領導者在開始新專案的時候，都是要求『我畫面上要有三個按鈕』、『這裡的圖如果會跳動一定很炫』、『這個字型應該用美麗一點的』...等等。發現了嗎，一個專案由視覺開始，這～～不好嗎？

我相信一個程式他的使用者介面是一個小小的部份，通常那只是展現的問題，所以每次當面試的時候有人問說『那個OOXX的library你有多熟』，恩～～我都會回答，可以上網查跟看書就很熟，不行～～就不熟。其實大多數的圖形介面library都做的很容易上手，當然你要給它弄的不像原來library的呈現就要花功夫，但～～那也是你自找的。

用使用者介面當成思考的起點通常有一個大麻煩，就是實際內部運作的程式碼常常會跟圖形library綁在一起怎麼也切不開，當然如果你對一個GUI library至死不渝，那我沒有意見，但如果要你換一個GUI～～你會不會想哭。很多Open Source的程式都可以有不同GUI的支援，因為他們通常把程式運算與程式呈現分的很清楚，這樣容易讓自己的程式那多樣化的作業系統（如linux）執行無誤。會這樣設計的程式，我相信一開始不會用使用者介面當成思考的起點，因為～～那不重要，重要的是這程式要完成哪一種任務。

商用產品通常用介面著手，因為商業人士了解到外觀是觸動你『想要』的重要因素，但滿足你『需要』的要素卻是內部的功能，因此站在一個業務的立場，當然希望外觀越美越好，但～～從工程的角度出發，是否該從程式架構與功能需求著手呢？

我當然不是說美麗的UI不重要，但應該仔細想想的是一個成功的產品一定具有人性化的操作方式（我是說操作方式，不是美麗的圖示），當然也會具有可愛讓人愛不釋手的介面，但營造這個可愛的介面前應該由程式的行為著手思考，有了行為～～再去分配外觀。

多年了我還是不習慣台灣很多軟體設計都先寫UI，在一個Do-nothing的UI上再去開發程式，這樣的下場通常都是讓程式越來越混亂，不過好像常常都是這樣，或許我們的主管們也必須在看到畫面後才能開始思考功能吧～～～這～～我有點不能理解。

講或不講～～～思考中

每次我對於一個開發linux軟體的公司，對於員工使用linux當成平台很困擾的狀況，都會感到十分詭異。

或許因為這些主管本身都是使用windows的作業環境，因此說實話他們對於linux很不熟悉，但～～他要指導工程師如何寫linux的程式，當然對於不同的環境每個人的編譯方式自然不同，反正最終還是要進到linux環境下面執行。對於習慣在linux下面開發程式的朋友應該很熟悉 autoconf與automake這些工具，他讓你可以快速的產生一個編譯環境，當然～～他不是圖形化的工具。

主管對於我的程式裡面有這些autotool產生的檔案非常不以為然，他今天下了指導旗，他覺得這些『不必要』的檔案不應該存在專案中，我想或許他沒有寫過具有大量程式檔的專案經驗吧，當你的程式檔案很多的時候，自己一行一行編寫Makefile可是一大通苦的差事。上次有跟他解釋過這些檔案並不是『無用的』，不過～～看來他無法接受，恩～～好吧～～對他無用就是無用。

我想這些MS體系出身的工程師，對於非MS的編譯環境自然感到十分排斥（其實跟我不習慣MS的環境是一樣的道理），但至少必須承認不同的方式也是一種方式，而不是～～～非我族類者殺之。

現在的我有兩個選項，一個是每次送程式碼給他的時候就自己辛苦點把這些設定檔刪除不要讓他看到，一個是繼續跟他說明，不過這會讓我想到一些過往的經驗，通常我的下場會是～～～此員工頑劣固執難相處。所以～～或許我會選擇就隨波逐流吧，反正，就是一個寫程式的小角色，高層～～～總是有讓人摸不透的思考的。