私はAndroidゲームを私の暇な時間に構築しています。それは libgdx ライブラリを使用しているので、かなりの重労働が私のために行われます。
開発中に、いくつかの手順で不注意にデータ型を選択しました。連想配列に近いものが欲しかったので、ハッシュテーブルを使用しました。人間が読めるキー値。同様のことを達成するために他の場所では、ベクトルを使用します。 libgdxにvector2クラスとvector3クラスがあることは知っていますが、使用したことはありません。
奇妙な問題に遭遇し、Stack Overflowでヘルプを検索すると、別のデータ型が技術的に「適切」である場合に、特定のデータ型を使用する質問を広げる人がたくさんいます。 ArrayListを使用するのと同じように、境界を定義する必要がないため、int []を新しい既知の境界で再定義する必要がありません。または、このような些細なことでも:
for(int i = 0; i < items.length; i ++)
{
// do something
}
すべての反復でitem.lengthを評価します。ただし、アイテムが15〜20個を超えないこともわかっています。それで、すべての反復でitems.lengthを評価するかどうか気にすべきですか?
いくつかのテストを実行して、今説明した方法と適切な方法を使用してアプリがどのように機能するかを確認し、チュートリアルに従って、コミュニティーから提案された正確なデータ型を使用しました。結果:同じこと。平均45 fps。私は電話と銀河のタブですべてのアプリを開きました。変わりはない。
それで、あなたへの私の質問はこれだと思います:適切であることがもはや重要ではなくなったときにしきい値がありますか? 「仕事が終われば、気にしない」と言ってもいいですか。
問題を解決するためのプログラムを作成します。その問題には、それを解決するための一連の特定の要件が伴います。これらの要件が満たされれば、問題は解決され、目的は達成されます。
それでおしまい。
現在、ベストプラクティスが守られているのは、一部の要件が保守性、テスト容易性、パフォーマンス保証などに関係しているためです。したがって、適切なコーディングスタイルなどを必要とする私のような厄介な人々がいます。 Tを越えてIをドットにするのにそれほど多くの努力は必要ありません。それは、後でコードを読んでそれが何をするのかを理解しなければならない人々への敬意の表れです。
大規模なシステムでは、この種の抑制と規律が不可欠です。それは、すべてを機能させるために他の人とナイスをプレイする必要があり、プロジェクトが自重で崩壊しないように技術的な負債を最小限に抑える必要があるためです。
スペクトルの反対側にあるのは、特定の問題を解決するために現在作成している1回限りのユーティリティであり、二度と使用しないユーティリティです。これらの場合、スタイルとベストプラクティスはまったく無関係です。モノをハッキングして実行し、次のモノに取り掛かります。
したがって、ソフトウェア開発における多くのことと同様に、それは状況によって異なります。
「賢明な老人の足跡をたどらないでください。彼らが求めていたものを探し求めてください」。 「適切な」コーディングのすべてのルールには理由があります。それらのルールが存在する理由を知ることは、それらのルールが何であるかを知ることよりも重要です。
そのようなforループで繰り返し再計算される可能性のあるテストを入れるべきではないというルールがあります。ルールが改善のために発明された場合(パフォーマンスが実際に異なる場合)、それは理にかなっています。その場合、正解は1つだけです。あなたの例では、パフォーマンスの違いはなく、数十回を超える反復はあり得ないことがわかっています。この場合、2つの正しい答えがあります。いずれにしてもルールを適用することです。シンプルで何も害を及ぼさず、良い習慣を形成するのに役立つためです。または、パフォーマンスの違いが心配されていないため、ルールを無視します。
私は最初の正解を好み、あなたは2番目を好むようです。あなたはそれについて間違っていません。 「適切な」プログラミングが何であるかについての考えは間違っていると思います。それは、無作為に選ばれたルールのセットに従うことではなく、あなたを助けたり、目的を持っていません。この例のforループを修正しないことは、実際には時期尚早の最適化に対して非常に優れたルールに従っていることになります。
実際の適切なプログラミングとは、インテリジェントな方法で意味のある適切なルールに従うことです。
これを検討する適切な方法は、収益を減少させることです。つまり、プログラムを開発することの追加の利点を、追加の開発のコストと比較します。
利益の減少は、限界利益が限界時間/努力より少ないときに始まります。
引っ越しのビジネスケースを作れますかitems.length
for
ループの外?経済的に、その変化はそれを正当化しようとすることに費やされた時間を正当化することさえできますか?ユーザーエクスペリエンスに違いはないため、測定に費やされた時間(覚えておくと便利なレッスン以外)については何も得られません。その変更の結果として、ユーザーはプログラムを好きにならないだけでなく、より多くのコピーが販売されなくなります。
ビジネスケースは未知数やリスクで満たされているため、これを評価するのは必ずしも容易ではありません。したがって、後から明らかになるだけの未検討の要因の犠牲になる可能性があります。提案された変更は、大きな違いをもたらすように、完全に自明ではない場合があります。
減少するリターンのタイプの思考は、言い訳が何らかの行動を取らないようにし、リスクを取ることを回避することになる可能性があり、それは後から見ると一連の機会を逃していることが判明する可能性があります。
しかし、時々notが何かをすることが明白な場合があります。開発の一部が開発の費用を支払うためだけに発生する経済的な奇跡を必要とするように思われる場合(損益分岐点)、それはおそらく悪い考えです。
コードが「適切」であることを気にする必要がない場合
適切なコードを書くべき時
あなたの質問は「それが仕事を成し遂げる限り、私は気にしませんか?」です。
私の答えは、「あなたは自分のコードに何が起こるかわからない」です。私は「ユーザーの問題に対処するために、この簡単なことを書かせてください」として始まった非常に多くのプロジェクトに携わってきました。それを書いて、それを出して、二度とそれについて考えないでください。
あるとき、私が書いたものは「ああ、今、ユーザーの部門全体がそのコードを使用したいと思っています」に変わりました。それを変える前に、「会社全体がそのコードを使用していて、監査に合格することを証明する必要があります」そして明日予定されている20人のコードレビューがあり、一部の副社長はすでにそれを顧客に販売しています。」
「Androidゲームをあなたの暇な時間に書いているだけ」だと思いますが、そのゲームが始まり、名声と運命のチケットになるかどうかはわかりません。さらに悪いことに、そのゲームはそれは人々の電話をクラッシュさせ続けるので、悪評のチケットになります。誰かの子供が彼らの電話であなたのゲームをプレイすることを止めることができないので、あなたは仕事のオファーを得る人になりたいですか、それとも悪質になる人になりたいですか?このような伝言板?
パフォーマンスが主な関心事ですか?それを最大化しようとしていますか?
もしそうなら、学ぶべき基本的な教訓があり、もしそうなら、あなたは数少ない人のうちの一人になるでしょう。
速くするために何をすべきかを「考え」ようとしないでください-それは推測です。 「このコンテナクラスとそのコンテナクラスのどちらを使用すればよいですか」、「length
をループ状態にする必要がありますか?」実際に患者に質問したり検査したりせずに行う治療.
それは推測です。誰もがそれを行いますが、それは機能しません。
代わりに、プログラム自体がその問題を教えてください。 これは詳細な例です。
違いがわかりますか?
自宅で自分でプログラミングしている場合は、いくつかの手抜きをすることができます。実験して物事を試すとき、これは完全に正当化されます。
ただし、注意してください。この例では、その角を切り取る必要はまったくなく、注意する必要があります。これは傾向を開始する可能性があり、自宅で行う悪い習慣が職場のコードに侵入する可能性があります。家庭で良い習慣を実践して改善し、職場でコードに浸透させる方がはるかに優れています。それはあなたを助け、他の人を助けます。
あなたが行うすべてのプログラミングと、プログラミングについて行うすべての思考は、運動です。価値のあるものにしてください。そうしないと、戻ってきてあなたを噛んでしまいます。
しかし、良い面を見てください。あなたはこれについて尋ねたので、多分あなたは私がしているポイントをすでに知っているでしょう。
家具メーカーが品質を最重要視していない、または品質が気付かれない場合に使用する家具を製造していた場合でも、カットをまっすぐにして、適切な作業を行って部品を結合する必要がありますか?
多くの人々はソフトウェアを職人技と見なしています。私たちが構築するものは、機能を実行するだけでなく、信頼性、保守性、堅牢性を備えている必要があります。このようなソフトウェアを作成するにはスキルが必要であり、そのスキルは実践から生まれます。
そのため、現在取り組んでいるものに対してループ構造を選択することは重要ではないかもしれませんが、常に適切な構造を使用するように努めているという事実は、時間が経つにつれて、より優れたプログラマになります。
答えはそれは決して重要ではなく、常に重要であるということです...
適切であるかどうかにかかわらず、プログラミングは目標を達成するための方法であり、それ自体が目標ではないため、問題になることはありません。 「適切な」プログラミングなしでその目標が達成されれば、それは問題ありません(ビジネスの観点からは、プログラミングなしで目標を達成できるのが最善です)。
適切なプログラミングは目標の達成を支援するツールであるため、常に問題になります。物事を行う適切な方法は、それを別の方法で行うと、節約するよりも長期的にはより多くの痛みを引き起こすという認識にすぎません。
いつそれを無視できるのかという質問に答えます-長期的には別の方法の方が簡単であると確信している場合(おそらく長期的にはないため)。
通常、1回限りのツールは、エラーチェックやその他の検証をほとんどまたはまったく行わず、例外のログを記録せず、マイナーな変更を加えたカットアンドペーストのコードや、汎用関数の代わりに変更を加えることなく、できる限り迅速かつダーティに行われます。 。
気をつけてください:時々これらの迅速で汚いアプリが独自の命を奪うことがあります。つまり、すべてのショートカットがあなたを噛みます...
または、このような些細なことでも:
for(int i = 0; i < items.length;i ++) {
// do something
}
すべての反復でitem.lengthを評価します。ただし、アイテムが15〜20個を超えないこともわかっています。それで、すべての反復でitems.lengthを評価するかどうか気にする必要がありますか?
実際、最終的なコードでは、コンパイラが最適化するため、items.lengthは反復ごとに評価されません。そうでなかったとしても、長さは配列オブジェクトのパブリックフィールドです。アクセスには費用はかかりません。
それで、あなたへの私の質問はこれだと思います:適切であることがもはや重要ではなくなったとき、しきい値はありますか? 「それが仕事を成し遂げる限り、私は気にしません」と言っても大丈夫ですか?
それは本当にあなたの最終製品に何を期待するかに依存します。平均的な製品と優れた製品の違いは詳細に依存しています。 Tata Nanoのような車とMercedes Sのような車は「仕事をこなす」-ある場所から別の場所にあなたを連れて行きます。違いは詳細に依存しています:エンジン出力、快適さ、安全性など。これは、ソフトウェア製品を含む既存の製品と同じです。たとえば、MySQLとPostgreは無料なので、なぜOracleデータベース、DB2、またはMS SQL ServerをOracle、IBM、またはMicrosoftに支払うのでしょうか。
詳細に注意を払い、高品質の製品を入手したい場合は、この点(および他の点)に注意する必要があります。