怎样把握这个平衡点
现在大型的项目几乎都是面向对象的，讲究的是高内聚，低耦合，这是设计模式的基本要求，从整体上来说逻辑更清晰了，同时执行效率也更高。如上面所说，大型程序是需要更新，维护的。就算一个新的项目的开发，都是模式化，对以前的代码或多或少都要进行重用，既能缩短开发周期，又能够减少错误。而且开发都是合作式的，并不是几十年前那样自己懂自己的就行。代码的可读性好必定能够提高效率，而且为了追求效率而牺牲一些代码可读性这种几乎是不存在的。
有一句话：代码是写给人看的顺便在机器上可以执行。维护性非常重要，成本最高。
当然值得.如果你写的代码可以读懂自然会有人重写这部分代码并提高效率如果你写的代码不可读懂......那个就是一般所说的一个软件的内核. 不是由于他写的多好,是说这个项目的生命周期与这段代码的生命周期一致, 如果这段代码非改不可项目就要重写了.
如果你的架构设计使你的这段代码不能两者兼得请再花时间设计你的架构......谢谢补丁这东西是打不完的.
这个问题要仁者见仁，智者见智。。。可读性是对人而言的，效率是对机器而言的，毕竟人是活的，如果你写好注释，思路清晰，并且代码的内容只需要自己理解的话，那么牺牲可读性来提高效率也不错。。。不过如果最后修改到自己都看不懂的地步，那还是保持原样比较好。。。总的来说，追求效率而牺牲一些代码可读性完全可行。。。要做好注释工作。。。
如果代码是很稳定的的东西，别人看不到或者将来不会修改的，可以牺牲可读性。其他情况应该还是以可读性优先，除非确实遇到了性能瓶颈了，再来针对性的优化。
如果是性能瓶颈部分，哪怕是极端点，用汇编又怎么样？只要你文档、注释全，保持人员梯队稳定，这不是大问题。
如果不是关键部分，建议不要“提前优化”。注释上打个标，测试和试用时发现慢了再改好了。
产品以满足用户为第一要务么，没人用，代码再易维护也没意义。
我觉得除非效率实成为了瓶颈，否则没太大必要。一般项目最大的精力都要花在维护上，代码的可读性对维护而言很重要！
1、如果对性能影响不是很大（10%以内），建议不要牺牲代码的可读性，毕竟现在硬件升级很快，否则后面代码维护的成本会很高；2、如果对性能影响较大(10%以上），可以优化，但是要写好注释，要详细，否则你会死的很惨；3、在不影响可读性的情况下，可以任意优化。
我觉得在大型项目中，项目维护是经常需要的，代码可读性是最重要的，而且逻辑要尽量简单。在保证代码可读性的情况下优化性能，通常并不会比放弃代码可读性的情况下优化差很多，如果真的差很多，那么你可能要考虑下是不是设计有问题了。
毋庸置疑，代码的整洁，可读性是第一位的！
养成好的编码习惯，其实代码可读性和开发效率并不冲突。
我们看到别人写的晦涩的代码，一个函数几千行，套上几十个循环时，心里肯定在骂“这tmd谁写的烂code"。然后毫不犹豫的再加上一个 for 或 case -_-
所以我们自己在写代码的时候，记住要让自己别成为被骂的那个人。
这就像走路时要先左脚还是先右脚----你爱tmd怎么干，就怎么干。
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
暂无简介
文章 0 评论 0
接受
发布评论
评论（11）
现在大型的项目几乎都是面向对象的，讲究的是高内聚，低耦合，这是设计模式的基本要求，从整体上来说逻辑更清晰了，同时执行效率也更高。如上面所说，大型程序是需要更新，维护的。就算一个新的项目的开发，都是模式化，对以前的代码或多或少都要进行重用，既能缩短开发周期，又能够减少错误。而且开发都是合作式的，并不是几十年前那样自己懂自己的就行。代码的可读性好必定能够提高效率，而且为了追求效率而牺牲一些代码可读性这种几乎是不存在的。
有一句话：代码是写给人看的顺便在机器上可以执行。
维护性非常重要，成本最高。
当然值得.
如果你写的代码可以读懂自然会有人重写这部分代码并提高效率
如果你写的代码不可读懂......
那个就是一般所说的一个软件的内核. 不是由于他写的多好,是说这个项目的生命周期与这段代码的生命周期一致, 如果这段代码非改不可项目就要重写了.
如果你的架构设计使你的这段代码不能两者兼得
请再花时间设计你的架构......谢谢
补丁这东西是打不完的.
这个问题要仁者见仁，智者见智。。。
可读性是对人而言的，效率是对机器而言的，毕竟人是活的，如果你写好注释，思路清晰，并且代码的内容只需要自己理解的话，那么牺牲可读性来提高效率也不错。。。不过如果最后修改到自己都看不懂的地步，那还是保持原样比较好。。。
总的来说，追求效率而牺牲一些代码可读性完全可行。。。要做好注释工作。。。
如果代码是很稳定的的东西，别人看不到或者将来不会修改的，可以牺牲可读性。其他情况应该还是以可读性优先，除非确实遇到了性能瓶颈了，再来针对性的优化。
如果是性能瓶颈部分，哪怕是极端点，用汇编又怎么样？只要你文档、注释全，保持人员梯队稳定，这不是大问题。
如果不是关键部分，建议不要“提前优化”。注释上打个标，测试和试用时发现慢了再改好了。
产品以满足用户为第一要务么，没人用，代码再易维护也没意义。
我觉得除非效率实成为了瓶颈，否则没太大必要。
一般项目最大的精力都要花在维护上，代码的可读性对维护而言很重要！
1、如果对性能影响不是很大（10%以内），建议不要牺牲代码的可读性，毕竟现在硬件升级很快，否则后面代码维护的成本会很高；
2、如果对性能影响较大(10%以上），可以优化，但是要写好注释，要详细，否则你会死的很惨；
3、在不影响可读性的情况下，可以任意优化。
我觉得在大型项目中，项目维护是经常需要的，代码可读性是最重要的，而且逻辑要尽量简单。在保证代码可读性的情况下优化性能，通常并不会比放弃代码可读性的情况下优化差很多，如果真的差很多，那么你可能要考虑下是不是设计有问题了。
毋庸置疑，代码的整洁，可读性是第一位的！
养成好的编码习惯，其实代码可读性和开发效率并不冲突。
我们看到别人写的晦涩的代码，一个函数几千行，套上几十个循环时，心里肯定在骂“这tmd谁写的烂code"。然后毫不犹豫的再加上一个 for 或 case -_-
所以我们自己在写代码的时候，记住要让自己别成为被骂的那个人。
这就像走路时要先左脚还是先右脚----你爱tmd怎么干，就怎么干。