---

highlight: obsidian theme: healer-readable

---

友情提示 本文字數為5800 預計需要15-20分鐘的閱讀時間

可以閱讀下面的【提綱】並挑選感興趣的內容瞭解細節

歡迎各位掘友在評論區與我交流 感謝你的時間~

寫在前面 & 提綱

簡單介紹下個人背景：23屆校招生 7月份以暑期實習生的身份加入阿里巴巴 並於九月轉正

本文旨在總結下這段時間的成長並對不足之處加以反省~

充滿曲折的2022已過，在迎來2023的全新成長節奏之前，就讓這份略有些遲到的小結，作為實習三部曲的終章，我2022年終總結的最後一塊兒拼圖吧~

---

在阿里實習了三個月，寫過業務、做過技術需求、也犯過一些錯誤踩過一些坑，本文將從幾個角度回顧下這段時間的成長（採取的敘述方式為實習期間做過比較有感觸的事兒 + 對應的收穫、教訓 比如 1.1-【業務需求】移動端webview開發這件事兒就對應著 【程式碼質量】嚴謹的程式碼規約... 等感悟）希望能對大家有所啟發——

• 1-改bug、寫需求
  • 1.1-【業務需求】移動端webview開發
    • 【程式碼質量】嚴謹的程式碼規約、程式碼倉庫管理規約、Code Review流程
    • 【未來發展】瞭解前端技術體系
    • 【專案管理】更好地把控開發週期
    • 高度密集任務處理能力
  • 1.2-【技術需求】完善了一個組內用於回溯文件的工具
    • 協同文件的技術原理
    • 瞭解、改進一個技術型專案的過程
• 2-熟悉部門的核心業務
  • 2.1-瞭解較為核心的業務、我現在&未來的工作與這些業務的關係
    • 拓寬視野
    • 對未來的自己所處的賽道更清楚
  • 2.2-以一名實習生的角度體驗部門產品，發現優點、挑出缺點
    • 瞭解了調研產品的方式、思路
    • 鍛鍊了產品思維
• 3-程式設計師生活的一些碎片
  • 3.1-開發、交付日常
    • 找到記錄開發文件與敲程式碼的平衡
  • 3.2-入職初期 新人如何平穩落地？
    • 和主管、師兄、同事們快樂地溝通、學習
  • 3.3-待人接物
    • 不卑不亢 低調務實
  • 3.4-刺激的轉正答辯
    • 在日常工作中提前準備好答辯材料（日常要注意量化好工作量）
    • 如何進行一場高質量的答辯？
      • 詳略得當的ppt、答辯話術
      • 提升總結能力！不要反覆說車軲轆話！

提綱差不多就是這樣，那麼 下面來總結下這段時間的收穫吧~

第三段實習——大釘釘事業部~

1-改bug、寫需求

1.1-【業務需求】移動端webview開發

從【修改缺陷、迭代小需求】（目的：熟悉專案程式碼、架構）到【參與重要版本迭代】，業務需求佔據了我實習的大部分時間，這段時間的開發經歷也讓我收穫頗豐

下面來具體聊聊這些收穫👇🏻

• 【程式碼質量】嚴謹的程式碼規約、程式碼倉庫管理規約、Code Review流程
• 【未來發展】瞭解前端技術體系
• 【專案管理】更好地把控開發週期
• 高度密集任務處理能力

【程式碼質量相關】程式碼、倉庫管理規約 & CR那些事兒

• 【程式碼規約】：阿里這邊的程式碼規約貌似和Airbnb那一套是一樣的，肝業務的同時別忘了寫出優雅的程式碼哦（當然了 程式碼寫得太醜Code Review也過不了）~

