我担任CTO已有一段时间了。在这个角色中，我不仅制定了指导方针，还领导团队、管理项目、设计架构、组织工作、开展代码审查、调查不同的问题、研究各种解决方案、会见许多技术人员、联系客户等等，做了很多东西的。在完成这些任务的过程中，我不仅学到了很多不同的技能，也做了很多我想与大家分享的观察。这篇文章是针对CTO和开发人员的，因为可能不是每个人都遇到过我在下面发现、学习和解决的问题。问题一：“我对X技术/工具不熟悉”这是我每次要介绍新技术和语言时最常听到的一句话。当我要求某人使用他们不认识的工具准备概念证明时，这也是一个非常熟悉的短语。这让我很吃惊，为什么？因为我觉得程序员都是高智商的！他们学习一些新的东西，新的概念、模型和结构不是很容易吗？他们不应该不断学习新事物并关注最新消息吗？也许这只是一种错觉？也许我们已经满足于我们以前学到的东西，不想改变？也许事实是我们已经失去了发展的动力？也可能是我们没有时间学习新事物？过了一段时间，我让对方完成的任务完成了。他们做到了，他们交付了。最初的犹豫最终被克服了。并且掌握了一些新的东西。那么，最初缺乏动力的原因是什么？我认为这是因为恐惧，对陌生的恐惧，对失败的恐惧。做我们已经知道的事情总是感觉很好，因为我们知道它并且我们认为这是我们擅长的事情。但问题是，我们也可以擅长其他的事情，只要我们需要，我们愿意去了解它，并像以前一样学着去做。问题2：“一开始想得太多”这是我在开始一个新项目时看到的最常见的问题之一。开发人员觉得加入一个已经工作的应用程序会更自在，因为要做出的决定要少得多。开始一个新项目是不同的。我们需要做出决定并优先考虑需求和最佳功能。最大的失败在于实施，例如，首先进行身份验证。这是应用程序最重要的功能吗？你要注意安全吗？不，大错特错。我们应该尽可能缩小范围。我们应该提供一个MVP来证明概念。我们应该提供基本的业务规则，应用程序的核心功能，而不是专注于性能、分页、超安全身份验证和极端可扩展性。保持简单，至少一开始是这样。我该怎么做呢？我觉得与客户的对话至关重要。这是他们投资的钱，我们需要拿走他们的薪水。我们不想浪费自己的钱，我们的客户也不想。我们应该一起讨论什么是重要的，什么应该呈现给他们的潜在客户或投资者。我们不需要关注不允许其他人区分我们的应用程序的事情，例如登录/注册功能、更改电子邮件或删除帐户。问题三：“没有选择合适的工具”我和不同的公司谈过很多次他们的开发栈。有时，他们用Ruby做一些非常奇特的、并行的和分布式的事情。当我问他们为什么要为这个要求很高的过程选择这样一种相对低效的语言时，他们的回答是——所有开发人员都知道Ruby是最好的。这当然是最快的，显然也是最便宜的方式。事实上，他们没有关于可维护性的长期目标。他们专注于价格和便利性。这导致他们背负了巨大的技术债务，并且很可能成为许多黑客要实现的既定目标。还有就是，我很多次看到开发人员在不熟悉业务规则之前就选择了一个技术栈。我看到很多积极性很高的开发人员，他们都差不多。他们非常热衷于立即开始开发和利用所有最新的框架。他们认为无论他们想建立什么系统，或者他们想解决什么问题，他们都可以使用他们选择的数据库和语言。遇到这种情况怎么办？我最好的选择是聘请了解不同技术的开发人员。在熟悉问题和用例之后，我们可以讨论我们知道或不知道的工具的优缺点。洞察一下现在市场上发生了什么，流行什么框架和语言，这些框架和语言能解决什么问题是很好的。坚持使用每个人都知道的工具，而不是为每个用例提供解决方案，可能会成为开发的痛苦。问题4：“重新发明轮子”问题涉及开发人员对他加入的项目不够熟悉。当我审查其他人的代码时，这种情况一直发生。我经常问：“你看到那个类/模块/函数了吗？它和你的实现完全一样”。这在扫描代码不好的开发人员中很常见。他们看不到的是，某些功能无论在何处提取都是可重用的。当我们遵循一些共同的模式、指南或结构时尤其如此。很可能其他开发人员已经在其他地方解决了这个问题，或者已经提取和抽象了我们现在需要的一些功能。为了避免此类问题，我们应该以明智的方式实施更多的代码审查。我们不应该检查括号对齐或添加遗漏的逗号，而应该使用一些智能、自动化的工具进行检查。我们应该重新审视业务逻辑和行为。过了一会儿，我们想：“哦，Kamil已经实现了，我可以使用他的模块。”问题五：“学习语法不是编程”我见过两类开发者。***组是优秀的程序员。他们了解他们使用的编程语言的方方面面，他们了解整个标准库，以及许许多多的第三方工具。他们知道如何以8种方式编写循环，如何使用模式匹配以及他们可以使用的所有语法。问题是，他们不了解架构和范例。他们的代码是命令式的，他们不抽取小功能，他们不处理封装和分离不同的层或模块。他们只是写代码。第二组是很好的工匠。他们是真正的架构师，他们为应用程序建模，每个人都负责提取组件、遵循格式并设计高效的流程。他们就是不会写代码。有时他们花太多时间设计，他们使用低效的算法、过时的函数、过时的库等。也许架构很坚固，工作流很强大，但代码本身很难看且难以阅读。哪里有问题？第一种情况可能是因为开发人员只阅读与他们使用的语言相关的编程书籍。这就像学习语法，仅此而已。我们认为一旦我们知道语法就可以编程。其实我们只能写代码。二是因为开发者看不到维护者或创造者发布的工具和语言的新版本。该组中的程序员不阅读变更日志，也不阅读新闻和时事通讯。怎么解决？这两类人都应该出现在项目中。取长补短，让大家满意，受益***。问题6：“忽略模式”当你进入一个已经有了坚实基础的项目时，它很可能会遵循某些规则和指导方针。因为通常，开发人员希望确保每个应用程序都有一个契约，以便于阅读和理解。不幸的是，许多人在刚开始编码时往往看不到正在进行的开发中内置的现有算法。他们将使用不同的和不必要的方法来与现有方法兼容。我们总是很高兴提供新功能，我们不想浪费时间观察当前的趋势和模式。所以我们不顾既定的规则，引入自己的习惯，从而打破了一致性。这很糟糕吗？不总是。有时，尤其是当更多有经验的开发人员加入团队时，这样做可以化魔法为魔法。他们教其他人如何构建应用程序并分享他们的知识。有时它可以为现有架构带来新的视图并改进许多现有概念。但实际上，上述情况很少发生。大多数时候，新开发人员往往会给大型项目带来麻烦。那么解决方案是什么？进口是必要的。但是我们不应该要求尽快提供新的特性，而是让人们先研究既定的规则。我们应该指定一个主管，让他在一开始就指导，让他掌握所有的概念。总结编程世界中存在许多问题。我们每个人都有不同的技能组合、不同的能力和动力来源。我们应该相互沟通，共同解决问题，权衡利弊。学习是关键。自我发展不应停止。如果我们不这样做，我们就会被归类为糟糕的程序员。我们的工作需要我们不断学习和学习新事物。你可以读书，可以结对编程，可以订阅时事通讯，可以写博客。方法有很多种，我们只需要选择最适合自己的即可。
