1.【預測再驗證|架構論述】 Day 02 畫過一張目標模組圖,並定了一條規則:「core 之間只能依賴 core:common」。現在 repo 裡有十幾個 Gradle 模組。下面每一小題都先寫預測和依據,再跑指令驗證。
不看任何 build.gradle.kts,畫出目前專案模組之間的依賴圖,每條邊標明是 api、implementation,還是只在測試時用到。接著回答:
build.gradle.kts 裡親手寫的,有多少是 convention plugin 幫你加的?驗證:./gradlew :app:dependencies --configuration devDebugRuntimeClasspath,加上讀 build-logic。
拿這張圖跟 Day 02 的目標圖比:多了哪些模組、少了哪些、哪條邊的方向跟當初畫的不一樣?每個差異,是計畫改了,還是實作偏了?當時的理由要去哪裡查?
重編的漣漪。下面三種改動,分別預測 ./gradlew :app:assembleDevDebug 會重跑哪些模組的 Kotlin 編譯:
core:common 改一行 internal 函式的實作。core:common 改一個 public 函式的簽章。feature:login 改一行。驗證:每次改完都加 --console=plain 跑一次,數出不是 UP-TO-DATE 的 compile…Kotlin 任務,跑完還原。api 和 implementation 會讓這三個答案差多少?
指標。每一項先寫預測,再寫你會用什麼指令量:
./gradlew koverHtmlReportUnit 的行覆蓋率,最高和最低的各是哪個模組、大約多少?assembleDevDebug 要幾秒?上面第 3 小題的增量建置又要幾秒?量完以後,挑出跟預測差最多的那一項:你原本的理解錯在哪裡?
這些數字裡,你會把哪幾個寫進文章?哪幾個看起來漂亮,其實什麼都說明不了?挑一個你願意每週追蹤的指標,說出它變差時你會做什麼。
最後回答:這張圖和這些數字,哪一個能證明「重寫之後比較好維護」,哪一個證明不了?
我的回答:(待補)
2.【模擬面試追問|取捨與交付】 路線圖排了 30 天。Day 01–12 有對應的程式碼,也打了 day-NN tag。從 Day 13 起,大綱只有開頭兩題,路線圖上的 feature 都還沒寫,包括任務列表、磅秤、拍照上傳、掃描、地圖、定位、交接。
這段時間的程式碼花在路線圖以外:
設計文件的待辦清單累積到三十幾條,其中有幾條要後端改。
面試官看完你的系列,不看下面的大綱,依序追問:
最後用三句話寫「沒做到的事」:沒做到什麼、為什麼沒做到、你打算怎麼處理(做、不做,還是交給誰)。
我的回答:(待補)