谢谢回答。
是， 我现在就是按照spec中的register 手册来写。 我想问， 这样的驱动怎么才能写得好呢?...
我所认识的都有5年以上工作经验。 谢谢上面几楼回答的tx.大家的意思理论联系实际。我刚刚从亚马逊上定了书， 圣诞节回家正好带回来。 我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序员。他应该明确指出你代码中的缺陷和修改方法，而不是自己动手来修改。虽然对很多老手来说自己做一遍比一遍一遍教菜鸟来的简单方便，但是一来新程序员无法从中学习，二来自己精力也有限，一个一个修改哪里忙的过来？ LZ是程序媛吧。可能读书的时候代码写少了，写到了一定程度就能融会贯通了，就形成自己的风格了，等那时候有有人把你代码全改了那绝对是士可杀不可辱，真刀真枪跟他们拼了。到时候你看到别人不入你法眼的代码也会头皮发麻，有删掉重来的冲动，但是千万要忍住，真的会死人的。
话说回来，现在你看你的头具体给你改了什么地方，如果是觉得你算法效率不行，你有时间可以去注册一个topcoder参加上面的算法比赛，看看大小高手们的代码，有时候会豁然开朗。还有一本书程序设计的艺术也不错。如果整个程序框架都给改了，那估计是要对面向对象概念加强理解，慢慢来吧，写够多了再回去看设计模式就会觉得这些所谓模式早就在自己代码里实现过或者使用过。 远帆 发表于 2014-11-25 13:21
我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序 ...
这个就是lead developer和team leader的区别，有时候可以是一个人，也可以不是一个人 远帆 发表于 2014-11-25 13:21
我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序员。他应该明确指出你代码中的缺陷和修改方法，而不是自己动手来修改。虽然对很多老手来说自己做一遍比一遍一遍教菜鸟来的简单方便，但是一来新程序员无法从中学习，二来自己精力也有限，一个一个修改哪里忙的过来？
理论上你说的是对的，但是很多情况下不现实。一个不懂设计模式的人，你给他花上一个星期讲设计模式，改一个月改出来的东西依然是不符合设计模式的。你打算让他自己完全弄懂设计模式，得等上一两年。你等得起项目等不起，要不就牺牲产品质量，忍受将来的头痛。你要是头儿，你怎么选？这种培养要有个平衡，在不至于影响到项目的情况下，比如时间充裕，以及别人有时间给他慢慢审核。 本帖最后由 深知我心 于 2014-11-25 14:42 编辑
设计模式这种东西只能靠实际经验才能掌握，光看书没有用
书上写的都很好理解，但这些东西实际中到底是怎么用的，只能通过实际经验积累才能慢慢理解，书上那些理解都太表面了
比如用过spring你才会对工厂模式有深刻的理解，才知道工厂模式到底用在哪，怎么用
这些都需要靠时间去积累的，没个几年时间根本不行
再比如代理模式，书面上写的都很好理解，但代理模式实际中到底怎么用的，恐怕很多人都没有一个直观的概念，举不出一个真正的例子
还有观察者模式，书面也很好理解，但实际中怎么用的，实际例子恐怕知道的人不多，比如java swing的event驱动就是观察者模式，但swing的event深层到底怎么实现的，没几个人知道
这些东西都是实际经验，看书没用，急也急不来
另外头帮你改一次还好，如果经常改，就要小心了 havoc 发表于 2014-11-25 13:44
LZ是程序媛吧。可能读书的时候代码写少了，写到了一定程度就能融会贯通了，就形成自己的风格了，等那时候有 ...
多谢，你说的各个方面我都需要加强。感觉跟男生比，好像少根做程序的筋{:5_354:}
这个帖子能吸引来这么多高手介绍经验和指点，好哈皮{:5_315:}
深知我心 发表于 2014-11-25 14:40
设计模式这种东西只能靠实际经验才能掌握，光看书没有用
书上写的都很好理解，但这些东西实际中到底是怎 ...
原来不是我一个人的问题，设计模式读过了，感觉也理解了，但是还是不知道哪种情况下该用哪一种。除了那种特别有慧根的，我这样的也只能慢慢赞经验了。
是啊，我现在提交代码之前都特别小心，检查了再检查，怕有什么低级错误被头儿抓到。搞的跟考试之前要交卷一样。主要是非常费时。 水号号 发表于 2014-11-25 14:57
原来不是我一个人的问题，设计模式读过了，感觉也理解了，但是还是不知道哪种情况下该用哪一种。除了那种 ...
我也是， 上传代码前都特别小心， 检查了再检查， 测试了再测试。就跟交考卷一样。。。 本帖最后由 和路雪 于 2014-11-26 23:12 编辑
可以的话，代码发上来看看呗。
不然没人知道他到底改了啥，为什么改。
另外，你自己能分析出他改过之后的好处吗?
我想别人大改你的代码，一般不会因为代码风格或者美观之类的因素。
可能更多还是涉及到，设计，算法，内存管理之类的问题。
另外，怎么才算好的代码，很难有统一的标准。
当然有一些业界共识的规则和好习惯，需要去学习和遵守。这能降低你的开发和维护成本。
至于怎么规划类，抽象要到什么程度，怎么解耦，用什么设计模式。
这些问题可以去系统的学习下，但万万别当成套路和公式。
也不要为了漂亮或者显得高大上而刻意的去怎么样。。
任何工程上的设计都是综合各方面妥协后的结果，过度复杂或者过于简单的设计都是值得商榷的。
不同于传统工业，软件是需求相对不稳定的行业。
最大的风险在于，不能把过去某些成功的经验直接照搬。而要具体分析每个实际的问题。
lz公司流程里缺少团队精神，为啥要让一个人折腾一周，为啥要一个lead developer review所有的代码，他就一定对的？模块设计应该是小组共同决定而不是一个人决定。组内要关注每个人的成长而不只是交付项目，组员水平高低不同要合理分配任务 和路雪 发表于 2014-11-26 21:19
可以的话，代码发上来看看呗。
不然没人知道他到底改了啥，为什么改。
代码就不太方便放上来了，毕竟和公司都有保密协议。
不过我觉得对比他的代码，他多加了几个类，我觉得主要是设计问题，或者可扩展性不够。 水号号 发表于 2014-11-27 13:54
代码就不太方便放上来了，毕竟和公司都有保密协议。
不过我觉得对比他的代码，他多加了几个类，我觉得主 ...
那你正好学习了。
不过别忘了，任何设计都是有取舍的。可能某些地方有优势了，比如好扩展了，另一方面就有下降。 远帆 发表于 2014-11-25 13:21
我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序 ...
我觉得提高自己开发的质量最主要要靠自己，而不是lead dev.的职责。lead dev.可以给你Unterstützung，在你需要的时候，但是aktiv的应该是程序员自己。
楼主的这个lead dev.亲自改了楼主的代码就好像一个师傅给学徒演示一下正确的操作方法一样，肯定不会是长期的，否则谁都受不了，短期内也算是传递他对软件开发的认识和经验比较高效的方式。
指出错误让程序员修改，如上面有人说，实际抄作上可能不那么容易，和双方的沟通能力，程序员的悟性和经验关系很大，很多时候是个徒劳的事。最高效的就是他给你改了，你看懂了，下回照葫芦画瓢 tadios 发表于 2014-11-27 09:18
lz公司流程里缺少团队精神，为啥要让一个人折腾一周，为啥要一个lead developer review所有的代码，他就一 ...
呵呵，我就挺喜欢pair-programming的。。看着编程的时间doppel了，可是省去review的时间，而且大家可以交流经验，互相都可以学到东西。不过这个有的时候由于politik，或者是persoenlichkeit的原因不能实现。就是说不是每个team都可以用一个模式。我们也在不断调整我们的prozess, review现在竟然要四只眼，两个人。。可是大家叫苦连天，因为这些都是Aufwand，Aufgabegeber在跟你讨论budget的时候才不会考虑到team成员的发展和因人给Aufgabe呢。他们认为你们都是一样的，是PT{:5_383:} krap 发表于 2014-11-27 15:39
呵呵，我就挺喜欢pair-programming的。。看着编程的时间doppel了，可是省去review的时间，而且大家可以交 ...
我也在苦恼这个流程。而且review的质量很不好把握，有时候看reviewer的心情和性格 krap 发表于 2014-11-27 15:39
呵呵，我就挺喜欢pair-programming的。。看着编程的时间doppel了，可是省去review的时间，而且大家可以交 ...
每个组不一样，组里的人也不一样，不是pair programming就适合所有的情况，我们组里很少pair programming，而是一个task完了以后另一个组员review。如果大家都对review process不满意说明需要改进，一个大家都认可并乐意的工作环境是效率的前提 什么语言。。。 远帆 发表于 2014-11-25 13:21
我个人认为你的TeamLeader处理方法不合适。作为LeaderDev，重要的是把自己对软件开发的认知普及给每个程序 ...
你说的对，我认为这种方法才是最高效的，而且最好是说明原因，然后让程序员自己改。 看来论坛里程序高手好多，有没有搞ABAP的大拿，给新人点建议 {:8_490:}
页:
1
[2]