ソフトウェア工学

私は多くのRobert C. Martinのコンテンツを読んだり見たりしています。私は、ソリッドステートドライブのためにSQLが不要であると言ってきました。これをバックアップするために他のソースを検索すると、ハードドライブとソリッドステートドライブのSQLパフォーマンスの違いを説明するランダムな記事がたくさんあります（これは関連していますが、研究しようとしているものではありません）。 最終的に、私は彼が何を得ようとしているのか理解できません。彼はSQLをNo-SQLテクノロジーに置き換えると言っていますか？彼はファイルシステムのファイルにデータを保存すると言っていますか？それとも、SQLi攻撃のために、人々にSQL /リレーショナルデータベースの使用をやめさせたいのでしょうか？彼がやろうとしているポイントを逃しているのではないかと心配しています。 あなたが彼の心から直接読むことができるように、ここにいくつかのリンクを提供します： ボビーテーブル クリーン建築レクチャー まず、SQLをシステムから完全に削除する必要があると述べています。 ソリューション。唯一の解決策。システムからSQLを完全に削除することです。SQLエンジンがない場合、SQLi攻撃はありません。 また、彼はSQLをAPIに置き換えることについて語っていますが、その前の引用と彼が記事の前半で述べていることから、SQLをAPIの背後に置くことを意味するとは思いません。 フレームワークは問題を処理しません; ... サイドノート：SQLと言って、Robertはほとんどのリレーショナルデータベースを意味すると確信しています。すべてではないかもしれませんが、ほとんどです。いずれにせよ、ほとんどの人はとにかくSQLを使用しています。そう... データの永続化にSQLが使用されていない場合、何を使用することになりますか？ それに答える前に、私も注意する必要があります。ロバートは、ソリッドステートドライブがデータの永続化に使用するツールを変更する必要があることを強調しています。SørenD.Ptæusの答えはこれを指摘しています。 また、「データ整合性」グループに対応する必要があります。さらなる調査の結果、ロバートは、datomicなどのトランザクションデータベースを使用する必要があると述べています。その後、CRUDはCR（作成および読み取り）に変わり、SQLトランザクションは完全になくなります。データの整合性はもちろん重要です。 このすべてを網羅する質問は見つかりません。私はロバートのガイドラインに一致する代替案を探していると思います。Datomicは1つですが、それですか？これらのガイドラインに適合する他のオプションは何ですか？また、ソリッドステートドライブで実際に機能しますか？

45 architecture  enterprise-architecture  architectural-patterns  plugin-architecture 

ボブおじさんのきれいなコードの提案に従い、特にメソッドを短くするようにしています。 ただし、このロジックを短縮することはできません。 if (checkCondition()) {addAlert(1);} else if (checkCondition2()) {addAlert(2);} else if (checkCondition3()) {addAlert(3);} else if (checkCondition4()) {addAlert(4);} 私はelseを削除することができないため、全体を小さなビットに分割し、「else if」の「else」を使用するとパフォーマンスが向上します本当です、私はそれらを避けたいです。 意味的に言えば、前の条件が満たされた場合に次の条件を評価することは、ビジネスの観点からは意味がありません。 編集：この質問は、if（if else）elseを処理するエレガントな方法の可能な重複として識別されました。 これは別の質問だと思います（これらの質問の回答を比較することでも確認できます）。 私の質問は、すぐに終わる最初の受け入れ条件をチェックしています。 リンクされた質問は、何かをするためにすべての条件を受け入れようとしている。（この質問に対するこの回答でよく見られます：https : //softwareengineering.stackexchange.com/a/122625/96955）

45 clean-code  conditions 

