ソフトウェア工学

再帰の考え方は、現実の世界ではあまり一般的ではありません。そのため、初心者のプログラマにとっては少し混乱するようです。とはいえ、彼らは徐々にコンセプトに慣れてくると思います。だから、彼らがアイデアを簡単に把握するための良い説明は何ですか？

74 recursion 

チームが（驚くほど！）正常に動作しているソフトウェアシステムを作成するとします。 ある日、エンジニアの1人が、DBデータの一部を変更するいくつかのSQLクエリを誤って実行し、それを忘れてしまいました。 しばらくして、破損した/誤ったデータを発見し、誰もがコードのどの部分がこれを引き起こしたのか、なぜそうなったのかについて頭を掻きます。一方、プロジェクトマネージャーは、それを引き起こしたコードの一部を見つけると主張しています。 これにどう対処しますか？

73 project-management 

条件チェックなどの除算が必要なときはいつでも、除算の式を乗算にリファクタリングしたいと思います。たとえば： 元のバージョン： if(newValue / oldValue >= SOME_CONSTANT) 新しいバージョン： if(newValue >= oldValue * SOME_CONSTANT) 回避できると思うから： ゼロ除算 オーバーフローoldValueが非常に小さい場合 そうですか？この習慣に問題はありますか？

73 coding-style  language-agnostic  math 

私のコードベースでよく使用する方法の1つは、つづりが間違っています（そしてそれは私よりも前のものです）。 これは単にスペルが間違っているだけでなく、もっと重要なことですが、最初にタイプするときに常に名前を間違えます（そして、「ああ、そうです、これにスペルを間違えるべきです...」） 元の方法を中心にいくつかの変更を行っています。機会を利用して、単におかしな方法の名前を変更する必要がありますか？

73 refactoring 

if i>0 : return sqrt(i) elif i==0: return 0 else : return 1j * sqrt(-i) VS if i>0: return sqrt(i) elif i==0: return 0 else: return 1j * sqrt(-i) 上記の例を考えると、コードベースに最初のスタイルがほとんど見られない理由がわかりません。私には、コードを表形式に変換して、必要なものを明確に示します。最初の列は事実上無視できます。2列目は状態を示し、3列目は必要な出力を示します。少なくとも私には、簡単で読みやすいようです。それでも、この単純なケース/スイッチの状況は、拡張されたタブインデント形式で常に表示されます。何故ですか？人々は2番目の形式をより読みやすいと感じていますか？ これが問題になる唯一のケースは、コードが変更されて長くなる場合です。その場合、コードを長いインデントされた形式にリファクタリングすることは完全に合理的だと思います。いつもそれがいつも行われていた方法だからという理由だけで、誰もが2番目の方法でそれをしますか？悪魔の擁護者である私は、if / elseステートメントの複雑さに応じて2つの異なる形式を見つけて混乱する別の理由があると思いますか？どんな洞察もいただければ幸いです。

73 coding-style 

未来と約束の違いは何ですか？（AkkaとGparsで。） 彼らはブロックと同じように見えますが、getが呼び出され、将来の結果を取得することが約束されているときに未来の値を返します。

73 api  scala  groovy  akka 

次のような3つのリソースがあるとします。 Grandparent (collection) -> Parent (collection) -> and Child (collection) 上記は、これらのリソース間の関係を示しています。各祖父母は、1つまたは複数の親にマップできます。各親は、1つまたは複数の子にマップできます。子リソースに対する検索をサポートする機能が必要ですが、フィルター条件があります。 クライアントが祖父母へのID参照を渡した場合、その祖父母の直接の子孫である子供に対してのみ検索したいです。 クライアントが親へのID参照を渡した場合、親の直接の子孫である子に対してのみ検索したいです。 私はそのようなことを考えました： GET /myservice/api/v1/grandparents/{grandparentID}/parents/children?search={text} そして GET /myservice/api/v1/parents/{parentID}/children?search={text} 上記の要件に対して、それぞれ。 しかし、私はこのようなこともできます： GET /myservice/api/v1/children?search={text}&grandparentID={id}&parentID=${id} この設計では、クライアントにクエリ文字列のいずれかを渡すことができます：grandparentIDまたはparentIDのいずれかで、両方ではありません。 私の質問は： 1）どのAPI設計がよりRESTfulであり、その理由は何ですか？意味的には、同じ意味であり、同じように動作します。URIの最後のリソースは「子」であり、事実上、クライアントが子リソースを操作していることを意味します。 2）クライアントの観点からの理解可能性、およびデザイナーの観点からの保守性という点で、それぞれの長所と短所は何ですか。 3）リソースの「フィルタリング」以外に、実際に使用されるクエリ文字列は何ですか？最初の方法を使用する場合、フィルターパラメーターは、クエリ文字列パラメーターではなく、パスパラメーターとしてURI自体に埋め込まれます。 ありがとう！

