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
最近有一篇 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 大一新生理解。 最好的程式碼是根本沒有程式碼。
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
之前四處工作有時候講習慣了，原本錄音想講品質一直講質量 XDD
上片前一天才發現，所以硬給他改下去
但基本上不影響整支影片想傳達的內容啦
希望觀眾不要見怪，下次會注意細節 😆
無所謂的，不要怕支語警察，這樣硬改變更怪
@@gpcgpc810 不是支語警察是術語要講對的基本要求。
@@cyanide929 謝謝你出來示範，支語警察辛苦了。
這邊有個疑問想順便跟大家調查一下，小弟因為很多時候想不到甚麼好的命名方式 我就會打很長 ex:Single_Line_Loop_effect
像這種名命方式算合格嗎?
第五點我常常幹阿XDD.....
組裡面有沒有大神帶真的差很多，以前待過很弱的公司/組的情況下，怎麼亂寫code都沒人糾正。
之後去到一個Code Quality要求很高的地方被罵了/訓練了兩年，實力大增，從此不會寂寞。
哦哦哦 內褲面試官登場！
我一開始也是到沒人帶的地方野蠻生長
後來遇到我師父之後，被電被糾正的情況下
強制升級 code quality ，過程飽受挫折一度認為我應該不適合做軟體開發 XD
跟你差不多也是兩年左右的修行，很感謝我的師父當初願意電我
我覺得能在職場上遇到能夠罵你訓練你的人真的是幸運
感謝泰瑞的經驗分享 😁
想問在沒人帶的狀況下怎麼提升自己的 code quality
現在的工作都沒要求code quality這些，因為一些原因無法立刻馬上換工作
很好奇什麼樣的開源專案適合？
難不成要從超大又複雜的那種專案開始看？
@@mingqp777 我是滿建議針對你寫的領域去找相關的分享源碼來看耶，我目前工作的東西網路上還有辦法找得到相關資源，挑選一些看起來擴充性不錯的來學習XD
我個人寫的時候也會畫圖筆記，對於程式架構也有些幫助
我是沒人電，自己就提昇了，但花了三年....其實初心很重要，當初第一次工作的時候，我每次在開始撰寫時，都會要求自己"拿出自己認知最好的寫法"的方式來撰寫，三年過去了，習慣就養成了
有一種賀瓏跑去寫程式的感覺
靠難怪覺得似曾相識
還在想說為什麼明明是第一次看到卻不覺得陌生xd
我第一眼也以為是賀瓏😂
我一直以為賀瓏會寫程式
真的像
順便分享一些有用的技巧：
如果函數參數過多不知道怎麼處理，以下幾點建議：
1. 像是影片中說的函數違反SRP，應該根據不同行為拆出不同函數。
2. 把函數的參數轉換成instance variable，如果原本函數的物件加上新的instance variable變的太複雜，恭喜你發現隱藏的物件，這時候使用extract class把函數跟這些instance variable轉換成class
3. 函數實作盡量抽象化一致，函數名稱要比函數實作細節高一個抽象化層級，這樣函數看起來就很像讀文章。抽象化越接近行為代表越少實作細節，能有效降低參數的數量。
希望能幫助到需要的人 😀
筆記:
提升品質可以增加可讀性和可測試性。
提升品質的技巧:
1.有意義的命名
2.傳入的參數量要適當=>太多參數要傳就用object打包一起傳
3.簡化邏輯/條件表達式=>避免不必要的if-else
4.盡量避免使用全域變數=>避免變數莫名其妙被更動或找不到定義導致效率降低
5.一個function就做對應名稱的事，不要夾帶私貨
6.Early return =>可以簡化if-else的層數，但C語言就不能用
謝謝Nic的分享
其实最重要一点他没说，写注释！ 比如微软的api都是一堆的参数，外加好多个重载
給覺得影片有點長的觀眾，Nic想傳達的其實就兩點:
1. 提高可讀性
2. 降低程式的耦合性(或相依性)，盡可能讓一個funciton只做一件事
可能前端比較少應用到物件導向，套用到物件繼承上也是同樣的概念，能不繼承就不繼承，member 能不設為 public 就不設。上面的概念其實就是 clean code，有興趣的觀眾可以找找這本書，Nic提到的概念裡面都有，也有更詳盡的例子~
還有沒意義的註解不要寫，看了會覺得很厭煩XD
真的遇過在set_time旁邊註解//設定時間
感謝你的熱心整理 揪甘心
每次覺得有人能看懂影片真的是莫大的安慰 😂
很好的學習，沒人帶的這些淺顯易懂的教學真的很好的觀念，以前一些前輩就建議不管再忙再亂，先用心智導圖，魚骨圖，流程圖，先把框架畫出來，不管在單人作業還是除錯或者後續資料建立都很方便，當架構出來了就可以開始用白話文方式寫註解，要做甚麼怎麼做，資料留得來龍去脈，程式流動，串接等，優先順序都可以先被框出來，不管是自己寫還是多人協作幫忙寫，因為架構都好了，閱讀維護，還是加功能刪功能都很方便，也容易讓一些喜歡外行充內行的看出他要的，而不是不斷追問，然後打斷工作，導致一堆無意義的重工修改。當然一些只會嘴的通常看完那些白話的註解後就會自己為很懂跑去邀功，根本不會去在意程式碼實現啥鬼，也會使維護上好做很多。
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
賀瓏真的很優秀，脫口秀好笑又會寫程式
真的是不可多得的人才
好像還會打桌球耶
還會在地上
滾
我朋友：你寫的程式就是一隻鴿子 他正在飛沒錯 但是他是用高速旋轉的頭在飛 不是翅膀
為什麼你可以傳圖片
It just works.
當你的程式毫無邏輯 卻可以運行的很好.jpg
comment：此程序由bug作为核心运行，切记，请勿修改！
:所以你到底想說甚麼
朋友:你不覺得用高速旋轉的頭在飛的鴿子很帥嗎?
感謝nic大
本身非相關科系出身
剛好在山中當大王(沒人帶自己搞)
有一直在修正自己的code
但因為沒人告訴我該怎麼做
即便有用上影片中的技巧也不知道外面的人是否也會這樣使用
看完影片之後稍微放心了
感謝nic大提升信心
讓我知道自己確實是有在進步
其實你說的那些很實用，也不會多花時間，在剛學寫程式的朋友養成這樣的好習慣，真的受益無窮。
100% 同意這六項技巧，這幾點已經算是當前寫程式的標準規範了。
現在碰到多年前寫的系統會更能體會到， 違反這些規則的程式碼所造成的混亂場景有如地獄。
把if內的條件直接放return符合就true不符合就false真的讚
真的很多人都會把學校教的壞習慣帶過來，例如一個好好的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
厲害 要向你學習
開始學程式一個月，到學習一個小階段半年，到開始工作一年
每次看都是不同的感受，加上最近接到前輩丟出來的專案
隨便一個方法傳了12個參數然後超過20個if/else判斷，整個感觸超深(重構起來也超痛苦...)
真的感謝Nic大的經驗分享，可以淺顯易懂的理解箇中奧妙!讚
除了第2點限制傳入參數以外，其他的我都是在自己的side project，開始變得超級混亂的時候
決定找時間全部重寫時學到的，畢竟沒有人帶，Nic提到的很多東西程式初學者在寫的時候
根本不會考慮那麼多東西，這樣的影片真的很讚!
拜託請多做一點有關這類型code風格的影片（尤其是有關python的範例）！！！超級有幫助的
Nic 的影片已經變成我學習源頭之一，看著你講著我學習中遇到的問題跟你那淡定的臉真的超有喜感
受益良多，剛入門，在這邊跟正在猶豫要不要轉行、嘗試程式語言的朋友們信心
我自己是文組商科，自學搭配工具書，效果也不錯。 大家加油
另外很喜歡你寫的一篇文章「如何成為一個失敗的軟體工程師」
只要你每次撰寫程式時，都願意拿出 "自己所知道最好的寫法" 來撰寫的話，就建議你成為軟體工程師
命名的問題，我自己是只讓全域變數的命名有意義，function裡的區域變數就會極簡化，因為有時候變數需要做一堆and or，命名太長的話邏輯式就很容易一行寫不完，這樣也會造成不好debug
感謝分享
我在寫 golang 的時候也有發現這個社群的 convention
主要是他們希望 life cycle 很短的變數在一定的範圍內可以用簡寫
這個我覺得也 ok，畢竟他們的社群規範寫的滿清楚的
只是我自己寫下來有時候編輯器拉超過一個 pagedown 我就會覺得有點難閱讀了
通常還是會依照個人喜好或是團隊協作方向在做些微的共識上調整
我跟樓主一樣 因為函數名稱都已經說明功能了 函數內的變數就沒有必要取那麼長的名稱 只要能在該函數看得懂就好了 太長反而更難讀懂
if else真的很容易出現，該好好思考怎麼樣避免這種恐怖的波動拳,感謝分享!
最近有一篇 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 大一新生理解。 最好的程式碼是根本沒有程式碼。
感謝感謝，這個我有看過 XD
很有趣的是，在幾年前我師父就有說過類似的話了 😂
品質真的很重要，都重新錄音了
覺得很有趣😂😂😂
XDDD 差點趕不上發佈時間
看在Nic這麼貼心的份上幫忙點個讚
還有一點很重要的是資料流的追蹤
其實寫程式真的可以當成在寫作，只是多數人不知道如何 正確的表達
進而導致後人不知無法理解當時的時空背景
最根本的解決方式是寫完把自己換個角度觀察一下程式碼
如果不理解這些函數、變數，是否能理解當初想做什麼
很多工程師都是功能能跑就好，省略了很多描述的細節，開發是真的快，但未來接手程式碼的人真的能快速理解並調整嗎
很棒的影片，值得一看再看^^，希望能持續以「白話幽默」的方式去解讀程式碼意義、如何提高效率品質，以及若遇到接手前人地獄級的程式碼時有哪些技巧去解決等類似影片。
謝謝你的鼓勵
你提出的主題不錯，剛好我也有相關的經驗，日後會納入拍攝考慮！
這個影片給予我幫助很多再次感謝!
要写好一个程序很难，读过《代码整洁之道》《重构，改善既有代码的设计》 很多问题其实都是边界问题，有的时候倾向于这边，有的时候又倾向于那边，重点是明白自己的目的，在从中找到最合适的设计方式。目的改变了，设计也就需要改变。熟悉设计方式，明白设计的目的和优点，在结合自己的目的找到最优解。这是一个过程，而这个过程，也是需要知识量和时间分析来支撑的。《重构》这本书，提供了一个用不断的重构来应对改变的思路，而且提供很多设计思路以及优缺点，就是没有实际场景优点难以明白其中的代理。
宗旨就是不要搞死以後看代碼的自己和別人，怎樣好讀易懂就怎麼寫
支持Nic大一波～
第四點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
這些在clean code都有看過
但使用上常常忘掉
if else在現在還是比較容易出現的
看完又被提醒了一次🥺
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
講得真的很精準！！
雖然已經沒寫程式兩年了，但對這些Ｄｅｂｕｇ的日子真的還是歷歷在目
以前我在寫程式，最後會給自己一個要求
「任何的Ｆｕｎｃｔｉｏｎ不超過１５行」為主
這樣就會慢慢學到六招實用技巧的做法了
在一些沒有GC的programming language, 不建議使用第6點early return，在這些沒有GC的coding中，使用early return容易造成memory leak.
逆向思維: 如何寫出不可維護的代碼, 提升自己的不可替代性...
寫出被其他工程師詛咒的代碼！🤣
咒術系工程師💪🏻
請左轉去IOCCC 國際C語言混亂代碼大賽
這個不是逆向思維，而是正向思維，因為你先思考了"確定沒有人會來要求或檢查"這件事！
Joe write:
calcTotalAmount(data[] d){
sendEmail("boss@com.tw", "Fck bos*...as* hol.., by Johnny");
}
每當財報的時候，
不小心又做掉了一同競爭升職的同事。
過了2年後，會發現連自己都無法取代自己，每天工作到晚上10點還在抓蟲@@
Nic 感恩啦！正是有您願意拍影片細說，大道上的巨石才一一現形。事非經過不知難，能有這些許多好的工具並非天降，沒看真不知道。
觀點不錯！雖然每個人的說法不見得相同，但方向類似！
最近幫客戶上課，給個觀念
我不求最新的技術，也不用最快的撰寫方法（開發時程或執行成本）
但我會寫出最好維護的方式！
因為就像板主說的，你的程式會被閱讀或修改多次。
一時的省工，將來必定耗時。因為沒有一個程式不需被維護的！需求總是變來變去！
喜歡這樣有條理的分享～收穫滿滿^ ^
第一點跟剛接觸程式設計時老師的提醒一模一樣！
跟模組命名與實際功能連結有異曲同工之妙
講真的不錯，這實用技巧剛好可以來檢視一下自己的程式習慣。
非常實用的技巧, 感謝分享.
不客氣 😆 感謝你的留言鼓勵
第5個很有親身感受
許多早期在專案時寫的基本功能function
之後擴展專案規模時卻無法拿來延用
往往都是當初自己在function內做了太多事
造成該function形同跟舊需求綁定
一旦需求改變
就得重寫一個程式碼有7成重複的新function
一來失去了function的延用性
二來多個重複功能的function在未來要對該功能進行調整時也會是個麻煩
（等於每個都要改，而且還不能漏改or改錯）
耦合太嚴重又很難拆開，尤其沒測試更不敢拆 XD
說的很棒~clean code 這本書也有提到影片說的這些東西
硬着头皮在C#混了2年，抛弃project无数，这些知识真的是刻骨铭心
10:50 波動拳比喻的真好
一邊看一邊默默數自己達到幾個 好像全部都達到了欸
我還有一個習慣是function通常會用動詞開頭 variable會用名詞
表示基本功還不錯，協作起來有一定的舒適度 XD
好實用的幾點技巧，尤其第四點最有感，感謝Nic的分享！
感謝你的支持！
關於第一點，我還看過有工程師function用Lily,Emily然後變數用aa,aaa,aaaa的，我接手的時候根本不知道該不該把這坑留給下一個人
第二點算是受益良多，解決了我的長期備受參數過多的困擾，感謝🙏
可以製造更多工作機會!
第一個是國棟粉嗎 a三小 是要開墮嗎 快笑死
若是我接手，我就直接對他開大
這太噁心了吧，那你接手怎處理的？
軟體工程就是不斷在追求降低時間成本的方法
這集很棒👍
超實用的建議，謝謝 Nic ！已經整理好筆記，要不時檢視一下自己寫扣品質，超感謝～
很開心
自己有慢慢調整
符合上面的條件
在 C 裡面想寫類似 early return 的 pattern, 看過使用 goto 統一出口在 function 末端作處理
goto好用
這種實際上不還是early return嗎？只是強迫他在同一個return裏，但debug還是要往回看，所以有什麼實際好處？
我是寫lua腳本的 以前很喜歡用early return 可讀性高 運算快 但壞處是 資源占用高 有好有壞 將超大的巢狀全變成if return end 會吃超多資源 尤其在thread裡
為什麼 early return 會吃資源?
最近計畫結束開始回頭維護code，基本上每一點都被說中了XD
看完就知道怎麼改比較好，受益良多，謝謝Nic !!
裡面大概有三種技巧就是因為要讓之後交接順利才想出來，但也有3種是我完全沒想到的，感謝你的分享
有意義的命名, 簡化條件表達式, 避免嵌套 if ...這些都只是常識，都是對上過學的人的最低要求, 感謝分享
整理+範例說明的很清楚.
同意1/2/4/5/6, 尤其6在有大量邏輯判斷, 例如申請表單、人員履歷這種欄位多、判斷條件多的功能，early return能讓維護團隊很好理解。
3的例子我個人試為舉得不好：目前遇到新手維護時，return沒有明顯true/false或function不是強型別，常不能直覺看懂。
試舉一例：中華民國民法規定，男性結婚年齡為18歲、女性結婚年齡為16歲。
要判斷申請人可不可以結婚，可以在一個function或類別屬性寫邏輯，功能面判斷時只需取用一行isAgeGetMarried(applicant)或applicant.isAgeGetMarried
例3其實就是：
不要做
If (1 == 2) == true:
Return true
Else:
Return false
而是直接做
Return (1 == 2)
其實最主要還是 團隊的coding style有沒有統一
各種style 大家都互相覺得別人寫爛code XD
順便寄 email 那個真的蠻難搞的，有的時候把function 拆得很單一，但其中兩個function 他們就是會一起進行的，例如排序，資料整理完必須做排序回傳給前端，而且這部分已經是寫在Service了，另外開一個service也蠻奇怪的，只要這種狀況一多，若按照大大你的第一個方法，這種Service也會變得越來越多。
總之是個很頭疼的問題，我是習慣放在裡面一起做，因為如果這兩件事沒有任何情況是需要拆分開的話，還是會比較prefer寫在一起
有些東西可以拆去 Callback 處理
這種好像有event driven pattern 去做
只是真的很難寫…
超級實用的六個技巧!!
維護前人寫的東西時很常遇到，尤其是經手過很多人的Code，然後常常崩潰又不知道怎麼整理XDDDD
最後會決定相信後人，交給之後的人整理(壞
就可以為公司創造就業機會了
@@k2dave64512 去別的公司就業的機會嗎 - -
@@gpcgpc810 當然不是，因為要聘人還技術債
感謝Nic 每次看你影片都覺得學習到很多技巧 謝謝
個人看法:
關於第三點condition縮成一行有時候更難閱讀，尤其是condition越來越多時候
我反而會寫成這樣，讓每一行閱讀字數少，也方便下錯誤斷點 或是新增新的條件
// 1. 確認用戶是否超過18歲
if (user.age < 18)
{
return false
}
// 2. 確認用戶是否有駕照
if (user.has_driver_license == false)
{
return false
}
// 用戶符合條件，可以騎車
return true
原PO用的Python 語體風格比較適合他這樣做。
我用 C# 和 Java 都希望看到明確看到一行 "return false" ， 這代表程式在這裡中斷退出，是很重要的控制點，應該清楚看到，尤其是有一堆必須退出的判斷要處裡時。
but 只傳回一個Value 就很適合只用單行。
這批真的好純好純,我為了這個訂閱了,請一定要做更多這類相關的內容,
小弟我在小公司上班,很大部分都一人作業,頂多做些singleton,不太需要用到什麼factory 一些design pattern,
interface會用 但也是少少用到,git 的rebase更是沒有在用,因為很少有人跟我一起作業,也沒有必要
所以如果面試回答 我都是只能回答教科書寫的內容,不知道到底有什麼作用
(我都自己作業,我怎麼知道程式碼好看可以幹嘛,雖然我會抓底線,但偶爾真的會偷懶不遵守/忘記自己訂的規矩),
我頂多就是說我有做過哪些作品,但寫出一個程式可以運作很簡單,
即便我很想證明它是有很多擴展的空間,短短的面試時間,我還是很難完全的展示出來我的能耐。
面試人也不可能直接看我的code,讓他知道我可以擴充到什麼地步,還是我其實是在滑水
今天有幾點東西讓我印象深刻,希望能多出一些這類相關的,尤其是design pattern的應用,幫幫我這個剛出社會1年的拉基工程師
ps:尤其是範例,真的很棒,讓我印象很深,能完全理解你想表達的概念
Guard Clauses 有額外的好處：
會優先考慮 Exception 與 bad path，比較不會遺漏
配合 test case 風味更佳
第6點好實用!
條理清晰,看到4:41分就必須訂閱給讚,希望影片都是高質素
聽完蠻有感的，但大部分公司只喜歡把東西快速做出來，包含工程師也是。導致後來維護都覺得在通靈前人的髒code
我很久以前還在寫程式的時候 (後來還有升遷，但明顯不是因為程式能力的關係)，就會發現老闆的心理：
* 為了好的 coding style 而花時間做的努力，不算一件事情
* 搞清楚 requirement ，畫出好理解的流程圖，不算一件事情
* 研究程式語言，找出最好的coding 方式，不算一件事情
老闆只懂 "到底做出來沒有!?"，一旦他開始進去 review ，除了 "breakdown 後的小成果"和 "debug" ，他們不懂也不關心，問題是我上列的三件事情都會對進度和debug 有影響。結論就是，不要跟不懂的人鬼打牆，在時間壓力內把東西做出來，期間盡可能不要搞一些搬磚頭砸腳的事情 (i.e. 爛code)，如果上面還是堅持超短開發時間並且持續對他不懂的事 ggyy 的，等於在逼著寫爛 code 讓你和你的團隊生不如死，那就跳槽吧。
工程師 = 靈媒（x
那我應該是那少部分
最近在看重構與clean code這兩本書 很有感xd
希望以後多分享相關內容～
謝謝Nic大大分享，新新新手初學者受益良多!
看完好有感觸，目前正在學習階段的我常常聽到，程式碼的品質，但都沒提到[什麼是品質] 謝謝 Nic的無私分享
之前沒人教過我這些 , 沒想到都是我寫多年後的習慣
我也是…我是老手了
謝謝這影片的人再次提醒我
以前網路沒這麼發達
都沒人教我
我也不知道能看什麼書可以學到這些
这是个很不错的影片对于工程师本身必须要有的技巧。至于团队里，毕竟不是每个工程师的水平都一样，所以团队要有一定基本的编码方式统一。最后，我个人觉得最重要的是要有一个方法能把业务逻辑和执行逻辑分开以便测试和debug。这也能提升维护性。
太實用了 感謝Nic分享 如果可以的話希望可以多分享這類影片 感恩 感謝
好的好的 👌 我多分享你也記得幫我多分享 😆
@@niclin 沒問題👍
可以多發寫程式影片～跟大概解說，像這部影片的技巧關鍵點。讓瞭解程式變得有人性化還有邏輯跟乾淨方便閱讀。
感謝 Nic 分享，這集太重要了！現在再回去看以前寫的 code 真的很毒，這些撰寫原則真的要早點習慣
蠻棒的，講解的主題抓的很精準，希望能有一集分享design pattern
感謝分享。
第3項通常會因為擴充變成需要第6項來支援，再加上不同條件彼此不一定獨立，所以後續又會抽成object。
感謝分享，本身是非程式設計相關出身的，目前已有撰寫C++兩年左右的經驗。
目前依舊還在探索程式碼撰寫風格，看到這部影片提供的技巧 覺得獲益良多
感謝你的鼓勵，能有幫助到你一些些都是我的榮幸
講得不錯讚讚
另外補充一下，var 作用域其實並不是真的全域而是 function scope 哦
const、let 則是 block scope（左右大括號 '{' 、 '}' 中間的範圍）
看完這六項後
突然覺得自己很幸運
以前跟過的領導都有強逼我把這些技巧練起來
剩下的品質就看自己造化了
喜歡把變數宣告放在最上面+1.....希望nic以後繼續出類似的影片 大推
很喜歡你的幽默，很舒壓
講得很好是我在課堂上學不到的東西，很有啟發性
這影片內容對我這個小菜雞來說很有幫助，畢竟是半路自學與同事一起討論，這些經驗還沒遇到過，內容很棒，讚讚!
肯定花不少時間剪這個片子，流程很順，感謝分享
同感，你講的東西真的很重要，公司為了加快完成需求開發都是以快速落地為目的，造成的技術債真的很痛苦。
請求NIC分享更多這方面的內容！收穫良多
關於 2，如果參數過多會很難讀懂引數代表什麼，為什麼要傳。如果語言有支援，例如 Dart，可以將不必要的參數變成具名參數；或是在 JavaScript 中使用一個 object 傳入可選參數；或是考慮拆分函式。雖然許多編輯器都有顯示參數名稱的功能。
想看和写程序有关的影片多一点
好的我會安排
身為一位資深軟體工程師，到現在還有新的觀念讓我學習。limited scope 雖然算是一個準則，但還是還要看情況。建議，加入Sanity test 跟unit test的思維，對code的掌握度更高。
第三點,我覺得重點是,有時候寫在主段落的判斷式,
可以另外包成一個function,然後透過有意義的命名,之後看到這段Code,可以清楚知道這判斷式要幹嘛, 像Nic影片裡面就很清楚, 這個人能不能騎車
Clean Code 那本書有寫到, 一個好的命名, 就不需要去註解
讚！很好的提醒！
我一直以來寫code模式也是像你說的這樣，自己寫起來感覺比較乾淨易懂
以團隊協作這方面切入的話 您的行動準則相當的好
但是實際上東西出去的時候一定會加以包裝甚至是複雜化 讓其他公司或購買的單位 難以去辨別這些程式內容到底是控制什麼
對小白來說這是一部觀念很好的影片，支持你希望繼續做下去
講得很好, 這些習慣真的推薦^_^
感謝分享，也是在提醒不要犯這些錯誤~
感謝支持！
新手正嘗試開發小型app,日前陷入需使用多層if else的窘境,看到波動拳直接噴笑,感謝製作好笑又實用的影片
第五點有幫上忙，受教了。最近趕專案確實被這點婊到了幾次。
不過第三點就不好說了，許多情況下不是簡寫或縮略內容就能提升可讀性這麼簡單，同時如果有遵守第五點並且好好寫滿summary解釋清楚，別人根本不需要進去看該function究竟寫了什麼，最好的程式就是不必打開的程式，需要進去看這一點本身就是瑕疵的體現。
這影片讓我想起前公司很多寫前端CSS的會一直加入好幾層的style, 後面蓋前面, 管他以前的人怎麼寫. 最後改不動就是加上 !important. 寫code精簡明瞭很重要. 除非進入3D多層開發, 否則應該是不需要太多判斷式攪在一起.
之前改車看過你的影片，現在想學程式又看到你的影片，好神奇的感覺😂 事實證明改車的不一定都是社會底層？
希望以後能多出這類技巧的影片