• 【倉庫管理規約】：需要注意的是如何有效地在一個大型專案中進行協同開發

  • 我所在的專案組採取的是兩週一迭代的方式，一個小模組有時可能會有三四個人一起開發，養成小步提交併及時進行cr的習慣可以避免在封板前還要手忙腳亂地解決衝突、重新做cr
    • 另外把大需求劃分成小塊進行commit也更方便自己量化產出 答辯時候更好說~
    • 話又說回來了 其實大部分同事還是會選擇開發完一個大需求再去做cr、合併入分支hhh 總之把握好一個平衡 保證自己可以按時完成任務就好咯 個人認為打出點提前量也是個解決思路

• 【Code Review】為什麼要進行CR？合理、高效的CR流程是怎樣的？如果有疑問的話 可以讀讀這一篇——一文梳理Code Review方法論與實踐總結

  • 分享下部門的CR流程：請兩名本次迭代相關的同事進行review（我們一般是直接找組內同事看一看程式碼規範、有沒有優化空間、會不會有風險）最後再找一位專案負責人做最後的質量把關 這樣“費時費力”做CR的目的上面這篇文章說得很全面——提前發現缺陷、統一規範和風格、進行知識分享，學習同事們優秀的編碼思路並瞭解各個模組的業務細節、達成團隊共識...總之 如果cr流程執行得合理 好處就是很多~

【未來發展相關】瞭解前端技術體系 拓寬個人技術棧

2014年迎來無線時代，移動端逐漸成為業務的主要陣地，前端的技術重點也逐步從PC轉向無線

客戶端的能力可以給頁面帶來更大的提升，React Native等跨端框架可以讓前端將能力延伸到客戶端領域

回顧下我這幾段實習經歷過的業務——

• 京東實習那段時間做的中後臺 無非就是藉助元件庫實現各種表單 各種列表 複雜一些的場景涉及一些視覺化庫的使用
• 美團實習時的業務則與搭建平臺、低程式碼平臺強相關 主要業務場景是移動端
• 在阿里這段時間同樣是聚焦於移動端 藉助國際化庫實現多語言

這幾段實習下來，也讓我對前端人未來的職業發展，需要深入挖掘的技術專長有了更多思考——我應該如何塑造作為一名前端的不可替代性？

拿我來說 未來（加入釘釘之後）我的技術棧應該會與webview開發&一些團隊產品相關，並在完成這些業務的同時儘可能地拓寬技術廣度（瞭解一切能提升開發效率、質量的技術）——

• 【工具】用於打包、自動化測試等工程化工作的庫...
• 【體系化方案】前端監控平臺的使用 根據平臺反饋資料及時發現問題並找到解決方案...
  • 找到問題並解決的過程需要一定的經驗 還是多踩踩坑吧~
• 【效能】可用於提升專案效能的技術 注重載入效能、渲染效能...
  • 如何減少白屏時間？
  • 如何高效渲染海量資料？
  • 如何合理利用快取？

高度密集任務處理能力

• 同時接手幾項任務，如何保證按時完成所有內容？

短時間內寫了好多要求嚴格（且需求變化頻率極高！！經常寫著寫著1.0版本就把需求迭代到新版的2.0版本了。。）的業務 然後自然而然就把處理高度密集任務的效率提上去了

所以 為了少做無用功 寫著寫著發現需求不太合理 我們應該在開始做之前想好對應需求大致的實現方案並及時與產品、後端、UI溝通好細節

另外 個人覺得高效處理任務的方法論可以按照👇🏻下面這樣 按照較為嚴格的專案管理方式進行思路清晰的開發工作 規定好需求排期 在一個大迭代中留好buffer（緩衝時間）避免耽誤整體開發進度！

【專案管理相關】把控開發週期的方法論

• 入職初期經常出現錯誤評估需求用時的情況另外就像上面提到的一樣 碰到過幾次寫著寫著需求就變了的情況

反思了一下 覺得出現這些問題是由於自己專案管理、需求評估能力有所欠缺 遂請教了一位同事，得到了如下的方法論——

• 【1】拆分任務——畫腦圖；
  • 抽絲剝繭 細化任務
  • 