73 design  rest  api 

コードコンプリートブック以下の引用が来ます： 「通常の場合は、後ではifなく後に入力しますelse」 つまり、標準パスからの例外/偏差をelseケースに入れる必要があります。 しかし、プラグマティックプログラマーは「早くクラッシュする」ことを教えています（p。120）。 どのルールに従うべきですか？

73 design 

シナリオ 現在、私はヘルスケアプロジェクトの一員であり、その主な要件は、ヘルスケアプロバイダーがユーザーが作成したフォームを使用して、未知の属性を持つデータをキャプチャすることです。2番目の要件は、データの整合性が重要であり、アプリケーションが40年以上使用されることです。現在、過去40年間のクライアントのデータをさまざまなソース（紙、Excel、Accessなど）からデータベースに移行しています。将来の要件は次のとおりです。 フォームのワークフロー管理 フォームのスケジュール管理 セキュリティ/ロールベースの管理 報告エンジン モバイル/タブレットのサポート 状況 わずか6か月で、現在の（契約している）アーキテクト/シニアプログラマーが「高速」アプローチを採用し、貧弱なシステムを設計しました。データベースは正規化されず、コードは結合され、層には専用の目的がなく、データベースで「削除」を実行するようにいくつかのBeanを設計したため、データが失われ始めています。コードベースは非常に肥大化しており、データベースが正規化されていないため、データを同期するだけのジョブがあります。彼のアプローチは、欠落したデータを復元するためにバックアップジョブに依存することであり、リファクタリングを信じていないようです。 私の調査結果をPMに提出したので、建築家は契約が終了すると削除されます。このアプリケーションを再設計するタスクが与えられました。私のチームは私と1人のジュニアプログラマで構成されています。他のリソースはありません。このシステムの再構築に集中できる6か月の要件凍結が認められました。 DrupalのようなCMSシステムを使用することをお勧めしましたが、クライアントの組織のポリシー上の理由により、システムをゼロから構築する必要があります。 寿命が40を超えるシステムを設計するのはこれが初めてです。私は3〜5年の寿命を持つプロジェクトにしか取り組んでいません。そのため、この状況は非常に新しいものですが、刺激的です。 ご質問 どのような設計上の考慮事項が、システムをより「将来性のある」ものにしますか？ システムをより「将来の証拠」にするために、クライアント/ PMにどのような質問をする必要がありますか？

73 design  architecture  project-management  web-applications 

私はこの質問をするのは用心深いです。JavaScript：The Definitive Guideを開いたところ、第1章の最初のページの状態 「JavaScriptは、高レベルで動的な、型付けされていないインタープリタ型プログラミング言語です」 だから、解釈された部分は言語仕様の要件であると解釈するのですか、それとも言語とその多くの実装の違いを尊重するときに言語が解釈されるプログラミング言語であると言うのは誤解を招くのでしょうか？ JavaScriptのための静的コンパイラは明らかにありません- https://stackoverflow.com/questions/1118138/is-there-a-native-machine-code-compiler-for-javascriptので、多分それは、このだけの反射です。

73 javascript 

コードにセマンティクスを持たせないためにJavaで文字列を使用することを思いとどまらせるブログエントリを見つけました。代わりにシンラッパークラスを使用することをお勧めします。これは、このエントリが問題を説明するために提供する前後の例です。 public void bookTicket( String name, String firstName, String film, int count, String cinema); public void bookTicket( Name name, FirstName firstName, Film film, Count count, Cinema cinema); プログラミングブログを読んだ私の経験では、90％はナンセンスであるという結論に達しましたが、これが有効なポイントかどうか疑問に思っています。どういうわけか私には正しくないように感じますが、プログラミングのスタイルで何がおかしいのかを正確に特定することはできませんでした。

