株式会社PRUMでエンジニアをしている人見です。
日々、プログラミング学習や実務の中で
つまずきやすいポイントを整理して発信しています。
PRUMについて気になった方は、
コーポレートサイトもご覧ください。
▶ 公司官網
― 為什麼審查會出現錯位 ―
在前篇,我把審查中發生的事情整理為以下5個階段的流程。
- まず 內容是否正確 を確認する
- 內容被整理後,會看見 不足的資訊
- 資訊整理後,會看見 表達上的問題
- 表達整理後,會看見 結構上的問題
- 最後會看見 與其他文件的整合性
審查之所以會來回往返,並不是單純因為錯誤很多。
是因為 被檢視的視角會逐階段增加。
審查也是一個 解析度逐步提升的過程。
那麼在實際的現場,審查是如何進行的呢。
在後篇中,我會在分解審查結構的同時,整理面對審查的各種視角。
談到審查時,常會有人以「好的審查」「不好的審查」來評論。
但實際現場上,審查經常是混合型的。
多數情況下,審查會以下列三者之一,或它們混合的形式進行。
最常見的審查類型。
「哪裡怪怪的」
「不容易理解」
「請在這裡修改」
審查者會對內容有違和感。多半審查者自己也處於
「用感覺可以判斷,但要說明很困難」
的階段。這種情況下進行的審查就是所謂的 氛圍審查。
教育學者 Donald Schön 將熟練者的思考稱為 Reflection in Action(行為中的反思)。
熟練者一邊操作一邊判斷情況,會直覺地找到問題。
因此雖然會有「總覺得不對勁」的感覺,卻可能無法立即把它語言化。
其次常見的是「請這樣修改」的審查。
例如:
・這裡請改成條列式
・請按這個順序調整
就為了以下目的來說:
・遵守截止日
・完成交付物
這類審查是非常合理且務實的。在實務現場,常有把「先完成成果」擺在教育之前的情形。
最後是教學(教育)型的審查。
這類審查會解釋「為什麼會有問題」。重點有三個:
- 指摘(指出問題)
- 理由(為何是問題)
- 思考的提示(如何思考或判斷)
例如下面這段審查:
「這段說明讓註冊條件不易讀取。規格上電子郵件驗證為必填,電話號碼為選填。把條件改成條列式會比較好閱讀。」
這樣的審查不只是要求修正,還會把 判斷基準本身一併共享。
審查中被共享的並不只是修正的方法。
多數情況下,還會共享像是:
這些都是 規格書上未寫明的判斷基準。
審查也是一個 把尚未成為語言的判斷基準共享出來的過程。
哲學家 Michael Polanyi 把這種知識稱為 Tacit Knowledge(默會知識)。
他留下了一句著名的話:
We know more than we can tell.
意思是人們知道的東西,超過了能用言語說明的部分。
審查的目的不是單純找出錯誤。真正的目的在於
共享思考方式
審查前,只有「新人本身的思考」,但審查後會變成「新人本身的思考 + 審查者的視角」。
就這樣,判斷基準會逐步增加。也就是說,審查可以被視為
把經驗者的思考安裝進新人身上的機制
如果在審查中一直被要求修正,不要只是想著「又要改了」。
或許應該想的是:「可能還有尚未被共享的視角存在。」
審查也是一個逐步接收經驗者視角的過程。當那些視角累積到一定程度,某天你可能會突然發現:
自己已經站在寫審查的一方了。
PRUM 的工程師中,超過 95% 是從無經驗錄用。歡迎到公司官網看看。
原文出處:https://qiita.com/hitomin_poke/items/568cc5e9b6050522611e