Yung-Yu Chen
banner
yungyuc.bsky.social
Yung-Yu Chen
@yungyuc.bsky.social
17 followers 12 following 490 posts
adjunct assistant professor at NYCU CS :: teaching https://yyc.solvcon.net/en/latest/nsd/ at 7am :: PSF fellow
Posts Media Videos Starter Packs
撰寫程式開發文件是一種教育行為
行事工作,要重視自己的本心。思考以後再作選擇,才能意識到事物的價值。

要感覺得到事物的價值,才有替別人著想的基礎。對事情沒有感覺,連分析都無法開始。

感覺非常重要。感覺只是難以言說,但不應該被忽視。

如果你對事情沒有感覺,很可能是因為不夠重視自己。要先相信自己是重要的。你值得自己的尊重。
寫程式文件很困難。對大部分的程式來說,基本上不應該浪費力氣寫程式文件。

寫文件的困難並不在於寫,而在於寫好,讓別人看了文件以後,能對程式碼理解到比只讀程式碼還要更深入的程度。

如果作得到的話,還讀程式碼作什麼呢?

當我們程式寫熟了之後,讀程式碼的速度會超過看文件的速度。把程式碼讀通,不但能深入理解程式行為的邏輯,還能增進我們改程式的速度。

尤其現在很多人用 AI 讀文件。用 AI 寫給 AI 讀的文件,自產自銷更直接,就不需要人為干預了。

程式是寫給人用的,而文件是寫給人讀的。在寫文件之前,要先找到讀者。如果文件的讀者比程式碼的讀者還要少,直接寫程式就可以了。
不管用哪一種筆記方式,書寫才是目的。能讓你一直寫的方法就是好方法。

目的是寫不是讀。
我鼓勵記憶程式碼。記住才能通靈。

思考能力有限,追蹤理解每一行程式會消耗巨量的時間,實務難以為繼。

抓住程式碼的重點,然後死記下來,會節省很多精力。

記憶程式碼以及相應的系統行為也是掌握系統的關鍵。記不住所有的程式碼沒有關係,盡量多記就好。記得愈多,掌握度愈高。

掌握度愈高,生產力就愈高。別人在問 AI 查文件的時候,你已經開始編譯測結果了。同時,因為你知道 (記住) 程式碼長什麼樣子,在看到系統的行為出錯的時候,可以很快找到問題點。

此之謂通靈。系統直通心靈。

記憶程式碼其實不難,認真除錯就會記住。是忘記比較難。
軟體開發的工具愈進步,資歷愈重要。

工具含括了前人的經驗,讓我們更容易作到別人也會作的事情,人工智慧工具尤是。

資歷是作他人所不能作的事情的經歷,工具難以取代。資歷帶來洞見,洞見讓人掌握問題的本質以及預測未來。

累積資歷要依靠那些不作不知道的事情。從經典問題中尋找應用是很有效的作法。經典之所以成為經典,就是因為經典通過了時間的考驗,用途廣泛。尋找新的或已知的應用都有效果,而且產業與研究環境一體適用。

資淺不是問題,缺乏累積資歷的環境才是大問題。進步的自動化系統取代了很多工作,但不會取代以簡馭繁的能力。
參加開源社群活動,其實是把時間花在談論技術,而不是在寫程式。

在自己的桌前能夠更快速地寫好程式。使用白板與對談能夠更清楚地表達技術的關鍵。
又到了敦請同學寫程式專案的提案的時間了。

提案是寫程式的計畫。沒有計畫也寫得出程式,所以不是很多人會在寫程式之前作好計畫。

直接寫程式不好嗎?不是不好,而是沒在寫程式之前寫下計畫,就不會記得寫出來的程式和計畫的不一樣。

如果想到什麼就能寫出什麼,這個題目你很可能已經寫過三次以上了。

寫下計畫就是假裝先寫程式。計畫地愈清楚,會愈能掌握開發過程中的變化。愈早開始計畫,也會愈省時間。
弄清楚 dict 和 list 的應用時機,就能表達幾乎所有的序列式邏輯。

所以我們可以用 yaml 寫 playbook/workflow。yaml 其實就是 dict 和 list 的集合。能用這種具備高度限制的 serialization format 表達 (受限制的) 程式邏輯,是很有意思的事情。
獨立開發程式,是有機會看書自己練習學會的,但合作寫程式,就不能單獨作業。

好團隊懂溝通和財務。Vibe coding 是好好和電腦溝通,請電腦作事,開會就是好好和人溝通,請人作事。

錢的事情也同樣重要。軟體開發是工業活動,必然連結於人類經濟。了解錢怎麼來、怎麼去,把工作的內容與工作的成果連接起來。

廣義來看都是橋接。都要靠別人,讀書學不會。
回答不知道、不確定,就是不想作的意思。說的人要知道,聽的人也要懂。
對大學生來說更划算
每年這麼多開源研討會,資訊系的大學生研究生都應該作一些實務專案去發表才對。
技術都在人身上,所以技術也都是和人學的。直接找到人學技術當然最有效率,問題是找誰?

開源研討會提供各種主題,協助參加者尋找自己發展技術的方向。技術演講的數量愈多,愈容易出現有用的資訊。

訊息的傳遞產生對話,對話引起討論,然後咀嚼磨練,成為有用的技術。

雖然勞苦了點,但人多資訊多,效率是很高的。
寫程式產生結果,說真的,算是容易的工作。一直改程式還要產生相同的結果就難了。改愈久愈難。
要記得,喜愛的反面並不是恨,而是漠不關心。
你得自己去作,才能得到自己想要的事物。希望別人幫忙而不自己動手,就一定作不到。

程式尤其是這樣。錨定現在的需求,就少了擴充的彈性。滿足了彈性,會犧牲隨來即用的便利。沒有百分之百完美符合需求的工具。
Scrum standup meeting 能夠大幅提昇團隊的工作效率,但有三個前提:有團隊、工作互相耦合,同時每天都有進展。

許多團隊連一個條件都不滿足,所以作了也沒用。
我們訂的 metrics (尺標) 會決定成果的模樣。大部分的事情是複雜的,無法使用單一尺標衡量。堅持單一尺標,就只會得到尺標期待的結果。

心思意念要隨時更新變化,瞄定真實的目標。
筆記型電腦再外接兩片 4k hidpi 的組態實在是方便好用
這下有趣了。明明傳回一個 C++ 物件,但卻沒有呼叫 copy constructor。

最可能是觸發了 copy elision,但還看不出是哪裡。
開會不痛苦,議而不決才痛苦。
有很多時候我們想重構程式,只是想把程式變成自己看得懂的樣子。程式是無辜的。