恐惧症

您好,我叫Dmitry Karlovsky,我是一名专业自行车手。 在我的整个职业生涯中,我制造了许多自行车:大小不一,快速舒适,弯曲不平直。 因此,看到聪明的程序员制作大型而复杂的应用程序对我来说很疯狂,但同时又将另一个左键盘连接到项目上,而不是用我自己的双手写几行简单的代码。 这样做的原因是担心自行车生产会在程序员中间发展起来并自给自足。


我为什么以前生气?我只是没有自行车。


程序员进化


为了简化演示,我们区分了3个条件程序员。 有条件的,因为它们之间没有明确的边界,并且不同地区的同一个人可以属于不同的群体。


新手


  • 他仍然很少有经验和知识,但是由于他还没有养成习惯,因此他很快就会学习新知识。
  • 由于新颖性的影响,他很好地看到了现有解决方案的缺点,并强烈希望自己做些没有这些缺点的事情。
  • 他不知道这些或其他惯例和原则是如何形成的以及为什么形成的,如果这样,他不会感觉到它们出现在自己皮肤上的原因。
  • 他编写的大多数代码要么被丢弃,要么重构到无法识别的程度。 充其量是在经验丰富的同事的指导下,用自己的双手。
  • 他因编写自行车而受到残酷殴打,因为从许多标准来看,第三方图书馆更有可能变得更好。

专科医师


  • 绝大多数受欢迎的图书馆都是他在业余时间写的,因为他仍然为自行车和开放源代码而战。
  • 通常,其代码质量对应于生态系统中代码的平均质量。 如果每个人都从回调中编写面条,那么对他来说就一无所有。
  • 通常,它使用第三方代码,因为由于时间限制,它本身并不好,甚至更糟。
  • 因此,它继续显式地(在代码审查中)或隐式地(错误报告)接收骑自行车的手。
  • 当问题完全解决他时,他看到了一辆自行车。 而且由于此类程序员的绝大多数,因此结果证明有100,500辆彼此不兼容的自行车,并得到一个半开发人员的支持。

专业的


  • 他能够比医院的平均水平更好地解决任何问题,但由于资源有限,他被迫选择花时间去做。
  • 由于习惯,他们殴打了他。 尤其是如果公司实行Scrum,而所有决定都是由多数人做出的,则受Dunning-Krueger效应的影响。
  • 通常,由于前两个阶段形成的复杂性,他限制了自己,并相信自己无法做得比经过“测试”,“考虑”,“得到大量开发人员支持”的第三方库更好。

恐惧的原因


随着程序员的发展,很容易注意到,起初他几乎没有技能,但是没有恐惧,随着他掌握技能,对自行车的恐惧会出现并加剧。 为了应对这种恐惧,您需要分析其原因。


我做不到


初学者确实不能。 他应该用自己的精力向更有经验的同事和图书馆开发人员解释他所看到的问题的实质和重要性。


如果专家精通问题并咨询其他专家和专业人员,则成功的可能性很可能更大。


专业人士在大多数情况下都可以做得更好,因为他已经精通该主题,甚至具有综合分析的技能。 不幸的是,通常没有人可以与他协商,因为其他专业人员很少,而且他们从事其他主题。 而且专家缺乏视野。


将没有人修复缺陷


通常,这辆自行车的作者非常有动力去修理他脑海中的缺陷。 但迟早,只要他下班后这样做,这种动机就会过去。 在这里,第三方库似乎可以让您节省资源,因为其他无需付费的人都在使用它的支持。 但是不可能影响它们,因此,为了赶上最后期限,您将不得不袖手旁观并自行修复缺陷,此后将补丁很难打入主存储库中很长且很困难,而无法保证成功。


没有人会改善和发展


