Improve the quality of software development! 6 practical skills for coding 

之前四處工作有時候講習慣了，原本錄音想講品質一直講質量 XDD 上片前一天才發現，所以硬給他改下去 但基本上不影響整支影片想傳達的內容啦 希望觀眾不要見怪，下次會注意細節 😆

組裡面有沒有大神帶真的差很多，以前待過很弱的公司/組的情況下，怎麼亂寫code都沒人糾正。 之後去到一個Code Quality要求很高的地方被罵了/訓練了兩年，實力大增，從此不會寂寞。

有一種賀瓏跑去寫程式的感覺

我朋友：你寫的程式就是一隻鴿子 他正在飛沒錯 但是他是用高速旋轉的頭在飛 不是翅膀

順便分享一些有用的技巧： 如果函數參數過多不知道怎麼處理，以下幾點建議： 1. 像是影片中說的函數違反SRP，應該根據不同行為拆出不同函數。 2. 把函數的參數轉換成instance variable，如果原本函數的物件加上新的instance variable變的太複雜，恭喜你發現隱藏的物件，這時候使用extract class把函數跟這些instance variable轉換成class 3. 函數實作盡量抽象化一致，函數名稱要比函數實作細節高一個抽象化層級，這樣函數看起來就很像讀文章。抽象化越接近行為代表越少實作細節，能有效降低參數的數量。 希望能幫助到需要的人 😀

給覺得影片有點長的觀眾，Nic想傳達的其實就兩點: 1. 提高可讀性 2. 降低程式的耦合性(或相依性)，盡可能讓一個funciton只做一件事 可能前端比較少應用到物件導向，套用到物件繼承上也是同樣的概念，能不繼承就不繼承，member 能不設為 public 就不設。上面的概念其實就是 clean code，有興趣的觀眾可以找找這本書，Nic提到的概念裡面都有，也有更詳盡的例子~

Summary: 1. Define your variable with meaningful name . 2. Limit the number of the input parameters of a function. 3. Return conditions to simplify returing True/False with a conditional expression 4. Define your variable in a limited scope. 5. Do only one thing in a function. 6. Use early return to avoid nested conditionals

第四點JavaScript的部分我覺得怪怪的, 範例裡的3個var都是global scope, 本來就可以讓每個function都使用吧? 就算是let或const,宣告在global scope也是每個function都能使用阿。 而function D裡宣告的var socketIsConnected是function scope, 所以跟global scope的var socketIsConnected雖然名稱一樣,但卻互不相干,是兩個獨立的變數吧? 改變function scope的socketIsConnected,並不會影響到global scope的socketIsConnected, let和const也是一樣的,都具有function scope的概念。 var之所以麻煩是因為他沒有block scope的概念, 所以會有很多問題,後來才不被大家喜愛,改用let

最近有一篇 Reddit 有一篇很熱門的 post (幫你想個一個延伸主題 :D) Drunk Post: Things I've learned as a Sr Engineer 裡面有提到一個很棒的概念 Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. 好的程式碼是可以被初級工程師理解。 偉大的程式碼是可以被 CS 大一新生理解。 最好的程式碼是根本沒有程式碼。

這些在clean code都有看過 但使用上常常忘掉 if else在現在還是比較容易出現的 看完又被提醒了一次🥺

賀瓏真的很優秀，脫口秀好笑又會寫程式

拜託請多做一點有關這類型code風格的影片（尤其是有關python的範例）！！！超級有幫助的

很好的學習，沒人帶的這些淺顯易懂的教學真的很好的觀念，以前一些前輩就建議不管再忙再亂，先用心智導圖，魚骨圖，流程圖，先把框架畫出來，不管在單人作業還是除錯或者後續資料建立都很方便，當架構出來了就可以開始用白話文方式寫註解，要做甚麼怎麼做，資料留得來龍去脈，程式流動，串接等，優先順序都可以先被框出來，不管是自己寫還是多人協作幫忙寫，因為架構都好了，閱讀維護，還是加功能刪功能都很方便，也容易讓一些喜歡外行充內行的看出他要的，而不是不斷追問，然後打斷工作，導致一堆無意義的重工修改。當然一些只會嘴的通常看完那些白話的註解後就會自己為很懂跑去邀功，根本不會去在意程式碼實現啥鬼，也會使維護上好做很多。

