> 这和个体或职业成长如何相互作用呢？我不想为一个经理工作，他坚持让我永远留在公司最初做的几个项目上……要培育一个花园，而不是一棵树。让我们区分“项目”和“系统”这两个词（不是“产品”——那是销售部门的事）。我们把项目定义为一个在时间与范围上有限的努力，用来创建或修改你套件中的某些系统（你的花园）。我认为把这两个概念混为一谈是很常见的错误。如果项目无休止地拖延下去，那么员工确实会感到被困住。按照这个定义，我当然不想永远只做一个项目。那一直做一个系统呢？问题在于，为了保持忙碌，你不得不把注意力放在一个可能不需要关注的系统上。项目结束时，系统应该已经实现了它的目的，并且应该永远持续下去。这个目的可能会过期，但系统不应该。没有必要急于去改动一个正常运行的系统。所以，让我们永远在一个花园里工作吧。…
源讨论构建理论以及为什么员工流动对软件公司是致命的原帖 420 条评论 · 导入时统计> 让软件持续运行的是那些对软件是如何构建和运行有准确心理模型（理论）的程序员。这种心理模型只能通过在项目成长过程中参与开发，或者与曾经参与过的人一起工作，从而帮助你吸收这种理论来获得。如果替换足够多的程序员，他们的心理模型就会与代码的现实情况脱节，代码就会死亡。这些死代码只能通过由当前程序员“培育”出的新代码来替代。 和 > 团队的稳定性对软件开发至关重要。每个团队都需要由大多数第一代开发者组成。 这与个人或职业成长如何相互作用呢？我不想为一个坚持让我永远留在公司最初几个项目上的经理工作... 要认真对待这一点，内部人员流动（即使只是某人被晋升）…
完整原文把你的经验，加入这段讨论。
我同意这个观点 - 在一家员工人数不到几千人的公司里，我通常会称其为一个“花园” - 并且认为这是对原文章的一个很好的扩展。不过，作者却非常狭隘地关注于“代码”层面，而不是“系统组件”层面。 如果你能培养人们成为那些了解系统组件如何协作的人，而不仅仅是在某个特定组件的代码层面上，那么你就可以制定出保留人才的计划，并保持机构知识的传承。（甚至在系统不断增长的过程中，还可以让人们进入更高一层的结构）。 你仍然无法留住所有人，有些人希望在不同的花园之间跳来跳去，但你确实可以留住很多人，这比告诉人们他们必须永远负责自己的每一行代码要好得多。
完整原文> 在项目结束时，一个系统应该能够实现其目的，并且应能无限期地持续下去。这个目的可能会过期，但系统不应该。没有必要急于修改一个已经正常运作的系统。 表达得非常好！我认为，忽视这一点是项目开始陷入范围蔓延（scope-creep）和“修复”与“增强”问题的根源。这也改变了对已完成项目满意状态的视角，与维护计划、对老旧系统的依赖等有关。你提到的花园比喻也非常美丽，据我所知是准确的。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。