写代码过程中最忌讳的是什么？总感觉最近太过于急于求成？
要说写代码最忌讳什么，对我来说，最怕的是“只求完成，不求甚解”。这话说起来轻描淡写，但实践起来，其危害简直是“牵一发而动全身”。
让我给你掰开了揉碎了说说：
1. 粗糙的逻辑，埋下隐藏的定时炸弹
你看，我们写代码，本质上是在构建一个逻辑世界。每一步，每一个判断，每一个循环，都必须精确无误。你急于求成，可能就是看了个大概的思路，觉得“行得通”，就一通乱写。结果呢？
边界条件处理不当： 用户输入个空字符串怎么办？数是个负数怎么办？你以为那些“正常情况”就够了，殊不知现实总是比你想象的要复杂得多。这些被忽略的角落，往往是bug的温床。
状态管理混乱： 你的程序里有多少个变量在管理不同的状态？它们之间是怎么流转的？如果你写代码时脑子里只想着“先把这个功能弄出来”，很可能就会出现状态错乱，本来应该A状态变成B状态，结果它卡在了C，或者直接崩溃。
依赖关系不清： 一个函数依赖另一个函数，一个模块依赖另一个模块。你急匆匆地把它们拼凑在一起，但有没有仔细想过它们之间真实的、严谨的依赖关系？一旦其中一个环节出了问题，或者你想修改其中一个，就可能引发连锁反应，整个系统都跟着摇摇欲坠。
我曾经有个项目，为了赶一个demo，我硬是把几个互相独立的模块直接拷贝粘贴，然后改了几个变量名了事。结果呢？上线不到一天，某个平时很少触发的路径就报了堆栈溢出，调试了大半天才发现是依赖的库版本冲突，加上我的“粘贴大法”把一些隐式依赖也给搞乱了。那场面，真是“死去活来”。
2. 缺乏文档和注释，给自己挖坑
这点估计很多人都吃过亏。你写代码的时候，思路清晰得不得了，觉得自己过几个小时就能看懂。可等你过几天，或者换个人来看，甚至是你几个月后的自己，再回头看那段代码，简直比看天书还费劲。
“我当时怎么想的？” 那些你自以为是的“聪明”写法，几个月后，你可能完全想不起来当初的逻辑是什么了。没有注释，你就得靠猜，靠调试，效率直线下降。
维护的噩梦： 你的代码不是一次性产品，它需要被维护，被迭代。如果连你自己都看不懂自己写的代码，那别人更不可能看懂了。这就导致了维护成本的急剧升高，每次修改都像是在拆炸弹，小心翼翼，生怕碰坏了什么。
知识的传承中断： 如果你的项目是一个团队项目，或者你希望有人能接手你的工作，那么缺乏文档和注释，就等于你把你的知识牢牢地锁在了自己的脑子里，一旦你离开，这些知识也就随之消失了。
我以前有个同事，写代码特溜，但从来不写注释。他说他的代码自己看了就能懂。有一次他请假，我们接手了他的一个模块。那个模块的功能特别核心，但他写的代码就像是一锅乱炖的意大利面，分不清哪里是面条，哪里是酱料。我们花了好几天时间，才勉强理解了其中的一个核心算法，然后小心翼翼地修改。那几天，我们几个人的表情，比霜打了的茄子还难看。
3. 缺乏测试，让BUG逍遥法外
“测试？有时间再说吧，先上线再说。” 这是我听到过最想“打醒”自己的话。急于求成，最容易跳过的就是测试环节。
功能性测试的缺失： 你辛辛苦苦写的功能，是不是真的按照需求完成了？没有测试，你就只能凭感觉，或者靠用户反馈来发现问题。而用户反馈，往往是出了大问题之后才会出现。
性能测试的忽略： 你的代码在各种负载下表现如何？是否存在性能瓶颈？没有测试，你可能觉得“现在跑得挺好”，但等到用户量上来，或者数据量增大，你的程序可能就成了“慢吞吞的老爷爷”。
回归测试的遗忘： 当你修改了一个bug，或者添加了一个新功能，有没有验证之前的代码有没有受到影响？没有回归测试，你以为你修复了一个问题，结果却制造了两个新问题。
我见过很多因为缺乏测试而导致项目彻底失败的案例。有一个开源项目，开发者热情很高，代码写得也很快，但就是不写测试。结果有一天，一个看似微小的改动，却导致了整个项目的核心功能彻底瘫痪。社区抱怨声一片，最后很多用户都转向了其他更稳定的项目。
4. 重复造轮子，浪费宝贵的开发时间
你是不是觉得“这个功能网上应该有很多现成的代码”，然后就马上去找，去模仿，去照搬？有时候，这确实能节省时间。但如果你不理解它的原理，只是机械地复制粘贴，那和前面说的“只求完成”又有啥区别？
没理解透彻，容易出错： 你不知道为什么这个代码是这么写的，不知道它的局限性在哪里，不知道它可能有哪些潜在的风险。复制过来的代码，可能并不完全适合你的项目场景，强行套用，只会引入更多问题。
学习机会的丧失： 很多时候，那些看似“重复”的工作，恰恰是你学习和成长的绝佳机会。通过自己思考、设计、实现，你才能真正掌握一项技能。如果你总是依赖现成的，你的技能树就很难生长起来。
维护成本高昂： 如果你使用了别人的库，而你又不了解它的内部实现，一旦出现问题，你就很难进行深度调试和修改。而如果你自己实现了，虽然一开始会慢一点，但后续的维护和定制化会容易得多。
那么，如何克服这种“急于求成”的心理呢？
这就像练武功，得先扎马步，才能出拳。
放慢脚步，理解为先： 在写代码之前，花足够的时间去理解需求，去设计你的方案。画流程图，写伪代码，和同事讨论。确保你的思路是清晰的，逻辑是严谨的。
先易后难，小步快跑： 不要试图一次性把所有东西都写完。把任务分解成更小的、可管理的部分，逐个击破。完成一小块，就测试一小块。
写注释，就像写日记： 养成写注释的好习惯，记录你的思路，你的决策，你的注意事项。这不仅是对别人的负责，更是对自己的负责。
测试是你的好朋友： 拥抱测试，写单元测试、集成测试。它们是你代码质量的保障，是你发现问题的侦探。
多读优秀的代码： 去看看那些写得好的开源项目，看看别人的代码是如何组织，如何设计的。从中学习，提升自己的编程品味。
学会说“不”： 有时候，面对不切实际的工期，学会说“不”，或者提出更合理的解决方案，比一味地“赶工”要明智得多。
总而言之，写代码最忌讳的就是 “急功近利”和“敷衍了事”。每一次看似节省下来的时间，到头来都可能以数倍甚至十数倍的时间成本来偿还。记住，代码是有生命的，你对待它的态度，它最终也会反馈给你。
最近感觉太急了，那就放慢点，把基础打牢。一杯茶，一本书，一段安静的思考时间，远比你熬夜写出 bug 百出的代码要来得有价值。共勉！
网友意见
讲个真实的故事。
在Stanford的第二个学期，我闲的蛋疼去图形学lab找个了写代码的工作。我的老板就叫V教授吧，他手下有一个博士生S哥，在做一个室内家具自动设计的项目。他写了一个demo，虽然算法效果还不错，但是渲染效果很差，而且缺少比如阴影一类的视觉效果。我的工作就是让demo看上去更牛逼一点。
我看了一下demo之后，感觉难度应该不大，首先是性能有问题，性能问题搞定之后，可以加一些eyecandy的标准效果。毕竟我大三的暑假在activision撸了3个月游戏引擎优化，也算是轻车熟路了。S哥特别兴奋，把cvs账号给我（对，那个时代还用cvs），说咱们1个月差不多就搞定了吧。我说不用啊就这么点东西两周吧。
这种项目优化起来就是那些手段，没啥难度，我决定推迟到周末再开始，最后总共留了一周左右的时间。
但是当我最终坐下来开始看代码的时候，就石化了。
这是我见过的最没有结构的代码，总共三四个文件，每个都几万行，大量重复但是修改过一点点的代码被复制来复制去。渲染是opengl写的，但是所有东西都是glbegin/glend画的，也没有任何抽象，矩阵运算也全部是gltranslate/glrotate一类的。但是它又是那么没有bug的正常运行，让我叹为观止。
任何的性能提升，都建立在大量的重构基础之上，然而任何的重构都牵一发而动全身。但是眼前这坨冒着蒸汽的热翔，又是这么有机的运作着，简直就像把C++ feed到一个C++到C++的compiler里，然后吐出来一堆没有任何抽象的C++。
我其实还是尝试重构了，但是基本意味着我要把全部渲染的东西重写一遍，一周（还要上课写作业啊）看来是肯定搞不完了。最后我写了一个shadow mapping，连pcf都没加，然后替换了部分glbegin/glend就报告了V教授，说实在是搞不定了啊。
第二天V教授说你们去买个新电脑吧。
卧槽，那我还优化个什么劲？
但是这并不是一个关于重构的故事。
我后来打听了一下S哥的底细，大概是这样的：这位仁兄在本科和master都是学的建筑，并不会写代码，后来强行申请了Stanford的CS Phd，居然还进来了。因为没有受过任何CS的科班训练，更不知道啥重构，抽象，OO，FP的概念。一切东西能用就行，还tm重构，累不累啊。而且S哥轻轻松松写个几万行毫无压力，功能都很正常。
许多年以后我才意识到，这是一位挥舞代码就像挥舞笔刷的艺术家啊，这才是代码作为一种表达方式的自然存在啊。无拘无束，放荡不羁，这才是真正的，自由的写程序！
急于求成算事吗？忌讳什么的算事吗？最重要的是写出功能，写出风骨，写出浪漫，写起代码来犹如李太白写诗，呼儿将出换美酒，与尔同销万古愁啊！
然后你就花$20/hr雇个小弟来帮你重构就好啦。
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有