「適切な」プログラミングはもはや重要ではありませんか？

暇なときに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。電話とgalaxyタブですべてのアプリを開きました。変わりはない。

だから私はあなたへの私の質問はこれだと思う：それは適切であることがもはや重要ではないときにしきい値はありますか？「仕事をやり遂げる限り、私は気にしませんか？」と言っても大丈夫ですか？

問題を解決するプログラムを作成します。その問題には、それを解決するための特定の要件が伴います。これらの要件が満たされると、問題は解決され、目的は達成されます。

それでおしまい。

ここで、ベストプラクティスが観察される理由は、いくつかの要件が保守性、テスト容易性、パフォーマンス保証などに関係しているためです。その結果、適切なコーディングスタイルのようなものを必要とする私のような厄介な人々がいます。Tを超えてIを点数化するのにそれほど労力はかかりません。また、後でコードを読んで何をするかを理解しなければならない人への敬意のしるしです。

大規模なシステムの場合、この種の抑制と規律は不可欠です。すべてを機能させるには他の人とうまくやらなければならず、プロジェクトが自重で崩壊しないように技術的な負債を最小限に抑える必要があるからです。

スペクトルの反対側にあるのは、特定の問題を解決するためにあなたが今作成した、一度も使用しないユーティリティです。これらの場合、スタイルとベストプラクティスは完全に無関係です。一緒にハッキングして実行し、次のものに取り掛かります。

したがって、ソフトウェア開発における非常に多くのものと同様に、それは依存します。

賢い古い引用があります：「昔の賢者の足跡をたどらないでください。彼らが求めたものを探してください。」「適切な」コーディングのすべてのルールには理由があります。これらのルールが存在する理由を知ることは、それらのルールが何であるかを知ることよりも重要です。

そのようなforループで繰り返し再計算される可能性のあるテストを入れてはいけないというルールがあります。ルールが改善のために考案された場合（パフォーマンスが実際に異なる場合）、それは理にかなっています。その場合、正しい答えは1つだけです。あなたの例では、パフォーマンスの違いはなく、数十回の反復しかできないことがわかっています。この場合、2つの正しい答えがあります。単純で、何も傷つけず、良い習慣を形成するのに役立つため、とにかくルールを適用します。

私は最初の正しい答えを好み、あなたは2番目の答えを好むようです。あなたはそれについて間違っていません。「適切な」プログラミングとは何かについて、あなたは間違っていると思います。それはあなたを助けず、目的のないルールのランダムに選択されたセットに従うことではありません。この例でforループを修正しないのは、実際には時期尚早な最適化に対する非常に優れたルールに従っています。

真の適切なプログラミングとは、理にかなった適切なルールに従うことです。

これを見る適切な方法は、収益を減らすことです。プログラムを開発することの追加の利点を、追加の開発のコストと比較します。

利益の減少は、限界利益が限界時間/努力よりも少ないときに始まります。

ループitems.lengthから抜け出すためのビジネスケースを作成できますforか？経済的に、その変化はそれを正当化しようとするのに費やされた時間を正当化することができますか？ユーザーエクスペリエンスに違いはないため、測定に費やした時間でさえ何も得られません（覚えておくと便利なレッスン以外）。ユーザーは、プログラムが好きになることを嫌い、その変更の結果として、より多くのコピーは販売されません。

これは、ビジネスケースが未知の要素やリスクで満たされているため、評価が必ずしも容易ではないため、後知恵で明らかになるだけの考慮されていない要因の餌食になりやすいからです。提案された変更は完全に自明ではないため、大きな違いを生みます。

減少リターン型の思考は、言い訳が何らかの行動を起こさず、リスクを回避するための狩りに相当する可能性があります。

しかし、ときどき何かをしてはいけないことが明らかです。開発の一部が開発の費用を支払うためだけに経済的な奇跡を必要とするようであれば（損益分岐点）、それはおそらく悪い考えです。

コードが「適切」であることを気にする必要がない場合

• あなたがビジネス目標に答えることができて、低いオーバーヘッドで時間をかけてそれを保つならば。（ユーザーは支払い前にソースを表示しません）
• MVP / POC-適切なコードを書くことは、お金を稼ぐ方法を知る前にコンセプトに時間を浪費することを意味する場合コードは適切でした）
• 生命を脅かす状況にあるとき（たとえば、アイアンマンプロトタイプ1は汚いハックでしたが、洞窟から抜け出しましたか？）
• または単に適切なコードの書き方がわからない場合（誰かがなんとかして適切なコードを書いて生計を立てている場合、今日の失業率では、ホームレスになるよりも悪いコードを書く方が良い）
• 自分が何をしているのかを単に知っているか、自分のふりをして逃げることができると思う

