分類
Books Programming

Joel on software (Part2)

選幾篇做個閱讀紀錄…文章在這裡都找的到… :)

22.每兩個程式設計師應該搭配測試員,畢竟測試員比程式設計師便宜多了 :p

23. 絕對不要讓人同時做一件以上的事,因為程式設計的工作就是需要很長的切換時間。

24. Netscape 犯了一個嚴重錯誤,他們在改版的時候決定把程式從頭重寫過,結果隔了太久沒有推出東西,市佔率都被人佔走了。在要從頭重新開始時,完全沒有理由相信這次會做得比第一次好。

25. 冰山的秘密,非技術人員總是比較看重介面外觀,但是其實那只佔 programming 的一小部份。文章中的五個推論都很有意思,其中推論四告訴我 :可以拿些無關緊要的家家酒內容讓客戶選,讓他們覺得自己很重要。哈哈~

26. “所有重大的抽象機制在某種程式上都是有漏洞的。下雨天時開車沒辦法開得和平常一樣快,雖然車上有擋風玻璃雨刷有頭燈有車頂還有暖氣,這些裝備應該是讓你可以忽略下雨這個事實(他們把天氣抽象化了),不過看吧,你還是得擔心天雨路滑,有時候雨甚至會大到你看不遠,所以在只好慢慢地開,因為天氣永遠不能完全被抽象化,因為抽象滲漏法則。

而唯一能適當處理漏洞的方法,就是弄懂該抽象原理以及所隱藏的東西。所以抽象機制雖然替我們節省了工作的時間,不過學習的時間是省不掉的。而這一切都似非而是地表示,即使我們擁有愈來愈高階的程式設計工具,抽象化也做得愈來愈好,要成為一個純熟的程式師卻是愈來愈難了。”

這一篇真是悲觀呀… ^^||

27. “有漏洞的抽象表示我們面對一個直線上升的學習曲線:你可以用一星期學到每天工作所需知識的90%。不過其他10%可能得要好幾年才能補齊。有些人會說:「不管你要我做什麼,我都可以拿本書來就學會了。」真正有經驗的程式師超越這種人的地方就在這裡。如果你正在建立一個團隊,當然可以找一堆經驗較少的程式師用抽象工具製作出一大堆程式碼,不過如果少了經驗老到的人去做真正困難的事情,這個團隊是做不起來的。”

“只認識一個世界的人是很討人厭的。他們每次聽到其他世界的複雜狀況時,就會覺得自己的世界沒那麼複雜。” 作者用來諷刺有些 unix 程式設計師老是喜歡嘲笑 windows 世界的複雜。

28.上有政策下有對策,如果你想根據什麼測量指標來獎勵員工,那有人一定心裡只想著那個測量系統,完全不顧工作的實際價值或品質。更何況連測量績效本身都有困難。

我覺得按照作者的想法豈不是任何獎賞都沒有作用??這好像有違一般常理 ^^|| 我覺得是有點因噎廢食,不能因為少數員工會鑽漏洞,而讓大多數的人拿不到獎勵,重點應該要放在如何讓獎勵機制公正吧。

分類
Books Programming

Joel on software (16~18章)

16. writing code 不是生產,而是 design ,某方面看則像 craftsmanship。craftsmanship 讓你會花500%的努力在1%的地方(修某個UI之類的)。完美的 craftsmanship 是非常昂貴的,只有大量的使用者能夠分攤成本。這也提供了其他公司更多的競爭點。

17.糾正三個CS觀念 : a.搜尋的重點不是找到夠多的資料,而是將這些資料排序。b.不要濫用 Antialiased Text (平滑字?)的顯示效果,因為其實不適合閱讀。c.小心”網路軟體應該要讓資源如同本機資源一樣”的論點,畢竟還是有 availability,latency,reliability 的差異。作者舉個例,在網路上傳檔案,是用FTP,而不是用copy file function,因為copy太簡單了無法應付網路太慢的情況。所以下次有人跟你推銷這個,請想想看如果是網路很慢的情況會怎樣。

