大数据文摘出品
来源：oprea.rocks
编译：Vicky、橡树
本文是能够揭示技术迁移和解耦项目背后真相的系列文章之一。
作者在过去三年里参加过几个BIG REWRITE™、DECOUPLING™和SCALABILITY™项目，在此，作者决定分享众多类似项目失败的原因，希望此文可以帮助读者及早发现软件开发过程中的不良趋势，让大家引以为戒。
所以，软件开发的小伙伴们，快来看看自己中枪没有！
城门失火后才开始招聘
在项目半途扩充团队成员以求求工作效率的立刻提升，这简直是一个疯狂的想法，就好比房屋失火时才开始买保险，以希望保存已经被大火烧毁的家具一样不切实际。
请记住，团队中每增加一名新成员，现有团队中就会有一名老员工的工作效率降低一半，而且这一种现象从新员工开始入职时便会发生。此外，根据Tuckman的团队发展阶段理论，每当有新成员加入团队时，团队还会经历组建期（Forming）、激荡期（Storming）、规范期（Norming）和执行期（Performing）这第四个时期，甚至每次新成员的加入都会使团队使重复经历这样一发展阶段（期间有不同的矛盾冲突点需要领导者分阶段协调）！
没有调动起团队全体成员
当只有一小部分人（通常为“架构师”）来单独决定使用何种技术栈时，你的项目就会陷入困境。这就是为什么管理层最终会抱怨团队失信：架构师可能选了最好的技术栈，但如果没有整个团队的参与，再好的技术也无法实际部署，就好比身体在接受不相容器官之后的排异反应一样，而且情况只会变得更糟。
如果技术栈是由业务人员基于一些流行词甚至和商务伙伴那儿听来的流言所决定的，那基本上一连串诸如 “这不是我的工作”、“跟你说了这样不行”、“用另一种做好多了”或者“这是老张的错”的抱怨即将向你涌来——切忌拍脑子做决定。
我的建议：如果团队需要对结果负责，那么请将决策留给团队进行。切记！
缺乏规划
计划不足便意味着走向失败。
——一个比我博学的人
我认为这种行为通常发生在‘放飞自我型’的软件开发人员身上，他们认为写代码更像是一门艺术而非工艺，无需详细计划。不过，这种情况不止发生在开发人员身上，截止到2018年仍有一些商业人士相信他们“就差一个程序员了”，他们认为只要有了个想法和开发者，他们告诉开发者做什么他们就会做什么。
你不懂！
软件开发者可不像是铁匠。铁匠可能会面临着使用材料的质量、煤的质量或工具质量方面的不确定性，但软件开发所面临的不确定性要高得多。软件开发人员首先需要明确需求，寻找解决方案，验证解决方案，最后执行并实现——就为了一个需求，他们可能需要一次又一次地重复这个过程。
不坚守决定
专注（FOCUS）就是坚守一条道路直到成功）
——罗伯特·清崎
亨利·福特（福特汽车公司的建立者）的决策原则要点是切忌延迟下决策，要能够快速做出决定；而一旦做了决定，就不要再改变主意——频繁变卦会导致整个团队事倍功半并最终把任务搞砸。下定决心吧！
与其做个半成品，不如做好半个成品。
——Jason Fried，《Rework》
坚守错误的决定
人们在决定是否去做一件事情的时候，不仅是看这件事对自己有没有好处，而且也看过去是不是已经在这件事情上有过投入，这是典型的沉没成本谬论。因为“我们已经投入了很多xx（已经发生不可收回的支出，如时间、金钱、精力等 “沉没成本”），或者“我们一直都是这样做” 而无法放弃糟糕决定是一种无能的表现，也是一种来源于担心对决策失误做负责、并坚持继续往错误方向前进的危险行为。
这注定会将会带领团队陷入一次死亡之旅。
陈词滥调的鸡汤时间：
请记住，无论你在错误的道路上走多远都要回头；即使你选择了正确的道路，如果你站在那儿什么都不做，你最终都会被超过。
缺乏人员规划
如果没有人员规划，核心人员最后会偏离他们的原始职责而去处理一些无计划、无法预料且最无关紧要的工作。如果团队人员编制已满，那么还是要对参与项目的应有人数进行一些现实的规划。如果项目计划是迁移一个成熟的应用，那么魔数（人们拍脑子想出的数大多为3/4/7）在这里可不管用，随便挑个数字都不会让你更接近你的目标。
逃避心态
逃避心理会让你蒙蔽双眼，假装什么事情都进展顺利；你会逃避一些显而易见的事情，即使它们就在眼前；它还让你忽略了两个星期后的项目DDL，而你其实已经落后两个月的工作量了。尽早迎难而上，软件开发不应该像潘普洛纳奔牛节一样——不要去躲避那些公牛，因为它们最终会赶上你并把你‘顶翻’。
如果你真的有所顾虑，就让你的开发人员提出问题，这些开发员可擅长抱怨那些最微小的变化了。如果你培养了一种公平、公正且人人都有机会发言的开放性企业文化，无论问题有多“敏感”或是谁导致了这个问题，你的开发人员都会声嘶力竭地向你提问，尖叫着跟你说‘天都要塌了’。
计划太远
当只有两个月的路线清晰度时却计划了一年的工作量。
一年的计划只是个幻想。你可能年初时觉得你什么都安排好了，但等情人节再看看吧——你会开始希望你的计划更“灵活”一些，团队更“适应”一些了。为什么就不给自己省些麻烦，就只做一季度的计划呢？在作者看来，一季度是计划的最佳时间。此外，设定季度目标意味着你更有可能实现这些目标，因为你将处理的不确定性更少，并且你的目标会更加现实。
试着在项目管理中进行一整年的工作规划，并像你计划建造房屋一样规划软件，这完全就是一种浪费。
如果飓风来袭了呢？
如果伊隆·马斯克决定接管互联网并创建一支僵尸机器人军队呢？
如果你部署产品的唯一选择，是将你的应用程序装入一个外接硬盘并带到亚马逊的数据中心呢？
如果为了做到这一点你必须和马斯克的僵尸机器人军队搏斗呢？
这些都是合情合理的问题。同样合理的还有“你认为它要花多长时间？”或者“我们应该在这个用户故事中加多少个故事点呢？”。
你不是在建房子。房屋设计很容易，因为一切都已“完成”，你只需挖洞添点“胶水”，然后把房屋的每个部分放在一起就搞定了。但使用软件时，你甚至得先创造个想要挖洞的位置，然后才能进行后续操作。
房屋建造和软件开发的唯一相似处是在术语上，应用实际概念时却大相径庭。你不会在建房时中采用迭代策略，否则你就是在建一座新房，而且只有在拆掉旧房的情况下你才能建造一座新房子，期间所需
不要再因为“你需要交付了”或者“你在获投可以代码重构”这些原因而去构建那些非模块化且架构得乱七八糟的破烂软件了，后患无穷！
我不是说单片软件（非模块化）很糟糕，但一个模块化的整体结构在短期内比你找到的任何基于微集成服务的无价值工作运转得更好。但你构建之前要多考虑，使用个合适的前端框架，选个符合你需要的UI库并彻底对他们彻底了解。
错误衡量
我不打算谈论具体的测量方法，毕竟这个必须由读者自行决定。无论那个程序开发速度还是产品推出时间，你应该客观地评估你的当前情况，并基于此找出你需要衡量的标准。
在此举一个有关错误衡量的个人例子。
我们假设我的目标是增加我的电子邮件订阅者数量，那么我就不应该太关注网站访客量。如果我开始疯狂地关注后者，那么几个月后我就会觉得我已经非常受欢迎了，并且我就会像已经拥有更多的电子邮件订阅者一样生活——大多数崇拜幻想世界故事的人都是这样生活的。但反过来，我其实也可以查看我的订阅者列表，从而注意到没有任何订阅者数的进步，接着会查看访客量，结果发现网站上其实很多人浏览但没有订阅，从而便可以继续探求浏览者不订阅的原因。
过程太过僵硬
据我的经验，发生这种情况是因为人们过于死守交付流程，但实际的关注点应该在于交付的内容，许多使用SCRUM（敏捷开发）的团队也在抱怨它太死板了。在我看来它的确有些僵硬，但不乏一些主观性的偏见存在。其实客观来讲，任何敏捷的开发流程都具有很强的适应性和灵活性，但我们的天性就只是照搬书中的所有内容（特别是当我们被规则驯化后），从而使得一切都看起来非常僵硬。
正如Vasco Duarte在他的作品《No Estimates》中所说：“建造软件就跟疏通浴室管道一样——为了把厕所修好你还得再建三座房子。”软件开发的本质就是当你准备好解决一个问题的途中还发现了其他三个问题需要解决。在Quora上有一个很好的类比，拥有近三十年软件开发工作经验的Channing Walton借用“泡茶”为例形象阐述了软件开发过程的艰辛。
Q：我该如何向一个非软件从业者解释软件开发过程有多复杂、多耗时、多易错？
A：让他们描述制作一杯茶所需的步骤，他们可能会说：
1.烧水
2.把茶放进锅里
3.将水煮沸后倒入锅中
4.等5分钟
5.把茶倒进杯子里
6.往杯子里加牛奶
7.喝掉
接下来便是最有趣的部分，你需要开始继续问这些问题：
烧水？那么：
水来自哪里？
水壶在哪里？
你怎么把水倒进水壶里？
你怎么知道多少水放入水壶里？
没有水/水壶/电的时候怎么办？
如果填满传感器出现故障（溢出）怎么办？
如果沸腾传感器出现故障怎么办？
把茶放进锅里？那么：
锅是在哪里，如果没有锅怎么办？我们应该在煮沸之前想到这个问题吗？
茶在哪里？是哪一种茶？我们是否应该先问一下，如果我们没有合适的茶该不该继续这么做？以及关于溢出和传感器的类似问题怎么办？
倒开水？那么：
你确定它在沸腾吗？怎么能确保浇注的机器从水壶中得到正确的“完成”信号？
你怎么确定机器倒酒器知道锅的位置？
如果在倾倒期间锅翻倒怎么办？
诸如此类的问题，你可以继续问上几个小时，他们会感到无聊并说：“这种程度的细节考量是愚蠢的！”此时你的目的就达到了，你只需要微笑点头说道：“是的，但整个过程的确就是这样。”
相关报道：
https://oprea.rocks/blog/five-reasons-big-software-rewrites-fail/
3160
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
