您的第一个工程工作

软件工程师有一套潜规则。 他们不在学校教书,您不会在Wiki或自述文件中找到它们,并且在公司的文化手册中也不存在。 如果您发现并关注他们-这需要谦虚,纪律和野心-这将是最快获得同行和指导者尊重的方法。 问一个问题之前,先做些腿部练习 当您沿着逻辑路线前进时,遇到一些您有疑问的问题时,自然会寻求帮助。 寻求帮助不是一件坏事,但是如果Google或StackOverflow可以回答您的问题,那么您就是在浪费别人的时间-或可能是更有价值的事情:他们的关注点。 当您有问题时,请先用尽明显的资源再打扰别人。 接下来,花时间为您的问题提供背景信息,以便您的同龄人理解问题的范围。 最后,记住答案(或者最好记录下来)。 多次回答相同的问题会很快变得烦人。 出汗细节进行代码审查 当您要求同事检查您的代码时,您是在要求他们抽出时间来为您提供完成工作所需的反馈。 要求某人检查您的代码与寻求帮助非常相似,因此,您应该注意他们的时间。 打个比方,就像要别人帮你搬家一样。 当它们出现在您家中时,所有物品都应该已经装在有明显标签的盒子中并可以使用了。 等同于将所有内容都包装在盒子中的编码始于出色的自述文件。 您应该清楚地说明工作的背景情况,更改摘要以及您要反馈的内容。 接下来,您应该像检查人员一样检查代码,以便自己解决明显的反馈。…

PullApprove + GitHub代码审查

正如我们大多数用户所知,GitHub最近在代码审查方面添加了一些新功能(以及许多其他很酷的功能)。 我们被问过很多次了…… “这对PullApprove意味着什么?” 如果您同时看过两者,您将立即看到相似之处。 GitHub代码审查现在提供PullApprove功能的子集 。 目前,它仅允许您需要1批准(作者以外的其他人)才能通过PR。 GitHub内的审阅流程已更新为支持该流程,如果您仅需这些,那就一定要使用它! 尽管我们认为这是一个不错的开始,而且随着时间的推移,他们肯定会在此基础上继续前进,但对于工作流程稍微复杂些的用户而言,这简直是无济于事。 为什么要使用PullApprove? 对于那些希望实施更复杂的代码审查过程的团队,PullApprove一直是并将继续是该工具。 我们的目标是成为需要对过程进行更多控制但又不想构建和管理自己的内部集成的任何人的首选解决方案。 PullApprove的一组简单而强大的功能可以帮助您确保您的代码符合所设置的标准。 因此,我想宣布我们迈出的下一步。 在听取并处理了用户的反馈意见数月之后,我们已经采用了所听到的一切,并重新设计了如何构造代码审查。 结果是.pullapprove.yml`version:2`-.pullapprove.yml布局中的微小变化,极大地提高了灵活性。 现在,您可以在每个组的基础上应用您了解和喜爱的所有PullApprove设置,这意味着每个组可以具有不同的“ approve_regex”,并且您可以独立进行“代码审查”和“安全审查”。…