新しいプロジェクトをゼロから始めています。約8人の開発者、1ダースほどのサブシステム、それぞれ4つまたは5つのソースファイル。 「ヘッダー地獄」、別名「スパゲッティヘッダー」を防ぐために何ができますか？ ソースファイルごとに1つのヘッダーですか？ サブシステムごとにプラス？ 関数プロトタイプからtypdef、stucts、enumを分離しますか？ サブシステムの内部をサブシステムの外部のものから分離しますか？ ヘッダーまたはソースがスタンドアロンコンパイル可能である必要があるかどうかにかかわらず、すべての単一ファイルを主張しますか？ 私は「最善の」方法を求めているのではなく、何に気を付け、悲しみを引き起こす可能性があるのか​​を示し、それを回避しようとすることができます。 これはC ++プロジェクトになりますが、C情報は将来の読者に役立つでしょう。

45 c++  headers  include 

同じソフトウェア/プログラム/アプリ/スクリプトの2つの異なるバージョンを作成し、バージョン管理下に保存しているとしましょう。最初のバージョンは無料の「ベーシック」バージョンで、2番目は有料バージョンの「プレミアム」バージョンで、無料バージョンのコードベースを取得し、いくつかの付加価値機能で拡張します。新しいパッチ、修正、または機能は、両方のバージョンへの道を見つける必要があります。 現在、有料版のサイドとブランチに沿って、メインコードベース（無料版）のブランチを使用することmasterを検討していdevelopます。無料版に変更が加えられ、ブランチにマージされると（もちろん徹底的なテストの後）、さらにテストするためにコマンドを介してブランチにコピーされ、にマージされます。master-premiumdevelop-premiummasterdevelopdevelop-premiumcherry-pickmaster-premium これは、この状況を処理するのに最適なワークフローですか？認識すべき潜在的な問題、警告、または落とし穴はありますか？私がすでに思いついたものよりも良い分岐戦略がありますか？ あなたのフィードバックは大歓迎です！ PSこれはGitに保存されているPHPスクリプト用ですが、回答はすべての言語またはVCSに適用する必要があります。

45 version-control  workflows 

Webサイトのサーバー側開発には、あらゆる汎用プログラミング言語を使用できることを理解しています。 サーバーとプログラミング言語を連携させるために、サーバーにはCGIなどのインターフェイスが必要だと思いますか？もしそうなら、なぜいくつかのプログラミング言語（phpなど）が他の言語よりも人気があるのですか？

45 programming-languages  web-development  web 

