初次見面。我是在 PRUM 株式會社擔任工程師的，すもも🍑。
我每天都會整理並分享在程式學習與實務中，容易卡關的重點與思考方式。
如果你對 PRUM 感興趣，也歡迎到公司官網看看。
▶公司官網
數學苦手的文組人也沒問題，成功克服 IT 的邏輯思考與條件分支
對於文組出身、正在學習並準備轉職成工程師的人來說，應該有不少人在條件分支或迴圈這一帶卡關過吧。
我自己最初學到這些內容時，也曾經誤以為「這種東西一定要有數學天分才能理解」，然後拿自己跟身邊一起學習的夥伴比較理解速度，結果有一段時間非常沮喪。
實務中所需要的，不是複雜的數學公式
提到工程師，大家常常會聯想到熟練運用艱深數學公式的形象，但在實務中的許多場景裡，只要理解國中程度的四則運算，以及「如果 A，那麼 B」這種基礎邏輯，就已經足夠了。
因為複雜的計算本身，電腦或 AI 都能比人類更快速且更精確地完成。
人類被要求的，不是自己去計算，而是思考「在什麼條件下，要讓它以什麼步驟處理」這件事。
條件分支與迴圈，其實是日常生活的一部分
「條件分支」或「迴圈」這些詞本身，或許就帶有某種數學感，讓人先緊張起來，這可能也是其中一個原因。
不過仔細看內容，其實和我們日常生活中不自覺在做的判斷幾乎一模一樣。
「如果下雨就帶傘，沒下雨就不帶」
這就是很標準的條件分支。
「每天早上在同一時間起床，做同樣的準備」
這就是迴圈的概念本身。
實際的程式設計裡，也會出現幾乎相同的情境。
例如「對登入中的使用者顯示專用畫面，未登入時則顯示登入畫面」這就是條件分支本身；而「對清單中的每一項商品逐一計算折扣價格」這類處理，則正是迴圈的概念。
再稍微深入一點來看，「是否登入中」在系統裡，會被儲存成代表「已登入／未登入」的某個值，而條件分支只是去確認那個值而已。
這和日常生活中用眼睛判斷「是否正在下雨」其實做的是同一件事，只不過在程式裡，是看放在名為「變數」的容器中的值來做判斷，差別只在這裡。
這麼看來，程式設計中的邏輯思考，也許不過是把我們在日常生活中不自覺進行的條件判斷與重複動作，拆解得更細，重新整理成更精確、更簡潔的機制而已。
線性思考困難時可以做的事
不過話雖如此，腦中懂了，實際開始讀程式碼或寫程式碼時，還是有可能再次混亂。
這種時候，可以試著做下面這些事：
- 不要把它先當成符號或公式，而是先換成日常的日文／中文口語來思考
- 與其先想「為什麼不能動」，不如先用日文／中文把「想讓它做什麼」寫下來
- 不要在還搞不懂的情況下硬往前走，先用最小的例子實際跑一次確認
- 不要跟周圍人的學習速度比較，只記錄自己卡住的地方，之後再回頭看
尤其是最後一點，我自己開始刻意注意之後，感覺不必要的焦躁少了很多。
總結
即使在條件分支或迴圈上卡關，也通常不是因為自己沒有數學天分，而只是還不習慣這種寫法，所以才感到困惑而已。
與其在意自己數學好不好，不如更重視能不能意識到「在什麼條件下，要怎麼運作」這種指示的組裝方式，我認為這重要得多。
如果你想更進一步培養逐一仔細追蹤條件與流程的感覺，也推薦可以試著解題基本資訊技術人員考試科目 B 中會出題的偽語言演算法題目。
一開始可能會因為不熟悉記法而感到困惑，但隨著反覆練習，你會逐漸自然地讀懂處理流程。
PRUM 的工程師多數都是以無經驗者身分錄用的。
如果可以的話，也歡迎到公司官網來逛逛。
▶ PRUM 招募頁面
我們也經營了一個整理對工程師有幫助文章的網站。如果有興趣，也歡迎看看。
▶ 對工程師有幫助的文章網站
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
