engineering > 裏所有文章列表
臨睡前看到 joel 的這篇文章，實在太震撼，忍住睡意快寫下來。
這篇文章中joel提到他當年成立Fog Creek軟體公司的理念：
Best Working Conditions -> Best Programmers -> Best Software -> Profit!
他用了很長的篇符來解釋為何請最好的工程師對軟體公司很重要，原因如下：
-以生產軟體產品為主的公司，不像一般的製造業，例如wal-mart, 傳統製造業中人力成本越低，每件產品的單位成本就越低，因此製造業都會跑到東南亞設廠；但軟體產品的成本不會隨者銷售數量增加而倍增，一套產品寫出來後，成本只會隨者越賣越多而攤銷掉，不會上升。
-因此，一開始就請最好的工程師把產品寫好，這些成本反而可以更快回收。
Essentially, design adds value faster than it adds cost.
-好的工程師可以用更快更短的時間寫出更高品質的程式，這比請三個二流工程師還好，因為二流工程師只會把案子拖的更慢，效果更慘，而且永遠也生產不出一樣好品質的東西(人月真的只是神話)。
不過joel也提到，他的這套 高品質論 只適用於 software company, 而不是一般百大企業的IT部門，因為兩者的需求完全不同，就像沒有人會請dolly parton去婚禮唱歌一樣，她只適合大舞台。
全篇最讓人震撼的quote:
The mediocre talent just never hits the high notes, they just don’t have it
| by admin
昨天的文章中出現 anti-pattern後，被很多人在msn上詢問到底是什麼意思，怎麼查不到這個pattern，GoF也沒提啊~
wiki的解釋
基本上 anti-pattern不是一個pattern，而是一堆亂例子的組合體，從字面上就可以感覺到這個意思。一般來說 design pattern是指好的應用，而 anti- 自然就是違反pattern的意思。
不過這個字的應用範圍實在太廣泛，因為在寫程式的過程中難免一定會犯錯(例如做了錯誤的決定、採用了錯誤的手法、或是想到要用pattern但卻implement錯誤結果更慘之類的)，所以這些錯誤都可以統稱為 anti-pattern。
當然如果你去amazon鍵入這個字的話，會找到幾本相關的書籍，有前輩們已經把常見的錯誤整理出來，或許看完可以瞬間增加一甲子功力吧~
_
| by admin
功能：Blog reader
特色：支援video blog與RSS
主要技術：php, xml, actionscript, js
介面做的很用心，把macromedia的ui元件都 re-skinning一遍，操作還算順暢，跟之前看到的 flash mail reader比起來算是好很多。
不過一看到程式碼就開始頭痛，果不其然這是一個 frame-based 的 procedural 產物，所有元件都宣告在同一個frame，所有的功能也是一個個的function四處散佈，這種程式最終的下場就是很難維護與debug，並且如果日後要新增不同的功能或業主要求能自訂版型layout甚至讓user換面板等細節，這位工程師將會身陷火海痛不欲生。
通常這種frame-based的RIA app 主要的問題都在於modulization程度不夠高，設計者缺乏基本的component-based design或物件導向觀念，一切只以「能快速達成眼前目標為出發點」，所以最後就會出現一個又一個的hack手法，也就是採取俗稱的”quick and dirty” way來寫程式。
這也是我在這篇裏所提過的諸多缺點之一，以及為何尋求正確的methodology/framework是很重要的原因。
不過往好的方面想，類似mediatuner 或 wallop 這樣的app，都是很好的 anti-pattern教材，當爛的例子一多時，量變總有造成質變的一天，有時多看壞的範例也是學習啊~
| by admin
原文
他大致介紹了目前Java平台上幾個可用的選擇，並說明為何最後相中Hibernate。
基本上他的前進路徑與我相似，現在只差熱血青年出來寫一個 Hibernate for Actionscript 2了。(笑~)
| by admin
PB/OOAD: Pattern-Based Object Oriented Analysis and Design.
CBD: Component-Based Design.
SOA: Service Oriented Architecture.
這三個字真是 料多 實在 妙用無窮 啊~
任何一個好的、成熟的、複雜的專案，都應該遵照這三個原則，從一開始的規畫設計就整合Pattern與OO，並使用UML做為溝通的工具(我常用的幾種圖是 use case, class diagram, sequence diagram, ER，其它就隨緣了)，等A/D出來後，在實作階段就應該盡量採取Component-Based Design(在flash裏面，component可以是指單純的UI components，但也可以是多個UI components的集合單元)；而後端的部份則應該儘量採用SOA(不論是像.net的code behind, coldfusion的cfc或其它各種web service應用，總之後端服務應該有一定的封閉性，透過facade或adapter原理來操作)。
所以簡單來講，這三個字是有先後性的：
分析 - 前端實作 - 後端實作
PB/OOAD - CBD - SOA
雖然這三個字每個都不簡單，個個也都是大學問，但越早採用受益越多，對flash-based 的 RIA製作來說，比較大的難題可能是工程師得先從其它領域(.NET/JAVA)學會這些概念，然後再自行轉換到actionscript 2來，雖然過程中會造成進度遲緩，但就像大浪要來前必然會先退潮，退的越多後續沖上來的力道越強，一旦過了這個轉折之後就輕鬆了。
經過近兩個月的努力，最近我們終於完成一套貼近人性、彈性高又易用的framework(或稱做RIA best practice也行)，可以用最接近傳統win32 programming的方式達到快速開發(RAD)應用程式的效果，在未來幾個星期中我會將部份範例程式整理成教學文章放上來，請大家多指教。
ps. 經常被問到：為何我要這麼在意 方法論/framework/best practice/軟體工程 之類的東西，理由其實很簡單：
1、要認真開發商用軟體(不論是用flash/.net/java)，這都是必經的路，就跟做音樂一定要買mac是一樣的道理，雖然用其它方法也能達到類似效果，但路遙知馬力差別總有顯現出來的一天(而且往往會快的讓人嚇一跳)，所以與其繞路不如直指核心一次搞定最重要的部份。
2、受夠了flash向來惡名昭彰的惡搞開發流程，十個設計師寫出來的程式就會有二十種不同的手法跟三十種不同的錯誤加上四十個修不掉的bug，這一切會發生絕對都是有原因的，其中共通的一點就是在於先天缺乏正統的CS訓練，後天又沒有generally agreed-upon methodology可依循，再加上flash也是這一兩年才開始進入Application的開發領域，所以一切都太年輕、太混亂(不論是人、技術、市場皆是如此)。
| by admin
Next Posts
Previous Posts