私は、暗号化を使用して、ユーザーがプログラム自体の外にある私のプログラムのコンテンツを理解できないようにするという考えを持っています。ユーザーのように、ゲームのデータを調べながら、ゲームで決して使用されていないテクスチャが、ある種のイースターエッグの一部であることに気付くかもしれません。これは、たとえば、オンラインで投稿された場​​合、全員を台無しにする可能性があります。 プレイヤーがゲーム内のセキュリティドアの正しい番号を押す必要がある秘密の部屋を想像してください。正しい番号が正しい場合は正しい解読キーを生成し、レベルのその部分を解読してドアを開けます。したがって、キーは実際には保存されないため、ゲームデータを調べてもイースターエッグにアクセスできなくなります。これは、ユーザー入力に基づいて生成されます。 ここに私が想像していたものの別の例があります。20のレベルのパズルゲームがあり、それぞれが異なるキーを使用して暗号化されています。解読キーをプログラムに保存して、誰かがプログラムを逆コンパイルして見つけられるようにする代わりに、前のパズルの解に基づいて暗号化/解読キーを生成します。この方法では、ゲームデータを見ても、プレーヤーは次のレベルに関する情報を取得する前にパズルを実際に把握する必要があります。 プレーヤーは、知識があれば、パズルソリューションの数がおそらく復号化キーの数より少ないことを考えると、「簡単に」ブルートフォースすることができます。それは本当にパズルの問題の複雑さであり、ここではあまり重要ではありません。私はそれに関する答えをここに投稿しましたが 今日、このようなことをしたプログラム/ゲームはありますか？暗号化されたコンテンツをゲームに保存しますか？そして、もしそうでなければ、なぜですか？店舗または国レベルで、それに関する多くの規則と規制がありますか？誰かが私が見落としている明らかな落とし穴を見ていますか？ユーザーエクスペリエンスのようなものを無視すると、このアイデアは私には聞こえるかもしれませんが、なぜこれを見たことがないのか興味があります。 編集：私が言っていることは正確には明確ではないかもしれないので、ここでより具体的な例を示します。 20文字の文字列を受け取り、ゲーム内の一部のコンテンツを暗号化/復号化するために使用できる対称キーを生成する関数があるとします。ユーザーがそのコンテンツにアクセスできる唯一の方法は、これらの20文字を知って同じキーを生成することです。このキーは直接保存されることはなく、ユーザーの入力に基づいてその場で生成されます。これらのキャラクターは、本やNPCとの対話など、ゲームの外に隠されていたり、ゲームの外でも箱の後ろに隠れていることがあります。 そのため、2 * 10 ^ 28通りの組み合わせを試してみると、ゲームデータを調べるよりも、意図した方法でコンテンツを見つける可能性が高くなります。 編集2：問題のコンテンツは、消費者に出荷される前に、任意の秘密鍵で暗号化されます。このキーは明らかにゲームに同梱されません。キーに基づいて作成された一連の手がかりを考えると、彼または彼女は何らかの方法でキーを一緒に戻さなければならず、それはゲーム全体またはどこかで隠されています。ただし、実際にゲームデータを調べない限り、コンテンツが暗号化されていることがわからないため、このシステムはユーザーに対して透過的です。 多くの人が言及しているように、これにはユースケースが限られているという明らかな欠点があります。一人の人がそれを理解したら、彼/彼女はそれを他のすべての人と共有するかもしれません。しかし、あなたの意図が何かを秘密にして、一人で解決できないようにし、人々が協力して解決する必要がある場合、またはイースターエッグが非常によく隠れて（設計上）それが怖い場合誰かがゲームプレイを通してではなくコード内でそれを見つける可能性が高いです。その後、これはうまくいくと思います。 個人的には、ゲームごとに一度だけ、コアゲームプレイに影響を与えないもの、たとえばイースターエッグ、秘密の結末などにのみ使用することをお勧めします。コンテンツを暗号化するのに十分なほど人々を遅くするためには、パズルは非常に複雑であるか、十分に隠されている必要があります。

45 encryption 

Builderパターンを実装するとき、私はしばしば、ビルドを失敗させるタイミングに戸惑いを感じ、数日ごとにその問題について異なる立場を取ることさえできます。 最初にいくつかの説明： 初期の失敗私は、無効なパラメータが渡されるように、オブジェクトを構築するとすぐに失敗することを意味しています。だから、内側SomeObjectBuilder。 後半に失敗し、私は唯一のオブジェクトを構築する上で失敗する可能性があることを意味build()暗黙オブジェクトのコンストラクターを構築するために呼び出すコール。 次に、いくつかの引数： 失敗を遅らせるために：ビルダークラスは、単に値を保持するクラスにすぎないようにします。さらに、コードの重複が少なくなります。 早期の失敗を支持する：ソフトウェアプログラミングの一般的なアプローチは、できるだけ早く問題を検出することです。したがって、チェックする最も論理的な場所は、ビルダークラスのコンストラクター、「セッター」、最終的にはビルドメソッドです。 これについての一般的なコンセンサスは何ですか？

45 java  design-patterns 

では特効薬、フレッド・ブルックスは最高でまとめソフトウェア工学の将来に関する予測、さまざまなになります： 技術または管理技術のいずれにおいても、それ自体で生産性、信頼性、シンプルさの1桁の改善さえ約束する単一の開発はありません。 彼の議論は非常に説得力があります。ブルックスは1986年に書いていた：彼は正しかった？2014年の開発者は、1986年の開発者の10倍未満の速度でソフトウェアを生産しますか？いくつかの適切な指標で、生産性の向上は実際にどのくらいの大きさですか？

45 productivity 

