私は走っていました.. トヨタについてのポッドキャストを聞いていました.. とにかく.
この原則は、ソフトウェア プロジェクトでは使用されないと思います。（おそらくプロジェクト管理）。芸術はまだまだ未熟です。現時点では、私たちが何をしているのかわかりません。しかし、最終的にはそうするでしょう。
あるいは、この核となる原則の使い方を理解している人はいますか?
わかりました、これがポッドキャストです。面白いと思います
2 に答える
0
メソッドが適切に機能することが証明されている場合（パフォーマンス/メンテナンス/セキュリティ/など）、小さな変更をお勧めします。その後、毎回それを使用します。
コツは「動作確認済み」、そして「きちんと」です。
基本的には、今のやり方に問題がない限り、変更のために変更しないでください。（実際には、他の方法に問題があることを強調し、特にうまく機能しない方法がよりうまく機能することに注意してください）。
特に私たちの分野では、ほとんどのコードが同じ方法で構築されたときに生産性/スケーラビリティが向上するため、特に適用できます。例: メンテナンス、開発者トレーニングなど。
他の、有名な哲学者からのより身近な言葉で:
壊れていない場合は、修正しないでください。
于 2008-09-21T12:25:13.890 に答える
0
まあ、私はそれが絶対に依存していると思います。すでに使用しているメソッドの実行時間が長く、(ほとんど) バグがなく、希望どおりに機能する場合は、このタスクを実行する新しい方法を記述する必要はありません。特に、お金や会社のためにプログラミングしている場合はなおさらです。
ただし、プログラミング言語の新しい機能を学びたい、または単に別の方法を学びたいと思っているのであれば、完全に個人的な興味のためではないでしょうか?
トヨタのような企業では、時間とお金を節約することが最も重要です。しかし、あなたの個人的な時間には、あなたが割り当てた重要性があります。何かを行うための新しい方法を学ぶことが収益に良い場合は、それを実行してください。肝心なのは、可能な限り多くを学ぶことである場合、これはおそらく正しいことです。一方、あなたの結論ができるだけ多くのプロジェクトをできるだけ早く終わらせることであるなら、そうではありません。
ただし、時間とお金を節約することが最終目的であっても、別の方法を試すことは依然として有効です。なぜなら、すでに行ったことを別の方法論で行うことで、長期的には時間を節約できる (そして時は金なり) 可能性のあるアイデアが得られる可能性があるからです。
ですから、何かをまったく違う方法でやり直すことがあなたのやりたいことなら、それをやり直せばいいのです。
于 2008-09-21T12:26:10.770 に答える