How many documents should we have?

Documents are of little importance, but documenting is essential.

Documents are valuable but costly. How many documents should we have? "Less is more". How less is enough?

You will need more documents until you can synchronize your team.

So, how many is enough?
It depends on the culture, quality, workflow of your team, and mutual understanding between members. The less stable your team, the more documents you need.

讀到這篇「美國碼農加班少很多、卻能開發出厲害的產品？」，讓我想起了一件事：

某公司的主管，總喜歡在客戶或PM還沒提出需求，或是需求規格還沒共識前，就發動團隊依照他的想法開始作業 (應該是希望當規格出來後，就可以很快的遞交成果，向上級展現自己團隊的效率)

不過這作法產生了許多問題：

1. 規格最後如願被提出大概不到三成，他還常常要求PM把這功能補列入需求，讓團隊做出的功能可以計入credit，卻造成遞交的產品over spec，程式碼變得肥大了 (幸好公司不重視code coverage test)

2. 他的想法可能與客戶或PM的需求有出入，以致於開發團隊需要花更多時間在修改程式上

3. 有時實作必須修改架構，而修改架構會有意外的風險，需要花更多時間來測試與修改；若是為沒有需求的功能來增加這風險與成本，更是讓人懷疑這樣硬做的決策品質

4. 將開發團隊投入於完成又不被採用的功能，不僅時間沒花在刀口上，排擠了做其他事或進修的時間，每每做一些虛功更是打擊士氣

5. 公司PM常常spec.開得不清不楚、模擬兩可 (就所知，PM對專業知識了解不足，一些細節無法明確定義)，這就造成開發團隊與DQA對spec.解讀不同而常有爭執。而此公司的issue tracking process是紊亂的，常搞到最後，產品最後的長相連PM可能都無法掌握

謀定而後動！

在開始踏出第一步前，先定義好你的目標與目的吧！

你如何設計你的產品？

創業者請想清楚，該關注自己的產品還是需要解決的問題？
「每次他們發現新問題或新需求時，就不停地添加新功能。最終結果就是產品變得異常複雜，功能零亂，又沒法徹底解決用戶需求」

這篇文章讓我想起昨天在辦公室裡的事
昨天下午三點多接獲一個新指令，要做一個新功能。
思考了一下，把疑點跟主管討論了一下
嗯...這功能A在操作上會自己與自己抵觸
OK，主管決定修正為功能B
再思考了一下，覺得還是怪怪的
再去找主管，仔細的問這功能是要給誰(actor)用？這功能要呈現什麼價值(use case)？
被我這樣一問，大家才搞清楚誰是使用者，操作情境是如何，也才發覺原來功能A與功能B都不是最好的解法。從整個scenario重新構思，分析出我們的需求應該是功能C

在設計產品時，得不斷提醒自己，這是要給誰用？你的產品在那個情境中，能提供他們什麼價值？

真的不應該依賴software stack嗎？

在這篇文章中The full stack developer is dead, long live the un-stack developer，提出了un-stack developer的理念

不過現在的開發環境與應用平台，以及software reuse的概念下
不用software stack，什麼都自己動手做，在講求效率的今天，已經是接近天方夜譚了

也有許多開發者並沒有身處於start from zero的機會
不過開發者應該知道，一位好的開發者
必須要有從零開始的能力，必須要有設計架構的能力
並且努力為自己培養這樣的能力
因為有這樣的能力，才能讓自己有start-up的技能、觀念與胸懷

有時，工程師做的事是一種ART！

今天一整天，就只改了一行程式。

對，就只有一行！

我很偷懶嗎？才不，今天可是超級「精實」。
那為什麼只改一行而已？改一行要那麼久嗎？
如果你是主管，你會怎麼評斷這位工程師？

如果你是位注重量化，把「人月」、「line of code」「function point」掛在嘴上，透過一些指標，這位工程師的一天簡直是災難吧！

