在软件工程领域，经常会听到一句话，那就是“我们一直都是这样做的”。这句话看似简单，却反映出许多团队在实际工作中没有质疑或反思既定流程和规范的现象。就像一个家庭在烹饪火鸡时会切掉火鸡尾巴，却从未思考过原因，只是因为上一代一直这么做，软件开发中的“火鸡尾巴”比比皆是。这种现象不仅存在于小团队，也在大型企业中屡见不鲜，无论是老旧的架构设计、过时的代码规范，还是冗长无效的会议流程，都可能因为“传统”而被保留下来。软件开发是一个快速演进的行业，技术和方法论的更新速度极快。然而，长时间的不加思考的持续沿用旧习惯，往往会成为团队发展的障碍。
这些“老规矩”在没有合理评估的情况下被一代代传承下来，导致效率下降，创新乏力，甚至阻碍新人融入和适应团队文化。首先，固守陈规影响团队的适应性和竞争力。当一个团队为了保持惯性的稳定，拒绝调整工作流程和技术框架时，就会错失行业进步带来的红利。比如仍旧坚持80字符宽度的代码行限制，虽然是昔日硬件条件下的合理规范，但在现代宽屏显示器上显得多余。这种“不合时宜”的规范成为了束缚，降低了开发者的书写和阅读体验。同样，某些过时的开发流程，比如机械式的每日站会问答，照搬敏捷理论的框架却不结合实际团队需求，往往形同虚设，浪费人的时间和精力。
此外，团队对旧有架构的依赖也是常见问题。许多软件架构是在团队人数多、业务复杂时设计的，然而随着时间推移，团队规模和业务需求发生改变，原有架构的复杂度反而成为负担。若团队成员缺乏对架构设计的深入理解，盲目维护旧架构，可能造成代码难以维护，bug频发，进而影响产品质量。新成员加入时，会被大量遗留的老代码和无文档说明困惑，延长学习曲线。这种情况下，若没有主动诊断和调整，问题将不断累积，导致技术债务加剧。面对这种现状，首先团队需要意识到习惯的风险和改善的必要。
挑战“那是我们一直以来的做法”这一敷衍的理由，鼓励成员提出质疑并积极探索改进方案非常关键。质疑并非否定所有传统，而是在理解背景和目的的基础上，判断其是否仍适用。作为团队领导，透明化决策过程和思路，促进团队成员参与讨论，可以增强归属感和责任感，打消抵触情绪。合理记录流程变更的原因和预期效果，有助于日后持续优化。同时，调整流程不应是盲目的革新。许多团队在追求新技术和工作方式时，忽视了历史上积累的经验和解决过的问题。
一次大型重构如果不充分考虑遗留问题和隐藏的业务逻辑，往往会导致系统不稳定，甚至引发意想不到的故障。因此，在变革中应保留核心价值，充分测试和验证变更效果。对于新技术的采纳，也应结合团队能力、业务需求以及发展阶段做出理性判断，而非随波逐流。此外，建立持续回顾和改进机制十分必要。定期开展团队回顾会议，审视当前工作流程、代码规范和协作方式的有效性，及时发现并去除“火鸡尾巴”，让流程更加适应现实需求。通过实践驱动改进，比单纯的理论宣传更有说服力。
新成员作为外部视角，也有助于发现陈旧方法的不足，鼓励他们提出建设性反馈，促进团队健康发展。总结而言，固守“那是我们一直以来的做法”的行为虽能带来一定的惯性稳定，但也存在诸多隐患。软件团队应倡导反思文化，不断审视和革新流程和架构，兼顾历史经验与未来发展。这样不仅能提升团队效率和产品质量，更能打造积极向上的团队氛围，吸引并留住优秀人才，实现可持续发展。
