程序员可能常犯的 6 个错误

我担任 CTO 已经有一段时间了，我觉得这是一个非常好的锻炼机会，因为我不仅可以编写代码，还要带领团队，管理项目，设计架构，组织工作，审查代码，调查不同的问题，研究各种解决方案，了解许多技术以及联系客户等等。

通过这么广泛的任务，我学到了很多不同的技能，并有很多想法想跟大家分享一下。也许你的观点是不同的，也许你学到了一些其他的东西想在这里跟我们分享一下。我期待着听到您的意见和见解。

本文主要针对 CTO 和程序员，因为不是每个人都遇到过这些我观察到的、学到的和解决过的问题。

问题1. “我对XX技术/工具不熟悉”

这是当我要介绍一门新的技术或者语言的时候听到的最常见的一句话。这也是当我要求某位同学用他之前没用到过的工具验证他的想法的时候常常遇到的问题。

这让我感到非常惊奇，因为我是在问一个非常聪明的人，一个开发人员。我们是不是能够很容易地学习新的东西，一些新的理念，模式和架构？我们不应该不断的学习新的事务，了解最新的消息吗？

或者，这只是一种假象？也许我们对很久之前学到的东西感到很满足并且不想更换？也许是我们没有时间学习新的东西？也许我们不能有不同的想法？

一段时间之后，那个被我安排了任务的人完成了任务。他们做到了，最初的犹豫终于被克服了，他们的舒适区扩大了。那么，一开始缺乏动力的原因是什么呢？

我认为这是一种对新鲜事物的恐惧，对失败的恐惧。我们在我们所做的感到舒服，因为我们了解它，我们认为我们擅长它。事实是我们可以擅长其他一切东西，只要我们像学习之前的技能那样去学习、去实践。

问题2. “在一开始就考虑的太多”

这是我在开始新的项目时遇到的最常见的问题。程序员更加愿意加入到已经在开发的项目中，因为不需要做什么决定。而新的项目却不一样，我们需要考虑并确定需求以及功能。

我看到的最大的失败就是实现，比如，一开始的身份认证。这不是我们应用中最重要的功能吗？我们不应该考虑安全吗？不，根本不是。

我们应该尽可能的缩小范围。我们应该提供一个MVP展示概念验证。我们应该提供基本的商业规则，以及应用程序的核心功能，而不是考虑性能、分页、安全认证以及扩展等等。这是非常简单的，至少在一开始的时候是这样的。

如何实现呢？我觉得跟客户的沟通是至关重要的。这是他们的钱，他们的投资，他们是给我们付钱的人。我们不想浪费他们的资金，他也不想浪费。我们应该一起讨论重点是什么，我们应该向他们的潜在客户或者投资者提供什么。我们不应该专注于其他人不会考虑的地方，如登录/注册功能，更改电子邮件或删除帐户。

问题3. “没有选择正确的工具”

我多次与不同的公司谈到他们开发堆栈。有时候他们做的很花哨，并发和分布式事物使用Ruby…。当我问他们为什么选择这个相对低效的语言时，他们的回答是所有的程序员对Ruby最了解。当然，这显然是最快并且最廉价的方式。他们并没有考虑到长期运行的可维护性。他们只关注价格和便捷性。这给他们带来很大的技术债务，并且很可能需要做很多hacking来实现既定目标。

另一个常见的现象是，很多程序员在熟悉业务规则之前就选择技术栈。经常可以在充满激情的程序员中见到这种现象。他们是如此热衷于开始开发和使用所有的最新的框架。他们不考虑系统将要做什么，需要解决什么问题，他们就已经选好了数据库和语言。

在这种情况下该怎么办？我的建议是让程序员了解很多不同的语言。在熟悉问题和用例后，我们可以讨论这个工具的利弊。了解市场上有正在发生什么，有什么框架或者语言，它们解决了什么问题是非常好的。坚持使用一种大家都知道的工具，可能在开发过程中带来很大的痛处。

问题4. “重复造轮子”

