我作为CTO已经有一段时间了。在这个工作岗位上，我不但制定准则，还带领团队、管理项目、设计架构、组织工作、制定代码审查、调查不同的问题、研究各种解决方案、结识许多技术人员和联系客户等等等等，做了很多事。
在完成这些任务的过程中，我不但学到了很多不同的技能，并得出了很多观察结果，想与大家分享。
本文针对的是***技术官和开发人员，因为可能并不是每一个人都碰到过我下面发现、学习并得到解决的问题。
问题1：“我不熟悉X技术/工具”
这是每次在我要介绍新技术和语言的时候，最常听到一句话。也是在我要求某人用一种他们不认识的工具准备一个概念证明时，非常耳熟的一句话。
这让我很惊讶，为什么呢？因为我认为程序员都是高智商的！学习一些新的东西，新的理念、模式和架构对于他们来说难道不是一件很容易的一件事吗？难道他们不应该不断学习新的东西，关注***的消息吗？
可能这只是一种假象？也许我们早就满足于我们以前学会的东西，并不想转变？也许真相是，我们已经丧失了进取心，不想发展了？也有可能是我们没有时间学习新的东西？
一段时间后，我要求对方完成的任务做好了。他们做到了，他们交付了。最初的犹豫最终被克服了。又掌握了一些新的东西。那么，一开始缺乏动力的原因是什么呢？
我认为这是因为害怕，害怕陌生的东西，害怕失败。做自己已经会的东西，总让人感觉得心应手，这是因为我们知道它，我们认为这是我们擅长的。但问题是，我们也可以擅长别的东西，只要我们需要它，肯去了解它，用之前相同的完成方式去学去做。
问题2：“一开始就想太多”
这是我在启动新项目时看到的最常见的问题之一。开发人员之所以觉得加入已工作的应用程序会更舒心，是因为需要做的决策会少很多。而开始一个新项目则不同。我们需要作出决定，并优先考虑需求是什么以及***能够具备的特点。
***的失败是在实现中，例如，在一开始的身份验证时。这是不是应用程序最重要的特点？要不要关注安全？No，大错特错。
我们应该尽可能地缩小范围。我们应该提供MVP来展示概念验证。我们应该提供基本的商业规则，应用程序的核心功能，而非着眼在性能、分页、超安全认证和极度可扩展性上面。要简单化，至少在一开始的时候。
如何做到这一点？我觉得与客户的谈话是至关重要的。这是他们投资的钱，我们需要拿他们的薪水。我们不希望浪费自己的资金，客户也是。我们应该一起讨 论什么重要，什么应该提交给他们的潜在客户或投资者。我们不需要关注那些不能让别人将我们的应用程序区分出来的事情，如登录/注册功能，更改电子邮件或删 除帐户。
问题3：“没有选择一个合适的工具”
我和不同的公司谈过很多次关于他们的开发堆栈。有时，他们会使用Ruby做一些非常花里胡哨的，并行的和分布式的事情。当我问他们为什么为这个要求 苛刻的进程选择这么个相对低效的语言时，他们的答案是——所有的开发人员都知道Ruby是***的。理所当然这是最快，也显然是最廉价的方法。事实上他们并 没有关于可维护性的长远目标。他们专注于价格和便利。这导致他们背负了巨大的技术债务，并且可能会成为很多黑客行为实现的既定目标。
还有一件事是，我多次看到开发人员在他们熟悉商业规则之前就选好了技术堆栈。我看到很多动力十足的开发人员也一般无二。他们是如此热衷于立马启动开发和利用所有***的框架。他们认为无论要做什么系统，要解决什么问题，都可以用他们已经选好的数据库和语言。
在这样的情况下该怎么办呢？我的高招是去招聘懂得不同技术的开发人员。在熟悉了这个问题并使用案例后，我们可以讨论我们知道或不知道的工具的利弊。 洞察现在市场上正在发生什么，什么框架和语言受欢迎，这些框架和语言能解决什么问题，是一件好事。坚持一个每个人都知道的工具，而不是为每个用例制定解决 方案，可能会成为开发过程中的痛脚。
问题4：“重新发明轮子”
这个问题涉及到有的开发人员不够熟悉他加入的项目。这在我审查别人的代码时时有发生。我经常问：“你看到那个类/模块/功能了吗？它跟你的实现完全一样”。这常见于那些没有好好浏览代码的开发人员。他们没有看到，有些功能不拘在哪里提取，都是可重用的。
特别是当我们遵循一些共同的模式、准则或架构时，尤其如此。极有可能其他的开发人员已经在别的地方解决了这个问题，或者已经提取和抽象好了我们现在需要的某个功能。
为了避免这类问题，我们应该用一种明智的方式实现更多的代码审查。我们不应该检查是否对齐括号，或添上缺少的逗号，而是应该通过一些智能自动化的工 具进行检查。我们应重新审视业务逻辑和行为。一段时间后，我们会想：“哦，Kamil已经实现过了，我用一下他的模块就可以了。”
问题5：“学习语法不是编程”
我见过两个组的开发人员。
***组是优秀的程序员。他们知道他们所使用的编程语言的各个方面知识，他们知道整个标准库，和很多很多第三方工具。他们知道如何用8种方法写循环， 如何使用模式匹配和他们可以使用的所有语法。问题是，他们不知道架构和范例。他们的代码是命令式的，他们不会提取小功能，也不会处理封装和单独的不同层或 模块。他们只会写代码。
第二组是非常棒的工匠。他们是真正的建筑师，他们会模型化应用，各自负责提取组件，遵循格式和设计有效流。他们只是不会写代码。有时他们将太多的时 间花在了设计上，他们使用的是低效率的算法，废弃的功能，过时的库等等。也许架构是可靠的，工作流程是强大的，但是代码本身却既丑陋又难以阅读。
问题出在哪里？***种情况可能是因为开发人员只读他们使用的语言的相关编程书籍。这就像只学习语法而不学其他。我们以为我们知道了语法之后就可以编 程。其实我们只会写代码。第二种情况则是因为开发人员没有去看维护者或创造者发布的工具和语言的新版本。这一组的程序员不阅读更改日志，也不看新闻和简 讯。
如何解决？项目中这两种类型的人都要有。相互学习，这样才能既让大家满意，又获利***。
问题6：“无视模式”
当你进入一个已经拥有坚实基础的项目中，那么很可能它遵循某些规则和指引。因为通常情况下，开发人员要保证每个应用程序有一个约定，以使其易于阅读和理解。
不幸的是，很多人在刚开始编码时，往往看不到持续开发中内置的现有算法。他们会使用不同又没有必要的方法来兼容现有的方法。
我们总是兴致勃勃地提供新的功能，我们不想在观察目前的趋势和模式上面浪费我们的时间。于是我们无视了既定的规则，引进我们自己的习惯，从而打破一致性。
这是不好的吗？不总是。有时，特别是当更多有经验的开发人员加入团队时，这么做反而会化腐朽为神奇。他们会教其他人如何构建应用程序，并分享他们的 知识。有时，它可以为现有的架构带来新的视图，并改善很多已有的概念。但是事实上，上面这些情况很少发生。大多数的时候，新的开发人员往往会给大项目引进 麻烦。
那么解决方案是什么？引进是必要的。但是我们不应该要求尽快提供新的功能，而应该先让人好好研究既定的规则。我们应该任命一名主管，让他在开始的时候指导，让他掌握所有的概念。
总结
在编程世界中存在着许多问题。我们每个人都有着不同的技能，不同的能力和动力来源。我们应该互相沟通，共同解决问题，权衡利弊。
学习是关键。自我发展应该永不止步。如果我们不这样做，就会归为坏程序员。我们的工作要求我们不断地学习和了解新的东西。
可以读书，可以结对编程，可以订阅时事通讯，也可以写博客。
方法很多很多，我们只需要选择最适合我们的。
