啥也不说，当主管审核我的流程文档，说这里的标点用错了之后.......

[hq136234303]

背景：

刚入职一家上市游戏公司，工作几年，入职服务器开发部门。本来想写更详细一点的，发现有可能主程看到，我还是不写了,很多具体我都模糊写下。

---

说说我的入职那么久经历：

第一件事：我负责实现所有逻辑和前端对接，实现和策划，前端对接完成之后。主程拉所有人去开需求会，会议上演示完成，策划和前端都觉得 OK，然后主程觉得流程需求不行，然后他和策划在会议上需求讨论，基本上换了一个流程在实现一遍。我觉得要大改，主程说如果你连这个需求都要大改我觉得你代码编写设计不行，你应该要想到策划没想到的，要预留以后策划要改实现空间。

---

第二件事：主程设计了 git commit 注释，通知整个服务器，也就我一个人，要安装他格式提交，有一次主程审核 git 提交注释格式，发现我少空格了。然后指着说，你这里少了空格呀，然后指着他 xx 上的文档说，你看我这里就有一个空格。。。。。

---

第三件事：主程审核代码。有一天说 你这个方法名应该要写 xxByxx 要写明要根据条件得来的，然后又有一天，审核代码。指着我写的 xxByxx，你这个只有一个相同类型方法的情况下，Byxx 不用写的，因为你的参数就表达了这个条件的意思。我疑问到，如果后面新增了相同类型的函数，那不就得改之前的方法函数吗？主程严肃的说到：“你到时候在改呀，我们代码不就是天天重构的吗？”，“这样不是得需要重新测试修改的代码了吗？”。“你不用管，这是规范。。。。。”。

---

第四件事：主程要求服务端所有人写需求的时候写流程文档，这里是没有设计文档的，只是平常说了一下要怎么做。新需求我开始写流程文档，主程审核流程文档，你这个流程文档有问题呀， 你看这句话都不通顺，主谓宾都没，这里这个不应该用逗号。我小心的说这个不是应该主要写下大致流程给前端看吗？前端没问题不是没事的吗？主程严肃的说，但是你这个流程表达不清晰呀，以后下个人接受怎么办。（这是暗示我？）然后这里呀巴拉巴拉巴拉。。。过去了办个小时。

[PerFectTime]

六字真言？

[kokutou]

六字真言!

[wanacry]

6word

[Ariver]

走？

[tcfenix]

每个主程都有自己的风格,你提到的这几件事情,比如提交信息格式,方法命名,流程文档这些都是针对多人(3,5 个人以上)开发的时候设定的规则

也不知道你们的项目有多大,未来会不会变成几十人,上百人的项目,不过,用这个办法打下基础也是不能说不好....虽然过程的确很麻烦...你在项目最初期开始设定规矩,这个项目是<不一定>变成屎山,而如果不写就<一定>会变成屎山

------------------------
关于实现思路的问题,实际上这也是对开发的一个软要求,很多地方对于业务开发的要求不是说产品来一个需求,我们实现一个,那样的话代码毫无架构可言,一定会崩掉, 上面需要一个资深开发能理解产品 /策划的需求,然后考虑的比他们远,面向未来的可扩展的设计框架,实现功能,最后是能够用技术引导他们去迭代功能

这个要求会对人帮助很大,你在跟策划推拉的过程中,他们会对你刮目相看,而且你自己对代码的把控能力也会更强


总而言之
你的主程肯定是一个踩过很多坑的人,他的做法不一定能解决所有的问题,但是如果不做的话....基本过一两年代码什么样就不好说了...

[luckyrayyy]

统一楼上，你的主程估计大公司来的吧，基本都有这样的流程规范。如果只有长期一两个人开发，那遵不遵守的无所谓了，但是如果考虑未来人多，或者人员经常变动，按照规范来还是很有必要的

[Jooooooooo]

我感觉你主管挺认真的

[xuanbg]

除了「只有一个相同类型方法的情况下，Byxx 不用写」这个点外，其他的真的没得黑。代码风格保持统一、文档严谨是对的。

[l00t]

让他立字据！说的东西都自相矛盾了还扯啥扯。不要口头交流，交流内容务必都文字留痕，以后他再改口就甩出来打他脸。不要怂，刚正面。

[coderluan]

只要他对别人, 对自己也这样, 那就没多大问题.

[whileFalse]

这主要看给你开多少钱。

[johnchshen]

命名规范等代码规范不是行业要求吗？

开车这么小点事还一堆交规呢。管你阿猫阿狗还是张总李总都要遵守。到写代码，明显门款比驾车高，看到规范就不想遵守了？

还好公司人少，正规点公司老不按规范设计，老不按规范编码转正都难。

[blindpirate]

他能掏出一个 checkstyle 配置+git commit hook 我就服他，要不然就是扯淡

[kuyuzhiqi]

太抠细节就过犹不及了吧，就第 3 件事情真的影响写代码的心情，都不会写了

[xieguanglei]

第一件事太宽泛了，没法评价；但是通过第二、三、四件事，可以看出这个主程还是相当靠谱的，有点完美主义者的倾向，挺好。提交规范、函数命名、文档语病，这些都不能遵守的话…………。

「只有一个相同类型方法的情况下，Byxx 不用写的，因为你的参数就表达了这个条件的意思」，个人非常赞同，楼主仔细体会吧，过早预留 /过度设计是万恶之源。

「这句话都不通顺，主谓宾都没」，个人也非常赞同，而且人已经给你指得很专业了：「主谓宾不全」。没有主谓宾，是因为你自己写的时候上下文（隐式的主谓宾）在你的脑海里，但是读者并没有你脑海里的上下文；代码和文档是写给其他人看的，你写下一句话 /一句代码的时候，有没有从读者的视角 review 一下。建议去读读专业的文档和自己的文档，仔细分析分析区别。

只要主程不是专门针对你的话，我觉得楼主还是好好跟着学吧，相信你会受益匪浅的……

个人博客： https://xieguanglei.github.io/

[noparking188]

感觉楼主所在单位的主程看起来很有经验
听闻楼主分享这些，不免让我想起现在工作的辛酸，没有规范、风格混乱、堆积屎山、维护地狱
特别是眼睁睁看着组里那个程序设计能力很弱的但是呆了很久的老人一点点写出一个屎一样的框架工具，并且常常固执己见不肯听取旁人建议而做修改，ta 觉得这样设计就很好，于是后面很大一部分工作就得在这玩意儿上写，每次打开这东西我就忍不住感到恶心。
真的感觉团队里有话语权的人去推进开发规范，是件对大家都很有益的事，这件事是个逐步迭代的过程，可能刚开始只是口头建议，然后简单记录下，再形成文档不断丰富，最后用工具做自动化流程去强制约束