There are a lot of rules about the software development process in tech companies, and each of them has was developed to solve a problem to create a maintainable, robust system. When you develop a solo home project, you usually have two steps: write code and push code using some sort of version control like git. However, developing features with other developers in a large code base will be hard to manage, and create technical debt. Technical debt is like a credit card debt, the longer you ignore it the worse it is down the road. It will decrease developer productivity, and decrease job satisfaction. Therefore, each company NEEDS to have rules of maintaining clean code when they onboard engineers. The process of clean code can be divided into these 5 major steps:
Define Rules -> Write Code -> Use Static Code Checker -> Code Review -> Merge
Defining Rules
When a new member joins, senior engineer or team lead needs to onboard the new members with a set of rules on how they write code. This means defining conventions on writing code. Each company has its own convention on developing the application. For example, Google has its own style guide on writing Java code, Twitter has effective scala, code convention for scala programming. If you have a team that cares about code quality, that is good because you can cooperate with them to create or establish that rule. Otherwise, you will need to use your persuasion skills to persuade others and business unit on why clean code is important. The team needs to create a readable and maintainable code to decrease technical debt so that business won’t spend more resources and time to fix bigger problems in the future. In addition, you cannot be the only one who cares about code quality. Why? Because it is like swimming against the current. You might advance forward a little bit, but you will feel furious and unproductive every time developing a feature and eventually burn out. You and your team need to be at the same mindset on creating better code culture. It might take some time, effort and discipline, but the outcome will create faster development speed and job satisfaction.
一旦您的团队定义了规则和约定，就可以开始开发功能并编写代码。
如何保持团队中的每个成员都遵守定义规则？ 如果您有2人的团队，则很容易根据约定持久地编写代码。 但是，当团队中有10名以上工程师时，如何确定这些规则是否适用？
Static Code Checker to the Rescue
Static code analysis tools are a method for a computer program that is done by examining the code without compiling them. It is the best way to check if your code smells. Example of static code checker tools include: Eslint, 小号onarlint … etc. Each team or company will can setup convention rules. One example of a popular coding convention for javaScript is by engineers in Airbnb. It gives an easy way to notify developers to follow conventions and best practice while they are coding.
如果您分配给旧代码并需要在旧代码的基础上构建功能，该怎么办？ 许多工程师没有特权从头开始开发可靠的新项目。 查看遗留代码可能很困难，因为它可能不可读。 您可以使用Robert C. Martin的《童子军规则》：
“让事情比发现的要好。”罗伯特·马丁
这包括：found dirty code -> need to complete task -> refactor
有时，您需要重构的代码可能比花在开发功能上的时间还多。 因此，您需要估计工作量是大还是小。 如果很小，则进行重构。 如果很大，请标记为注释去做在代码上，并使用问题跟踪器进行设置。
使用此规则，将进行少量更改，并为以后的维护人员创建更好的可读性代码，以进行错误修复或添加新功能。
Code Review
There are a lot of ways to do code review, and each company has different rules in how they conduct code review. This process is the general process that I see the majority of the company have on code review.
举几个例子来说，代码审查的重要性和好处可以提高代码质量，对团队文化产生积极影响，并且通过同行对代码专业知识的认可是许多程序员的骄傲。
至少有2个人进行代码审查。 但是，一个人也可以，但是他/她应该了解您要完成的基本业务逻辑和任务。 一旦所有突出显示的问题得到解决，您就可以合并代码并进行讨论。 此外，如果您的代码收到注释，则应解决所有问题。 说，“是的，我已根据您的建议进行修复。”要么“由于x，y，z的原因，这不是它应该如何工作。”
还应使用构建工具（例如单元和集成测试）对代码审查进行测试，以使过程更快，更无缝。 如果您没有构建工具，则可以在屏幕上进行配对编程。 这样，被审核者就能够获得有关该审核的即时反馈。 每当您希望有人执行您的代码时，都会说：“嘿，你能过来看看我的代码，看看是否有什么奇怪的东西吗？”
最后，代码审查是无阶级，成为团队中最高级别的人并不意味着您的代码不需要审核。 尊重受审者。 对抗性思维很方便，但这不是您的功能，您无法做出所有决定。 如果您不能按原样使用代码与被审核者达成共识，请转至实时讨论或寻求第三者的意见。
Conclusion
通过在工程师入职时阐明规则，他们可以在开发新功能时了解任何期望。 创建一个静态代码检查器，自动构建工具可以保持可读代码不变。 最后，拥有良好的代码审查流程不仅可以提高代码质量，而且可以为团队中的工程师营造良好的文化氛围。干净的代码不是“不错”。 这是必须的。即使您正在为业务需求争取新功能并且需要尽快推送代码，也请避免跳过这些开发过程。 永恒的警惕是所有品质的代价，而养成这种习惯可以帮助您实现这一目标。
9092
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
