这是一个创建于 4857 天前的主题，其中的信息可能已经有所发展或是发生改变。
总是遇到这种情况：
团队中的主力也都停留在： 扒代码、复制粘贴改改就用、无代码质量意识或者并不重视质量 的状态。实习生，暂时连使用的语言都不太熟练。
这种情况下，各种重复代码，临时方案到处都是，动不动就出问题，修一个 bug 也会造更多的 bug。
我的问题是：
1. 如果作为团队的普通成员，认识到了这些问题，该怎么做？
2. 如果作为团队的负责人，认识到了这些问题，该怎么做？
团队中的主力也都停留在： 扒代码、复制粘贴改改就用、无代码质量意识或者并不重视质量 的状态。实习生，暂时连使用的语言都不太熟练。
这种情况下，各种重复代码，临时方案到处都是，动不动就出问题，修一个 bug 也会造更多的 bug。
我的问题是：
1. 如果作为团队的普通成员，认识到了这些问题，该怎么做？
2. 如果作为团队的负责人，认识到了这些问题，该怎么做？
 | 2 hyh1048576 2012-07-29 00:35:43 +08:00 难道不能只招代码写得好的人么？ |
 | 3 reus 2012-07-29 00:47:56 +08:00 集体读书学习 |
 | 4 insraq 2012-07-29 00:55:25 +08:00 Coding standard + BDD/TDD + Good version control workflow + Code Review |
 | 5 keymorek 2012-07-29 01:12:43 +08:00 喜欢这份工作 |
 | 6 sdjl 2012-07-29 09:26:20 +08:00 @hyh1048576 我也是这么想的 |
 | 7 kurten 2012-07-29 09:44:50 +08:00 这个我觉着关键还是在于团队负责人这里，负责人可以先制定一个coding style，参考google的coding style https://code.google.com/p/google-styleguide/ 。有了统一的风格就比较好控制整体的编程质量。然后定期，团队内部做技术分享。再者么，定期做小范围的重构。负责人一定定期要做code review。只要团队内部整体上逐渐形成一种氛围，团队成员自然而然的会提高么。 |
 | 8 NemoAlex 2012-07-29 10:01:27 +08:00 你说的这个不是水平问题而是态度问题 解决办法只有多拿出一些精力和资源放在招聘和人员培养上 招一些热爱此事业的人，不是以混饭为目的而工作的人 如果团队现状已是这样，作为负责人，想要改变着实困难。恐怕要大面积裁人了。 作为团队中的一员，如果 |
| 9 NemoAlex 2012-07-29 10:02:51 +08:00 [接上]想要改变，建议还是换个环境来得直接 |
 | 10 lainuo 2012-07-29 10:03:42 +08:00 Pull requests + Code review |
 | 11 vven 2012-07-29 10:33:30 +08:00 不知道在团队开发中大家怎么管理共同编辑的模块 有的人为了调试方便先把别人的或者已经稳定的代码注释或者修改了，搞得新功能没弄完旧功能又出错了 |
 | 12 saharabear 2012-07-29 10:45:47 +08:00 这种问题基本上不需要解决。因为：团队老大都不在乎，你在乎又能如何，还不如换一个能让你感觉不错的环境。 这年头，谁不想和优秀的人一起工作？ |
 | 13 treo 2012-07-29 12:03:50 +08:00 答案依次是 1. 打酱油 2. 换人 |
 | 14 dreampuf 2012-07-29 12:57:51 +08:00 《代码匠艺》里有一章描写了Coder中不同人。 里面也针对不同的用户给出了一些很好的建议。 如果作为普通员工，第一件事情就是姿态摆好，不要把自己限定到一个“普通员工”中，上面的设计傻X，你就直接反驳，直到给你一个满意的答复为之。但要对事不对人，把整体项目方向把握才是公司看重的。其实没有最好的方案，大家一致同意的才是团队进行最好的，哪怕坑，吃一堑长一智，下次还可以做得更好。 作为Leader，把握“好”与“坏”，注重团队内部的意见，及时给与反馈，技术上辅导团队成员，多做培训，团队内部多交流沟通。培养有“潜力”的好Coder。 另外，我始终觉得，如果只是因为环境不行，而直接换一个环境的行为，怎么说，都感觉有点弱。 “要么我改变你们这群害群之马，要么把我开除”，这是我工作的时候抱有的决心。 |
 | 15 ine181x 2012-07-30 13:16:07 +08:00 @dreampuf 喜欢楼主的最后一句话，如果大家都是抱着环境不好就换公司的话，工程师这个圈子，好的始终是少部分。既然已经决定要走，那为什么不在走前去试试看能否改变现在的环境呢。 |
 | 16 eas 2012-08-03 15:31:40 +08:00 保持关注，我目前也有这种困扰 |
 | 17 JerryKwan 2012-08-28 09:37:54 +08:00 可以尝试code review， 如果原有的代码管理系统就是git，gerrit是一个不错的选择 |
 | 18 vexfisher 2012-08-28 10:13:58 +08:00 个人看法： 1. 个人职业操守。部分人的节操和意识就那个层次，意识不到问题所在，或是即使意识到也懒得改进。 2. 团队氛围。周围人都这么干，随大流吧。 3. 公司的考核原则影响。代码写得好坏与否，反正不会太影响考核，特别是在大公司，会说话比会写优质的代码重要多了（无可奈何的认同）；另外有人会认为与其花点时间写好代码，还不如把时间投入在一些其他的项目中，年度考核、晋级时还有东西可讲，短期上看，貌似ROI更可观。 |
 | 19 xcl3721 2012-08-28 10:14:26 +08:00 计划，落实，考核 计划好所有你要做的事情和目标 落实责任到每一个人，让他们明白自己做的东西要负责 考核，考察进度，核对质量，奖罚分明 |
 | 20 wangkangluo1 2012-08-28 11:15:19 +08:00 coding rule + code review |
 | 21 davidx 2012-08-28 13:22:01 +08:00 @vexfisher 我觉得你这么说太偏激了 不是每个人都可以成为大牛, 或者愿意成为大牛的. 一个好的团队, 应该培养大家一种共同的习惯, 有一种共同的约定, 大家都在这个框框下办事, 质量就会高很多 同时, 应该有各种培训, 促使大家进步, 再同时, review的质量也要保证好 |
 | 24 jiggy 2012-08-29 23:53:47 +08:00 这类问题负责人不出面压根就没出头之日.码农每天bug一大堆哪有时间给你整这些东西.产品的，测试的都盯着你,没辙.质量慢慢降低.终于等到不得已而为之的时候再开整吧.上面关注的可不是你的代码有多优秀.功能需求全部ok成功80%了.最后ANR啊。Crash啊一个一个解决掉阿弥陀佛了就 |
Select Language