※ 引述《aass5576843 (信長)》之銘言：
: 寫程式不知不覺也一年半了
: 看著公司龐大的老舊程式
: 前人寫的實在雜亂
: 造成了維護上有一定難度
: 最近有心想要嘗試從簡單的地方開始試著重構
: 讓後人可以更好的閱讀程式
: 但想想，整理這個不知道有沒有意義
: 以目前能力重構效能會不會變得更好都是未知數
: 而且還要花大量時間進行測試
: 最終效果可能就是變得 模組化 、好維護、易讀
: 不知道各位前輩 對於程式要求是什麼
: 維護能動就好？
: 偏好clean code的原則？
: 不管環境、工具、寫法如何 只要能快速端出需求就行？
Fred Brooks(1975)
"Show me your flowcharts and conceal your tables, and I shall continue to be
mystified. Show me your tables, and I won't usually need your flowcharts;
they'll be obvious."
Linus Torvalds
"Bad programmers worry about the code. Good programmers worry about data
structures and their relationships."
然後Peter Naur最經典的"Programming as Theory Building"
https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f342fb1
這篇真的是寶藏，你看懂了，你可以少花很多時間在重構上。
我太晚才了解這道理了，clean code不是不好，但那不是很重要。
最重要的是你需要了解"Theory"，你才能快速修改程式。但我們誤以為clean code可以讓我們快速修改程式。
有"Theory"的程式就會有clean code。有clean code但沒有"theory"還是一團混亂。

蛤

有空來讀一下

未看先感謝推薦，晚點丟 GPT 看中文摘要

我怎麼覺得這跟clean code說的是同一件事

所以理論是啥 連gpt都能brief的比這篇更好

團隊不理解才是主因吧？最早原PO的問題是不知道自己處在什麼環境，自以為的想導入正確的架構，說實話根本不是寫程式的問題

就是要知道knowhow Y

Peter Naur's 理論是code+doc是無法解釋intent和design。元po不了解原來的程式，所以他認為龐大，老舊，雜亂。但他認為他整理的就會容易理解。答案是並不會，因為後續接的人也不懂元po的intent和design。如果我們不了解這個問題，不管我們自認為如何clean code，後面接的人如果不了解theory還是會認為我們寫的code+doc是雜亂，難以維護。

我懂你意思了，thx

邪魔外道

推-domain knowhow另外，論文我還是習慣有方程式的軟工這邊好辛苦

這篇確實有點亂 引用前兩個論點差不多 最後的比較泛化 個人認為運作機制才是最重要的 怎麼運作決定它數據結構應該是什麼 由運作反推結構修正結構更好人更適合看一個面而不是一個點 光有波動與粒子二象性考慮的是面微小細節無法顧及 考慮的是點各點統合gg個人認為由面入手更好

推 謝謝推薦文章 覺得有道理

獨立思考果然好重要

元po有個錯誤觀念。認為從code下手，就可以，模組化，好維修，易讀。但"There is no silver bullet"，Fred Brooks告誡我們多少年了，可惜我們還是都要犯同樣的錯誤。