適切なコードを書くとき

• 業績に大きな影響がある場合、たとえば、パフォーマンスが収益に影響を与えたり、販売を妨げたりする場合
• コードの保守がビジネス上の問題になるほど適切でない場合（高い保守コスト）
• あなたが有名なプログラマであり、大きなオープンソースプロジェクトに取り組んでいる場合
• 社内図書館を世界に提供している大企業でも同じ
• 今後のインタビューで作品をポートフォリオとして見せたい場合

パフォーマンスが主な関心事ですか？それはあなたが最大化しようとしているものですか？

もしそうなら、学ぶべき基本的な教訓があり、もしそうなら、あなたは数少ない人の一人になります。

速くするためにすべきことを「考え」ようとしないでください-それは推測です。「このコンテナクラスを使用するべきですか？」または「lengthループ状態にする必要がありますか？」患者への質問または検査。

それは推測です。誰もがそれを行いますが、うまくいきません。

代わりに、プログラム自体に問題の内容を伝えてください。 詳細な例を示します。

違いがわかりますか？

あなたの質問は、「仕事が終われば、私は気にしませんか？」です。

私の答えは、「あなたのコードに何が起こるかわからない」です。「ユーザーの問題に対処するために、この簡単なことを書かせてください」として始まった非常に多くのプロジェクトに携わってきました。それを書いて、それをそこに置き、二度と考えないでください。

かつて、私が書いたものが「ああ、今ではユーザーの部門全体がそのコードを使用したい」に変身しました。明日には20人のコードレビューが予定されており、一部の副社長は既にそれをお客様に販売しています。」

あなたは「暇なときにアンドロイドゲームを書いているだけ」と気づいていますが、そのゲームが成功して名声と富のチケットになるかどうかはわかりません。さらに悪いことに、そのゲームは人々の電話をクラッシュさせ続けるため、悪名高いチケットになる可能性があります。誰かの子供が携帯電話でゲームをプレイするのをやめられないために求人を受け取る人になりたいですか、それともこのような掲示板で中傷される人になりたいですか？

答えは、それは決して重要ではなく、常に重要だということです。

プログラミングは、適切であるかどうかに関係なく、それ自体が目標ではなく、目標を達成する方法であるため、重要ではありません。「適切な」プログラミングなしでその目標が達成される場合（ビジネスの観点からは、多くの場合、プログラミングなしで目標を達成できるのが最善です）。

適切なプログラミングは目標を達成するのに役立つツールであるため、常に重要です。物事を行う適切な方法は、別の方法でそれを行うと、保存するよりも長い目で見れば痛みが大きくなるという認識にすぎません。

それはあなたがそれをいつ無視できるかという質問に答えます-長い目で見れば別の方法がより簡単であると確信しているとき（たぶん、長い目で見ないから）。

通常、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に支払うのはなぜですか？

詳細に注意を払い、高品質の製品を入手したい場合は、この項目（および明らかに他の項目）に注意する必要があります。

自分で自宅でプログラミングしている場合は、いくつかのコーナーをカットできます。そして、あなたが実験して物事を試しているとき、これは完全に正当化されます。

ただし、注意してください。あなたが与える例では、実際にその角を切る必要はなく、注意する必要があります。これはトレンドを開始する可能性があり、自宅で行う悪い習慣が職場のコードに忍び込む可能性があります。自宅で良い習慣を練習して改善し、職場であなたのコードに浸透させるのがはるかに良い。それはあなたを助け、他の人を助けます。

プログラミングを行うこと、およびプログラミングに関して行うことは運動です。それは価値がある、そうでなければそれは戻ってきてあなたを噛むでしょう。

良い面を見てください。あなたはこれについて尋ねたので、多分あなたはすでに私が作っているポイントを知っているでしょう。

家具メーカーが、品質が最重要ではない場所や品質に気付かれない場所で使用する家具を作っている場合、彼らはカットをまっすぐにしようとするべきでしょうか？

多くの人々はソフトウェアを職人技と見なしています。構築するものは機能を実行するだけでなく、信頼性、保守性、堅牢性が必要です。そのようなソフトウェアを作成するにはスキルが必要であり、そのスキルは練習から生まれます。

そのため、現在作業しているものに対してループ構造を選択することは重要ではありませんが、常に適切な構造を使用しようと努力するという事実は、時間の経過とともに、より優れたプログラマーになります。