从我的第一个（半）生产应用程序中学到的经验教训

是的 我知道。 已经有一段时间了（我的上一个博客是4月17日）。 我对此不满意。

人们在问我，“你停止写博客了吗？” “没有！ 我只是在做不同的事情。” 我告诉他们。

但是，现在比以往任何时候都是反思的好时机。 所以，让我们这样做。 让我与您分享我在过去几个月中在IBM工作的内容。

因此，我不会为您带来无聊的日常细节，但是我从事的最激动人心的项目是最近在这里发布的代码模式 。

代码模式？

嗯，所以代码模式 ？ 那是什么？ 好吧，让我为您分解一下。 IBM是一家大型科技公司（仅从角度来看，它是美国第六大私营雇主）。 而且IBM有非常大的产品目录。 我做了一些研究，仅IBM Cloud目录就有170多种产品。 而且这还没有算上我们的硬件（存储/大型机）。 因此，如果我用11个字来描述什么是代码模式 ，它们将是：

利用IBM技术解决复杂编程问题的指南。

您可能会想， 好吧，如果我不想使用IBM技术怎么办？ 好吧，那也很好！ 有许多代码模式不一定专注于IBM 技术 ，而只是使用IBM Cloud作为部署方式。 本文主要介绍iOS上的MapKit。 好的，现在您知道什么是代码模式，为什么还要关心？

为什么要使用代码模式？

在学习新技术或寻找应用创意灵感时， 代码模式非常有用。 已经有很多很棒的解决方案，因此，寻找自己喜欢的技术领域，然后寻找一些现有的解决方案并试用该应用程序，是了解更多有关特定技术的好方法。 不仅如此，您还可以找到该代码的Github存储库，做出贡献，与开发人员交谈等。

沃森第二意见

因此，例如，我的应用程序https://2ndopinion.mybluemix.net/利用Watson Natural Language了解 ，使用户可以更好地了解亚马逊上某产品的评论。 该应用程序基于以下想法：我们许多在线购物都使用评论作为决定购买哪种产品的方式。 如果评论是假的或不正确的怎么办？ 2nd Opinion通过使用AI来发现评论中所用语言的细微差别，试图改善用户选择的1–5星级评分系统。 例如，如果用户将产品评为5颗星，但实际上在给出5颗星评论后抱怨产品的某些部分，则Watson可以理解这一点，并将其评为低于5颗星。 Watson只是从评论中提取文本并进行处理。 它不关心用户给予产品的星级。 之后，它将输出从（负1到正1）-1–1的评分（称为情感评分）。 然后，该应用程序将-1–1分数映射到一个百分比，-1为0％，1为100％。 这是您在下面看到的紫色条形图。 最后，该应用程序将百分比映射为1-5比例。 这是您在下面看到的Watson评分 。 最终，“第二意见”为用户提供了一种方式，可以将AI得分与亚马逊使用的5星级量表并排比较。

我从第一个项目中学到的东西（半）

我从来没有从事过已经投入生产的代码的工作，而代码模式实际上是我将代码推向生产的最接近的模式。 尽管我不会真正考虑每个代码模式的“生产”，但这是正确的。 有了更多的人力和时间，它肯定可以投入生产。 让我概述一下从该项目中学到的主要知识。

1. 保持要求简单 。 不知何故，本课花了我一年多的时间来学习-例如，几周前在研究不同的代码模式时，在会议上，我感到非常兴奋，感到越来越复杂。 一直以来，我们甚至没有一个API能够真正有效地执行所有必需的功能。 而且，我们项目的时间表非常紧张。 从构思到生产就绪的代码，我们只有大约一个月的时间。 我喜欢最小生存产品范式来解释这一点。 使用一项功能即可提供该应用程序80％的功能，并不断简化直到您可以使用为止。 最初，在我的Watson 2nd Opinion应用程序中，我们对产品进行了所有评论（某些产品具有10,000多个评论），并将其输入到Watson NLU中。 那个简朴的老人花了太多时间。 当然，结果要准确一些，但是使用户只能盯着微调器10秒钟以上的额外计算时间是不值得的。 现在，我只抽取一个评论样本（仅200个）。 当然，也许我们没有得到准确的结果，但是性能和缺少错误确实值得。 此外，由于代码模式的范围是提供解决方案的路径，而不是完全解决问题，因此该想法对于本项目的范围是有意义的。
2. DevOps很难。 设置CI / CD和部署管道需要时间。 我遇到了我的应用程序所依赖的某些软件包的安全问题，这些软件包花了几天时间解决了—我将解决方案发布在StackOverflow上，并且能够帮助其他开发人员解决此问题，但是我从来没有想到过某些软件包我什至没有安装都会引入一个需要花费几天时间才能解决的错误。 仅使应用程序在本地正常工作，实际上只是战斗的一小部分。
3. 不要害怕重新开始。 在项目中多次，代码变得如此复杂，以至于我们回避了要解决的实际问题-如何使用AI来增强用户在Amazon上的购物决策。 不仅如此，新代码还破坏了旧代码。 它并没有解决问题。 我最终要做的是从头开始尝试所有后端逻辑，并只编写项目第一遍所用代码的约30％。 该项目更易于管理，更有趣并且漏洞更少。

4.完成后进行反思。 找出哪些有效，哪些无效。 在完成第二意见模式之后，我立即开始研究另一个代码模式，但我还没有准备好继续前进。 学习和理解提高编码能力所需过程的一种好方法是对项目进行反思。 简单地思考什么有效，什么无效与撰写或撰写博客要点不一样。 就像思考某件事并不等同于告诉别人您正在做某件事一样，写下某件事也是如此。 博客使您负责。 考虑到这一点，我准备开始下一个代码模式。

谢谢阅读。 我知道我的博客很生锈。 但是，只有一种方法可以完成工作，那就是做事。 所以我在这里，写下我的想法，并向世界开放。 如果愿意，请回到正轨。 如果您喜欢此按钮，请按住那个????????按钮，如果不喜欢，请评论并告诉我它很烂，我想知道其中一种！ 霍里亚·星巴克出去了。

From: https://hackernoon.com/lessons-learned-from-my-first-semi-production-application-4463eb656a1d