• 【2】把控風險——使用應用表格-表格檢視、甘特圖檢視記錄排期，使用Teambition及時溝通風險；
  • 強推一下使用多維表（的表格檢視、甘特圖）進行記錄排期的操作 個人感覺這個方案不管在協同場景還是在個人場景 都是很高效的！——
  • 
• 【3】開發過程
  • 根據prd與設計稿構思出技術方案並簡單記錄；
  • 及時與設計、產品、後端進行溝通，避免被動、照本宣科地完成需求，而是在開發過程中不斷思考：
    • 這個需要是否應該這麼做？
    • 這個需求該怎麼做？
  • 不僅僅要開發任務，更是要以owner意識去看待這部分內容、仔細梳理需求的資料鏈路

1.2-【技術需求】完善了一個組內用於回溯文件的工具

• 協同文件的技術原理
• 瞭解、改進一個技術型專案的過程

這個技術需求的細則這裡就不提及了 主要聊聊這個過程中一些可通用的方法論——

協同文件的技術原理 & 做技術型需求的過程

感興趣的朋友可以看看下面這個技術分享 其中第一段就是有關於協同文件的原理——

線上Excel表格技術難點講解

這也是做技術需求的第一步：瞭解基本原理 那麼接下來就是做技術型需求的流程——

• 寫好技術方案並讓有相關領域經驗的同事給把把關
• 確定一下技術需求做出來是否有實際價值 如果價值不大 思考一下應該如何提升其實用性
• 排好期 開始開發~

當然了 我做技術需求的經驗還比較少 回溯工具的通用性並不高 後期還需要再瞭解更多效率提升相關的技術需求~

2-熟悉部門的核心業務

2.1-瞭解所在部門較為核心的業務、我現在&未來的工作與這些業務的關係

• [x] 拓寬視野
• [x] 對未來的自己所處的賽道更清楚

釘釘，讓進步發生~

實習期間 我對自己所在部門主要業務有了一個全面且細緻的瞭解 同時也對公司整體的市場狀況有了基本認識 多少是有點命運共同體的感覺hh

當然了 雖然嘴上說著“要接觸核心業務 要了解哪塊兒業務更核心 領導更看重” 但是 作為網際網路研發新人 要先把通用的coding能力、職場軟素質鍛鍊好 在業務上先獨當一面再說咯

至於所在賽道鑽研的深度 還是需要慢慢來~

2.2-以一名實習生的角度體驗部門產品，發現優點、挑出缺點

• [x] 瞭解了調研產品的方式、思路
• [x] 鍛鍊了產品思維

• 背景：剛剛加入團隊的新人對於釘釘文件產品的心智大多都是一張白紙，這時候看問題的角度比較有參考價值
• 任務：輸出一篇文件初體驗
• 動作：
  • 一、從不同使用者的角度，闡述對釘釘文件的使用體驗；
  • 二、細化到釘釘文件產品的各個模組，談談自己對這些產品的第一印象、個人認為的產品優缺點（並提出一些改進建議）

上述過程也是讓我接觸到了產品的一些工作日常——調研一些友商產品並站在全域性的角度上思考產品是否有哪些可以提升的點

整個過程還是很有意思的！尤其是當時提到的一個改進小建議，這兩天發現被採納了 感覺成就感和參與感滿滿！

回想一下自己三段實習 心態也是有一系列的變化——

• 從剛到京東時的“來啥活兒幹啥事兒，悶頭寫程式碼”；
• 到美團期間被主管提醒著“多以產品的思維去看問題”，但是依舊有點不明所以；
• 再到釘釘之旅：終於是對產品思維稍微有了一些認知
  • 平時在使用任意一個產品的時候，都會很敏感、主動地去找尋痛點、bug，從而進一步思考應該怎麼改，技術方案可能是怎樣的？
  • 接需求的時候思考：這個需求的意義，該不該有這個需求？是否應該換種途徑、展示方式實現需求？