私は視覚障害者です。メガネをかけると運転には十分ですが、フォントサイズでは快適に作業できますが、一度に表示できるのは100文字の15行のみです。これは私のコーディングスタイルに影響を与えました。 私がやっていることの1つは、短い関数を書くことです。私のコードは良い名前のこれらの短い関数がより高いレベルの関数を非常に読みやすくするので良いレビューを得る傾向がありますが、パフォーマンスの高い状況では一部の人々は変数をいくつかのレイヤーに渡してスタックに占めるスペースについてコメントします処理。 2番目に行うことは、クラスをファイル間で分割して短いファイルを作成することです。これにより、スクロール距離が短くなり、関連する機能に到達します。組織によっては、ファイルを別のモニターに配置して一緒に見ることができる場合があります。 これらのプラクティスはどちらも、ほとんどのコーディングスタイルでドキュメント化が必要なドキュメント化可能な単位になります。これにより、ファイルの長さと関連する関数間の距離が長くなり、問題がさらに悪化します。 現在Visual Studioを使用しています。VisualStudioでは、関数とコメントブロックレベル（頻繁に使用します）でコードを折りたたみますが、Notepad ++のようにブラケットレベルでは折りたたみません。優れたコード折りたたみを提供するエディターには、VSのすべてのインテリセンス機能がありません。VSでリージョンを使用することもできますが、10行ごとに使用すると、非常に煩雑になります。折り畳みは、コードの別の機能に取り組んでいるときに、完成したコードを見えなくするのに役立つことがあります。 誰もがコードの可視性を制限するのに役立つより良いコーディング方法を推奨できますか？

45 coding-style 

Common Lispでの開発を開始することには、実装の選択という差し迫った問題があるようです。CLの実装を検討するとき、何を考慮に入れる必要がありますか？ ANSI規格に準拠する必要がありますか？SLIMEでサポートされるべきですか？特定の実装には適切なライブラリ、ドキュメントなどが欠けていますか？

45 lisp  implementations  common-lisp 

私はカードゲームのJava実装を書いているので、ゾーンと呼ぶ特別なタイプのコレクションを作成しました。Javaのコレクションのすべての変更メソッドはサポートされていませんが、ゾーンAPIにmove(Zone, Card)は、指定されたゾーンからそれ自体にカードを移動するメソッドがあります（パッケージプライベートテクニックによって達成されます）。これにより、ゾーンからカードが取り出されず、単に消えることを保証できます。別のゾーンにのみ移動できます。 私の質問は、この種の防御コーディングはどのくらい必要ですか？それは「正しい」ことであり、正しい実践のように感じますが、Zone APIが公共図書館の一部になることは決してありません。それは私だけのためです。したがって、標準のコレクションを使用することでおそらくより効率的になる可能性があるときに、自分からコードを保護しているようなものです。 このゾーンのアイデアをどこまで取り入れるべきですか？誰でも私が書いているクラス、特に実際に公開されないものについては、契約を保存することについてどれだけ考えるべきかについてアドバイスをいただけますか？

45 java  programming-practices  data-structures  api-design 

多くの企業が「逆ドメイン名」の名前空間を使用していることに気づきました。そのプラクティスがどこから始まったのか、なぜ続くのか興味があります。それは単純な練習のために単に継続するのですか、それとも私がここで見逃しているかもしれない顕著なアーキテクチャの概念がありますか？ また、のような質問注意：https://stackoverflow.com/questions/189209/do-you-really-use-your-reverse-domain-for-package-naming-in-javaをその答えのようなもの、私の質問はありません100 ％ （気分が良くなったら、javascriptのネームスペース作業にそれを使用すべきかどうか本当に興味がありますが、その時と理由についてはもっと興味があります。 bene： "window"） フォルダーとファイルに拡張するこのプラクティスの例：

45 architecture  namespace 

