受教了

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。

所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

写一个大型项目的时候，要把功能成每一个函数，以及相互调用关系， 由主函数来调用， 

每一个函数下面要大致了解每个函数的作用以及数学背景，不必用草稿列太多，然后开始写代码，可以针对个函数边写边修改 边列数学背景。 技术细节

写每一个函数的都要用好好写，然后调试，测试，必须等测试成功再转下一个程序！不行就就单独函数拉出来测试

如果有些功能没想到，也写成独立的函数 再母函数下进行调用。