逆向思維: 如何寫出不可維護的代碼, 提升自己的不可替代性...

筆記: 提升品質可以增加可讀性和可測試性。 提升品質的技巧: 1.有意義的命名 2.傳入的參數量要適當=>太多參數要傳就用object打包一起傳 3.簡化邏輯/條件表達式=>避免不必要的if-else 4.盡量避免使用全域變數=>避免變數莫名其妙被更動或找不到定義導致效率降低 5.一個function就做對應名稱的事，不要夾帶私貨 6.Early return =>可以簡化if-else的層數，但C語言就不能用 謝謝Nic的分享

其實最主要還是 團隊的coding style有沒有統一 各種style 大家都互相覺得別人寫爛code XD

聽完蠻有感的，但大部分公司只喜歡把東西快速做出來，包含工程師也是。導致後來維護都覺得在通靈前人的髒code

感謝nic大 本身非相關科系出身 剛好在山中當大王(沒人帶自己搞) 有一直在修正自己的code 但因為沒人告訴我該怎麼做 即便有用上影片中的技巧也不知道外面的人是否也會這樣使用 看完影片之後稍微放心了 感謝nic大提升信心 讓我知道自己確實是有在進步

說的很棒~clean code 這本書也有提到影片說的這些東西

把if內的條件直接放return符合就true不符合就false真的讚

看VB程式也很痛苦 使用的變數竟然在另一個asp檔裡….

命名的問題，我自己是只讓全域變數的命名有意義，function裡的區域變數就會極簡化，因為有時候變數需要做一堆and or，命名太長的話邏輯式就很容易一行寫不完，這樣也會造成不好debug

要写好一个程序很难，读过《代码整洁之道》《重构，改善既有代码的设计》 很多问题其实都是边界问题，有的时候倾向于这边，有的时候又倾向于那边，重点是明白自己的目的，在从中找到最合适的设计方式。目的改变了，设计也就需要改变。熟悉设计方式，明白设计的目的和优点，在结合自己的目的找到最优解。这是一个过程，而这个过程，也是需要知识量和时间分析来支撑的。《重构》这本书，提供了一个用不断的重构来应对改变的思路，而且提供很多设计思路以及优缺点，就是没有实际场景优点难以明白其中的代理。

真的很多人都會把學校教的壞習慣帶過來，例如一個好好的username就偏偏要打成un，甚至有些人用s1, s2(string 1, string 2)代替 但是自學就比較不會有這個問題，因為自學的時候你有比較多機會會想要去讀別人的原始碼，當你在閱讀你差不多一個月就能發現原來Retrun能這樣用 或者了解到變數名稱應該怎麼取才比較容易讀之類的技巧 最後我認為還有第七點: 確保擴充性 不懂是不是所有語言都可以做到，但是Java是可以透過Reflections做到非常容易擴充的 例如今天你在遊戲好了 (我腦袋只想得出來遊戲@ _ @ 因為我是寫遊戲居多) (我好像還沒說: / 我今年只有14歲 沒寫過使用者之類的有的沒的，寫遊戲居多，但是從8歲左右就開始寫程式了，去年本來還差點不小心創業，至少零成本，並且第一個月就有超過10萬的收入，更何況我在做的是以指數型成長的領域，競爭對手也不多，但之後因為沒地方收錢而放棄了，加上我爸媽還是有點希望我繼續好好讀書，不要每天搞這些有的沒的，所以我爸媽目前還是不知道我目前在寫遊戲的事) (目前的狀況是: 每天只要有空就寫+學程式，這個暑假是每天從起床學+寫到睡覺，中午稍微休息一下，晚上也休息一下，加起來休息兩個小時，這樣下來每天大約寫13小時左右) (現在在另一個團隊寫遊戲，就是當好玩的，順便提升自己的團隊合作技能) (然後最近才剛開始學一些考試真的會用到的技能，但是因為那些東西我很常用到，所以其實做起來很簡單，因為我以前Frontend和Backend都有寫) (所以很常需要用到資料結構之類的東西，在Frontend也很常寫演算法) (離題了: / 回歸正題) 你可能會想要有武器，武器就會有特殊功能，例如: 傷害, 耐久等等的屬性，這時候要擴充一個新屬性(我們假設已經有人幫我們設計好了，所以拋開要每個物品都加一個參數的問題) 很多人的遊戲可能都需要改很基層的東西，例如String getItemDescription()之類的，但是使用Refelction可以超級簡單的完成: 這裡留個例子，是使用Java Annotation + Reflection完成的 @ItemAttribute(name = "damage", languageName = "items.description.harmable.damage") public Integer getDamage(); // 或者 @ItemAttribute(name = "durability", languageName = "items.description.breakable.durability") public Integer getMaxDurablity(); /* 在 getItemDescription() */ Reflections classScanner = new Reflections("me.......items.attributeDatas"); for (Class

