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

私は10年以上ソフトウェア開発に携わっていますが、「新しい」ものを作成することはめったにありません。「新しい」という用語は曖昧な用語であることを理解していますが、明確な新しい大規模プロジェクトから既存のプロジェクトの新しい大規模な機能に至るまで、その定義を定義します完了するには2週間以上かかります）。大まかなガイドラインは、書面による仕様が必要な場合は新しいものかもしれません。ほとんどのプログラマは私が話していることを知っていると思います-あなたはゾーンにいて、大量のコードを速いペースで書いています。 とにかく、自分がやったことを振り返ってみると、「新しい」仕事に費やされている時間は10％未満だと見積もっています。「この既存のシステムをこの新しい環境で動作するように適応させる」など、確かに多くの計画が必要ですが、実際のコーディングと「新しいもの」は、コード全体の多くの場所で小さな変更を行うことになります。同様に、小さな機能のリクエストについては-何をすべきかを知っていれば、これらは1時間以内に完了することがよくありますが、そうでない場合は、コードを読んで何をすべきかを考え出すだけです読むことではなく、行うことでより良くなります）。 一般的に、私はほとんど何も実際に作成していないように感じます。ほとんどの場所でこれが当てはまると思います-新しい製品がかなり早く出て、その時点で誰もが興奮してコードを速いペースで叩き出しますが、一度ライブになるとメンテナンスモードに移行しますその後の変更のいくつかは、「新規かつ創造的」と見なされます。 私が間違っている？私はほとんどのプログラミングの仕事を正確に説明していますか、それともほとんどのプログラマーは新しいものを頻繁に作成していると感じていますか？

63 programming-practices  maintenance 

ソフトウェアエンジニアリングと土木工学を比較すると、私は異なる考え方を観察して驚いた：土木技師なら誰でも、庭に小さな小屋を建てたいなら、材料を手に入れて建てることができるのに対して、 10階建ての家（または、たとえばこのようなもの）では、崩壊しないことを確認するためにかなりの計算を行う必要があります。 対照的に、一部のプログラマーと話したり、ブログやフォーラムを読んだりして、次のように定式化できる幅広い意見をしばしば見つけます。理論と形式的方法は数学者/科学者向けであり、プログラミングは物事を成し遂げることです。 ここで通常暗示されているのは、プログラミングは非常に実用的なものであり、形式的な方法、数学、アルゴリズム理論、クリーン/コヒーレントなプログラミング言語などは興味深いトピックかもしれませんが、すべてが必要な場合は必要ないことです完了しました。 私の経験によれば、100行のスクリプト（小屋）をまとめるのにそれほど理論は必要ありませんが、複雑なアプリケーション（10階建ての建物）を開発するには、構造化された設計が必要です。定義されたメソッド、優れたプログラミング言語、アルゴリズムを検索できる優れた教科書など。 したがって、IMO（適切な量の）理論は、物事を成し遂げるためのツールの1つです。 私の質問は、なぜ一部のプログラマーが理論（形式的手法）と実践（物事を成し遂げる）の間に対照があると考えるのですか？ ソフトウェアエンジニアリング（ソフトウェアの構築）は、例えば土木工学（住宅の構築）と比較して多くの人が容易に認識してい ますか？ または、これらの2つの分野は本当に異なりますか（ミッションクリティカルなソフトウェアは別として、ソフトウェアの障害は建物の障害よりもはるかに許容されます）。 これまでの回答から理解したことを要約しようと思います。 ソフトウェアエンジニアリングとは対照的に、土木工学では、特定のタスクに必要な理論量（モデリング、設計）がはるかに明確です。 これは、土木工学が人類と同じくらい古く、ソフトウェア工学が数十年しか存在していないという事実に一部起因しています。 別の理由は、ソフトウェアがより不安定な種類のアーティファクトであり、より柔軟な要件（クラッシュする可能性がある）、さまざまなマーケティング戦略（すぐに市場に出すために良いデザインを犠牲にすることができる）などであるという事実です。 結果として、適切な設計/理論の量がソフトウェアエンジニアリングに適切であるかを判断するのははるかに困難です（少なすぎる->乱雑なコード、多すぎる->私は決して終わらない） （多くの）経験が役立ちます。 したがって、あなたの答えを正しく解釈すると、 理論が実際にどれだけ必要かについてのこの不確実性が、一部のプログラマーが理論に対して抱く愛と憎しみの混合の原因になります。

