我出去跑步了……听一个关于丰田的播客……无论如何。
我认为这个原则不会在软件项目中使用。(也许是项目管理)。艺术还很年轻。目前,我们不知道我们在做什么。但最终,我们会的。
或者,有人知道如何使用这个核心原则吗?
好的,这是播客。我觉得很有趣
我出去跑步了……听一个关于丰田的播客……无论如何。
我认为这个原则不会在软件项目中使用。(也许是项目管理)。艺术还很年轻。目前,我们不知道我们在做什么。但最终,我们会的。
或者,有人知道如何使用这个核心原则吗?
好的,这是播客。我觉得很有趣
我建议进行一些小的修改,如果该方法已被证明可以正常工作(性能/维护/安全/等),那么每次都使用它。
诀窍是“证明有效”,也是“正确”。
所以基本上,除非当前的方法有问题,否则不要为了改变而改变。(请注意,一种可以证明效果更好的方法,实际上突出了另一种方法存在问题,尤其是效果不佳)。
特别是在我们的领域,它特别适用,因为当大多数代码以相同的方式构建时,您可以获得生产力/可扩展性。例如维护、开发人员培训等。
换而言之,这位著名哲学家更熟悉的话:
如果它没有坏,就不要修理它。
好吧,我认为这完全取决于。如果您已经使用的方法具有良好的执行时间,(大部分)没有错误,并且可以按照您的意愿工作,那么就没有必要编写新的方法来完成这项任务。特别是如果您是为金钱或公司编程。
但是,如果您想学习一种编程语言的一些新特性,或者只是一种不同的做事方式,完全出于您的个人兴趣,为什么不呢?
在丰田这样的公司中,节省时间和金钱至关重要。但是,您的个人时间具有您赋予它的任何重要性。如果学习一种新的做事方法对你的底线有好处,那就去做吧。如果您的底线是尽可能多地学习,那么这可能是正确的做法。另一方面,如果您的底线是尽可能快地完成尽可能多的项目,那么事实并非如此。
但是,尝试不同的方法仍然有用,即使您的底线是节省时间和金钱;因为,通过使用不同的方法做一些你已经做过的事情,可能会给你带来一些想法,从长远来看可能会节省你的时间(时间就是金钱)。
所以我几乎想说,如果以完全不同的方式重做某事是你想做的事,那就去做吧。