在 C 裡面想寫類似 early return 的 pattern, 看過使用 goto 統一出口在 function 末端作處理

想看和写程序有关的影片多一点

其實你說的那些很實用，也不會多花時間，在剛學寫程式的朋友養成這樣的好習慣，真的受益無窮。

if else真的很容易出現，該好好思考怎麼樣避免這種恐怖的波動拳,感謝分享!

100% 同意這六項技巧，這幾點已經算是當前寫程式的標準規範了。 現在碰到多年前寫的系統會更能體會到， 違反這些規則的程式碼所造成的混亂場景有如地獄。

一邊看一邊默默數自己達到幾個 好像全部都達到了欸 我還有一個習慣是function通常會用動詞開頭 variable會用名詞

很棒的影片，值得一看再看^^，希望能持續以「白話幽默」的方式去解讀程式碼意義、如何提高效率品質，以及若遇到接手前人地獄級的程式碼時有哪些技巧去解決等類似影片。

還有一點很重要的是資料流的追蹤 其實寫程式真的可以當成在寫作，只是多數人不知道如何 正確的表達 進而導致後人不知無法理解當時的時空背景 最根本的解決方式是寫完把自己換個角度觀察一下程式碼 如果不理解這些函數、變數，是否能理解當初想做什麼 很多工程師都是功能能跑就好，省略了很多描述的細節，開發是真的快，但未來接手程式碼的人真的能快速理解並調整嗎

我頂多把測試資料塞入滿滿的pikachu而已...想不到還可以module命名用HelloKitty,又學了一招（修蛋幾累

Nic 應該要再補上第七點，真的想精進自己的一些觀念跟技術的話，可以多去看一些Design Pattern，了解到為什麼人家這麼設計，他解決了甚麼，帶來了甚麼好處， 絕對會對你的開發實力大大提升(思維上也是)，我都對我的團隊成員們說，千萬別當一些二流的工程師阿~~~ 共勉之

在一些沒有GC的programming language, 不建議使用第6點early return，在這些沒有GC的coding中，使用early return容易造成memory leak.

第一眼看像賀瓏。 第二眼看像三個字 sunguts 搞得我好亂🤣

品質真的很重要，都重新錄音了 覺得很有趣😂😂😂

這個影片給予我幫助很多再次感謝!

受益良多，剛入門，在這邊跟正在猶豫要不要轉行、嘗試程式語言的朋友們信心 我自己是文組商科，自學搭配工具書，效果也不錯。 大家加油 另外很喜歡你寫的一篇文章「如何成為一個失敗的軟體工程師」

12:37 我寫C的，我并沒有覺得early return沒有不好啊._.? 又提高可讀性，又提高運算效率，可以減少不必要的判斷。 不過有可能是編譯後長度會增加一些的原因，對於CODE存儲區較小的設備是會有這個問題

