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

(147)

| 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.

36 Reviews

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

    (La recensione si legge meglio presso il mio blog: http://www.jhack.it/blog/2014/09/14/joel-on-software/)

    Questo libro deve (MUST, RFC 2119) essere letto da chiunque lavori nell'ambito dell'informatica, sia questi programmatore, project manager, com ...(continue)

    (La recensione si legge meglio presso il mio blog: http://www.jhack.it/blog/2014/09/14/joel-on-software/)

    Questo libro deve (MUST, RFC 2119) essere letto da chiunque lavori nell'ambito dell'informatica, sia questi programmatore, project manager, commerciale, direttore tecnico, amministratore delegato, ecc. Aiuta a capire cosa significa creare un software dal punto di vista di uno sviluppatore diventato CEO di diverse aziende.

    Devo dire che non conoscevo questo Joel Spolsky: magari non vi importa sapere che abbia lavorato nel team di sviluppo di Excel negli anni '90, ma sicuramente è interessante sapere che si tratta del co-fondatore di Stack Overflow e, attualmente, CEO di Stack Exchange Network. Se non avete mai sentito parlare di Stack Overflow e lavorate nel mondo dell'informatica, beh, forse c'è qualcosa che non va.

    Il libro deriva direttamente dai post presenti sul suo blog, http://www.joelonsoftware.com/, e tratta di tutto ciò che gravita intorno ad un progetto informatico con particolare attenzione per i programmatori e chi li deve guidare. Come svolgere colloqui per assumerli, come metterli a loro agio nell'ambiente lavorativo e come (non) farli interagire con tutte le altre figure di disturbo presenti in un'azienda. Per quanto riguarda il project manager, mostra come creare un team efficiente, interagire con altri team ed altri ruoli superiori, così come trattare con i clienti.

    Salendo nella scala gerarchica parla di strategie per affrontare il mercato, citando esempi di progetti vincenti o falliti, spiegandone le motivazioni che ritiene abbiano portato a tali esiti.

    Detto così sembrerebbe un classico libro noioso di gestione aziendale, ma sia per come è scritto, sia per il fatto che non si perde in teorie astratte, ma descrive casistiche realmente accadute a lui o intorno a lui, è davvero spassoso e quasi mai noioso. Infatti, l'ho letto sostanzialmente in un giorno effettivo.

    Essendo io un analista sviluppatore mi sono ritrovato perfettamente nelle vicende da lui descritte, sia nel bene che nel male e riporto quello che lui stesso ha chiamato "The Joel Test", che può essere utilizzato per capire se la propria azienda sia virtuosa o meno nel trattare chi vi lavora e nel produrre qualcosa di buono.

    The Joel Test

    Do you use source control?
    Can you make a build in one step?
    Do you make daily builds?
    Do you have a bug database?
    Do you fix bugs before writing new code?
    Do you have an up-to-date schedule?
    Do you have a spec?
    Do programmers have quiet working conditions?
    Do you use the best tools money can buy?
    Do you have testers?
    Do new candidates write code during their interview?
    Do you do hallway usability testing?

    Per quanto alcuni punti possano sembrare scontati, vi invito a vedere quale punteggio raggiungete e vi stupirete di quanto ci sia ancora da fare.

    Cosa non mi è piaciuto di questo libro? Se Joel fondasse una religione, sarebbe il dio di se stesso e si venererebbe contemplando la propria perfezione.

    Is this helpful?

    Jhack ❦ said on Sep 14, 2014 | Add your feedback

  • 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

Book Details

Improve_data of this book