タグ付けされた質問 「programming-practices」

プログラミングプラクティスは、ソフトウェアの開発で一般的に使用される、またはあまり使用されないプラクティスです。これには、アジャイル開発、かんばん、コーディングのショートカットなどが含まれます。

3
スイッチのデフォルトケースでブレーク
私はbreak、最後のケースの後に含めるかどうかについて、しばしば困惑していますdefault。 switch (type) { case 'product': // Do behavior break; default: // Do default behavior break; // Is it considered to be needed? } break唯一の目的は、コードが残りのswitchケースを実行しないようにすることです。 break一貫性のために最後を持っているのがより論理的であると考えられbreakますか、機能的な使用をまったく適用しないためにそれをスキップしますか?私の意見では、両方とも異なる方法で論理的です。 これは、.phpファイルをで終わることとある程度比較できます?>。私は?>ほとんど空白スペースを出力するリスクのために終わることはありませんが、ファイルを終了することは論理的なことだと主張することができます。

7
短絡評価、それは悪い習慣ですか?
私がしばらく知っているが、考慮されていないことは、ほとんどの言語では、順序に基づいてifステートメントで演算子を優先することができるということです。私はよく、これをヌル参照例外を防ぐ方法として使用します。例えば: if (smartphone != null && smartphone.GetSignal() > 50) { // Do stuff } この場合、コードは最初にオブジェクトがnullでないことを確認し、次にこのオブジェクトが存在することを知って使用します。言語が賢いのは、最初のステートメントがfalseの場合、2番目のステートメントを評価しても意味がないため、null参照例外がスローされないことがわかっているためです。これはandand or演算子でも同じように機能します。 これは、インデックスが配列の境界内にあることを確認するなど、Java、C#、C ++、Python、Matlabなどのさまざまな言語でこのような手法を実行できるなど、他の状況でも役立ちます。 私の質問は次のとおりです。この種のコードは悪い習慣を表していますか?この悪い習慣は、隠れた技術的な問題から生じますか(つまり、最終的にエラーになる可能性があります)、または他のプログラマーにとって読みやすさの問題につながりますか?紛らわしいですか?

9
過剰な思考の発達
私は1年半の間アプリ開発者として働いてきました(長くは知りません)し、最初の大きなプロジェクトを与えられました。 言うまでもなく、それは非常にスムーズに進まなかったので、プロジェクトに携わる上級プログラマーにアプローチ方法についてアドバイスを求めました。 彼は、私が目の前のタスクについて思い切って考えすぎていた、そしてデザインパターンを考えるのに時間をかけすぎてしまう前にこの規模のプロジェクトに取り組んだことがなかったからだと言った。彼の賢明な言葉で、彼は私に、「F * ck the future、build for now」と言った。 これは、プログラマーがこのようなプロジェクトに取り組む際に一般的にフォローする傾向ですか?たとえば、概念実証モデルの実行を求められた場合、できるだけ早く実行可能な例を破壊するのが一般的な傾向ですか? 編集:これがきっかけとなった議論を踏まえて、この状況は非常に極端であることに言及したいと思います:私たちがコントロールできない要因のために非常に厳しい期限があります(つまり、私たちが目指している市場は興味を失います「彼らに何かを見せないでください」と彼のアドバイスは、この特定のタスクに非常に効果的であることが証明されました。

12
単体テストを行うには、プロジェクトの大きさはどれくらい必要ですか?[閉まっている]
私のプロジェクトは、単体テストを可能にするほど十分に分離されていると思います。しかし、単体テストを価値のあるものにするために、プロジェクトは、正確に、クラスと機能の面でどれだけ大きくする必要がありますか? 私たちは皆、間違いを犯し、完璧な人はいませんが、小さなプロジェクトのエラーをステップスルーで処理するための自分はまともなプログラマだと思います。または、プロジェクトのサイズに関係なく、単体テストは非常に必要ですか?

17
私のネガティブなインターンシップの経験は現実の世界を代表していますか?[閉まっている]
インターンとしての私の現在の経験が実際の業界の代表であるかどうか、私は興味があります。 背景として、私は2つのコンピューティング専攻と主要な大学の数学専攻の大部分を経験しています。私はすべてのクラスをエースし、それらすべてを崇拝してきたので、私はプログラミングがひどくないと思いたいです。私は大手ソフトウェア会社の1つとインターンシップを取得しましたが、途中でコードの品質が非常に低いことにショックを受けました。コメントは存在せず、すべてスパゲッティコードであり、間違っている可能性のあるものはすべてさらに悪いものです。私はたくさんの個別指導/テイニングを行ったので、悪いコードを読むことに非常に慣れていますが、私が見ている主要な業界製品はそれのすべてに勝っています。私は1日10〜12時間働いていますが、どこにでも行くような気がしません。文書化されていないAPIを見つけようとしたり、(完全に文書化されていない)製品のその他の部分の動作を決定しようとする無限の時間。私はこれまで毎日仕事を嫌う仕事を辞めてきましたが、これが私の人生の残りの部分であるかどうかを必死に知りたいです。 インターンシップに短いストローを描いたのか(馬鹿げた大きな給料は、それが低品質のポジションではないことを意味します)、またはこれは現実の世界のようなものですか?

11
単体テストでは独自のメソッドを使用すべきではありませんか?
今日、私は「JUnitの基本」ビデオを見ていました。著者は、プログラムで特定のメソッドをテストするとき、プロセスで他のメソッドを使用しないでくださいと言いました。 具体的には、引数に名前と姓を使用するレコード作成メソッドをテストし、それらを使用して特定のテーブルにレコードを作成することについて話していました。しかし、彼は、このメソッドをテストする過程で、他のDAOメソッドを使用してデータベースにクエリを行って最終結果を確認するべきではないと主張しました(レコードが実際に正しいデータで作成されたことを確認するため)。彼は、そのために、データベースを照会して結果を確認するための追加のJDBCコードを作成する必要があると主張しました。 私は彼の主張の精神を理解していると思います:あるメソッドのテストケースが他のメソッド(この場合はDAOメソッド)の正確さに依存することは望ましくなく、これはあなた自身の検証を(再び)書くことによって達成されます/ supportingコード(より具体的で焦点が合っている必要があるため、よりシンプルなコード)。 それにもかかわらず、私の頭の中の声は、コードの重複、不必要な追加作業などの議論で抗議し始めました。他の方法をテストしながら、それらの方法の一部を使用しても大丈夫ですか?それらの1つが想定されていることを実行していない場合、独自のテストケースは失敗します。それを修正し、テストバッテリを再度実行できます。コードの複製(複製コードがいくぶん単純であったとしても)や無駄な努力は必要ありません。 私が書いたいくつかの最近のExcel - VBAアプリケーション(VBA用Rubberduckのおかげで適切にユニットテストされた)のため、私はこれについて強い気持ちがあります。 これについての洞察を共有していただけますか?

11
一般的にプログラミングは、経験を積むにつれて読みやすく、書きやすく、理解しやすくなりますか?[閉まっている]
私はプログラミングの初心者であり、本を読んだり、勉強したり、記事を読んだりしています。プログラミングを学び始めてから素晴らしい結果が得られており、初心者の頃はプログラミングに関するすべてを知っていたと思っていましたが、学習するにつれて、この分野の難しさを実感しました(実際、すべての分野は難しい、しかし、それはポイントではありません)。 今日、私は機能的なソフトウェアを書き、3つの言語の基本を学び、たった1つの言語で中級です。MYSQL、OpenGLプログラミング、またはVisual Studio C ++コードなどの高度なものを見ると、頭痛の種になります。また、多くのWebサイトのHTMLソースコードを視覚化するときでも(Google Chromeで見られるWebサイトのほとんどのソースコードは、非常に乱雑で整理されていないようです) )それは私の脳の極限に私を混乱させます。最初はすべてシンプルに見えますが、これらの高度なものを見ると、どうやってそんなに学ぶことができるのかと思うようになります。 簡単に言えば、質問は、プログラマーがキャリアを進めるにつれて、これらのことがより明確になるかどうかです。上記のような複雑なトピック(OpenGL、MySQL、高度なhtmlサイト)は、学習するにつれて読みやすく、書きやすく、理解しやすくなりますか、それとも複雑になりますか?あなたがプログラミングの世界でアリであり、このようなものがあなたをつぶそうとしているという気持ちにどうやって対抗できるでしょうか?

7
コードファーストとデータベースファースト
作業するソフトウェアを設計および作成するとき、通常、最初にバックエンドSQLテーブルを設計および作成してから、実際のプログラミングに進みます。私が現在取り組んでいるプロジェクトは、私を困惑させます。これはおそらく、適切で堅実な要件が不足しているためですが、残念ながら今度はそれについてできることはほとんどありません。それは「それを実現させるだけ」のような状況です。しかし、私は脱線します。 ワークフローを頭に入れ、最初にUIクラスとデータモデルクラスを作成して、データベーススキーマが最終的にどのように見えるかを明確にすることを考えています。これはいい考えですか?私はUIになり、dbをどのように構成するのかまだわかりません。 好奇心anyone盛な方は、SQL Serverをバックエンドとして、MS Accessをフロントエンドアプリケーションとして使用しています。(アクセスも私の選択ではありません...だから、あまりにも嫌いにしないでください。)

11
テスト目的でコードを厳密に変更するのは悪い習慣ですか?
私はプログラマーの同僚と、テスト可能なものにするためだけに作業中のコードを変更するのが良いか悪いかについて議論しています(例えば、単体テストを介して)。 私の意見では、オブジェクト指向とソフトウェアエンジニアリングの優れた実践を維持することの範囲内で(「すべてを公開する」などではなく)OKです。 私の同僚の意見は、テスト目的でのみコードを修正するのは間違っているというものです。 単純な例として、一部のコンポーネント(C#で記述された)で使用される次のコードを考えてください。 public void DoSomethingOnAllTypes() { var types = Assembly.GetExecutingAssembly().GetTypes(); foreach (var currentType in types) { // do something with this type (e.g: read it's attributes, process, etc). } } 私は、このコードを修正して、実際の作業を行う別のメソッドを呼び出すことを提案しました。 public void DoSomething(Assembly asm) { // not relying on Assembly.GetExecutingAssembly() anymore... } このメソッドは、作業するAssemblyオブジェクトを取り込んで、テストを実行するために独自のAssemblyを渡すことを可能にします。私の同僚は、これが良い習慣だとは思いませんでした。 良い一般的な慣行とは何ですか?

17
「賢い」コードを書かないように自分を訓練する方法は?[閉まっている]
s で新しいトリックを披露したり、3つの異なる手順を一般化したりする必要があるときの気持ちを知っていExpressionますか?これはArchitecture Astronautの規模である必要はなく、実際に役立つかもしれませんが、他の誰かが同じクラスまたはパッケージをより明確で率直な(そして時には退屈な)方法で実装することに気づかずにはいられません。 私はしばしば問題を過剰に解決することによってプログラムを設計することに気づきました。時には故意に、時には退屈から。どちらの場合でも、反対の証拠を見るまで、私のソリューションは非常に透明でエレガントであると正直に信じていますが、通常は手遅れです。また、コードの重複よりも文書化されていない仮定を好み、単純さよりも賢いことを好む私もいます。 何をするために行うことができ、「cleverish」のコードを記述する衝動に抵抗してたときにベルリングをすべきであること、私はそれは間違ってやっていますか? 私は今、経験豊富な開発者のチームと協力しているため、問題はさらに押し進められています。スマートコードを書くという私の試みは、時間が優雅さの幻想を払拭した後でも自分にとっては愚かに思えます。

10
Javaではクラスごとに何行が多すぎますか?[閉まっている]
あなたの経験では、Javaの1つのクラスには何行のコードが多すぎるかについての有用な経験則は何ですか? 明確にするために、行数は特定のクラスにあるべきものとそうでないものに使用する実際の標準にさえ近いものではないことを知っています。クラスは、適切なOOP哲学(カプセル化など)を念頭に置いて設計する必要があります。そうは言っても、経験則はリファクタリングの考慮事項の有用な出発点を提供することができます(つまり、「うーん、このクラスには> n行のコードがあります。ある時点でリファクタリングされます」)。 反対に、おそらく、OOP設計を順守し、長さにも関わらず読み取りと保守が可能な非常に大きなクラスの例に遭遇したことはありませんか? これは、関数ごとの行に関する、重複しない関連する質問です。

15
大規模なソフトウェアでバグの絶対的なゼロ状態に到達することは可能ですか?
たとえば、Autodesk Mayaの規模と複雑さのコード、2千万から3千万行以上のコードについて話しています。 必要に応じて開発をフリーズした場合、単一のバグがなくなるまで、すべてのバグを実際に修正できますか?バグのないシステムの存在に対する賛否両論は何ですか? 修正するたびにバグが増えるという考えがあるため、それは真実ではないと思います。 バグとは、UIの最も単純なタイプミスから、回避策のないより深刻な予防バグまでを意味します。たとえば、特定のスクリプト関数は法線を正しく計算しません。また、回避策がある場合でも、問題を解決する必要があります。したがって、提供された関数を使用する代わりに、この特定のことを手動で行うことができますが、その関数はまだ修正する必要があります。

8
プログラムの有効期間中にメモリを使用する必要がある場合、プログラムの終了直前にメモリを解放する必要は本当にありますか?
多くの本やチュートリアルで、メモリ管理の実践が強調されていることを聞き、使用後にメモリを解放しないと、不可解で恐ろしいことが起こると感じました。 私は他のシステムについて話すことはできません(私にとっては同様のプラクティスを採用していると仮定するのは合理的です)が、少なくともWindowsでは、カーネルは基本的にほとんどのリソース(奇数を除いて)をクリーンアップすることを保証されていますプログラム終了後のプログラム。これには、ヒープメモリなどが含まれます。 ユーザーが利用できるようにするためにファイルを使い終わった後にファイルを閉じたい理由や、帯域幅を節約するためにサーバーに接続されたソケットを切断したい理由を理解していますが、プログラムが使用するすべてのメモリをマイクロ管理する必要があります。 今、私はこの質問はあなたが必要とどのくらいのメモリに基づいており、あなたの記憶を処理する方法以来、幅広いであることに同意し、あなたがそれを必要とするとき、私はこれまで、この質問の範囲を狭めるます:私はの作品を使用する必要がある場合プログラムの存続期間中のメモリ、プログラム終了直前にメモリを解放する必要は本当にありますか? 編集:重複として示唆された質問は、オペレーティングシステムのUnixファミリーに固有のものでした。その一番の答えは、Linux固有のツール(Valgrindなど)でさえも特定しました。この質問は、ほとんどの「通常の」非組み込みオペレーティングシステムと、プログラムの寿命を通じて必要とされるメモリを解放するのが良い習慣であるか、またはそうでない理由を網羅することを意図しています。

17
正しいループを書く方法は?
ほとんどの場合、ループを書いている間、間違った境界条件(例:間違った結果)を書くか、ループ終了に関する私の仮定が間違っています(例:無限ループ)。試行錯誤の結果、仮定は正しいものになりましたが、頭の中に正しいコンピューティングモデルがないためにイライラしすぎました。 /** * Inserts the given value in proper position in the sorted subarray i.e. * array[0...rightIndex] is the sorted subarray, on inserting a new value * our new sorted subarray becomes array[0...rightIndex+1]. * @param array The whole array whose initial elements [0...rightIndex] are * sorted. * @param rightIndex The …

8
ソフトウェアプロジェクトの最初に物事を正しく行うにはどうすればよいですか?[閉まっている]
私は1年の経験を持つプログラマーです。最近、プロジェクトを正しく開始することはほとんどないことに気付きました(ほとんどのサイドプロジェクト)。通常、プロジェクトサイクルは次のようになります。 いくつかのユースケースから始めます コーディングを開始 うまく処理できず、現在のコードベースにうまく適合しないいくつかのことを理解してください。 コードの大部分を書き換える そして、これは数回行くかもしれません だから私の質問は そのような慣行は一般的ですか、またはそれは私が能力がないことを意味しますか? この面でどうすれば自分を改善できますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.