3-程式設計師生活的一些碎片

3.1-開發、交付日常

找到記錄開發文件與敲程式碼的平衡

之前提到 我在美團實習那段時間 每個需求都要求嚴格走完一套流程——拉人開需求分析會並確定排期、寫技術文件、開發、自測、交付給測試

在釘釘這段時間 慣性地延續了之前的開發方式 發現 誒 怎麼好像時間有點不夠用？經過幾次緊鑼密鼓地需求開發之後得出結論——在大量的業務需求面前 一些流程可以從簡

• 比如需求分析會 在需求開發之前 有疑問在小群裡溝通好即可 有疑問及時提出來就好 大家時間都很寶貴 再協調時間去開會。。
  • 時間變成碎片之後 大家效率都低 這就沒必要了
• 比如技術文件 不一定非要記錄下來 自己看一眼需求 心裡有個大致的解決方案就好 太複雜的那種需求 可以簡單記錄一下 也不用特別規範（畢竟組內是沒有這個要求的）

3.2-入職初期 新人如何平穩落地？

和主管、師兄、同事們快樂地溝通、學習

很幸運很幸運地又一次碰到了超負責超nice的主管和師兄（之前京東美團同樣得益於此 獲得了很棒的實習體驗）這段時間也是經歷了一系列的成長過程👇🏻

• 從最開始被動地在需求評審會上接受任務；
• 到自己開發過程中不斷踩坑、慢慢主動向設計、產品、後端同學自信地輸出自己的想法；
• 再到養成較好的owner意識，主動去找到問題並與產品溝通後進行處理；✅
• 不斷迭代後，獲得新的需求記錄方式，形成了任務跟進的方法論
  • 接需求 —— 在開工之前想清楚有沒有什麼坑 與其他模組是否會有衝突 是否有可以複用的地方
  • 跟進需求 ——
    • 合理排期
    • 如果遇到可能出現的風險與問題 要及時與產品 後端 UI溝通，不要踩了坑浪費了時間再去提問
  • 完成需求 ——
    • 自測下是否有bug
    • 小步提交每個模組的程式碼並注重程式碼質量 合理拆分commit
    • CR時候做好註釋 方便同事看

3.3-待人接物

不卑不亢 低調務實

我這人屬於比較人來瘋 社交牛逼症那種感覺 另外就是有時候有點咋呼 樂意跟朋友們吹牛x啥的 沉不住氣~

這一點吧 說來慚愧 也是因為和同事們一起玩耍的比較多 才能發現自己這方面的問題 在此也是非常感謝主管大大沒有放棄我 真誠地給出了一些待人接物方面的建議 現在哥們兒多少是沉穩一些了😄

總結了下 之後待人接物要注意把握一個度 —— 不能太卑微，也不能太高傲；不能太張揚，多低頭做事，但也不能一直埋頭苦幹、不去溝通。——“不卑不亢 低調務實”

3.4-刺激的轉正答辯

我算是23屆校招生all in轉正的一個鮮明例子 所以這段實習期間壓力其實還蠻大的 這裡分享一些轉正答辯的經驗 希望能對你有所啟發~

當然了 轉正答辯與晉升、述職答辯有一些通法 在這個過程中 希望可以一起思考🤔一下

在工作的過程中提前準備好答辯材料

下面這部分內容借鑑了雲謙大大知識星球的內容 也有一些自己的感觸~

• 就像上面【待人接物】模組提到的一樣 不能一直埋頭苦幹
  • 平時肝需求的時候要留意一些硬指標（比如程式碼量 組內沉澱的文件量）
    • 可以養成小PR的習慣 合理拆分commit 一個commit做一件事兒~
    • 多沉澱文件 教學相長&擴大自己在公司技術圈裡的影響力
  • 要清楚自己所在這條業務線的目標 比如我所處的業務線是DingTalkA 那就不光要忙活好自己手頭這點DingTalkA下面的小需求 還要知道DingTalkA這個業務的規劃 多和同事、老闆聊一下
