krave1986 / how-to-manage Goto Github PK

1、合并分支
git merge --no-ff --no-commit dev
把 dev 分支合并到当前所在分支

在生活实践中，我们会看到说，你买了小米笔记本，然后发现有着非常多的问题。
工程师实际上，已经修复了很多地问题，但是消费者并不清楚。
遇到问题以后，仍旧会指责企业的技术差，不负责任。

我们想要的结果是：
成果触达

如果你付出了努力和汗水，而其成果，是可以被复制，可以被更多人享受到的。
那么，你的工作还没有完成。
你的工作是，需要尽可能地让更多人，不过不能是所有人的话，享受到这份成果。

这是你的义务，也是让你的成果实现价值最大化的唯一方式。

首先，我们在工作当中，所做的所有努力，都是为了能够把某件事情做成。如果他人所做的一些工作，由于某些原因，没有成功。而你是来判断他是否成功的那个人。别告诉他，你因为哪些条款没有成功！而是告诉他，他怎么做，才能成功！越细致越好。特别是审核这一块。比如百家号的C位直达的审核。其实百家号的所有员工的工作，都是要尽可能地去贡献更多的词条记录。但是在百家号作者完成了记录，但是不符合某些要求的情况下，只是告知他，要求点中那几条没有通过。应该去查XX标准。

被告知的人，拿别人的例子去处理问题的时候，是茫然无措的。我并不觉得别人做的比我的好在哪里。

为什么不能这样？既然你已经阅读了我写的这篇文章。为什么不直接就我的这篇文章，来说，哪里是有问题的。原因是违反了哪条标准。你的这篇文章如果可以这样修改的话，就可以通过审核了。为什么不多说一点？！

想尽一切办法，最高效地完成这件事情。OK?!

持续激励这个想法，我觉得是发挥团队战斗力的最主要来源。

物质激励和精神激励同样重要。

大项目，分阶段来做激励；
小项目，立项的时候，stakeholders 出预期；交付后，stakeholders 和 盲眼用户 进行预期评价，专属工具，来做评分评价。

一定会既有高于预期，又有低于预期，还有预期中根本就没想到或要求的点，感动盲眼用户了，就能开启激励。

同样，低于预期的话，也要有罚。

有经济效益的项目，直接拿效益来分享；
没有经济效益的项目，综合 间接效益、社会效益、行业效益、公益效益，等等等等，
一起来做评价。

需求评审大会，可以由业务和业务之间开会。
审核业务需求的合理性，把其它的业务需求，以及同行经验带入。
更重要的是，能够做到业务相辅相成，技术充分复用。

把项目学习和研究的过程，直接放在项目里。开一个 research 分支即可。这样即便你是在学习，中间学到的所有内容都记录在案。让我们的努力皆可成为后继者的阶梯。

想法非常多，但是真正要进入到需求阶段，
必须经过 可行性 分析。

怎么做可行性分析？我也不知道。
继续学习。

我们在多人开发的时候，会遇到代码覆盖的情况。

祥哥以前有提到过 merge request 的方式非常好。

但是如果仅仅是一个人进行代码评审，并进行 MR 的话，
仓库大了，势必会有漏网之鱼。
让代码评审形同虚设。

那么如果上线（目前这边的状态是，一个monolith非常大，任务非常多），
基本上每天都会上线，所有人都留下来做评审的话时间上，巨大的浪费。

可以通过 gitlens 中，某一次的提交，对应到上一次提交，所受影响的那一行代码的提交人，
把这些所有受影响的人，集中起来，一起做代码评审，就会比较高效。

如果效率要再提高的话，每次 commit 被 merge 到 remote 的时候，都可以发邮件提醒，你的代码已经被修改了。
可以及时做纠偏。

但是！我们要有一个理念：尊重新的想法，和，新的尝试。

大家可以交流，提出可能的问题点。但是不要带有指责的方式去看待这个事情。

1、所有bug做责任认定，责任认定之前，bug不关闭。bug不关闭，测试的任务就没完成。

贡献点的提出，是为了能够让整个团队更加乐于贡献，更加懂得感恩。在员工评价的过程中，先列出他人对自己的帮助，记为贡献点。然后每个人拿到自己的贡献点列表之后，自己再做补充。然后再结合病假和事假。总体一起评价一段时间下来的绩效。

在生产实践当中，一定会有一些东西是你所没有 cover 到的，并不是你不想 cover 到，而是现实的情况不允许你花太多的时间在上面。

所以，即便如此，有一个 not covered 记录表，之后就可以跟踪自己的学习进度。也可以让公司知道技术水平，以及接下去的需求，是否能够简单地被 cover 到。有利于更好地评估需求。

同样是和项目工程实操有关的问题。
在项目上线的过程中，会发现项目需要优化，以及来不及修复的 BUG
统一加入 TODO list 当中去。

作为下次开发的任务排期。

架构师的职责，就在于解决项目中的实质性难题的。
如果有地方卡住，需要加班的，就找架构师。

架构师不能解决，下面解决了，直接王驹异位。

有快的途径，不用；坚持加班的，鼓励！
出发点除学习以外的，通通立项！

同贡献点，可以抵扣任务进度。但是需要定期分享知识点内容。

我们主张程序员做 research ！！！！！

我就想说这个。
我们所有人，都是科学家。

我们对自己的领域深入研究，对企业和个人的发展都有好处！

1天、2天、1周，没有写代码？没事！！！
给出你 research 的东西，过程、经历、结论，论坛上发的提问帖也行！！！！！！！！

我们主张 research ！！！！！！！！！！！！！！！