18.文化差異 : Unix的核心價值是製作有助於其他程式師的東西,而Windows則把製作有助於老百姓的事視作核心價值。造成文化差異的原因出自各自歷史與背景因素的不同,而 unix 程式師有時弱勢的傲慢嘲笑 windows,但是事實是 windows 的世界比較實務… :p

— 

發現有中文翻譯了…. XD

local.joelonsoftware.com/mediawiki/index.php/%E9%A6%96%E9%A0%81

www.csie.ntu.edu.tw/~p92005/Joel/index.html

分類
Books Programming

軟體預先架構 Prefactoring

 

蔡學庸學長有篇介紹了,可以先參考看看。我是看歐萊禮剛出的中文版啦 :p

書的介紹寫說介於「設計模式」和「重構」之間,我本來以為是一本還蠻理論的著作。不過拿到書之後,發現整本書透過一個開發租借CD軟體的情境來當作範例跟引子,依序講解開發過程中的可以思考的地方跟建議。基本上各個方針都很實際,有些出自 design pattern 的技巧,像是書中的委代機制 ( strategy 模式 ),代理人 proxy 模式,Factory 工場模式等。有些出自重構技巧,像是 Replace Type Code with class 用 ADT 類別取代基本型別等。而開發的流程基本上走 agile process,但是作者也只有第一章提了一下這個名詞而已。

作者擷取各家絕招成各項方針,這本書是本還不錯的小精華集。如果你之前不知道設計樣式跟重構,建議你可以看看不用怕,不知不覺學到的方針就是了。如果你之前就會了,那這本書也可以帶你示範如何應用這些技巧。

不過老實說取這個驚死人的書名實在是有點誇張 :p 真正熟讀重構的人,已經把重構變成每天的麵包與黃油,變成團隊的空氣跟水,早在一開始就不知不覺融入開發的過程啦,又何需預構呢。

by the way… 中文完整書名: 軟體預先架構之美學 : 極致抽象化、區隔化、可讀化。…… 天殺的哪裡來的美學兩個字… .XD

分類
PHP Programming Security

PHP Security Guide

這禮拜把 PHP Security Guide ( phpsec.org/projects/ ) 看完了,還蠻不錯的一份文件。

最基本步驟 1.考量壞心的使用者 2.要自我教育安全知識 3.過濾所有來自外部的資料。以下小記幾個重點:

分類
Books Programming

Joel on software (12~15章)

12. 作者把programming分成五個世界: Shrinkwrap(給大家用的軟體,重視使用性跨平台,又分Open Source,Web Based,Consultingware三種變形) ,Internal(重視開發速度), Embedded(重視品質),Game(看熱不熱門,像電影),Throwaway(用過即丟的script)。知道你自己在什麼世界,選擇適合自己的軟體開發方法。

13. 使用 Paper Prototyping 節省時間跟成本。不要使用 Software Protypes 太浪費了。作者還推薦 paper prototyping 一書給所有要設計使用者介面的人。

14. 小心 Architecture Astronauts (因為太不切實際,不像我們呼吸氧氣,像離開地球的太空人一樣)的誇大(行銷?)說詞,像是什麼什麼技術可以怎樣怎樣的。記得他們總是想他們可以解決的問題,而不是去想真正有用的問題。

15.有翻譯,生產力的重點 : just getting started。另外提到 cover fire,大公司一直開火(推新技術)的原因不一定是必要的技術,而是讓小公司疲於應付(忙於升級或支援這項技術)。大公司的業務只要說 “沒錯, 你不一定要買我們的東西. 要買就要買最好的. 不過記得你買的產品一定要支援(XML /SOAP / CDE / J2EE), 否則你就會被綁住了.” 然後小公司只好吃鱉,疲於加上這些沒什麼用的功能。

對小公司來說,fire and motion 表示,你必需讓時間站在你這邊,每天都前進一些,這樣軟體才可以每天每天變的更好,客戶越來越多,這就夠了。不用去想偉大的策略。

分類
JavaScript Programming Web Design

ajax 傳送格式比較

雖然有了ajax framework來即時傳送資料,但是這個資料的格式該怎麼辦呢?如果這個ajax應用很簡單的話,也許用自訂的文字格式即可,但如果複雜些,目前有三個選擇,XML,HTML,JSON。

The AJAX response: XML, HTML, or JSON?