我接手的程式碼遇過最瞎的就是 明明function是寄信，但CommandName寫delete... 想害誰？

這批真的好純好純,我為了這個訂閱了,請一定要做更多這類相關的內容, 小弟我在小公司上班,很大部分都一人作業,頂多做些singleton,不太需要用到什麼factory 一些design pattern, interface會用 但也是少少用到,git 的rebase更是沒有在用,因為很少有人跟我一起作業,也沒有必要 所以如果面試回答 我都是只能回答教科書寫的內容,不知道到底有什麼作用 (我都自己作業,我怎麼知道程式碼好看可以幹嘛,雖然我會抓底線,但偶爾真的會偷懶不遵守/忘記自己訂的規矩), 我頂多就是說我有做過哪些作品,但寫出一個程式可以運作很簡單, 即便我很想證明它是有很多擴展的空間,短短的面試時間,我還是很難完全的展示出來我的能耐。 面試人也不可能直接看我的code,讓他知道我可以擴充到什麼地步,還是我其實是在滑水 今天有幾點東西讓我印象深刻,希望能多出一些這類相關的,尤其是design pattern的應用,幫幫我這個剛出社會1年的拉基工程師 ps:尤其是範例,真的很棒,讓我印象很深,能完全理解你想表達的概念

10多年前曾經有過一次最爛的維護與變更需求經驗。 一進新公司就被拜託幫忙，協助修改與撰寫某個需要重新上線的功能網站。 前任撰寫者(當時的上司)用了讓人完全看不懂的邏輯方式，命名所有的參數(就是單個英文字母+重複使用)，以及所有的文件檔案(完全不知道什麼意思的縮寫)...。 命名有多離譜，我永遠記得，我當時到唯一大概理解的是裡面內容提到的 super personal 應該就是一般所謂的admin....，並且還用參數sp作為代表。 其他一堆都是 int a , b, c, d....。 每改一個部分就得從第一份文件翻到最後一份文件。 改了一小段就花了半天，根本改不完，當下就已經萌生辭意。 結果那位上司還火上加油，在下班時候，特別跑來和我搭話。 並對我說表示說，他不是科班出身的，程式全部是自學的，所以他的程式碼應該很簡單不難理解，並且他有去在職專班學習，然後都近期都有用課堂上學到的小技巧撰寫....。 我當下聽到很茫然，還以為是下馬威，整個事情，就是要唬弄新人一下給個難關，殊不知我隔天找了其他前輩要了一些既有正在線上的程式備分。 裡面幾乎八成都一樣情況，還都沒註解，後面接手要修改的的人老實說是會根本看不懂的程度，我還問了前輩學長某段程式碼在幹嘛的，明明就他自己寫的當下也答不出來。 二話不說馬上就轉身去提離職了。

Opino lo mismo

最近在看重構與clean code這兩本書 很有感xd 希望以後多分享相關內容～

講得不錯讚讚 另外補充一下，var 作用域其實並不是真的全域而是 function scope 哦 const、let 則是 block scope（左右大括號 '{' 、 '}' 中間的範圍）

我是被演算法推薦過來的XD 因為目前我還是小菜雞，所以想請問Nic大大2件事~ 1.請問目前在軟體開發跟程式撰寫使用到python的機會高嗎? 2.請問Nic大大是用哪款程式進行編寫的呢?

自己有一個小小的問題，第六點中如果if else的邏輯要儘量簡化，那我們上課學那種巢狀迴圈畫金字塔，是不是在實務應用上很少用，甚至可以說是很過時的東西。

最後一個early return我也常用 不過被客戶要求「有其他錯不會一起說喔」 後來就用替代解法，定義一個error object， 原本return處改成填寫object狀態，一樣由上到下跑一次，最後return 該object 缺點是程式還是要跑完，但可以一次知道錯哪些

