※ 引述《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告诫我们多少年了，可惜我们还是都要犯同样的错误。