63 programming-practices  theory  formal-methods 

よく文書化されたコードの重要性を理解しています。しかし、自己文書化コードの重要性も理解しています。特定の機能を視覚的に読みやすくするほど、ソフトウェアのメンテナンス中にすばやく移動できます。 とはいえ、私は大きな機能を他の小さな機能に分離するのが好きです。しかし、1つのパブリックメソッドを提供するためだけに、クラスが5つまで持つことができるようになります。ここで、5つのプライベートメソッドに5つのパブリックメソッドを掛けると、それらのパブリックメソッドによって1回だけ呼び出される可能性のある、25の隠しメソッドを取得できます。 確かに、これらのパブリックメソッドは読みやすくなりましたが、機能が多すぎるのは悪い習慣だと思わざるを得ません。 [編集] 人々は、なぜ機能が多すぎるのが悪い習慣だと思うのかと私に尋ねてきました。 簡単な答え：それは直感です。 私の信念は、少しの間、ソフトウェアエンジニアリングの経験に支えられていません。「ライターのブロック」を与えたのは、プログラマーにとってだけの不確実性です。 過去には、私は個人的なプロジェクトのみをプログラミングしてきました。チームベースのプロジェクトに移ったのはつい最近のことです。ここで、他の人がコードを読んで理解できるようにします。 何が読みやすさを改善するのか分かりませんでした。一方では、1つの大きな関数を、わかりやすい名前を持つ他の小さな関数に分離することを考えていました。しかし、それは単に冗長であると言っている私の側面がありました。 それで、正しい道を選ぶために自分自身を啓発するように私はこれを求めています。 [編集] 以下は、私がどのように2つのバージョンが含ま可能性が私の問題を解決します。最初のものは、コードの大きな塊を分離しないことでそれを解決します。2番目は別のことを行います。 最初のバージョン： public static int Main() { // Displays the menu. Console.WriteLine("Pick your option"); Console.Writeline("[1] Input and display a polynomial"); Console.WriteLine("[2] Add two polynomials"); Console.WriteLine("[3] Subtract two polynomials"); Console.WriteLine("[4] Differentiate two polynomials"); Console.WriteLine("[0] Quit"); } 2番目のバージョン： public static int …

63 programming-practices  code-quality  documentation 

私はしばらくの間MapReduceについて読んでいますが、私が理解できないのは、誰かがMapReduceを使用する（または使用しない）ことを決定する方法です。 つまり、MapReduceを使用できることを示す問題のパターンは何ですか。

61 programming-practices  parallel-programming 

私はif声明を持っているときに戻るより良い方法と考えられるものを知りたいです。 例1： public bool MyFunction() { // Get some string for this example string myString = GetString(); if (myString == null) { return false; } else { myString = "Name " + myString; // Do something more here... return true; } } 例2： public bool MyFunction() { // Get some …

60 programming-practices 

プロジェクトで作業する場合、コードは1日でかなり高速に開発される場合もあれば、数週間/月/年の長期にわたって少しずつ開発される場合もあります。コードコミットはプロジェクト開発の指標と見なされるようになっているため、コミットが少ないプロジェクトよりも多くのコードが記述されているという意味ではありません。 では、問題は、いつコミットを正当化できるようにリポジトリに実際にコミットするかです。 アドオンとして：コミットに基づいてプロジェクトの開発を測定することは正しい習慣ですか？

59 programming-practices  version-control  coding 

ここでクロージャーを説明する多くの投稿を読んだ後、私はまだ重要な概念がありません：なぜクロージャーを書くのですか？ プログラマーが実行する特定のタスクのうち、クロージャーが最も役立つと思われるものは何ですか？ Swiftでのクロージャーの例は、NSUrlのアクセスとリバースジオコーダーの使用です。以下にそのような例を示します。残念ながら、これらのコースは閉鎖を示しています。コードソリューションがクロージャとして記述されている理由は説明されていません。 私の脳を「あぁ、これのためにクロージャを書くべきだ」と言うかもしれない現実世界のプログラミング問題の例は、理論的な議論よりも有益でしょう。このサイトで利用可能な理論的議論の不足はありません。

58 programming-practices  functional-programming  swift-language 

私たちは日々の生活の非常に重要なタスクを含め、コンピューティングにますます頼るようになっているので、私はそれらの重要なコンポーネントがどのようにテストされるのかと思っていました。 より技術的には、コンパイラとアセンブラはどのようにテストされますか？（これは停止の問題に関連すると思います!!）

57 programming-practices  compiler  theory 

私たちは、プロジェクトの1つに貢献する必要がある非プログラマー（ライター）と協力しています。 現在、彼らは自分の作業をバージョン管理するためにGit（またはそのことは何でも）を使用するという考えを嫌っています。これは、バージョン管理のねじれた概念に頭を悩ませるだけの価値がないためだと思います。（私が最初にそれらをブランチとマージに紹介したとき-彼らは私がそれらを怒らせていたように見えました。） 今、私たちは彼らを教育したり、それを使うように説得する立場にはありません。私たちは、彼らのすべての作業をバージョン管理するための代替案を探しています（これが必要なものです）-彼らは簡単なワークフローを取得し、彼らの仕事に集中します。 私はいくつかのアイデアを思いつきました... 自明ではない変更を行うたびに作業を個別のファイルとして保存するように指示し、変更を追跡するために差分を使用します。 CSSEditの「マイルストーン」を何らかの方法で実装するプログラムを（Pythonで）作成します。 プロジェクトについて： これは自然言語処理システムです（C + Pythonで記述されています）。さまざまな言語でシステムの入力を準備するために、いくつかのライターを雇いました。そして、ソフトウェアを進化させると、それらのライターが入力（記事）を変更する必要があります。時々、変更は非常に小さい（1つか2つ）こともあれば、大きくなることもあります。 これらの変更をバージョン管理する必要があるのは、入力のあらゆる小さな/大きな変更がシステムの出力を劇的に変更する可能性があるためです。

57 programming-practices  version-control  teamwork 

私は長年の経験を持つプログラマーです。ある習慣があることに気づきました。それが本当に悪い習慣であるかどうかはわかりません。 ソリューションのために実行するタスクのリストを取得します。たとえば、小さな小さなタスクでも このユーザーコントロールのリソースを変更する 別のサイズを変更する 別のユーザーコントロールにHTMLとコーディングを追加する これらのタスクはすべて小規模です。10分以内にできることを意味しますが、小さな変更を加えてからWebブラウザーで何度もテストするという悪い習慣がありました。これは良い習慣ですか？ または、一度にすべてを実行してから、一緒にテストする必要がありますか？ それが本当に悪い習慣であれば、小さな変更を何度もテストするのに時間を浪費しているように感じるので、どうすれば修正できますか？

54 programming-practices  coding-style 

私はソフトウェア開発者です。アナリストによって書かれたテストケースをフォローして実行するが、探索的テストも実行するテスターのチームがあります。テスターは誰がより多くのバグを開くかを競い合っているようで、バグレポートの質が低下していることに気づきました。機能のテストやソフトウェアの動作に関連するバグの報告の代わりに、テスターは画面の機能強化、使いやすさ、または愚かなバグに関するバグを提出しています。 これはプロジェクトに適していますか？そうでない場合、どうすれば（ソフトウェア開発者として）テスターチームの考え方や態度を変えようとすることができますか？ もう1つの問題は、期限が推定されて変更できないため、期限が近づくと、テスト担当者がテストケースを終了するためにスクランブルし、テストの品質が低下することです。これにより、クライアントが受け取った最終製品に正当なバグが発生します。 OBS：この競争は会社の慣行ではありません！それは彼らによって組織されたテスターだけの間の競争であり、賞はありません。

54 programming-practices  testing  project-management 

私はしばらくコーディングしてきましたが、ほとんどはスクリプトと単純なアプリケーションです。Web Appsの開発と適切なMVCアーキテクチャの使用がすべての新しい役割に移行したため、そのすべてについて非常に迅速に学習しようと必死です。 この質問が「MVCアーキテクチャのベストプラクティス」とあまり似ていないことを願っていますが、いくつかの異なるチュートリアルを進めていると、いくつかの異なるコントローラが複数あることがわかりました。 1つのWebアプリに必要なコントローラーの数は？ 例がなければ答えるのは難しいと思いますので、例を示します。 応用： ユーザーがログインします。 ユーザーは、次の3つのいずれかを実行できます 。a ）ファイルをアップロードします（メタデータとともにmongodbデータベースに保存されます）。 b） ファイルを検索します。 c） ログアウトします。 私の質問は一般的な質問ですが、答えようとしている人を助けるために例を挙げました。

54 web-development  design-patterns  programming-practices  mvc 

時々、私が書いているコードの一部が、その名前が基本的にコメントとして繰り返されることを自明である（またはそうであるように思われる）状況に自分自身を見つけます： class Example { /// <summary> /// The location of the update. /// </summary> public Uri UpdateLocation { get; set; }; } （C＃の例ですが、質問は言語に依存しないようにしてください）。 そのようなコメントは無意味です。私は何を間違えていますか？間違っているのは名前の選択ですか？このような部分をより良くコメントするにはどうすればよいですか？このようなことに対するコメントをスキップする必要がありますか？

54 programming-practices  documentation  language-agnostic 

私が働いている場所では、このようなことをするクラスがたくさんあります。 public class ClassThatCallsItsOwnGettersAndSetters { private String field; public String getField() { return field; } public void setField(String field) { this.field = field; } public void methodWithLogic() { setField("value"); //do stuff String localField = getField(); //do stuff with "localField" } } これを最初から書いた場合methodWithLogic()、代わりに次のように書いたでしょう。 public class ClassThatUsesItsOwnFields { private String field; public …

53 java  object-oriented  programming-practices 

プロジェクトがあります。このプロジェクトでは、機能を追加するためにリファクタリングしたいと考え、機能を追加するためにプロジェクトをリファクタリングしました。 問題は、作業を終えたときに、それに対応するためにインターフェイスを少し変更する必要があることが判明したことです。だから私は変更を加えました。そして、新しいクラスの観点から、現在のインターフェイスでは消費クラスを実装できないため、新しいインターフェイスも必要です。今では3か月後に、無数の事実上無関係な問題を修正する必要があり、1年前にロードマップされた問題、または問題がコンパイルされる前に修正できないと単純にリストされている問題の解決を検討しています再び。 この種のカスケードリファクタリングを今後回避するにはどうすればよいですか？これは、以前のクラスが互いに緊密に依存しすぎているという単なる症状ですか？ 簡単な編集：この場合、リファクタリングは機能でした。これは、リファクタリングにより特定のコードの拡張性が向上し、一部の結合が減少したためです。これは、外部の開発者がより多くのことができることを意味し、それが私が提供したかった機能でした。したがって、元のリファクタリング自体は機能的な変更ではないはずです。 5日前に約束したより大きな編集： このリファクタリングを開始する前に、インターフェイスのあるシステムがありましたが、実装では、dynamic_cast出荷したすべての可能な実装を単純に確認しました。これは明らかに、インターフェイスから継承することはできなかったことを意味し、第2に、このインターフェイスを実装するための実装アクセス権を持たない人は不可能であることを意味しました。だから私はこの問題を修正し、誰でもそれを実装できるようにインターフェースを公開し、誰でもそれを実装できるようにし、インターフェースの実装が必要な契約全体であると判断しました。 私がこれをしたすべての場所を見つけて火で殺そうとしていたとき、特定の問題であることが判明した場所を1つ見つけました。それは、さまざまな派生クラスのすべての実装の詳細と、すでに実装されているが他のどこかより優れた複製機能に依存していました。代わりにパブリックインターフェイスの観点から実装し、その機能の既存の実装を再利用することもできます。正しく機能するには特定のコンテキストが必要であることを発見しました。おおまかに言って、呼び出し元の以前の実装はちょっと似ていました for(auto&& a : as) { f(a); } ただし、このコンテキストを取得するには、次のようなものに変更する必要がありました std::vector<Context> contexts; for(auto&& a : as) contexts.push_back(g(a)); do_thing_now_we_have_contexts(); for(auto&& con : contexts) f(con); これは、以前はの一部であったすべての操作についてf、一部はgコンテキストなしで動作する新しい関数の一部にする必要があり、一部は現在の遅延の一部で行う必要があることを意味しますf。しかし、すべてのメソッドf呼び出しがこのコンテキストを必要とするわけでも、必要とするわけでもありません。一部のメソッドは、別個の手段で取得する別個のコンテキストを必要とします。そのため、最終的にf呼び出しを行うすべて（大まかに言えば、ほぼすべて）について、必要なコンテキスト（ある場合）、取得元、および古いものからf新しいものへの分割方法を決定する必要がfありましたg。 そして、それが私が今いるところに行き着いた方法です。とにかく他の理由でこのリファクタリングが必要だったからです。

52 design  programming-practices  refactoring  coupling