Hooray! You have added the first book to your bookshelf. Check it out now!
Create your own shelf sign up
[−]
  • Search Digit-count Valid ISBN Invalid ISBN Valid Barcode Invalid Barcode

Joel e il software

By Joel Spolsky

(148)

| Others | 9788804540571

Like Joel e il software ?
Join aNobii to see if your friends read it, and discover similar books!

Sign up for free

Book Description

Joel Spolsky ha pubblicato il suo weblog, www.joelonsoftware.com, per offrireai lettori dei suggerimenti che potessero migliorare il mondo dellaprogrammazione. Dopo pochi anni le sue competenze tecnologiche, il suocaustico senso dell'umorismo e le su Continue

Joel Spolsky ha pubblicato il suo weblog, www.joelonsoftware.com, per offrireai lettori dei suggerimenti che potessero migliorare il mondo dellaprogrammazione. Dopo pochi anni le sue competenze tecnologiche, il suocaustico senso dell'umorismo e le sue qualità di scrittore gli hanno permessodi guadagnare lo status di guru della programmazione. Il suo blog è conosciutoin tutto il mondo informatico e oggi non solo offre collegamenti a più diseicento siti Web, ma è stato anche tradotto in più di trenta lingue diverse."Joel e il software" affronta i diversi aspetti della programmazione, dal modomigliore per scrivere del codice, fino al modo migliore per costruire unufficio nel quale si scrive del codice.

35 Reviews

