和 mentor 代码习惯不一样,好头痛

查看 134|回复 9
作者:Ainokiseki   
校招生一枚,入职半年了,和 mentor 一起负责项目的某个模块,代码自然是两个人互相 review 。
mentor 之前在某大厂,看起来是比较资深的那种,再加上前期对项目不熟,小透明基本上是 mentor 说啥是啥。
review 的时候 mentor 的代码只要功能 ok 那就好,但是 mentor review 我的时候就有点不走心,有些地方没看懂就写 comment ,还有些地方我的设计本来 ok 的,他又要按他自己的习惯来改。
我理解这项目最开始是 mentor 写的,可能看着自己创造的东西被别人改来改去总会不舒服?至少我是无数次幻想着哪天 mentor 不在了我要把现在的代码按我的风格从头到尾重构一下 hhhh
可能 mentor 觉得我菜吧,但我觉得我只是经验不足,好歹哥们也是名校出来的,开发工作难度也就那样,要是功能缺陷那让我改我没话说,但只是代码习惯不一样就被要求改就很烦
关于例子:之前的写法可能误导大家,我重新 append 一下
注意不是只处理最后一个,不是只处理最后一个,不是只处理最后一个
```
for i:=range array{
// do sth normal to array[i]
if i==len(array)-1{
// do sth special to array[len(array)-1]
}
}
```
mentor 要我改成:
```
for i:=0;i_<

mentor, 代码, Review, 习惯

liprais   
@Ainokiseki 他看错的原因我觉得能理解,因为他是在没想到你只处理最后一个居然要循环,自然以为是你循环处理别的东西了。说不好听的就是高估你的水平了
idealhs   
for in 是最简洁的,少点花里胡哨的语法糖
hahastudio   


我主导的项目都是微服务,DDD ,拆模块拆项目,总是就是求求你别把代码写我项目里,我们俩 rpc 交流就行
什么代码风格,能用就行,眼不见为净
Ainokiseki
OP
  
你举的这个例子如果让我 review ,我应该也会指出同样的问题。不同的代码风格各有利弊,可以商量,团队里商量出一个大家都能接受的共识就好。但你这个例子不属于代码风格或代码习惯的问题,这种代码逻辑的差异,虽然等价,但是存在明显优劣。
lifei6671   
op 或许可以把视野放宽到你们公司的整个技术团队,看看大家的规范是如何?如果你和大多数人都不太一样,建议还是按团队规范走
Ainokiseki
OP
  
@ScepterZ 我 不 是 只 处 理 最 后 一 个!只是最后一个要特殊处理。。。omg 我还是 append 到主楼吧
undeflife   
if 越少,代码越好。
kxct   
@Ainokiseki 两个差不多, 但如果一定要分个好坏, 那么 mentor 的更好.
首先, 明确一点: 任何软件都是业务软件. 对于技术软件, 技术本身就是业务.
* 对于团队项目, 大部分情况下, 代码的可读性要比效率更重要.
* 根据单一职责原则, 每段代码只做一件事情.
* 代码应该尽量只表达其业务意义. 这也是函数式编程的好处之一.
对于你给的例子, 最后一个元素要特殊处理, 就应该把这块特殊逻辑"独立且突出", 增强可读性.
Yuhyeong   
@Ainokiseki 那是我理解错了,这样的话看具体的逻辑吧,哪种和产品思路比较顺就怎么写
您需要登录后才可以回帖 登录 | 立即注册

返回顶部