深夜2点的编程心得：尽量避免推倒重来
深夜2点的编程心得：尽量避免推倒重来
大家好！此刻深夜2点，我在修改代码的过程中感悟颇深，决定和大家分享一下这段经历。希望你们能从我的故事中找到一些启发，避免犯我所犯的错误。
故事的起因：编写编译器遇到的困境
我正在编写一个自定义语言的编译器，目前已经进行到了parser部分。但因为语义分析的deadline临近，parser部分写得又十分糟糕，我开始感到焦虑。
经过今晚，我有了一个坚定的信念：绝对不重新写代码，一定要设计得非常合理。
翻阅C语言的grammar：重新认识Token
为了解决这个问题，我研究了C语言的grammar，并经过3个小时的阅读，逐渐理解了大概400行的grammar。这个过程让我发现，lexer中的Token分类并不符合主流的方式。比如将Type token之前包括： int float string bool四个类型重新定义为，如今我想拆分为四个小token INT FLOAT, STRING BOOL。
的确应该拆分更好，虽然在parser部分已经实现了区分它们的函数。可我修改代码的方式却是推到重来。如今事实证明我是错误的，绘制DFA太费时间，绘制成功后，
冲动的我，竟然想重写lexer！
反思：推倒重来的代价
我开始意识到绘制DFA非常耗时，即使成功绘制出来，我也已经不想用Java重新实现了。因为实现起来虽然不难，但确实太琐碎。
最后的妥协：灵活的代码设计
最后，我回过头来看之前的代码，发现其实还是比较灵活的。在Type类型中定义返回具体Token，这样做的好处是不用合并DFA，而且实现起来很快。虽然如此，当我写到这篇文章时，还是有些后悔，因为修改了Symbol构造函数，也意味着parser部分也需要改动。
成也曹操，败也曹操：
我的成功在于之前的代码设计还算合理，使用了合适的设计模式，改动起来相对方便。但失败在于太过于刻板追求设计模式，以至于居然想重新写它。
我的教训：
实际上，parser写得一团糟的原因是grammar设计得不好，导致代码不断地反复修改。即使使用了不错的实现方法，也抵不过错误的设计带来的损失。
总结：
希望大家能够从我的教训中吸取经验，在写代码之前一定要设计好，最好是定义好测试函数。这种思维方式不仅仅适用于编程，也适用于生活。把如何做人的原则运用到编程中，应该是不会错的。
关键点：
-
不要轻易推倒重来：即使你觉得代码写得糟糕，也要尽量避免重新写。尝试从现有代码中发现潜在的优势和可改进之处，然后进行优化。
-
设计好再动手：在开始写代码之前，一定要对整体结构和细节有清晰的规划。这样可以避免在后期不断修改，浪费时间和精力。
-
测试至上：定义好测试函数，这将有助于验证你的设计是否正确，同时也可以及时发现问题，避免在后期累积过多的问题需要修复。
-
把握核心原则：在编程过程中，将生活中的原则运用到实践中，如同在生活中一样，把事情做好，做到极致。