接手的程式碼(三層for loop): for(i=......) for(ii=......) for(iii=......) 我: 唉~~~~ 我不會怪先前撰寫的工程師, 我只會認為他是在為自己的血汗工時表達不滿 我還看過 for(fuckyou=......) 的程式碼, 真實事件不唬爛......

1. Meaningful naming is better than shorthand 2. Limit the number of incoming parameters, 建议一个function，最多三个参数，如果超过三个可以使用hash或者object 3. Simplify the conditional expression，判断函数直接返回条件判断就是boolean值 4. Variable definition range limit，变量定义在一定的作用域里面，用完就丢，不要放在全局 5. Do only one thing at a time, SRP，一个函数只做一个事情 6. Early return 可以避免过多的 if else

之前改車看過你的影片，現在想學程式又看到你的影片，好神奇的感覺😂 事實證明改車的不一定都是社會底層？

個人看法: 關於第三點condition縮成一行有時候更難閱讀，尤其是condition越來越多時候 我反而會寫成這樣，讓每一行閱讀字數少，也方便下錯誤斷點 或是新增新的條件 // 1. 確認用戶是否超過18歲 if (user.age < 18) { return false } // 2. 確認用戶是否有駕照 if (user.has_driver_license == false) { return false } // 用戶符合條件，可以騎車 return true

被主管刁真的是進步最快的方法...junior 告解中

寫程式的時候必須要有的心態： 之後要維護你的程式的人是一個殘暴的精神病患者，而且他知道你家在哪裡。

個人覺得有test case 比以上的都重要， 有test case 你可以在後面放膽重構

1:48 如果說只是內部區域變數像迴圈的那個，通常應該還是習慣直接給個短短的名稱吧，像 for i in range(5);的i

白牌不如黃牌 黃牌不如紅牌 租屋不如買房 強化車台不如龍骨 西方人改車 東方人也改車 就你的意見一大堆 ****************** 沒聽到slogan只好自己腦補

第三點,我覺得重點是,有時候寫在主段落的判斷式, 可以另外包成一個function,然後透過有意義的命名,之後看到這段Code,可以清楚知道這判斷式要幹嘛, 像Nic影片裡面就很清楚, 這個人能不能騎車 Clean Code 那本書有寫到, 一個好的命名, 就不需要去註解

順便寄 email 那個真的蠻難搞的，有的時候把function 拆得很單一，但其中兩個function 他們就是會一起進行的，例如排序，資料整理完必須做排序回傳給前端，而且這部分已經是寫在Service了，另外開一個service也蠻奇怪的，只要這種狀況一多，若按照大大你的第一個方法，這種Service也會變得越來越多。 總之是個很頭疼的問題，我是習慣放在裡面一起做，因為如果這兩件事沒有任何情況是需要拆分開的話，還是會比較prefer寫在一起

關於第一點，我還看過有工程師function用Lily,Emily然後變數用aa,aaa,aaaa的，我接手的時候根本不知道該不該把這坑留給下一個人 第二點算是受益良多，解決了我的長期備受參數過多的困擾，感謝🙏

這內容真讚，遙想當年在以前在做通訊軟體的公司寫code，看到一系列av開頭的變數，像是 avFile，一直想說我是在pornhub上班嗎？後來才發現av是avatar的簡稱，是給個人頭圖用的相關變數，整間公司沒人覺得有問題嗎？還是這是故意的彩蛋？這問題至今還是未解之謎。

Nesting 的問題在類似 reactjs 的框架真的會讀到死...

曾經遇過variable name 是mark 1至mark 50 不停上下跳找variable 代表什麼 不知道同事是不是很喜歡iron man，直接送我一套iron man 的裝甲，看到十分痛苦

不，你要知道，当你写出谁都看不懂的代码的时候，老板就绝对不会辞退你，因为如果你被辞退了，就没人能看得懂这串代码，也没人能改这个bug，哈哈哈哈哈哈哈

宗旨就是不要搞死以後看代碼的自己和別人，怎樣好讀易懂就怎麼寫 支持Nic大一波～

