隨手扎
【讀書筆記】學徒模式-優秀軟體開發者的養成之路
書名:
- 學徒模式-優秀軟體開發者的養成之路
- Apprenticeship Patterns(原文)
- 軟體開發者路線圖:從學徒到高手(陸譯)
讀完日期:2020/10/31
推薦指數:★★☆☆☆
這本書我是因為看到別人的書評筆記才去找來看的,其中最重要的幾點是因為有些與我想法相符,我想更了解作者還有什麼想法。這當中有許多想法或許與現在的主流思想不同(我認識一些求快而不懂原理的人),所以或許並不那麼值得推薦。但如果你是正在專研一項技術知識路上的旅人/學徒,這本絕對值得看看同為路上的人怎麼想。
STRT原則1
不過先插個題外話的筆記。這是一個說故事的手法,與本書無關,只是單純想到紀錄一下XD。
- Situation(情景)
- Task(任務 / 目標)
- Action(行動)
- Result(結果)
OMG!我發現我以前紀錄過同樣的東西。
行為模式
不知而不知其不知者,愚者也—避之!
不知而知其不知者,惑者也—授之!
知之而不知其知之者,蘇者也—醒之!
知之而知其知之者,覺者也—從之!
— Isabel Burton女士
本書中有不少我覺得值得紀錄的引用,會用上面方式紀錄下來。
幾種得以學習的模式:
- 暴露無知(放下面子)
- 正式無知
- 只求最差
- 持續學習
- 紀錄所學
- 分享所學
- 深入挖掘
本書中還有許多模式,我也只是紀錄下幾個我感觸特別深的,特別對我有啟發的。
成長型思維模式(Growth Mindset): 如果你願意鑽研一件事,你就會做的更好,一切也將得以改善。
努力是使得你聰明能幹的東西。而失敗不過是引導你下次嘗試不同方法的激勵機制。
學徒模式
- 我猜它基本上是指擁有這樣一種態度:對於已經做完或者正在做的事情,永遠都有一種更好、更聰明或更快的方法來完成它。(P28)
- 我們認為「不依賴於任何人向你提供的方案,靠自己找到處理問題的建設性方法」的內在動力是非常有價值的。(P28)
學徒期
最基本的學習情形是這樣:一個人幫助一個知道自己正在做什麼的人,從而讓他學到東西。
—Christopher Alexander等,《A Pattern Language》
現代學徒期的概念主要是一種心境:你認識到自己處於起始階段,哪怕你已寫程式多言;而且你想採取措施從你所處的環境建立自己的學徒過程。
成為學徒的方法,是你發現自身的不足,正視自身的不足,然後捨法嘗試補足它。
我們可以從容不迫地培養學徒開發者,因為我們面對的是過剩的問題,而不是短缺的問題……如今的開法者數量比我們需要的多,而我們缺少的是好的開發者。
— Peter McBreen, 《Software Craftmanship》
空杯心態
如果你自認為已經了解夠多,就像滿水的水杯,無法在容下更多的水。你應該認識到你需要換更大的容器,裝下更多的水。
白色腰帶
通常,每一步都該有進門的感覺。這是初學者的心 —— 一種正在"成為"的狀態。
— 禪者的初心你應該放下已有的認知。正入Yoda在電影星際大戰2中所說:「你必須忘記已經學到的東西」
係上白色腰帶,是基於這樣一種認知:係上黑色腰帶的選手知道該怎麼做,而係上白色腰帶的練習者別無選擇只能去學習怎麼做。
白色腰帶是一種認知,認知到自己應該學習。
暴露無知
暴露無知,最簡單的方法就是問問題。但說起來容易做起來難,如果要問的人認為你已經知道了答案,做起來就更難。別管那麼多,堅持要問!
暴露無知可以你讓更正確的融入環境(總是問問正確應該怎麼做,即使自身已有想法定見),反饋亦會對你有所收穫。別害怕失敗、別害怕被人認為無知。
針對"暴露無知"模式中列出的項目,努力學習其中的每一向,每學會一種就把它從列表中劃掉。這些新的知識又會揭示你以前沒有注意到的新空白;別忘了把這些新發現的空白也加入列表中。
這種作法我也已經無意識的在做了,當前也學習到不少東西,更發現許多自己不明白的空白。
漫漫長路
在程式開發學習上,真正需要一生的努力,還有不段學習實踐的進取心。
—極限編程實施
通常技藝精通的目標無法快速達到,這或許與現在諸多人的觀念背道而馳,但你得知道你選擇的是漫漫長路。
每當你向著技藝精通的目標邁出一步,你的目標就會像著更遠的方向移動兩步。
要把臻於精通的目標作為一生的努力來擁抱。
學著愛上這個旅程。— 精通(Mastery)
自訂路線
如果你需要轉到一個在等級上不太重要的角色才能保持自己不脫離路線,那可以考慮"漫漫長路"模式並比較一下兩者的相對重要性:是(短期)更響亮的頭銜和更豐厚得薪水重要,還是一個更符合自己的目標,從長期來看能讓自己飛得更高的公司重要。
只求最差
作為最差,待在高技術團隊之中,你有更多老師可以學習。
情景分析
你的成長超出了團隊的需要,甚至可能超出了整個開發組織的需要。
問題描述
你的學習速率曲線已經變平。
解決辦法
讓周圍多些水平比你更高的開發者。找一個更強大的團隊,在那裡讓自己成為最弱的成員並擁有成展的空間。
正視無知
讓大腦放下所有不重要的東西,一種好的記號(notation)
使大腦關注於高級問題,效果上就相當於提高了人類的智慧等級……任何專業和行業的技術名詞,在那些沒經過專業訓練的人們看起來都是哪裡理解的。
但這並不是因為它們本身很難。相反,它們無一例外地是為了讓事情更簡單才被引入的。—數學引論
這讓我想到這個月面試的一家公司,認為JS的let
只是var
的另外一種寫法Orz。程式語言之所以會增減功能,正是社群認為有所必要。
同樣的設計模式、架構模式、框架本身等等,或許有一定學習門檻,但這也是隱藏了諸多無須關注的細節,好讓設計本身專注於高層次問題。
同樣的,我雖然了解C/C++,也略懂組合語言、作業系統和網路,卻喜愛使用Python來解決我多數問題,正式因為Python可以讓我在更高層次上思考。但這不代表你不應該去了解更細節的部份。
不要讓你對它的精通阻礙了自己對於其他語言的學習和使用。健康的職業生涯會把你帶入軟體開發領與多采多姿的語言洞天。每一種語言都為你提供了使用不同模式來解決問題的機會。……安逸於服務器端程式的學徒應該考察一下用戶界面設計。
不同的領域知識是可以相互補足的,對於程式語言。學過C結構化程式語言、C++/Java物件導向程式、tcl命令式程式、Lisp/Haskell函數型程式設計。每種設計方式都有可能有其特別適用的場景,甚至帶入不同語言的設計方式,可能擴展你的視野。
你不應該"嫁"給任何特定技術,而應該有足夠寬的技術背景和經驗基礎,使自己能針對特定情景選擇好的解決方案。
— 程序員修煉之道——從小功到專家
持續學習
學會那些本來不會做的事情,常常比去做已經會做的事情更加重要。
— 敏捷軟體開發生態系統
這一關鍵是劃出一些時間,在一種沒有壓力、又充滿樂趣的環境中開發軟體:沒有發布日期、沒有外界打斷。Dave Thomas如此評說實踐:「他必須讓人感到輕鬆,因為如果你不能放鬆,你就不會從實踐中學到東西。」
我也比較喜愛在無壓力的環境下學習。
在《Programmer at Work》一書中,Bill Gates說:「對於程式能力最精細的測試就是給程序開發人員大約30頁的程式碼,看他能多快通過閱讀並理解它。」……那些能直接從原始碼中快速汲取知識的人很快就能成為更好的程式開發人員,因為他門的老師就是世界上的每一個程式開發人雸寫下的一行行程式碼。
我自認自己有部份這樣的能力。
(看過一些朋友寫的程式,並隨後詢問過。或許我該去看一些大型開源項目了?XD)
學習模式、慣用法和最佳實踐,最好的方法就是閱讀開源程式碼。看看其他人是如何編寫程式碼的。這是一種保持自己不落伍的優秀方法,而且是免費的。
—— Chris Wanstrath(2008年Ruby大會)
使用原始碼
行動指南
挑選一個演算法精深的開源項目…..瀏覽項目程式碼,記下讓你覺得神奇的演算法、資料結構和設計理念。然後寫一篇部落格,描述一下項目的架構,著重突出自己的新思想。
且行且思
自我反省是困難的,但我相信我們能從失敗中學到的東西比成功中學到的更多。
—— Norm Kerth, 《Project Retrospective》
記錄所學
你也不應該低估寫作本身的威力……
你會失掉更大的目標感。但寫作能讓你後退一下
並完全想通一個問題。即使最怒氣沖沖的演說
也能使一位作者達到某種程度的深思熟慮。—————
如果你認為一樣東西有趣,你就能學到有趣的東西。
—— Atual Gawande, 《Better》
同樣的我以前也紀錄過這樣一段話:
无论是否是技术人员,我觉得都应该坚持写作。写作带给你的是思维的总结,因为有些事情你只是去想,貌似是很简单。当你去深入思考,其实又是另一个境界。
深入挖掘
說認真的,這個模式我原本沒啥感覺,直到看到:
找來RFC 2616讀一讀,它描述了HTTP 1.1; 還有RFC 707……有了對HTTP的深入了解,試著實現基於RFC 707的客戶端和服務器。…
雖然我沒去讀過RFC 2616(當時對我來說太硬,現在應該也不軟),但我還真搞過一小部份HTTP 1.1的伺服器處理邏輯。
分享所學
單純紀錄一下:
有些東西是不能分享的,一定要記住知識還是有道德維度。在分享經驗前,要考慮這種經驗是否完全屬於自己。它可能是機密,或可能給他人造成損失。
Apprenticeship Patterns by David H. Hoover and Adewale Oshineye. Copyright 2010 David H. Hoover and Adewale Oshineye. 978-0-596-51838-7
https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/