这里的情况与有缺陷的情况相同。 但是,如果存在缺陷,通常每个人都知道需要维修,那么每个人对发展方向的看法就不同。 第三方开发人员将在他需要的地方(而不是为您)开发他的库。 以对他方便的速度,而不对您方便。 因此,如果需要特定的发展载体,那么您的自行车将为您提供控制和可预测性-这两种品质对管理而言比时间和金钱更为重要。


我不能在其他地方使用它


如果要在公司外部使用自行车,则必须在业余时间开发自行车,或者同意开放原始码,这通常比较困难,但很有可能。 毕竟,该公司在其他自行车使用者中几乎免费获得潜在雇员以及免费Beta测试人员(甚至是贡献者,但您不应依赖此)的PR。


时间和金钱将被浪费


首先,这里值得与替代方案进行比较。 如果没有,那就别无选择-您必须削减它。 如果有其他选择,那么值得在金钱和时间上进行比较:


  • 编写自行车的成本很高。 这包括编写代码,编写测试以及将项目转移到自行车上的实际时间,以及评估引入的缺陷的成本。
  • 自行车带来的好处。 由于某些功能,越来越少的缺陷和其他因素,这可以节省成本。
  • 集成第三方解决方案的成本。 再次,包括评估测试成本和引入的缺陷。
  • 第三方解决方案施加的限制。 事实证明,第三方解决方案根本不合适。 否则它将使开发速度减慢2倍。

如果突然发现某些限制更令人无法接受,则也有必要单独评估从第三方解决方案转换为自行车的成本。 经常发生的是,现在实施第三方解决方案,然后在需要时(如果需要)将其快速转移到您的自行车上,比现在花时间在自行车制造上更有利可图。


这项评估不仅可以帮助您了解游戏是否值得,也可以向管理层解释为什么值得您编写自己的游戏而不是接受他人的游戏(反之亦然)。


我将被诅咒为我的前任


令人怀疑的是,自行车占据了项目的很大一部分。 因此,他们将在其余的代码中诅咒更多。 因此,自行车至少必须做得更好。 如果没有人希望将其替换为第三方库或另一辆自行车,那就更好了。 为此,您需要:


  1. 该项目具有明显的重要优势。
  2. 一个简单的使用界面,使您不必做包装。
  3. 灵活的API,这样您就不必再看需求稍有变化的新自行车了。
  4. 良好的测试覆盖率,这将减少错误报告中的刷新次数,并能很好地重现重构。
  5. 全面的文档,因此您无需寻找自行车的作者即可了解如何骑行。

我不想承担责任


如果您不对所从事的项目一无所知,这是正常的。 如果您不太在意一天中三分之一的时间,那么您必须捍卫自己的观点。 而且,您的地位越高,说出的话就越负责任。 的确,不仅您的工作方式如何,其他人的工作方式以及整个项目的进行情况也取决于您的声音。


推荐建议


我希望我能够表现出对自行车毫无根据的恐惧。 您越接近专业精神,您可以骑的野心就越大。 最好从较小的自行车入手,这些自行车的风险较低,但在该领域具有相当的经验。 有了这个产品组合,就可以承担越来越多的有趣和有趣的事情。 重要的是不要忘记,一个真正的专业人员不仅会做酷事情,而且知道何时放弃他们的创造。 因此,请始终进行分析,使您充满信心,认为自己做得正确,管理将在您身边,追随您的人们将了解它是什么类型的自行车,为什么在这里以及为什么不可能做到这一点。


好吧,为了帮助您分析第三方库,当晚我写下了一个应用程序,使您可以估算解决GitHub上项目问题的时间 。 数字越大,支持的项目越差,并且等待解决问题的时间也就越长。 例如: 比较Angular,VueJS,React,当然还有编写此自行车的$ mol 。 请记住,最后一个链接是一次性的,因为消除Angular的所有开放问题都吞噬了GitHub的所有限制,这雄辩地表明,其维护者无法应对他们所产生的怪物的支持。

Source: https://habr.com/ru/post/zh-CN435272/


All Articles