先聽聽我今天做了什麼事
一早被指派這個工作後，先瞭解問題是什麼，可能的因素又有那些，接著就開始設計如何測試來確定是什麼原因造成的。等確定成因，大概就過了半天。半天，真的很快了。

接下來，就是修正這個錯誤。對，就是改那一行！真的不是我偷懶，有問題的就只有那一行，所以也只能改那一行。(我也很盡責的加上註解喔)。這大概花了幾分鐘。

這樣不就解決了嗎？你還有半天可以做別的事呀。這半天被你摸掉了喔。

才不是啦。公司的機器有十幾種models，而這個程式會被用在所有的models中，所以，除了出錯的那個機種外，我還必須一個一個機種去做regression test，以確定這樣的改法在別的機種上也可以正確運作。等這些機種都測完，一天也結束了。

所以，別再用那些奇怪的指標來衡量工程師了。有時，工程師做的事是一種ART！
就好像，你不該跟梵谷計較，在那幅星空中應該多畫幾顆星星才比較有價值！

Android開發，appcompat_v7需要進版本管控嗎？

用Eclipse或Android Studio開發Android APP的朋友會發現，在ADT 22.6以後，當建立新的專案時，都會多一個appcompat_v7(或appcompat_v7_xx)的專案。
這專案是什麼？有什麼用途？網路上已有不少文章，大家找一下就可以找到一堆了 (參考)

那當專案要進版本管控(SVN, CVS, etc.)時，這個自動生成的support library project也需要跟著進去嗎？
找了一些文章，似乎沒有找到有較明確的說法。
當然，一起納管一定沒問題，可是納管這個自動生成的project似乎很沒道理。

換個角度來思考，如果我們在沒有這個project的workspace中，可以讓工具自動再生成這個project，讓我們的porject可以正常運作，那這個appcompat_v7就可以不用放進版本管控了。

做一個實驗，模擬一下當從SVN or CVS check-out一個專案時，是否能把整個開發環境建立回來。
開一個新的workspace，把一個之前做好的project給import進來，當然如預期的，會有一大堆的錯誤。錯誤當然都是跟support library有關。

接下來就要把support library project建立起來。相信大家的環境一定會有Android SDK。接著我們就要從下面的目錄把support library給import進來

<android_sdk>\extras\android\support\v7\appcompat  (註：<android_sdk>是指你SDK的安裝目錄)

不過還是一堆error

看一下原專案的properties，其library的名稱是appcompat_v7，但我們import進來的名稱是android-support-v7-appcompat，兩者名稱不同，必須修改一下讓兩者一致。那要修改那一個？我比較偏好改support library project的名稱。因為改properties裡的library名稱，再commit回版本管控時，可能會影響到別的同仁。

在project上right-click，用refactoring的功能來改project name為appcompat_v7 (如果在上一步驟所看到的project name不是這一個，以properties裡的設定為主)

修改完後，Eclipse就開始重新build workspace，這時errors就消失了

試跑了一下，原project的功能都正常。因此整個開發環境都回來了。

透過這個實驗可以得知，我們可以不用把support library project放進版本管控系統中，之後也能把開發環境重建起來。

補註：想瞭解Android support library有那些及分別有那些功能，<android_sdk>\extras\android\support\README.txt這份文件是個好起點

在Android中周期性更新ListView的內容

在一個Activity裡有一個ListView，需要每10秒鐘更新ListView的資料
用寫Java的傳統想法，寫出了這樣的程式
其中ListItemProducer.getInstance().getList()會傳回ArrayList<string>

ArrayAdapter adapter = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
  ...
  list = (ListView) findViewById(R.id.listView1);
adapter = new ArrayAdapter(ListActivity.this, android.R.layout.simple_list_item_1, ListItemProducer.getInstance().getList());
list.setAdapter(adapter);

timer = new Timer();
timer.schedule(new MyTask(), 5000, 10000);
}

