糟糕的代码设计真的让人很心烦..

为什么没辙？

只要提出的想法会改进代码，并且说的别人心服口服，为什么不能这么做呢？

如果你换做LZ，现在马上就修改代码吗？多想想LZ目前在公司的状况吧，人际工程比项目工程更难搞

一个问题就能把你噎死
你说这能改进代码，证据呢？
于是，继续等下个项目吧。
既然你也知道人际工程更难搞
项目进行中你还有机会做实事你不建议他去做，却叫他等到下次项目准备这种纯靠沟通技巧的时候去提建议
你这不是往坑里推人么？

 

 沟通不能完全解决问题,接触任何新东西之前,大家的想法是先看到改变能给我带来什么,是看到不是听到也不是别的...

我觉得一切得用事实说话..

 

 

怎么叫往坑里推人呢？此话有待商榷

以目前的情况项目推进到一半，而且开发都已经熟悉代码框架下，去修改代码是很费劲的事情，再说代码也不至于槽糕的要命

另外LZ刚到新公司，就这么凸显能力，恐怕今后的路子不太平坦，如果要修改也是很隐晦的提出自己的想法，和项目的主要管理者商量，你觉得呢？

如果让LZ很直接的说出来，我觉得会伤害一部分人（就算他说的很对，很有理），对不？

你要知道，什么事情都不是一下子发生的
代码不是一下子变坏的
改进不是一下子改好的
能力不是一下子凸显的
这个项目不去一点点积累，那么下个项目还是会和这个项目一样

 

 mingr6370 说有道理,gigix 说得也不错,只不过你们考虑问题的角度不同,观点其实并不矛盾,mingr6370 说的会伤害一部分人,我考虑到了,所以到现在我没和他们提过,有改动的只是我自己的这块,当然为以后别人代码的改进也留有余地..

gigix 提到的代码不是一下子变好的,这点我现在真的体会到的,不是从书上看到的,也不是听到gigix提到我才这样说,代码是一点点积累才导致它变质的,以至于现在的同事自己都不愿再去碰以前写的东西,我之前这样问过他们:你们明明知道这样做不好,为什么不重构下呢? 他的回答彻底让我无语:任何一个系统需求变化到了一定程度就会重做一次,所以没这必要..

基于这点,所以我现在只是打算改变自己的这一部分,让他们自己能看到这样改动后带来的好处,而不是用口去争辩......

我相信事实是最好的证明..

说得很对啊，除了“任何”两个字稍微有点极端。
要考虑成本与收益的。如果这个系统本来就没打算活过一年，你去为它两年后的可维护性做的任何工作都是浪费。

项目积累非常重要，同意你的观点

我之所以说LZ在目前阶段不要大面积修改代码，是从LZ目前的实际情况出发的，更多是想的人际工程

其实在项目生存，找到自己的位置是很重要，尤其是在很大的项目组里，这是生存的方法

平均方法不超过5行? 维护方便吗? 到处都是方法?

我觉得也不太好吧. 可能最后连方法名都不知道起什么好了吧? 什么事都是过如不及. 我感觉没有必要非得要这样. 只要在写程序时注意函数的功能单一性, 其实也就足够了.