73 java  coding-style  semantics 

私は、ロバート・マーティンによる「クリーン・コード」を読んで、できればより良いプログラマーになることを望んでいます。これまでのところ、どれも本当に画期的なものではありませんでしたが、アプリケーションの設計とコードの記述方法について、私は違った考え方をしました。 本の一部には、同意しないだけでなく、特にインターフェースの命名規則に関して、私には意味がありません。これは、本から直接取ったテキストです。混乱を招くと思われるこの側面を太字で示し、説明を希望します。 私はインターフェースを装飾しないままにしておきたい。前のIは、今日のレガシーワッドで非常に一般的であるが、せいぜい気を散らすものであり、最悪の場合には情報が多すぎる。ユーザーにインターフェースを渡していることをユーザーに知らせたくない。 おそらく、私が学生だからか、プロやチームベースのプログラミングを一度もしたことがないからかもしれませんが、それがインターフェースであることをユーザーに知ってもらいたいからでしょう。 インターフェイスの実装とクラスの拡張には大きな違いがあります。 それで、私の質問は、「コードの一部がインターフェースを期待しているという事実を隠す必要があるのか​​？」に要約されます。 編集 回答に応じて： タイプがインターフェースである場合、またはクラスがあなたのビジネスであり、コードを使用している誰かのビジネスではない場合。したがって、このサードパーティのコードでコードの詳細を漏らさないでください。 特定の型がインターフェイスであるか、サードパーティのコードのクラスであるかの詳細を「漏洩」しないのはなぜですか？サードパーティの開発者がコードを使用して、インターフェイスを実装するのか、クラスを拡張するのかを知ることは重要ではありませんか？違いは、私が自分の頭に浮かぶほど重要ではありませんか？

73 naming  interfaces  coding-standards 

読みやすくするために、次のコードのような関数を呼び出すときに一時変数を定義することがよくあります var preventUndo = true; doSomething(preventUndo); これに対するこれの短いバージョンは、 doSomething(true); しかし、コードに戻ったとき、私はしばしば何をtrue指しているのだろうと思います。この種の難問に慣習はありますか？

73 coding-style 

私は、困難な状況を解決するのに役立つ専門のプログラマを探しています。 これまでのインタビューは驚くほど残念でした。これまでの最良の候補者は、バージョン管理ソフトウェアを使用したことがない経験豊富なプログラマーです。 問題自体はそれほど深刻ではないかもしれません。なぜなら、それは短時間で学習できるものだからです。 しかし、より深い側面があり、私を心配しています： バージョン管理を必要とせずに10〜15年間、積極的にソフトウェアを開発する方法を教えてください。 追跡の問題の解決策を探していないという事実自体が、プログラミングに対する間違った態度の兆候を変えていますか？

73 version-control  experience 

アジャイルアプローチは、要件があいまいで、エンドユーザーのアイデアを形作るのに多くの相互作用が必要なプロジェクトに最適だと思います。 しかし...私の専門的な仕事では、「アジャイル」アプローチが前もってデザインに労力が費やされなかった理由の言い訳として使われている会社に行き着きます。要件が十分に理解されている場合。 アジャイルなアプローチがなかったら、いいハイレベルな仕様でここに座っていて、何か他のものができあがったときでも同じ画面と機能を二度と再訪する必要はないだろうと考えずにはいられませんそんなことは考えていませんでした。 アジャイル手法の利点は、カウボーイの技術的なリードに足りないという言い訳を上回るのに本当に十分なのでしょうか？ 更新：皮肉なことに、私は認定スクラムマスターになりました。スクラムコースで発表された論文の1つは、最適な開発プロセスは、設計上の決定を下す単一の専門家または第一人者がいるが、明らかな弱点があるものであると述べました。スクラムは、品質の高いソフトウェアを作成する責任を「チーム」に移します。つまり、標準以下のチームは、他のアジャイル開発プロセスや非アジャイル開発プロセスと変わらないスパゲッティを排除できます。

73 agile  cowboy-coding