class MyTask extends TimerTask {

@Override
public void run() {
adapter.notifyDataSetChanged();
}
}

一執行，當掉了，怎麼可能！？
這樣的Java程式我寫了無數次了，不應有錯呀
 靜下心仔細看了一下，原來出現"Only the original thread that created a view hierarchy can touch its views."的exception
Android只允許原始的thread去變動views，上面的MyTask是在另一個thread跑，不被允許去碰views
找找資料，Handler倒是個解決問題的好方向
於是加了這段

private Handler updateHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
adapter.notifyDataSetChanged();
}
};

然後把 MyTask改成

class MyTask extends TimerTask {
@Override
public void run() {
try {
updateHandler.sendEmptyMessage(0);
} catch (Exception e) {
e.printStackTrace();
}
}
}

讓MyTask在每次時間到時，透過handler來送message回原來的thread，讓原來的thread去做update views的工作

10 Reasons why Java Rocks More Than Ever

我喜歡Java，從2000年開始使用Java到今天已經有14年了。對我而言，用Java來開發各種系統，都是很美好的經驗。

Java，對有些人來說，是種語言。但對我來說，Java不只單單是種語言，她還是個執行平台(JVM)，更是個很漂亮的API。

今天看到這篇文章10 Reasons why Java Rocks More Than Ever，裡面提到的十點，真的點出了我也認同的Java十大優點：

Part 1: The Java Compiler
Java的結構讓Java程式在compile時可以快速且簡易，也沒有複雜的linking問題

Part 2: The Core API
經過十多年來的演進與累積，JDK core API無論在功能與效能上，都有明顯的進步。一般的程式，只要用core API幾乎就足夠了

Part 3: Open Source
這一點對我來說真的是獲益良多。Internet上充滿了一大堆好用的Java open source，你想得到或想不到的功能都有，讓我可以在很短的時間，就能做出符合需求的系統。不過對我也有些困擾，就是有太多類似功能的libraries/frameworks，讓我得花不少時間去評比與測試，來決定用那一個

Part 4: The Java Memory Model
Java在memory的規劃上完全支援了concurrency computing。這個只要用Java寫過threading就能體會它的好，連C++11與C11都加入了這樣的memory model了

Part 5: High-Performance JVM
JVM加上了JIT，讓這個雖然是虛擬機器(VM)，但跑起來卻不笨重。有不少benchmark的評比，Java跑起來的速度不會差C/C++太多，尤其是在server environment，雖然有不少C/C++的忠實者不太同意，不過它的效能在一般用途上真的是夠好了

Part 6: Bytecode
bytecode對JVM來說，其實就是這個VM的machine code。所有的Java程式都要先compile成.class的file，裡面就是可以在JVM上執行的bytecode。現在也有其他語言(http://c2.com/cgi/wiki?OtherLanguagesForTheJavaVm)可以compile成bytecode了，所以不一定只能用Java語言才能寫出能在JVM上執行的程式了

Part 7: Intelligent IDEs
對Java programmers來說，這一點真的很幸福，像Eclipse, Netbeans這些IDE，功能強大，而且不用錢

Part 8: Profiling Tools
由於JVM的結構容易與外界溝通，所以Java的開發者有不少profiling工具，可以來量測CPU, memory等等的使用狀況，幫助做performance的調校

Part 9: Backwards Compatibility
當你寫了十幾二十年的程式，看到好久以前寫的程式，不用修改就能在新平台上執行，你就會知道那是何等值得感動的事
Java就是這麼可愛，不像某家公司，換個版就夠你改得要死

Part 10: Maturity With Innovation
Java從1995誕生至今也快20年了，它的成熟度如何，看看金融界使用的情況就知道了，連在火星上都有它的足跡。Java仍在演進，與時俱進地不斷創新功能，這也是為何有這麼多Java的死忠者願意跟著它走。

你喜歡Java嗎？Java還有很多我都還未接觸過的面，值得大家一起來學習與分享。