本帖最后由 和路雪 于 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，重要的是把自己对软件开发的认知普及给每个程序 ...
你说的对，我认为这种方法才是最高效的，而且最好是说明原因，然后让程序员自己改。