代码被改的面目全非，求开导

水号号

棒棒夫人 发表于 2014-11-25 00:18
谢谢回答。
是， 我现在就是按照spec中的register 手册来写。 我想问， 这样的驱动怎么才能写得好呢?  ...

我所认识的都有5年以上工作经验。

棒棒夫人

谢谢上面几楼回答的tx.  大家的意思理论联系实际。  我刚刚从亚马逊上定了书， 圣诞节回家正好带回来。

远帆

我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序员。他应该明确指出你代码中的缺陷和修改方法，而不是自己动手来修改。虽然对很多老手来说自己做一遍比一遍一遍教菜鸟来的简单方便，但是一来新程序员无法从中学习，二来自己精力也有限，一个一个修改哪里忙的过来？

havoc

LZ是程序媛吧。可能读书的时候代码写少了，写到了一定程度就能融会贯通了，就形成自己的风格了，等那时候有有人把你代码全改了那绝对是士可杀不可辱，真刀真枪跟他们拼了。到时候你看到别人不入你法眼的代码也会头皮发麻，有删掉重来的冲动，但是千万要忍住，真的会死人的。
话说回来，现在你看你的头具体给你改了什么地方，如果是觉得你算法效率不行，你有时间可以去注册一个topcoder参加上面的算法比赛，看看大小高手们的代码，有时候会豁然开朗。还有一本书程序设计的艺术也不错。如果整个程序框架都给改了，那估计是要对面向对象概念加强理解，慢慢来吧，写够多了再回去看设计模式就会觉得这些所谓模式早就在自己代码里实现过或者使用过。

fusion

远帆 发表于 2014-11-25 13:21
我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序 ...

这个就是lead developer和team leader的区别，有时候可以是一个人，也可以不是一个人

adgjl

远帆 发表于 2014-11-25 13:21
我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序员。他应该明确指出你代码中的缺陷和修改方法，而不是自己动手来修改。虽然对很多老手来说自己做一遍比一遍一遍教菜鸟来的简单方便，但是一来新程序员无法从中学习，二来自己精力也有限，一个一个修改哪里忙的过来？

理论上你说的是对的，但是很多情况下不现实。一个不懂设计模式的人，你给他花上一个星期讲设计模式，改一个月改出来的东西依然是不符合设计模式的。你打算让他自己完全弄懂设计模式，得等上一两年。你等得起项目等不起，要不就牺牲产品质量，忍受将来的头痛。你要是头儿，你怎么选？这种培养要有个平衡，在不至于影响到项目的情况下，比如时间充裕，以及别人有时间给他慢慢审核。

深知我心

设计模式这种东西只能靠实际经验才能掌握，光看书没有用

书上写的都很好理解，但这些东西实际中到底是怎么用的，只能通过实际经验积累才能慢慢理解，书上那些理解都太表面了

比如用过spring你才会对工厂模式有深刻的理解，才知道工厂模式到底用在哪，怎么用

这些都需要靠时间去积累的，没个几年时间根本不行

再比如代理模式，书面上写的都很好理解，但代理模式实际中到底怎么用的，恐怕很多人都没有一个直观的概念，举不出一个真正的例子

还有观察者模式，书面也很好理解，但实际中怎么用的，实际例子恐怕知道的人不多，比如java swing的event驱动就是观察者模式，但swing的event深层到底怎么实现的，没几个人知道

这些东西都是实际经验，看书没用，急也急不来

另外头帮你改一次还好，如果经常改，就要小心了

水号号

havoc 发表于 2014-11-25 13:44
LZ是程序媛吧。可能读书的时候代码写少了，写到了一定程度就能融会贯通了，就形成自己的风格了，等那时候有 ...

多谢，你说的各个方面我都需要加强。感觉跟男生比，好像少根做程序的筋
这个帖子能吸引来这么多高手介绍经验和指点，好哈皮

水号号

深知我心 发表于 2014-11-25 14:40
设计模式这种东西只能靠实际经验才能掌握，光看书没有用

书上写的都很好理解，但这些东西实际中到底是怎 ...

原来不是我一个人的问题，设计模式读过了，感觉也理解了，但是还是不知道哪种情况下该用哪一种。除了那种特别有慧根的，我这样的也只能慢慢赞经验了。
是啊，我现在提交代码之前都特别小心，检查了再检查，怕有什么低级错误被头儿抓到。搞的跟考试之前要交卷一样。主要是非常费时。

棒棒夫人

水号号 发表于 2014-11-25 14:57
原来不是我一个人的问题，设计模式读过了，感觉也理解了，但是还是不知道哪种情况下该用哪一种。除了那种 ...

我也是， 上传代码前都特别小心， 检查了再检查， 测试了再测试。就跟交考卷一样。。。