abbreviation何止給別人看 過一陣子自己回頭看 都要重頭在想一下我寫三小

Early return 让我想起回呼地狱，callback：中国=>回调，台湾=>回呼。

第五點有幫上忙，受教了。最近趕專案確實被這點婊到了幾次。 不過第三點就不好說了，許多情況下不是簡寫或縮略內容就能提升可讀性這麼簡單，同時如果有遵守第五點並且好好寫滿summary解釋清楚，別人根本不需要進去看該function究竟寫了什麼，最好的程式就是不必打開的程式，需要進去看這一點本身就是瑕疵的體現。

Key: 降低維護成本 別管中國用語，專業術語還是用原文，大家都聽得懂

code的可讀性真的很重要，每次看到簡寫還不註釋的就很想砸電腦😂

還好聽下來都是大多已經會考慮的事情XD 只要以前被搞過，就會知道要注意什麼

bool Test(void) { bool Result = false; do { if (false) { break; } if (false) { break; } if (false) { break; } Result = true; } while (0); return Result; } 巢狀判斷式是一個債....簡化是必須的 多個function 的return 點...也是個債 不好的Codeing風格與習慣等同債留子孫...現在留的債...搞不好最後若干日子後..要自己還 例1 if(xxx) A=1; else A=2; 例二 A=2; if(xxx) A=1; 例三 A=(xxx)?1:2; 我偏向 例二 , 例一叫脫褲子放屁 ,例三 比較沒那麼直覺

好多老程都寫ea, kitty這種... =_=

我覺得我這6點都有做到, 但我仍然覺得我不是一個很好的軟件工程師🤣

作为大陆这边的软件工程师，工作5年后你说的这些也太基础了吧？好像大学生在煞有介事的介绍加减乘除。不过还是给你个赞

第5個很有親身感受 許多早期在專案時寫的基本功能function 之後擴展專案規模時卻無法拿來延用 往往都是當初自己在function內做了太多事 造成該function形同跟舊需求綁定 一旦需求改變 就得重寫一個程式碼有7成重複的新function 一來失去了function的延用性 二來多個重複功能的function在未來要對該功能進行調整時也會是個麻煩 （等於每個都要改，而且還不能漏改or改錯）

Guard Clauses 有額外的好處： 會優先考慮 Exception 與 bad path，比較不會遺漏 配合 test case 風味更佳

像是FW的話都用C語言，C語言就很難避免全域變數，但是我通常都是用file來區分不同的模組，所以相互之間不會互相干擾。 拜學校所賜，我的母語是C++。就算用C寫，也會想辦法模組化，以方便物件導向管理。 還有一種變數的宣告時機，這個可能會很有爭議，因為在C語言裡面，很多平台是不允許在function的中間宣告變數。但是在很多比較自由的語言或平台上，我常常會在用到該變數之前忽然宣告然後立即使用。缺點是讀者不容易看到這個funtcion有哪些變數，但優點是很容易把相關的變數整理在一起。尤其是在PC或是手機的APP當中，比較沒有資源匱乏的情況下我很喜歡當場宣告甚至當場new。但如果是在寫FW的話，就真的另當別論。

你提倡多多def 不会让整个code变长 还要拉来来去看不是跟麻烦

想問影片裡用的什麼語言，有點像PY但好像不是

我是寫lua腳本的 以前很喜歡用early return 可讀性高 運算快 但壞處是 資源占用高 有好有壞 將超大的巢狀全變成if return end 會吃超多資源 尤其在thread裡

我前公司在命名方面也是很要求，不能寫註解，不然會被退 所以每次想變數名稱都想很久ＸＤ

換過三間公司狀況都差不多,有些事只能活在理想中，基本上上面的人只在乎功能有沒有在他要的時間完成，code寫的好不好他們看不到，他們不懂也不想懂，剛剛講需求，最好明天就上線，然後每個工程師個性想法也不一樣，都有各自道理，很難一致，有想法的it主管被老闆電久了也會開始妥協，然後就開始爛了..…