Login or Sign Up to write a review
  • 1 person finds this helpful

    *** This comment contains spoilers! ***

    只讀完頭三章已足夠俾最高評價﹐尤其說明 Unicode 那篇實在是每個寫程式的人都應該閱讀一遍。他提出的約耳測試也是很一個好參考﹐可惜本人任職的公司只做到兩三分...Orz

    他指出微軟不斷更新產品版本和程式庫是一種邊走邊開搶策略﹐這思考角度對我來說很新鮮﹐環顧四周﹐很多成功的軟件公司的確不會將核心技術建立在其他軟件公司開發的技術上﹐大多是將最基本的程式語言客制化到適合自己使用﹐甚至重寫編譯部份增加效率﹐可以說每一個細節都了解透徹。

    另外有關請人策略和面試的部份很吸引﹐對於「請一個程式編寫員之 ...(continue)

    只讀完頭三章已足夠俾最高評價﹐尤其說明 Unicode 那篇實在是每個寫程式的人都應該閱讀一遍。他提出的約耳測試也是很一個好參考﹐可惜本人任職的公司只做到兩三分...Orz

    他指出微軟不斷更新產品版本和程式庫是一種邊走邊開搶策略﹐這思考角度對我來說很新鮮﹐環顧四周﹐很多成功的軟件公司的確不會將核心技術建立在其他軟件公司開發的技術上﹐大多是將最基本的程式語言客制化到適合自己使用﹐甚至重寫編譯部份增加效率﹐可以說每一個細節都了解透徹。

    另外有關請人策略和面試的部份很吸引﹐對於「請一個程式編寫員之前﹐不叫他露兩手怎行」的確很有道理。但我認為比起寫程式﹐閱讀別人程式的能力也很重要﹐因為除蟲和更改程式的時間一定比寫程式多。

    最後他也有提供如何應乎公司上下級的策略﹐這很實用﹐的確是我等程式開發人員每天都需要面對的問題。

    唯一需要抱怨的是書中他對 Excel 的過去實在說得太多了 XDDDD

    Is this helpful?

    Micwallo said on Jul 21, 2013 | Add your feedback

  • 1 person finds this helpful

    久仰大名已久的一本書

    作者文筆風趣,成為我上下班通勤的短暫時間的重要部分
    前幾篇讓自己了解到程式設計生涯上還有很多可以進步的地方
    後面則是比較如同書名般的專案管理的部分

    很推薦給有志成為專案管理的人,或許可以從其中得到許多東西

    Is this helpful?

    Jimms Hsieh said on Aug 25, 2012 | Add your feedback

  • 1 person finds this helpful

    原心得發佈於網誌http://blog.amowu.com/2012/06/blog-post.html

    激勵是有害的, 主要是說考績制度對程式設計師是不通的
    工作切換有害無益, 讓程式設計師只專注一件事情
    絕對不能把程式碼重寫(這裡不是指重構)
    冰山一角理論, 冰山有90%是在水面下, 大部分的軟體, 那些漂亮的使用者介面通常只占10%的工作, 而背後90%的程式設是看不到的, 如果再考慮一半時間都在抓蟲, 那使用者介面就只剩5%, 如果只計算介面中的視覺部分, 那客戶真正看到的, 只有1%......, 這並不是秘密, 真正的秘密是非程式人員根本不知道這件事......
    約耳測試:
    你有使用原始 ...(continue)

    激勵是有害的, 主要是說考績制度對程式設計師是不通的
    工作切換有害無益, 讓程式設計師只專注一件事情
    絕對不能把程式碼重寫(這裡不是指重構)
    冰山一角理論, 冰山有90%是在水面下, 大部分的軟體, 那些漂亮的使用者介面通常只占10%的工作, 而背後90%的程式設是看不到的, 如果再考慮一半時間都在抓蟲, 那使用者介面就只剩5%, 如果只計算介面中的視覺部分, 那客戶真正看到的, 只有1%......, 這並不是秘密, 真正的秘密是非程式人員根本不知道這件事......
    約耳測試:
    你有使用原始碼控制系統嗎?
    SVN, CVS, Git, Mercurial...
    你能用一個步驟建出所有結果嗎?
    準備一個Script擋, 只要執行這個腳本, 就能一次搞定從最新原始碼快照到自動建立釋出產品的過程
    你有進行每日編譯嗎?
    提交原始碼到版本控制系統前, 一定要編譯並且沒有出現錯誤, 因為別人也想下班
    你有沒有問題資料庫?
    記錄已知的Bug清單, 每筆Bug需記錄:
    1.重現問題的完整步驟
    2.應該看到的結果
    3.實際看到的結果
    4.被指派的負責人
    你會先把問題都修好之後,才寫新的程式嗎?
    愈晚修正問題, 之後付出的代價成本愈高
    你有一份最新的時程表嗎?
    程式設計師討厭排時程, 但牽扯到業務人員的決策規劃, 擁有時程可以強迫自己決定要作哪些功能, 並剔除不重要的功能, 以避免過度膨脹
    1.使用一些PMS工具
    2.時程表簡單就好
    3.每個功能應該包含多項任務(Task)
    4.只有實際要寫該程式的程式設計人員,才能排出該項目的時程
    5.要把任務分的很細(以小時為單位)
    6.紀錄最初和目前的估計
    7.每天更新已消耗時間
    8.把休假時間算進去
    9.把除錯時間算進去
    10.把整合時間算進去
    11.把緩衝時間算進去
    12.絕對不讓經理縮短估計時間
    你有寫規格嗎?例如: GDD TDD
    又是一件程式設計師討厭的事情, 設計初期的階段還看不出來, 愈後期程式碼一多修正的代價就愈高, 應貫徹沒有規格就不寫程式的原則
    程式設計人員有沒有安靜的工作環境?
    需要讓程式設計師進入沈浸狀態(in the zone), 因為這時候是最能全神貫注, 生產力最高的狀態, 所以, 要有安靜的環境!!!
    你有沒有用市面上最好的工具?
    你需要兩個以上的螢幕, 以及編譯程式不會讓你抓狂的電腦配備
    你有沒有測試人員?
    省下測試人員的錢並不是真正的節省, 因為你會付出更慘痛的代價, 這裡本書第22章有非常有趣的見解
    是否在面試時要求面試的對象試寫程式?
    你會不請魔術師表演幾招就直接僱用他嗎, 當然不會
    是否進行過走廊使用性測試?
    隨機找幾位使用者試用你的產品, 他們可以幫你發現程式中95%應該注意到的使用性問題
    約耳認為軟體開發有各種不同的領域, 他把它分為五個世界:
    熱縮封膜軟體(Shrinkwrap)
    簡單來說就是一般常看到的軟體, 商業軟體, 共享軟體或開放源碼軟體等, 特色就是使用者眾多, 通常都有替代商品, 所以開發者必須把東西做得更簡單易用才行
    內部用軟體
    這類軟體通常是公司針對特定狀況下能執行就可以了, 因此開發起來較容易, 但開發者較不容易從中得到成就
    嵌入式軟體
    這種軟體的特性是被放在硬體裡, 且幾乎無法更新, 因此品質要求會比平常高出許多
    拋棄式軟體
    為了產生其他東西而暫時創造的軟體, 當達到目的後就不會用到了, 例如格式轉檔軟體
    遊戲軟體
    遊戲開發的經濟學是打擊型, 有些遊戲擊出安打, 但更多的是三振, 要賺大錢必須用很多的遊戲來平衡失敗的損失, 和嵌入式軟體類似, 版本修正代價大, 所以品質要求高
    紙上原型製作的重要性
    別花太多時間想抽象的架構問題, 邊開火邊移動!!!
    寫程式並不是量產, 也不是工匠技藝, 它是一種設計
    約耳認為面試人員應該問的問題:
    簡介
    最近專案的問題
    尋找熱情
    好的人選會仔細地把事情由各個層面解釋清楚
    如果專案是由多個人一齊負責, 尋找擔任領導角色的跡象
    不可能的問題
    程式問題
    你有什麼問題嗎?
    小員工也能做大事, 這本書是關於軟體管理, 不過有時候你並沒有那個權力去改變組織, 如果你只是圖騰柱底層的一位程式設計人員, 約耳給你一些建議:
    去做就是了
    沒有每日編譯伺服器嗎?自己架一台就對了
    利用病毒性行銷的威力
    團隊沒有在用版本管理系統?
    自己先用吧, 等問題發生之後, 他們就會來找你了
    建立一個卓越圈
    找一些支持你的人一起改善吧
    讓笨蛋無害
    有時候會有天才花兩個星期寫出一點點程式, 而且爛到不可思議, 這時候你會想花15分鐘把這段程式重新寫過, 請忍住, 因為這是把這個白癡拖住幾個月的機會, 這段期間他不會再造成其他地方傷害了
    遠離干擾環境
    提升自己的價值

    Is this helpful?

    Amo said on Jun 12, 2012 | Add your feedback

  • 1 person finds this helpful

    E' la raccolta di una serie di articoli apparsi sul blog di Joel Spolsky che sono rintracciabili anche su internet. La sua visione della gestione purtroppo rispecchia la mentalità microsoft (joel ha lavorato 3 anni al team di sviluppo Excel) del "its ...(continue)

    E' la raccolta di una serie di articoli apparsi sul blog di Joel Spolsky che sono rintracciabili anche su internet. La sua visione della gestione purtroppo rispecchia la mentalità microsoft (joel ha lavorato 3 anni al team di sviluppo Excel) del "its good enough" ossia anche se un prodotto software fa schifo va bene lo stesso purche' si arrivi in tempo per la consegna e non si dia un vantaggio alla concorrenza. Se si applicasse questo concetto in altri campi della produzione industriale saremmo freschi! Pertanto, lo consiglio come buona lettura ma non sempre sono d'accordo con lui.

    Is this helpful?

    Antedoro said on Dec 27, 2011 | Add your feedback

  • 1 person finds this helpful

    裡面好多文章其實已經在網站上看過了,非常謝謝那些志願翻譯的人們。

    蠻多實用的建議:像是邊開火邊前進、用excel來管理時程、避免獎勵員工,以願景與福利吸引員工、公司的策略等等,很值得一看的書。

    Is this helpful?

    elleryq said on Dec 8, 2011 | Add your feedback

  • 2 people find this helpful

    一直沒有想到要看這本書,因為要去教召五天怕閒的發慌,所以就到公司書櫃借了這本書來翻。

    本書真的的確是本值得閱讀的書,很難想像這些都是10年前寫的東西,到了10年後的現在,大部分的發生狀況現今仍適用。由其是目前身為PG的各位,如果目前您為PM,而是由PG升上來的話,應該感覺會更強烈。小弟本身是由視覺介面設計升到管理階層,故當中提到關於程式設計的部分看的就比較沒有感覺。

    有個有趣的章節『約耳測試:邁向高品質的12個步驟』,來看看我們的狀況:

    01.你有使用原始碼控制系統嗎?,有,Tortois ...(continue)

    一直沒有想到要看這本書,因為要去教召五天怕閒的發慌,所以就到公司書櫃借了這本書來翻。

    本書真的的確是本值得閱讀的書,很難想像這些都是10年前寫的東西,到了10年後的現在,大部分的發生狀況現今仍適用。由其是目前身為PG的各位,如果目前您為PM,而是由PG升上來的話,應該感覺會更強烈。小弟本身是由視覺介面設計升到管理階層,故當中提到關於程式設計的部分看的就比較沒有感覺。

    有個有趣的章節『約耳測試:邁向高品質的12個步驟』,來看看我們的狀況:

    01.你有使用原始碼控制系統嗎?,有,TortoiseSVN
    02.你能用一個步驟建出所有結果嗎?,無
    03.你有沒有每天都重新編譯建立(daily builds)嗎?,有,PM會要求
    04.你有沒有問題追蹤資料庫(bug database)?,有,Gemini
    05.你會先把問題都修好之後才寫新的程式嗎?,有,PM會要求
    06.你有一份最新的時程表嗎?,有,PM會持續更新
    07.你有規格嗎?,有,SA或SD會撰寫相關文件
    08.程式人員有沒有安靜的工作環境?,無
    09.你有沒有用市面上最好的工具?,有
    10.你有沒有測試人員?,無,但有依專案需要的兼職
    11.有沒有在面試時要求面試對象寫程式?,無
    12.有沒有做走廊使用性(hallway usability)測試?,無,有可客戶代表測試

    12項目中有達成7項,差一點就及格了,不過改善空間看來頗大。或許可以以此為指標做為改善的依據。

    以下摘要整理印象較深刻的內容:

    ※邊開火邊移動:

    做就對了!!!市場永遠停不下來,不須專牛角尖於不重要的地方。筆者以Netscape失敗的地方,就是在於花了兩年時間修改核心,讓自己的市占率由80%降低至20%,最後一蹶不振。

    ※專案品質:

    當有專案做不完的時程規劃,應該是要刪減功能,而不是要求加班;加班並不會讓產能與品質更好。

    ※經濟效益:

    專案中所做的任何事情與工作,皆須思考是否有經濟上的效益(包含測試),做有效益的事情,而不是有問題就必須要處理。

    ※客戶永遠不知道自己的需求:

    客戶永遠不知道他們要什麼,別再期望客戶知道他們要什麼。除須了解客戶應用領域的知識外,擁有好的使用者介面技能是很重要的,於客戶溝通上才能有較具體的結果。

    ※激勵是有害的:

    因為有些事情是無法用績效明顯去評斷的。如在公司中是開心果、黏著劑、歡樂觸媒的角色,往往可是所散布出的是凝聚向心力的特質,但這些是無法明顯在工作中看出,造成績效低略,影響從業人員的信心,但對於團隊卻又是有效益的。故筆者建議,所有的激勵與績效僅能當作『參考』,永遠不能當作是實質的獎懲依據。

    全文請參閱:http://goo.gl/6QXlg

    ※求職者的熱情:

    裡面有一章節是在講述面試時需注意的事情,其中有提到,面試時要尋找求職者的『熱情』,而一個人的熱情可從眼神中或口語言談中表現出來。另好的人選會把事情的層面解釋得很清楚,也可代表可以清楚的和對方溝通。

    另面試時除了你問我達或填寫題目的方式外,可考慮舉辦『主題簡報』。也就是要求求職者針對某個議題進行約15分鐘的簡報,於簡報中說明該議題的特性,特殊處,觀察結果等,並讓未來要一起合作的專案成員參加,並於進行時提問。於面試後再由大家一起決定是否要錄取該求職者,這個做法似乎也是不錯,因為更可清楚評斷該員未來進來後與同事間相處的可能性。

    ※測試人員的必要性:

    組織中一定要有測試人員。但測試人員的工作沉悶與重複,需給予測試人員擴展職涯的願景,並鼓勵如可自行撰寫腳本或自動化測試套件。而測試人員的流動率一定會較高,可考慮臨時人員,但可能會有無法進行測試的風險。

    ※工作切換的問題:

    於開發人員來說(應該也適用於其他角色),工作切換(多工處理)有百害無一義,切換工作所需喚回的工作成本代價更高。例如撰寫程式時必須要了解如變數命名,資料結構,函數命名,程式存放位置等,如果切換工作反而回神所須花更多時間。

    ※環境影響的問題:

    除工作切換對開發人員的影響,還有工作環境對他們的影響,好的工作環境(安靜,不被打擾等)會影響產能。書中提到簡單的算術,我們可以說(依照陳述所暗示的)雖然僅僅打斷程式人員一分鐘,事實上是去掉了15分鐘的產能。以此為例,假設有兩個程式人員Jeff和Mutt, 把他們安排在一個標準呆伯特 (Dilbert – 美國漫畫) 養牛場裡相鄰的開放隔間中. Mutt忘記了strcpy函數的Unicode版本拼法。他可以花30秒自己查出來,也可以花15秒問Jeff。由於人就坐在旁邊,所以他問Jeff。Jeff分心所以就損失了15分鐘的產能(替Mutt省了15秒).

    ※進入障礙的困難:

    不是切換進去有多困難,而是切換出來有多困難。例如要讓原本使用你對手產品的使用者轉移到你的陣營,方法並不是你的產品能讀取對手的格式,而是要讓你的產品可以轉換成對手產品可讀取的格式。

    以作者的舉的例子,Lotus過去是試算表市場最大的產品,MS想要切入,推出了Excel。而Excel最大的轉淚點是發生在4.0推出的時候,而最大的原因是是4.0開始能確實會出Lotus試算表。

    ※開源碼的免費經濟學:

    開放式原始碼各位都知道是免費的,但是否有想過其實周邊所衍伸出的東西是要付費的?如Android系統,系統本身免費,但是Google授權給各家業者(HTC等)時,會從其他地方獲得利益,如Market,GMail等。

    也就是說當商品的價格下降時,互補商品的需求就會增加,觀點是從『整體持有成本』來看,因為整體的價值還是會在,並不會因為某個地方費用較低而影響整體成本。而對公司的策略利益來看,是讓互補品價格越低越好,以至於普及化,才有可能賺到更多的錢。

    ※小心方法論:

    方法論可以讓每個人的表現都提升到不佳但可接受的程度,同時也會產生很多約束,並激怒更多人。也因此公司在導入方法論時(如CMMI),需保有組織內的彈性。書中所提很多的大公司因為組織發展到後面僵化的問題,往往方法論變成組織的毒藥,甚者無法繼續推動。

    總之,這是一本不錯的書,推薦給開發人員與管理階層的您所閱讀 :)

    Is this helpful?

    大頭鼠 said on Jul 30, 2011 | Add your feedback

Book Details

Improve_data of this book