浅谈利用Code Review来增加自己在组内的影响力和Visibility

人手充足的大公司也许这样会有用吧。我们组人少活多，大家每人负责一块产品。每个人自己的story按计划做完就很不错了，request的feature都排到后年去了，根本没人有人花闲情花时间在cr上。
像我们这种小公司，高效高质量做好feature，才能提高visibility。cr这种只有senior给new hire仔细做一下，之后都是manager大致看一眼就merge了。
跟各组风格也有关系...隔壁a组就对code style啥的很敏感，有个new hire的cr搞了好久还没过，隔壁b组老板急着要用这个code，而且b组对style啥的一直都是无所谓，就给merge了...然后a组老板气死了跟b组老板大吵一架
我们公司总的来说对code质量不care。performance review都是看feature完成了多少个。什么代码质量，close多少defect，写文档什么的全都没鸟用。

“要是读不懂代码，那就是写得不好”
个人经验 虽然代码可读性重要 但如果写代码一味追求可读性 完全属于捡了芝麻丢了西瓜
而通常情况下 在遵循设计理念和代码规范的情况下 代码的可读性都不强
年轻的工程师 想靠Code Review 这种环节来增加可见性 怕会弄巧成拙哦

bemonster 发表于 2019-2-23 05:50
人手充足的大公司也许这样会有用吧。我们组人少活多，大家每人负责一块产品。每个人自己的story按计划做完 ...

非常感谢你的分享，我也非常赞同小公司就要看feature出得快。只要保证现在写的代码以后不用扩展，或者要扩展的时候原作者还在公司里，那么出feature的速度就可以保持一直超级快。
长远的话。。不知道是不是合适。祝愿层主在那之前找到更好的自己喜欢的职位/公司。

askforlove 发表于 2019-2-23 09:24
本质是占用别人的时间给你表现的空间。与文G时期的吃大锅饭评工分分粮食一个故事，今天你做了多少能得多少 ...

同意出成果靠的是知识积累，写贴目的是引导大家利用PR进行知识积累

baz 发表于 2019-2-23 06:35
“要是读不懂代码，那就是写得不好”
个人经验 虽然代码可读性重要 但如果写代码一味追求可读性 完全属于 ...

而通常情况下 在遵循设计理念和代码规范的情况下 代码的可读性都不强
想看看具体的实例呢

normanwu1990 发表于 2019-2-23 12:26
而通常情况下 在遵循设计理念和代码规范的情况下 代码的可读性都不强
想看看具体的实例呢

可以啊
想看什么语言的？ OOP 还是 FP ?

normanwu1990 发表于 2019-2-22 07:29
很好的问题！
我尝试来回答一下
1）我觉得你已经回答了自己啦，长期来看势必有好处。那有哪些好处呢？  ...

多谢楼主分享，学习了

baz 发表于 2019-2-23 13:14
可以啊
想看什么语言的？ OOP 还是 FP ?

都可以的，学习一下,oo更日常一点 :)

normanwu1990 发表于 2019-2-25 11:59
都可以的，学习一下,oo更日常一点 :)

1. #include <stdio.h>
   
2. struct str_rd{
   
3.     int len;
   
4.     char c[0];
   
5. };
   
6. 
   
7. struct foo {
   
8.     struct str_rd *s;
   
9. };
   
10. 
    
11. int main(int argc, char** argv) {
    
12.     struct foo f={0};
    
13.     if (f.s->c) {
    
14.         printf( f.s->c);
    
15.     }
    
16.     return 0;
    
17. }

复制代码

评价一下 这段代码？
本来只是觉得一句话说的不太妥当而已 博出位没什么错 但自己看不懂就让别人改的话 哈哈哈哈 服
既然想杠 那就来呗