这个问题主要是对其他人参与的不熟悉。当我review别人代码的时候经常看到这种情况。我经常问：“你看到那个class/module/function 了吗？它跟你已经实现的完全一样。”这主要是程序员不经常浏览代码，他们不知道一些代码可以重复使用，而不用在任何地方都重复提取。

如果我们遵循一些共同的模式，指导方针和架构的时候尤其如此。极有可能其他程序员已经在其他地方解决了这个问题，提取、抽象出了我们现在需要一个功能。

为了避免这种情况，我们应该用一种更加明智的方法更多的做 code reviews。我们不应该检查别人的括号是不是对齐了或者是不是缺少了逗号，这些应该留给自动化工具来做。我们需要 review 业务逻辑和行为。一段时间之后，我们会想，“ Kamil 已经实现了它，我可以用他的模块”。

问题5. “学习语法，而不是编程”

我遇到过这样两种程序员。实际上我可以说还有一种是前两种结合起来的第三种程序员，但在这里并不重要。

第一种是非常优秀的 coder。他们了解所使用语言的各个方面，他们知道所有标准库以及很多第三方的工具。他们知道8种方法来写一个循环、如何使用模式匹配和所有的语法。但问题是，他们不知道架构和模式。他们的代码是必要的，但他们不能提取出功能、处理封装并分解到不同的层或者模块。他们只会编码。

第二种是非常棒的 craftsmen (工匠)。他们是真正的架构师，他们会模块化他们的应用程序、使用单独的库来提取组件、按照模式设计有效的流程。只是他们不会编码。他们把太多的时间花费在低效的算法、不建议使用的函数、过时的库。也许他们的架构体系是可靠的，工作流是强大的，但他们的代码可能很难看，很难读。

问题出在哪呢？第一种情况可能是程序员只读与他使用语言有关的编程书籍。就相当于只学习语法而不学习别的。他们认为他们会语法，所以他们会编程。而实际上我们只会写代码。第二种情况是程序员忘记了他们使用的语言或者工具的新版本，他们不看更新日志，不看新闻和简讯。

解决方法是什么呐？就是在项目中两种人同时存在，每个人都会互相学习，这是每个人都会感到满意和受益最多的一种方式。

问题6. “忽略模式”

当一个人加入到一个有坚实基础的项目是，他很可能会遵循一些规则和指引。通常，开发人员在每一个地方都会有一个惯例，使其在每个地方都是可读和可理解的。

不幸的是，当一个新人加入编码的时候，他可能不知道内部正在开发项目的相似性。他可能会使用一种不同的、不符合当前要求的方法。

我们是如此热衷于提供一个新的功能，以至于我们不想浪费时间来观察现有的趋势和模式。我们完全忽略了既定的规则，并因为我们自己的习惯打破一致性。

这是不好的吗？并不经常是这样。有时候，特别是有经验的程序员加入团队的时候，这可能是好的。他们可以教其他人如何架构应用，并给他们分享知识。这有时候会给现有的架构带来一些新的观点，提高其中的一些概念。但事实上，这种情况很少见。大多数情况下，一个新的开发者只会带来麻烦。这在 The Mythical Man-Month (人月神话) 这本书中描写的很好。

如何解决呢？我觉得引进一个新的项目是必要的。我们不应该要求尽快的有新的功能，而是要有人能够深入到既定的规则。我们应该任命一个一开始就能指导别人的人为主管，让他掌握所有的概念。

总结

编程的世界中有很多的问题，我们每个人都有不同的技能，不同的能力和动力来源。即使是我们不这么想的方式也会不同。我们应该互相沟通，共同解决问题，并做出权衡。

学习是关键。自主开发不应该停止。我们不得不这样做，除非我们不想成为优秀的程序员。不断地学习和了解新的东西是我们应该做的工作。

读书是第一方式，结对编程是第二种方式，订阅电子报可能是第三条道路，以及关注一些博客可能是另一个方式。

可能性是无限的，我们只需要选择适合我们的就是最好的。