卒業（2005年後半）以来、私はc ++ソフトウェアエンジニアと同じ会社で働いていました。1年前、私はソフトウェアアーキテクトとして昇進しましたが、資格の取得とバグの修正、レベル2サポートにますます関与するようになりました。 私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったのかを把握するために費やしました。30％が他のバグを修正し、残りの（存在する場合）開発者のスパゲッティコードをレビューします。 私はこの製品を嫌い、この会社の出口戦略について考え始めました。 この状況で私にできることは何だと思いますか？他のソフトウェアアーキテクトはまだコードのバグを修正していますか？

45 architecture  teamwork  software 

バックグラウンド Syntactic SugarのWikipediaページには次のように記載されています。 コンピューターサイエンスでは、構文シュガーは、読みやすく、表現しやすいように設計されたプログラミング言語内の構文です。これにより、人間が使用する言語が「より甘く」なります。物事をより明確に、より簡潔に、または一部の人が好む代替スタイルで表現できます。 私は、Syntactic SugarとSyntaxの違いが本当に理解できません。 私は、甘いバージョンがより明確で簡潔になり、おそらくいくつかの定型的なものがなくなる可能性があるという点に感謝します。しかし、ある程度のレベルでは、すべての構文が本質的にそれを行って、コードがコンパイルされるものを抽象化することを感じています。 同じウィキペディアのページから： コンパイラー、静的アナライザーなどを含む言語プロセッサーは、しばしば「デシュガー化」と呼ばれるプロセスの前に、シュガー化されたコンストラクトをより基本的なコンストラクトに拡張します。 思考演習として、このステートメントで「頻繁に」「常に」を意味する場合：コンパイラが次の段階に進む前に構文を「デシュガー」するかどうかだけでは、内臓を知らないコーダーはコンパイラの何がSugar'd Syntaxとは何かを知っている（または気にしている）？ このサイトに関する非常に関連した質問「構文糖の厳密な定義？」始まる答えがあります： 私見私はあなたがフレーズがBSであり、「本当のオペレーティングシステム」で「本当のツール」を使用して「本当のプログラマー」について話す人々によって使用される可能性が高いので、構文糖の定義を持つことができるとは思わない おそらく、この言語を使用しているコーダーに大きな違いはないことを私に示すかもしれません。おそらく、違いはコンパイラの作者にしか認識できないのでしょうか？言語を使用するコーダーがSyntactic Sugarの内部にあるものを知ることが役立つ場合がありますか？（しかし、実際には、主題に関するどんな言説でも、炎の餌としてこの用語を使用する傾向がありますか？） 質問の核心 だから...質問の短いバージョン： SyntaxとSyntactic Sugarの間に本当の違いはありますか？ 誰が重要ですか？ 思考のための余分な食べ物 トピックの矛盾に関するボーナス： ウィキペディアのページに例を示します。 たとえば、C言語では、a[i]表記法は*(a + i) 上記のリンクされた質問に関する別の答えは、同じ例について語っています： 考えてみてくださいa[i] == *(a + i)。実質的な方法で配列を使用するCプログラムについて考えてください。 そしてそれを要約します： []表記は、この抽象化を容易にします。構文糖衣ではありません。 同じ例の反対の結論！

45 terminology  compiler  syntax 

私は、ゲッターとセッターのメソッドとカプセル化に関する興味深いインターネットの議論に入りました。誰かがすべきことは、それらを「純粋」に保ち、カプセル化を確保するための割り当て（セッター）または変数アクセス（ゲッター）だけだと言いました。 これは、最初にゲッターとセッターを持つという目的を完全に無効にし、検証と他のロジック（もちろん、奇妙な副作用なし）を許可する必要があると思いますか？ 検証はいつ行われますか？ セッター内で値を設定するとき（オブジェクトが無効な状態になるのを防ぐため-私の意見） 値を設定する前、セッターの外側 オブジェクト内で、値が使用されるたびに セッターは値の変更を許可されていますか（有効な値を標準的な内部表現に変換する可能性があります）？

45 object-oriented  language-agnostic  encapsulation