Improve the quality of software development! 6 practical skills for coding
ฝัง
- เผยแพร่เมื่อ 20 พ.ค. 2024
- The program can also be scribbled. If you want to write well or be easy to read, you have to spend a lot of effort to learn writing skills.
This video will share some basic knowledge points with you, and practical skills can basically be used in contemporary programming language development.
However, each era will have different ideas and opinions, and different teams will also have different conventions. I hope this content can give you some different ideas.
If you like the video, you can help like it, share it, and subscribe! 😘
chapter:
00:00 The impact of improving quality
01:29 Meaningful naming is better than shorthand
03:01 Limit the number of incoming parameters
05:03 Simplify the conditional expression
06:37 Variable definition range limit
08:28 Do only one thing at a time
10:35 Early return
━━━━━━━━━━━━━━━━
🎬 Watch my life scraps channel: bit.ly/2Ldfp1B
⭐ instagram (daily life): / niclin_tw
⭐ Facebook (information sharing): / niclin.dev
⭐ Blog (technical notes): blog.niclin.tw
⭐ Linkedin (Personal resume): / nic-lin
⭐ Shopee store:
⭐ Github: github.com/niclin
⭐ Podcast: anchor.fm/niclin
━━━━━━━━━━━━━━━━
✉️ Cooperation invitation mailbox: niclin0226@gmail.com
#Frontend#Backend#Engineer - วิทยาศาสตร์และเทคโนโลยี
之前四處工作有時候講習慣了，原本錄音想講品質一直講質量 XDD
上片前一天才發現，所以硬給他改下去
但基本上不影響整支影片想傳達的內容啦
希望觀眾不要見怪，下次會注意細節 😆
無所謂的，不要怕支語警察，這樣硬改變更怪
@@gpcgpc810 不是支語警察是術語要講對的基本要求。
@@cyanide929 謝謝你出來示範，支語警察辛苦了。
這邊有個疑問想順便跟大家調查一下，小弟因為很多時候想不到甚麼好的命名方式 我就會打很長 ex:Single_Line_Loop_effect
像這種名命方式算合格嗎?
第五點我常常幹阿XDD.....
組裡面有沒有大神帶真的差很多，以前待過很弱的公司/組的情況下，怎麼亂寫code都沒人糾正。
之後去到一個Code Quality要求很高的地方被罵了/訓練了兩年，實力大增，從此不會寂寞。
哦哦哦 內褲面試官登場！
我一開始也是到沒人帶的地方野蠻生長
後來遇到我師父之後，被電被糾正的情況下
強制升級 code quality ，過程飽受挫折一度認為我應該不適合做軟體開發 XD
跟你差不多也是兩年左右的修行，很感謝我的師父當初願意電我
我覺得能在職場上遇到能夠罵你訓練你的人真的是幸運
感謝泰瑞的經驗分享 😁
想問在沒人帶的狀況下怎麼提升自己的 code quality
現在的工作都沒要求code quality這些，因為一些原因無法立刻馬上換工作
很好奇什麼樣的開源專案適合？
難不成要從超大又複雜的那種專案開始看？
@@mingqp777 我是滿建議針對你寫的領域去找相關的分享源碼來看耶，我目前工作的東西網路上還有辦法找得到相關資源，挑選一些看起來擴充性不錯的來學習XD
我個人寫的時候也會畫圖筆記，對於程式架構也有些幫助
我是沒人電，自己就提昇了，但花了三年....其實初心很重要，當初第一次工作的時候，我每次在開始撰寫時，都會要求自己"拿出自己認知最好的寫法"的方式來撰寫，三年過去了，習慣就養成了
有一種賀瓏跑去寫程式的感覺
靠難怪覺得似曾相識
還在想說為什麼明明是第一次看到卻不覺得陌生xd
我第一眼也以為是賀瓏😂
我一直以為賀瓏會寫程式
真的像
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
順便分享一些有用的技巧：
如果函數參數過多不知道怎麼處理，以下幾點建議：
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旁邊註解//設定時間
感謝你的熱心整理 揪甘心
每次覺得有人能看懂影片真的是莫大的安慰 😂
Nic 的影片已經變成我學習源頭之一，看著你講著我學習中遇到的問題跟你那淡定的臉真的超有喜感
賀瓏真的很優秀，脫口秀好笑又會寫程式
真的是不可多得的人才
好像還會打桌球耶
還會在地上
滾
感謝nic大
本身非相關科系出身
剛好在山中當大王(沒人帶自己搞)
有一直在修正自己的code
但因為沒人告訴我該怎麼做
即便有用上影片中的技巧也不知道外面的人是否也會這樣使用
看完影片之後稍微放心了
感謝nic大提升信心
讓我知道自己確實是有在進步
這個影片給予我幫助很多再次感謝!
其實你說的那些很實用，也不會多花時間，在剛學寫程式的朋友養成這樣的好習慣，真的受益無窮。
開始學程式一個月，到學習一個小階段半年，到開始工作一年
每次看都是不同的感受，加上最近接到前輩丟出來的專案
隨便一個方法傳了12個參數然後超過20個if/else判斷，整個感觸超深(重構起來也超痛苦...)
真的感謝Nic大的經驗分享，可以淺顯易懂的理解箇中奧妙!讚
很開心
自己有慢慢調整
符合上面的條件
感謝Nic 每次看你影片都覺得學習到很多技巧 謝謝
超實用的建議，謝謝 Nic ！已經整理好筆記，要不時檢視一下自己寫扣品質，超感謝～
把if內的條件直接放return符合就true不符合就false真的讚
觀點不錯！雖然每個人的說法不見得相同，但方向類似！
最近幫客戶上課，給個觀念
我不求最新的技術，也不用最快的撰寫方法（開發時程或執行成本）
但我會寫出最好維護的方式！
因為就像板主說的，你的程式會被閱讀或修改多次。
一時的省工，將來必定耗時。因為沒有一個程式不需被維護的！需求總是變來變去！
軟體工程就是不斷在追求降低時間成本的方法
這集很棒👍
100% 同意這六項技巧，這幾點已經算是當前寫程式的標準規範了。
現在碰到多年前寫的系統會更能體會到， 違反這些規則的程式碼所造成的混亂場景有如地獄。
拜託請多做一點有關這類型code風格的影片（尤其是有關python的範例）！！！超級有幫助的
Guard Clauses 有額外的好處：
會優先考慮 Exception 與 bad path，比較不會遺漏
配合 test case 風味更佳
謝謝Nic大大分享，新新新手初學者受益良多!
除了第2點限制傳入參數以外，其他的我都是在自己的side project，開始變得超級混亂的時候
決定找時間全部重寫時學到的，畢竟沒有人帶，Nic提到的很多東西程式初學者在寫的時候
根本不會考慮那麼多東西，這樣的影片真的很讚!
最近計畫結束開始回頭維護code，基本上每一點都被說中了XD
看完就知道怎麼改比較好，受益良多，謝謝Nic !!
喜歡這樣有條理的分享～收穫滿滿^ ^
第一點跟剛接觸程式設計時老師的提醒一模一樣！
跟模組命名與實際功能連結有異曲同工之妙
可以多發寫程式影片～跟大概解說，像這部影片的技巧關鍵點。讓瞭解程式變得有人性化還有邏輯跟乾淨方便閱讀。
蠻棒的，講解的主題抓的很精準，希望能有一集分享design pattern
感謝 Nic 分享，這集太重要了！現在再回去看以前寫的 code 真的很毒，這些撰寫原則真的要早點習慣
條理清晰,看到4:41分就必須訂閱給讚,希望影片都是高質素
最近在看重構與clean code這兩本書 很有感xd
希望以後多分享相關內容～
if else真的很容易出現，該好好思考怎麼樣避免這種恐怖的波動拳,感謝分享!
講真的不錯，這實用技巧剛好可以來檢視一下自己的程式習慣。
這影片內容對我這個小菜雞來說很有幫助，畢竟是半路自學與同事一起討論，這些經驗還沒遇到過，內容很棒，讚讚!
这是个很不错的影片对于工程师本身必须要有的技巧。至于团队里，毕竟不是每个工程师的水平都一样，所以团队要有一定基本的编码方式统一。最后，我个人觉得最重要的是要有一个方法能把业务逻辑和执行逻辑分开以便测试和debug。这也能提升维护性。
讚！很好的提醒！
我朋友：你寫的程式就是一隻鴿子 他正在飛沒錯 但是他是用高速旋轉的頭在飛 不是翅膀
為什麼你可以傳圖片
It just works.
當你的程式毫無邏輯 卻可以運行的很好.jpg
comment：此程序由bug作为核心运行，切记，请勿修改！
:所以你到底想說甚麼
朋友:你不覺得用高速旋轉的頭在飛的鴿子很帥嗎?
有意義的命名, 簡化條件表達式, 避免嵌套 if ...這些都只是常識，都是對上過學的人的最低要求, 感謝分享
說的很棒~clean code 這本書也有提到影片說的這些東西
非常實用的技巧, 感謝分享.
不客氣 😆 感謝你的留言鼓勵
講得很好, 這些習慣真的推薦^_^
獲益良多，真的謝謝!
很喜歡你的幽默，很舒壓
Nic 感恩啦！正是有您願意拍影片細說，大道上的巨石才一一現形。事非經過不知難，能有這些許多好的工具並非天降，沒看真不知道。
講的超棒的！感謝！
請求NIC分享更多這方面的內容！收穫良多
很實用，超感謝
我一直以來寫code模式也是像你說的這樣，自己寫起來感覺比較乾淨易懂
感謝分享，也是在提醒不要犯這些錯誤~
感謝支持！
肯定花不少時間剪這個片子，流程很順，感謝分享
裡面大概有三種技巧就是因為要讓之後交接順利才想出來，但也有3種是我完全沒想到的，感謝你的分享
同感，你講的東西真的很重要，公司為了加快完成需求開發都是以快速落地為目的，造成的技術債真的很痛苦。
第6點好實用!
太實用了 感謝Nic分享 如果可以的話希望可以多分享這類影片 感恩 感謝
好的好的 👌 我多分享你也記得幫我多分享 😆
@@niclin 沒問題👍
看完好有感觸，目前正在學習階段的我常常聽到，程式碼的品質，但都沒提到[什麼是品質] 謝謝 Nic的無私分享
這些在clean code都有看過
但使用上常常忘掉
if else在現在還是比較容易出現的
看完又被提醒了一次🥺
很實用 感謝大大
以團隊協作這方面切入的話 您的行動準則相當的好
但是實際上東西出去的時候一定會加以包裝甚至是複雜化 讓其他公司或購買的單位 難以去辨別這些程式內容到底是控制什麼
對小白來說這是一部觀念很好的影片，支持你希望繼續做下去
好厲害的講解
講得很好是我在課堂上學不到的東西，很有啟發性
還有一點很重要的是資料流的追蹤
其實寫程式真的可以當成在寫作，只是多數人不知道如何 正確的表達
進而導致後人不知無法理解當時的時空背景
最根本的解決方式是寫完把自己換個角度觀察一下程式碼
如果不理解這些函數、變數，是否能理解當初想做什麼
很多工程師都是功能能跑就好，省略了很多描述的細節，開發是真的快，但未來接手程式碼的人真的能快速理解並調整嗎
Early return 真的常常用! 盡量避免else case.
第四點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
感謝分享，本身是非程式設計相關出身的，目前已有撰寫C++兩年左右的經驗。
目前依舊還在探索程式碼撰寫風格，看到這部影片提供的技巧 覺得獲益良多
感謝你的鼓勵，能有幫助到你一些些都是我的榮幸
感恩 很實用
講得真的很精準！！
雖然已經沒寫程式兩年了，但對這些Ｄｅｂｕｇ的日子真的還是歷歷在目
以前我在寫程式，最後會給自己一個要求
「任何的Ｆｕｎｃｔｉｏｎ不超過１５行」為主
這樣就會慢慢學到六招實用技巧的做法了
超級實用！
感謝分享。
第3項通常會因為擴充變成需要第6項來支援，再加上不同條件彼此不一定獨立，所以後續又會抽成object。
希望以後能多出這類技巧的影片
喜歡把變數宣告放在最上面+1.....希望nic以後繼續出類似的影片 大推
真的很多人都會把學校教的壞習慣帶過來，例如一個好好的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
厲害 要向你學習
超讚 學到了 感謝 !!!
有幫助 推推
好棒!YT推薦的影片
硬着头皮在C#混了2年，抛弃project无数，这些知识真的是刻骨铭心
品質給推
宗旨就是不要搞死以後看代碼的自己和別人，怎樣好讀易懂就怎麼寫
支持Nic大一波～
最近有一篇 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
很有趣的是，在幾年前我師父就有說過類似的話了 😂
這批真的好純好純,我為了這個訂閱了,請一定要做更多這類相關的內容,
小弟我在小公司上班,很大部分都一人作業,頂多做些singleton,不太需要用到什麼factory 一些design pattern,
interface會用 但也是少少用到,git 的rebase更是沒有在用,因為很少有人跟我一起作業,也沒有必要
所以如果面試回答 我都是只能回答教科書寫的內容,不知道到底有什麼作用
(我都自己作業,我怎麼知道程式碼好看可以幹嘛,雖然我會抓底線,但偶爾真的會偷懶不遵守/忘記自己訂的規矩),
我頂多就是說我有做過哪些作品,但寫出一個程式可以運作很簡單,
即便我很想證明它是有很多擴展的空間,短短的面試時間,我還是很難完全的展示出來我的能耐。
面試人也不可能直接看我的code,讓他知道我可以擴充到什麼地步,還是我其實是在滑水
今天有幾點東西讓我印象深刻,希望能多出一些這類相關的,尤其是design pattern的應用,幫幫我這個剛出社會1年的拉基工程師
ps:尤其是範例,真的很棒,讓我印象很深,能完全理解你想表達的概念
讚, 非常適合給剛畢業的新鮮人~~
受益良多，剛入門，在這邊跟正在猶豫要不要轉行、嘗試程式語言的朋友們信心
我自己是文組商科，自學搭配工具書，效果也不錯。 大家加油
另外很喜歡你寫的一篇文章「如何成為一個失敗的軟體工程師」
只要你每次撰寫程式時，都願意拿出 "自己所知道最好的寫法" 來撰寫的話，就建議你成為軟體工程師
好實用的幾點技巧，尤其第四點最有感，感謝Nic的分享！
感謝你的支持！
光是第一點就給你一個讚👍，我看過太多這樣子寫簡寫的工程師了🤣🤣🤣
10:50 波動拳比喻的真好
這集真的很不一樣👍👍👍👍
講得不錯讚讚
另外補充一下，var 作用域其實並不是真的全域而是 function scope 哦
const、let 則是 block scope（左右大括號 '{' 、 '}' 中間的範圍）
好實用
命名的問題，我自己是只讓全域變數的命名有意義，function裡的區域變數就會極簡化，因為有時候變數需要做一堆and or，命名太長的話邏輯式就很容易一行寫不完，這樣也會造成不好debug
感謝分享
我在寫 golang 的時候也有發現這個社群的 convention
主要是他們希望 life cycle 很短的變數在一定的範圍內可以用簡寫
這個我覺得也 ok，畢竟他們的社群規範寫的滿清楚的
只是我自己寫下來有時候編輯器拉超過一個 pagedown 我就會覺得有點難閱讀了
通常還是會依照個人喜好或是團隊協作方向在做些微的共識上調整
我跟樓主一樣 因為函數名稱都已經說明功能了 函數內的變數就沒有必要取那麼長的名稱 只要能在該函數看得懂就好了 太長反而更難讀懂
整理+範例說明的很清楚.
同意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)
必須來支持一下
第三點,我覺得重點是,有時候寫在主段落的判斷式,
可以另外包成一個function,然後透過有意義的命名,之後看到這段Code,可以清楚知道這判斷式要幹嘛, 像Nic影片裡面就很清楚, 這個人能不能騎車
Clean Code 那本書有寫到, 一個好的命名, 就不需要去註解
看完這六項後
突然覺得自己很幸運
以前跟過的領導都有強逼我把這些技巧練起來
剩下的品質就看自己造化了
感謝 漲姿勢
品質真的很重要，都重新錄音了
覺得很有趣😂😂😂
XDDD 差點趕不上發佈時間
看在Nic這麼貼心的份上幫忙點個讚
這影片讓我想起前公司很多寫前端CSS的會一直加入好幾層的style, 後面蓋前面, 管他以前的人怎麼寫. 最後改不動就是加上 !important. 寫code精簡明瞭很重要. 除非進入3D多層開發, 否則應該是不需要太多判斷式攪在一起.
要写好一个程序很难，读过《代码整洁之道》《重构，改善既有代码的设计》 很多问题其实都是边界问题，有的时候倾向于这边，有的时候又倾向于那边，重点是明白自己的目的，在从中找到最合适的设计方式。目的改变了，设计也就需要改变。熟悉设计方式，明白设计的目的和优点，在结合自己的目的找到最优解。这是一个过程，而这个过程，也是需要知识量和时间分析来支撑的。《重构》这本书，提供了一个用不断的重构来应对改变的思路，而且提供很多设计思路以及优缺点，就是没有实际场景优点难以明白其中的代理。
本身在美國 Fang 當 sde, 也差不多五年。溫故而知新。keep it up
很棒的影片，值得一看再看^^，希望能持續以「白話幽默」的方式去解讀程式碼意義、如何提高效率品質，以及若遇到接手前人地獄級的程式碼時有哪些技巧去解決等類似影片。
謝謝你的鼓勵
你提出的主題不錯，剛好我也有相關的經驗，日後會納入拍攝考慮！
在一些沒有GC的programming language, 不建議使用第6點early return，在這些沒有GC的coding中，使用early return容易造成memory leak.