带了一个实习生程序员，这波操作搞得我人都傻了，手把手教你写

虽然第一个解决方案可能很诱人，但是好的解决方案通常是在开始质疑所找到的所有解决方案时发现的。如果你不能想出一个问题的多种解决方案，这可能是因为你没有完全理解这个问题。

作为一名专业程序员，你的工作不是寻找问题的解决方案，而是为这个问题找到最简单的解决办法。所谓“简单”，意思是解决方案必须正确工作并充分执行，同时代码足够简单，便于阅读、理解和维护。

5.不放弃

另一个我经常犯的错误是，即使在我意识到第一种解决方案可能不是最简单的方法之后，仍然坚持使用第一种解决方案。这可能与“不放弃”心理有关。在大多数活动中，这是一种良好的心态，但不适用于编程上。事实上，当涉及到编写程序时，正确的心态是早失败和经常失败。

当你开始怀疑一个解决方案时，不管你在这个解决方案上投入了多少，你都应该考虑扔掉它，重新思考这个问题。像GIT这样的源代码控制工具可以帮助你扩展并尝试许多不同的解决方案，好好利用。

6.不谷歌（搜索）

有很多情况下，我浪费了宝贵的时间试图解决一个问题。但如果我去搜索一下，解决方案就出来了。

除非你使用的是尖端技术，否则当你遇到问题时，很可能其他人也遇到了同样的问题，并找到了解决方案。为自己省点时间，先去搜一下吧。

有时候，在谷歌上搜索会发现，你认为有问题的东西其实不是问题，你需要做的不是解决它，而是拥抱它。程序员都应该使用好谷歌这类搜索工具，它会让你的工作事半功倍。

7.为未知做计划

在你写作的时候，人们往往倾向于超越解决方案去思考。在你写的每一行代码中，所有的“如果”都会突然出现在你的脑海中。这对于测试边缘用例来说是一件好事，但是将它用作潜在需求的驱动程序是错误的。

你需要确定您的what-ifs属于这两个主要类别中的哪一个。不要编写今天不需要的代码，不要为未知的未来做打算。

因为认为将来可能需要某个特性而编写该特性是完全错误的，没必要这么做。

程序员新人按正确的流程开发?

1. 用GitHub或类似的现代平台

2. 平台上设置禁止直接push到主干，所有的修改必须fork后走Pull Request

3. 启用CI（持续集成），提PR时平台自动执行CI步骤，失败的不能被合并（不准开任何后门）

4. CI加入linter，确保代码规范；所有代码规范必须要可由linter检测，代码规范/linter配置规则也

要针对实践中发现的问题不断补充细化和更新

5. CI加入单元测试，代码的测试覆盖率至少60%以上，核心模块测试覆盖率必须90%以上；所有发

现的bug必须由造成bug的人负责补上单元测试

6. 每个PR强制要求改动代码行数小于100行，新人要求小于60行，以利code review

7. 每个PR在CI通过后必须有其他人进行过code review并approve，否则不能被merge，新人的代

码必须至少有两人review和approv