可惜這些都知道了😂 下次要不要專門拍一部 Git Commit、Git flow、分支命名的教學? 或是建議的變數命名原則

覺得滿有趣全部看完但不會寫程式的人✋

最不喜歡人寫 if((xxx!=0 && aaa!=1 && kkk=='2') || bb=='abc' && (ccc=='you' && bbq='okok')) , 寫多幾個if 有很困難嗎? 要表現他邏輯很利害?!

队里只有我和老板俩人，他留下来的代码以上六点全中，现在维护迭代的是我，他也不喜欢我做太多的更改。我应该怎么办？

看完好有感觸，目前正在學習階段的我常常聽到，程式碼的品質，但都沒提到[什麼是品質] 謝謝 Nic的無私分享

我不用early return 我都用 try catch 跟 goto了 好用

前陣子寫自動化才發生 call function 結果做多餘的事情 也發現很多人的 if else 都是好幾層再跑 決定來花點時間了解 Design Pattern 了！

我看過用中文命名的,因為用英文會太長且難以命名...

看完發現以前摸索的過程中就已經改過這六點了。 因為以前邊讀書邊趁空檔學著寫點東西，常常跟1個月前的自己協作，然後發現看不懂自己到底在幹嘛。 然後才注意到可讀性很重要，也從此再也不用 ?: 來代替 If

沒有人帶沒關係 當初我就是碰了前人流傳的糞扣摸索出來 像是一大把 global var 分散在各個 swift file 裡 超過三層的 async thread callback (combo global var 改動) 然後想辦法重構成好維護的方式 基本原則很簡單就是想像一個月後打開來看自己寫的會不會想做時光機捶自己 XD

Calculate 的發音是calculate,你唸成calculate了

很棒的分享，這些重點在我之前待過的公司很常在要求 一開始的時候都不知道，要這麼做的原因是什麼 只是就當成習慣而已 直到跟越來越多人合作過之後，才發現TMD超重要阿 臨時別的案子燒起來了需要去救火，發現一大堆亂七八遭或是邏輯很怪的程式碼 光看懂就要看很久了，更何況還十萬火急 遇到這種的真的會崩潰 感謝Nic整理並弄成影片分享!! 喔還有 漂亮的排版也可以讓開發者容易閱讀很多 像是這樣(看"="的部分) $address = '這裡那裏'; $name = '王大明'; $email = 'abc@gmail.com'; 這類的方式，會比較容易閱讀 甚至在能夠縱向選取的編輯器在編輯效率上能有奇效

理想是 一季的只談一季的開發規劃 增加的需求列入下一季的開發方向 根據需求開發著簡潔且明確的程式碼 在有限的時間內 做著有限度的事情 現實是 一季會談一年的開發規劃 增加的需求列如同一季的開發內容 根據原始及增加的需求 快速開發大量骯髒的程式碼 在有限的時間內 完成別人一年才需要完成的事情 程式的乾淨度是很重要，但對於公司來說你沒有在時間內完成大量的開發都是不好的 甚至 當我們說要去做clean code的時候，這是一個沒有產出的事情 公司都未必會讓你去做呢

最怕別人爲了優美啥的，把class的method name寫的超級簡單，比如Open, close之樂的。你妹的，我們整個程式包里有幾千個open，鬼知道哪里call的是你的open。

關於 2，如果參數過多會很難讀懂引數代表什麼，為什麼要傳。如果語言有支援，例如 Dart，可以將不必要的參數變成具名參數；或是在 JavaScript 中使用一個 object 傳入可選參數；或是考慮拆分函式。雖然許多編輯器都有顯示參數名稱的功能。

提议可以说说unittest和test coverage的重要性，说实话有时候product owner或者project manager就是不在乎这一系列的unittest，往往带来了很多连锁techinal debts，不然就是user story永远的被qa弹回，一直处于bug fix状态，还有提议可以说说test driven development的话题，抱歉我是马来西亚人，我的环境都是用英文，不确定有没有华语的说法