用一個小時編寫一個小程序

【CSDN 編者按】要想快速編寫程序,必須要認真考慮技能、工具選擇、攤銷和回報。

原文連結:https://buttondown.email/hillelwayne/archive/how-much-can-you-code/

未經授權,禁止轉載!

作者 | HILLEL WAYNE 譯者 | 彎月

責編 | 王子彧

首先,我們來探討一下哪些任務適合自動化。

如上圖所示,如果你花費一天多的時間實現了每個月只能節省 5 分鐘的任務,那麼純屬浪費時間。

當然,自動化除了節省時間之外,還有其他意義。例如, 花一天時間自動化每個月只能節省5分鐘的任務並不划算,但如果你十分厭惡這項任務,那麼仍然是值得的。

這個問題會引出另一個問題:為什麼你需要花費一天時間?

為什麼不能是一個小時?

如果你能快速寫出完整的程序,那麼編寫程序就能成為解決更廣泛的問題、且節省時間的解決方案。一個小時是「快」的一個很好的衡量標準。一個小時就是一頓午飯的時間。

談及快速編寫程序,我認為我們必須考慮到下面這些因素。

技能

技能

快速程式設計是與軟體工程截然不同的一項技能。軟體工程原則並不適用於快速程式設計。當然,良好的組織和清晰的意圖仍然很重要,但是很多 SE 理論都是圍繞如何作為團隊的一部分持續開發現有程式碼庫。例如,我很少為自己的腳本編寫測試。設置測試需要時間,使用固定裝置設置集成測試需要更多時間。

同時,快速反饋非常重要,甚至比常規程式設計更重要。我通過一種方式來快速設置和執行腳本。

程式碼是否方便理解也無關緊要。這些程序都很小,如果你無法理解程式碼,完全可以重寫。如果需要擴展,也可以「適當地」重寫。

對於腳本中應該使用多少第三方依賴項,我有點糾結。有時,第三方庫確實很有幫助,但是你需要花時間學習和了解,而且許多第三方庫的文件都很糟糕。我認為,能夠彌補語言本身缺陷的依賴是好的,但是你為了逃避學習而選用某些庫就不太正確。我用 click 製作了一個 Python 工具,很快就後悔了。

工具的選擇

工具的選擇

關係到工具選擇的因素有下面幾個。如果我們想盡可能快速地寫出一個完整的程序,就應該選擇簡潔而富有表現力的語言。簡潔的語言更容易調整,因為你需要修改的字符更少。樣板程式碼則是負面因素。

動態語言具有一定的優勢。運行時錯誤比靜態錯誤更好。如果程序在執行第 20 行程式碼時出現類型錯誤,那麼運行時故障仍會執行第 1~19 行,這就可以為你提供這些程式碼能否正常工作的資訊。

一個同樣重要的因素:選擇適合的領域。這取決於需要自動化的任務。有些語言有很好的內建函數,有些語言恰好有很好的庫。有時,最好的工具不是程式語言。最近,我遇到了一個任務:抓取Google地圖上 100 個街道地址的 url,我採用了 Power Automate。PA 是一款有點糟糕的工具,但它有良好的瀏覽器自動化技術,非常適合這項任務。此外,它在 Windows 11 中是免費提供的。所以,最終我們只用了半個小時就完成了任務。

此外,我還用正規表示式、shell(特別是 PowerShell)以及電子表格解決了很多問題。

其他注意事項:一個好的 CLI 庫是必須的。擁有一個良好的 GUI 框架固然很好,但不那麼重要。你需要保證能夠運行單個檔案,並且能夠使用偵錯程式。如果條件允許,還可以考慮使用非常友好的 Copilot。

攤銷

攤銷

攤銷指的是,演算法有一些昂貴的操作和許多開銷低廉的操作,因此整體運行時間低於你的預期。例如,向陣列追加元素的開銷是 O(1),即使有時你需要花費O(n) 來調整陣列的大小,整體開銷依然是 O(1),因為這種情況很少發生。

對於此處討論的問題來說,攤銷指的是,為編寫腳本投入的時間可以加快將來編寫腳本的速度。這對於提高技能非常重要,因此我們應該詳細討論一下。首先,熟練之後能減少查找資訊的時間。

通過搜尋引擎查找資訊需要花費很多時間。在軟體工程中,這點時間開銷並不重要,因為我們的大部分時間都花在閱讀上,但是現在你需要快速編寫程序。將資訊移動到本地快取(文字檔案、註釋)很好,如果你已經掌握了這些資訊,那就更好了。

此外,編寫腳本會生成可供你複製粘貼的程式碼片段。我製作第一款應用時花了很多時間,但後面的應用編寫速度明顯加快,因為我可以複製粘貼已有的程式碼。至少,在不同的腳本中查找某些程式碼的速度比上網搜尋更快。

編寫腳本會讓你接觸到語言中極具表現力的黑魔法,例如宏和元程式設計。你知道將哪些程式碼放入團隊維護的程式碼庫中是很糟糕的?但是,這些黑魔法非常適合快速編寫腳本,一旦你學會了如何使用這些黑魔法就會事半功倍。

因此,真正掌握一門語言有很大的好處,同時了解許多不同的工具也有好處。

回報

回報

在美國芝加哥,每逢芝加哥小熊隊主場的棒球聯賽,乘坐地鐵紅線就是噩夢。所以我編寫了一個 lambda 腳本來提醒自己。這個腳本真的可以改善我的生活嗎?可以。如果需要三個小時才能寫這樣一個腳本,我還會寫嗎?可能不會。

相關文章

C++23:下一個 C++ 標準

C++23:下一個 C++ 標準

【編者按】C++23 是 C++20 之後的下一個 C++ 標準,它包含了對 C++ 的一系列改進,但對於 C++98、C++11 或 C+...

破壞 java.lang.String

破壞 java.lang.String

【編者按】本文展示瞭如何利用 Java 的一個 bug 來製造一些奇怪的字串,包括字串相等性的條件、創建損壞字串的方法以及利用該 bug 在...

為什麼會有這麼多程式語言?

為什麼會有這麼多程式語言?

【編者按】本文主要探討為什麼存在這麼多的程式語言,以及新的程式語言為什麼不斷地被創造出來。作者從計算機歷史博物館的一幅展示程式語言演化的巨圖...

ORM 是「反模式」 嗎?

ORM 是「反模式」 嗎?

【編者按】ORM(對象關係對映)在軟體開發中受到爭議,常見批評包括違反 SOLID 原則和效率低,但實際問題在於透明性和調試困難。如果能夠正...

有必要追求 100% 的單測覆蓋率嗎?

有必要追求 100% 的單測覆蓋率嗎?

【編者按】本文主要討論了一個項目的開發過程中對測試覆蓋率的要求以及其帶來的挑戰,強調了 100% 的測試覆蓋率的重要性和好處,尤其是在避免隱...

微軟計劃將 Windows 完整遷移到雲端

微軟計劃將 Windows 完整遷移到雲端

【編者按】微軟計劃通過 Windows 365 將 Windows 作業系統完整遷移到雲端,以提供基於人工智慧的高質量服務和實現無縫數字化生...

MySQL如何支撐每秒百萬QPS?

MySQL如何支撐每秒百萬QPS?

【編者按】本文主要介紹 PlanetScale 是如何通過 MySQL 的水平分片支撐每秒一百萬個查詢(QPS)的。 原文連結:https:...