J021｜工程師和數學家在原始碼閱讀上的思維差異是什麼？
更新於 發佈於 閱讀時間約 1 分鐘
「 閱讀原始碼 (Source Code)是有技術的，要從以下的順序逐漸詳細化來閱讀：
01 如果有解說內部構造的文檔，就先讀
02 讀目錄資料夾 (Directory)的構造
03 讀檔案 (File)的構成
04 調查各種簡寫
05 了解數據(Data)的結構
06 把握函數所建立的關係
07 閱讀函數 」
這一段關於閱讀程式碼的框架，摘錄自日本作者西尾泰和[1]的著書，
《エンジニアの知的生産術 - 効率的に学び、整理し、アウトプットする》[2]的第21頁，
引發我對數學背景的人看「編程 Programming」的思考。
數學系的訓練，與上面閱讀原始碼的優先順序，本質上是反過來的。
在數學的訓練中，是先把函數定義的非常清楚，
再進一步去看函數應用在具體的數據上會發生什麼行為，
然後就到此為止，不太會再有進一步的討論。
但如上面西尾泰和所述，工程師看事情的角度，
是先掌握全局，然後再進一步細化每一層的細節。
而根據我這幾年與工程師背景的學生合作的經驗，
優秀的工程師的思維，
真的是先思考整個系統最後要的輸出是什麼，
接著看有什麼是需要當作輸入的，
然後再進一步思考「輸入->輸出」中間需要經過哪些環節，
每個環節的原料以及成果物又是什麼。
如此不斷細化，其實每週都能進展，
而且問題會愈問愈詳細，解答也會愈問愈精細，
然後10-12週的Progress就能有很具體的成果。
看來我需要多練習這種工程師思維，
從輸出開始，然後定義好輸入，然後找到實現的手段。
將工作流建立起來，然後一步一步去實踐過程，
感覺這樣才是真的在鍛鍊「編程 Programming」的能力。
留言0
查看全部
你可能也想看
Google News 追蹤
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「蛤！？到底什麼是編碼？網路上都查不到一個簡單的定義！」
剛進研究室的你，被教授指派了許多任務，其中一件是要把質性資料給「編碼」，你是不是也像我一樣霧煞煞QQ
快點進來看看，我幫你統整了一篇簡單易懂的說明，讓你快速了解編碼是什麼！！
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
最近有新的訂閱者加入，
想趁這個機會再分享一次學習心法與建議給第一次練習的讀者、同學們。
如果你本身已經很熟練演算法，那隨機挑題目練習ok，可以測試觀念是否正確，並且驗證寫code的效率與正確程度。
如果是剛畢業或還在學，以前沒有打過程式競賽。
想開始有系統地增強演算法&資料結構的能力
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
這個系列的文章主要專注於物件導向到函數式編程的差異與分析，並針對概念與機制上的不同進行比較。很多人說物件導向和函數式編程沒有哪個比較好的問題，只有哪個比較適合的問題，然而我並不這麼認為，我透過這一系列的文章從各個角度討論它們之間的優缺點就是為了闡述我的觀點。物件導向錯在沒有理論基礎，但它贏在熟悉性，
解決電腦上遇到的問題、證明正確性、探討效率
並且很著重溝通，說服別人你做的事是正確且有效率的。
內容：
計算模型、資料結構介紹、演算法介紹、時間複雜度介紹。
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
「蛤！？到底什麼是編碼？網路上都查不到一個簡單的定義！」
剛進研究室的你，被教授指派了許多任務，其中一件是要把質性資料給「編碼」，你是不是也像我一樣霧煞煞QQ
快點進來看看，我幫你統整了一篇簡單易懂的說明，讓你快速了解編碼是什麼！！
這篇文章探討了工程師在如何有效提升自己，強調不僅僅是多coding，而是要對程式碼有更深層的理解。隨著職涯發展，工程師需要從單純的技術執行者轉變為團隊領導者，具備解決複雜問題和與他人有效溝通的能力。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
最近有新的訂閱者加入，
想趁這個機會再分享一次學習心法與建議給第一次練習的讀者、同學們。
如果你本身已經很熟練演算法，那隨機挑題目練習ok，可以測試觀念是否正確，並且驗證寫code的效率與正確程度。
如果是剛畢業或還在學，以前沒有打過程式競賽。
想開始有系統地增強演算法&資料結構的能力
資料的統合
在程式設計中，其他人通常關心是否注意到執行的細節。作為程式設計師，主要應該關心的是程式的表現，但往往忽略了很多細節，這些細節可以決定程式的好壞。程式的好壞很大程度上取決於資料的統合，也就是資料是否被正規化。
不同類型的資料在系統中呈現一致
正規化可能對一些人來說聽起來很抽象，有些人
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
這個系列的文章主要專注於物件導向到函數式編程的差異與分析，並針對概念與機制上的不同進行比較。很多人說物件導向和函數式編程沒有哪個比較好的問題，只有哪個比較適合的問題，然而我並不這麼認為，我透過這一系列的文章從各個角度討論它們之間的優缺點就是為了闡述我的觀點。物件導向錯在沒有理論基礎，但它贏在熟悉性，
解決電腦上遇到的問題、證明正確性、探討效率
並且很著重溝通，說服別人你做的事是正確且有效率的。
內容：
計算模型、資料結構介紹、演算法介紹、時間複雜度介紹。