问一个(初级)开发人员应该努力在他们的开发/IT团队中推动更好的过程和实践吗？

EN

到目前为止答案还不错，但并不能涵盖所有的基础。

根据我的经验，许多刚从大学毕业的人都拥有非凡的理论知识--比我或其他几十年来以软件为生的大四学生要好得多。

但是，这是个很大的问题，但这些知识并不是建立在任何实际情况下的。在现实世界中，很多理论都是平淡无奇的，或者至少要用大量的盐来理解，因为在实践中发现，在现实世界的场景中，这种理论是行不通的。

例如:我很久以前工作过的一个应用程序是由一位杰出的OO理论家设计的，他的设计目的是将OO原则和理论应用到T中，并将许多模式应用到任何地方。

这是一款非常棒的软件设计。

可悲的是，这导致了生产和维护的噩梦。代码库是如此庞大和复杂，以至于不可能改变位置；不是因为它特别脆弱，而是因为它太复杂了，没有人敢去触摸它，担心会发生什么(最初的架构师/设计人员是一个早已离开的承包商)。

它的性能也很差，这正是因为模式的多层结构，以及设计所需的类库。例如，单击屏幕上的一个按钮对数据库进行一次调用，将导致数百个对象实例化和方法调用--所有这些都是为了确保松耦合之类的。

这位建筑师曾是一名大学教授，他的名字中有几本关于这个题目的书。他从未有过一天的商业项目程序员的工作。

有实际经验的软件开发人员会意识到，设计将不可避免地导致并采取更加务实的方法，从而形成一个更易于维护和性能更好的系统。

同样的事情也适用于你刚毕业时遇到的许多其他事情，或者是任何公司的新员工。不要认为，因为你的理论基础告诉你某些事情是错误的或次优的，所以没有很好的理由这样做。

即使是现在，在这一领域已有20多年的经验，我对批评与我一起工作的公司的做法还是很谨慎的。我顺便提一下，我注意到事情与我的经验是不同的，因为我的经验是最理想的，但不是好战的。这往往导致有趣的对话，为什么这些事情是这样的。变化可能会发生，也可能不会发生，这取决于改变事物的价值是否小于成本。

不要害怕说事情可能会做得更好，但一定要确保你不是一个无所不知的孩子，而是一个同事，他不仅努力学习，而且愿意帮助改善公司的发展过程，而不仅仅是理论上的正确。

是的，但是非常小心！

，让我澄清一下。

。

您应该努力提高软件的可居住性。如果您查看代码/团队/业务/项目/管理，而您的第一个响应是淋浴，那么它是不适合居住的。如果你的第一反应是喊耶！然后抱怨当你被赶出办公室，然后你需要让你的家更适合居住。这是一种感觉，你会知道的。

尽管如此，您是在一个复杂的合成中工作。你做的任何事情都有可能出错，而且至少在短期内会使事情变得更糟，因为一个简单的改变会带来涟漪。所以，首先要变得谦逊，我的意思不是成为一个推动者或接受事情一定是坏的，我的意思是要接受的事实，你的良好意愿将对你不利。

问题

怀着最好的愿望，你可能会觉得需要进行广泛的变革，我不反对这些情况确实存在，但是花点时间想想。当前的系统正在工作，您和您的团队正在生成代码，可能是缓慢的，也可能是痛苦的，但它正在工作，而且大家都有如何做到这一点的经验。你大概知道该期待什么，简而言之，你是这个系统中的专业人士。

然而，在这一彻底的变化之后，除了实现者之外，没有人知道该期待什么。简而言之，在系统的这一部分，每个人都被重置到了一个新的层次。这可不妙。新手必须学习新的规则，这需要时间。在那个时代，新手犯错误是因为他们没有练习。这些错误变成了系统的一部分，你现在必须接受，而现在它并不像现在那么闪亮。

--

的前进之路

有时候，砍、烧和重建是你所能做的最好的事情。如果没有人在旧系统中练习，那就特别吸引人了，因为唯一失去的就是成文的知识。如果这种知识是完全无法理解的，那么它已经失去了，重新开始是唯一的选择。相反地，如果编纂的方法，或者它的使用方式是有问题的，但起作用的话，那么这些知识仍然是可以获得的，也许是值得保留的，也许它不值得--只是不要轻率地做出决定。

另一种选择是与系统一起工作，这样每个人都有一个参考框架，但是要改变系统的小部分，使团队中的每个人都知道，或者如果他们没有意识到变化，这是很容易注意到的，也很容易学习。这是称为凯岑的实践的基础。在演示文稿中给出了一个更面向开发人员的公式--剃须金牦牛，我强烈建议您观看它并仔细考虑。

所以，找一件可以改变的小事情来改善你的生活，希望能改变一些其他人的生活。解决或改善这种情况。这将给你实践实践的实践和经验。确保你得到了反馈:你是否能更好地讨论它，如果它真的有用的话，它是否会使系统的另一个部分感到不安。培养你对能做什么以及如何去做的感觉。

现在发生了三件事：

• 你改进了系统，
• 您已经获得了如何更改系统的经验。
• 团队已经看到您成功地更改了系统。

现在，选择另一件事情来改进，随着您的经验的增长，以及您消除低挂问题，您将开始在系统中面对更困难的问题，但至少现在当您说我们必须改变X时：

• 你知道这种变化会对系统产生什么影响
• 你知道它会产生什么问题(什么规则需要重新学习)
• 您知道一些立即修复的方法，或者改进更改将带来的问题。
• 你周围的人都知道你对这个系统很了解，并且能够成功地改变它。

可以，停那儿吧。但你得小心点。

在我职业生涯的开始(很久以前)，我有幸/不幸地进入了一个几个月大的项目，作为“初级”。

我立即注意到(OMG)没有代码存储库！所有代码合并都是通过通过邮件向对方发送zip文件手动完成的。

所以我去找了我的(也是新的)经理，建议我们应该有一个存储库。答案是：“好的，组织起来”。

因此，在没有帮助的情况下，组织一个代码存储库，并且是公司的新成员，这是一种令人谦卑的体验。

当我把它全部设置好的时候，(震惊)，没有人愿意使用它。所以我试着把事情做好，幸运的是我的经理明白它的重要性，所以我得到了支持。

但这导致我不受欢迎。

我的建议是先感受一下你的团队成员。他们认为重要的是建立下一个步骤。

也许他们也有和你一样的名单。也许他们已经把所有的事情都考虑清楚了，他们想要做清单上的“事情”。

整个团队都必须团结一致。

但如果他们不是，那么你仍然可以在职业上工作。找出志同道合的人，一起合作，你认为应该怎么做。如果这能带来好的效果，那么更多的人会和你一起工作，最终会成为“过程”。

与代码一样，开发过程也是如此:需要持续改进。

所以，是的，你应该一直努力改进那些有可能改进的东西。

但也要记住，你和很多人一起工作也可能是专业人士，他们知道什么是错的，什么是需要的。