• 要善用技術達成業務目標
  • 想想我們DingTalkA這條業務線有哪裡有可以提升的空間
  • 找出提升點並主動向主管提出自己的想法 一個技術需求也許就誕生了
• 尋找資料支援
  • 上一點的技術需求完成之後是否有資料可以佐證——做這個需求之前如何 做這個需求之後如何
  • 平時可以和運營、產品多聊聊 瞭解下大老闆對於某塊業務的重視程度 瞭解下一些具體的資料 這些都是非常非常有說服力的點
• 我們在DingTalkA這個業務線中扮演著怎樣的角色 我們的重要性、不可替代性體現在哪裡~

如何進行一場高質量的答辯？

• 詳略得當的ppt、答辯話術
• 提升總結能力！不要反覆說車軲轆話！

上面這兩點我做的就不夠好 有的話反覆提及 不夠有總結性！所以~練習下一句話總結這段實習過程的成長——

通過這段時間的實習，達到了一名前端開發工程師的初步要求：可以規範、按時地完成開發任務，並不斷思考、成長。

唔 這個感覺 差不多對了~

寫在後面

為阿里 為釘釘打個Call

得益於阿里濃郁的企業氛圍和針對實習生制定的一些小活動 這段時間我的實習生活是相當開心的~簡單分享下這段時間的快樂實習生活的一些碎片——

• 絕版的EFC職場（阿里雲的小夥伴搬去了雲谷 唔~）快樂的辦公環境（週末去舍友的辦公室溜達了一下）👇🏻

• 組織實習生一起看電影的活動（衝鴨！實習生）

• 這個是釘釘組織的看電影活動 佔據了一下籃球🏀場 環境愜意得很~

• 作為程式設計師 身體肯定是第一位！（工區配置了引體向上裝置&組織了運動相關的活動）

• 作為一名周邊狂魔 來到阿里真的太幸福了~

花裡胡哨的辦公桌一角👇🏻

展望未來

這段時間的工作學習讓我擁有了較為清晰的職業規劃——

Not only a Front-End Developer, but also a Software Engineer!

• 短期（工作1-3年以內）

  • 【1】紮實的前端基礎能力，作為解決需求的基石
  • 【2】持續提升研發工程師基本功，包括但不限於：
    • 優秀的編碼思維
    • 紮實的計算機基礎知識-計算機網路、作業系統等、...
  • 【3】多看優秀的程式碼、工程，閱讀優秀的文章 並及時沉澱學到的內容
    • 向具有良好程式碼素養的同事學習 瞭解他們的coding方式、思路、對應模組需求 漸漸提升自己對整個專案的熟練度
      • 舉例（之前在內網讀到的一篇文章中有提到這個點）：我負責的需求可能要寫100行程式碼 但我瞭解了與這塊需求相關的1000行程式碼 日積月累 就能大大提升對這個專案的熟練程度
      • 最終目的：在某（幾）個專案能做到獨當一面 能輕鬆解決絕大多數需求
    • 書讀百遍 其義自見✅ 每日學習、輸出感悟
  • 【4】對組內專案深入地瞭解、思考（初步確定下自己的興趣、組內&部門對於這部分業務的重視程度）

• 長期（上述的短期“業務多面手”任務完成之後）

  • 深耕某一領域
    • 可以從老闆的OKR裡找一個有思路&感興趣的點[doge]
    • 可以從組內專案某一個值得注意的點著手
  • 找到自己感興趣的內容，深挖下去
    • 不斷嘗試各個方向並與對應領域的優秀前輩聊，慢慢找到感覺

## 感謝看到最後的你~

最後由衷感謝下實習期間同事們給出的無私幫助 希望大家之後都能前兔似錦~

也感謝讀到這裡的你 如果有什麼想要交流的 歡迎在評論區留言 希望我們的靈感可以碰撞💥出更絢爛的火花~