ソフトウェア工学

ソースフォルダー階層に関してはsrc、コンテンツがわかりやすい、docまたはtestフォルダーなどの一般的な機能が常にいくつかあります。 しかし、大きなプロジェクトにはa libとvendorフォルダーの両方があることに気づきましたが、名前は「libraries外部からのサードパーティ」を含めることを示唆しているため、常に同じだと思っていましたvendors。ただし、同じプロジェクトで両方を見ることは、違いがあることを意味します。 これは実際には何らかの形で一般的な慣行であるにもかかわらず、GoogleやFilesystem Hierarchy Standardなどのソースに関する情報を見つけることができませんでした。 Symfonyのより詳細な例を次に示します。プロジェクトを作成すると、プロジェクトlibのルートにフォルダーが作成されます。このフォルダーには、次の構造があります。 lib +--filter +--form +--… +--vendor +--simpletest +--symfony ここでは、symfonyフォルダーにはすべてのSymfonyのコアが含まれています。

103 directory-structure 

私は3人の開発者と1人のデザイナーのチームで働くWeb開発者です。アジャイルスクラムソフトウェア開発方法論を実装したのは、約5か月です。しかし、私はこのサイトで共有したかっただけの奇妙な気持ちを持っています。 人間の生活における重要な要素の1つは、意思決定プロセスです。ただし、意思決定には大きな違いがあります。一部の決定は内部または外部の力の結果にすぎませんが、他の決定は完全にあなたの自由意志に基づいており、一部の決定は単なる中間的なものです。意思決定の自由度が高いほど、仕事はより自己主導的になります。これがルールのようです。私たちは自分自身の人生を形作る傾向があるからです。 あなたが何をするかを決めるか、何をするかを言われるかには大きな違いがあります。 スクラムの前に、開発、分析、実装の優先順位付けなどに関連する決定をより自由に行えるようになりました。自分がやっていることを決定しているように感じました。 ただし、スクラム方法論により、多くの決定は製品所有者から単純に下されます。彼はPBIを優先し、ソフトウェアがどのように動作するか、時にはUIと機能をどのように実装するかを分析します。これはスクラム方法論の一部であることを知っています。また、これにより将来的に製品の売り上げが向上する可能性があることも知っています。しかし、私は今、何かをすることを決心するのではなく、常に何かをするように言われているように感じています。この症候群により、私は仕事に対してより受動的になりました。 より良いソリューション、アプローチ、またはテクニックを見つけるために、検索回数を減らす傾向がある 楽しい仕事ができると期待して朝目が覚めない。むしろ、生きるために働くことを余儀なくされるような気がします 仕事の後、自分の趣味のプロジェクトに取り組みたいと思っています より高い技術レベルに到達するためにチームをプッシュすることはもうありません 夕食やお茶の時間に今より多くの時間を費やしているので、仕事に戻る意欲があまりない 私は家に帰ることができるように、仕事をもっと早く終わらせたいと思っています 大きな問題は、同僚でもこの動作を確認して診断することです。それはスクラムの結果ですか？スクラムは、開発チームに、ソフトウェア全体の形成に関与していないように感じさせ、プロジェクトを受動的にさせますか？どうすればこの気持ちを克服できますか？

103 agile  self-improvement  scrum 

知りたいのですが、空き時間にプログラムすることはどれくらい重要ですか？あなたの9-5をプログラマーとして働いてから、家に帰って趣味に取り組み、より良いプログラマーになる必要がありますか？ これは、あなたがプログラミングでプログラミングを上手に行えることを知っています。 将来の雇用主は、インタビューで趣味のプログラミングを考慮しますか、それとも好奇心からこれを求めますか？ 私は趣味のプロジェクトを持っていないことに対して罪悪感を覚えますが、私ができると思うことはすべてすでに終わっています。だから、私はこれについて2つの心で、すでに行われたものを始めるか、私がオリジナルのものを思い付くまでそれを残すのですか？

103 skills 

自動化されたテストの価値を理解し、問題が十分に特定されていて、良いテストケースを思いつくことができる場所ならどこでもそれを使用します。ただし、こことStackOverflowの一部の人々は、依存関係ではなくユニットのみをテストすることを強調していることに気付きました。ここでは、利益が見られません。 テストの依存関係を回避するためのモッキング/スタブ化は、テストを複雑にします。実稼働コードに人為的な柔軟性/デカップリング要件を追加して、モックをサポートします。（これは良いデザインを促進すると言う人には賛成できません。余分なコードを書いたり、依存性注入フレームワークのようなものを導入したり、コードベースに複雑さを加えて実際のユースケースなしで物事をより柔軟/プラグ可能/拡張可能/分離することは、オーバーエンジニアリングではなく、良いデザイン。） 第二に、依存関係のテストとは、どこでも使用される重要な低レベルコードが、テストを明示的に考えた人以外の入力でテストされることを意味します。依存する低レベルの機能をモックアウトせずに、高レベルの機能で単体テストを実行することで、低レベルの機能に多くのバグを発見しました。理想的には、これらは低レベル機能の単体テストで発見されたはずですが、見逃されたケースは常に発生します。 これの反対側は何ですか？単体テストが依存関係もテストしないことは本当に重要ですか？もしそうなら、なぜですか？ 編集：データベース、ネットワーク、Webサービスなどの外部依存関係のモックの価値を理解できます（これを明確にする動機付けをしてくれたAnna Learに感謝します）。内部依存関係、つまり他のクラス、静的関数などに言及していました。直接的な外部依存関係はありません。

103 testing  unit-testing  dependency-injection  mocking 

ソフトウェアエンジニアとプログラマーの主な違いは何ですか？

103 skills 

反復的なタスクを避け、より安全に使用できる抽象化を構築するために、多くのメタプログラミングを採用しています。 私は最近、より大きなチームで働いている新しい仕事に移りました。これは私の同僚の何人かを心配します。彼らはそれを理解していないからです。 私は常に言語の可能性をフルに活用しようとしますが、同僚の一部（すべてではない）がそれをリスクとして認識しています（一部はアプローチを歓迎します）。 チームの他の誰も理解できないコードを書くことは問題だと思います。一方、私たちはすべてプロのC ++開発者であり、クラスでCを書くよりも高い標準を目指すべきだと思います。 私の質問は、誰が正しいのか、私は何をすべきですか？ 明確化： 言語の可能性を最大限に活用しようとしても、すべての問題にTMPを投げるわけではありません。C ++はツールボックスであり、私にとってC ++の習熟度とは、ボックスのすべてのツールを使用できることと、特定のジョブに適したツールを選択することです。

102 c++  meta-programming 

私は約1年間仕事で働いています。私は主にCバックエンドのメソッドを使用するGUIインターフェースで作業しますが、通常は戻り値を除いてそれらを処理する必要はありません。私たちのGUIは、制限があるため、かなり合理的に構成されています。 私は、プログラムのコマンドライン部分に関数を追加する仕事をしました。これらの関数のほとんどは、長さが300行で使いにくいものです。特定のアラーム情報を取得するためにそれらの断片を収集しようとしていますが、整理するのに苦労しています。単一の長い関数でテストを行うことで、テストをより複雑にしていることを知っています。 既存の機能のスタイルに従って、すべてを巨大な機能に保持する必要がありますか、それともアラームを独自の機能にカプセル化する必要がありますか？ 現在のコーディング規約に反するのが適切かどうか、または単に弾丸を噛んでコードを少し混乱させて書くべきかどうかはわかりません。 要約すると、私は比較しています showAlarms(){ // tons of code } に対して showAlarms(){ alarm1(); alarm2(); return; } alarm1(){ ... printf(...); return; } 編集：みんなのアドバイスのおかげで、ファクタリングされたコードを設計し、彼らが何をしたいのかを尋ねることに決めました、そして彼らがそれをすべて1つにしたいなら、ファクタリングされたコードから切り取って1に戻すことができます大きな機能。これにより、すべてのコードを単一の定義で必要とする場合でも、簡単に記述してテストできるようになります。 更新：彼らはファクタリングされたコードに満足しており、複数の人がこの前例を設定してくれたことに感謝しています。

102 coding-style  conventions 

私は常に仕事で厳密にDRYの原則に従うようにしています。怠inessな状態からコードを繰り返すたびに、後でそのコードを2か所で維持する必要が生じたときに戻ってしまいます。 しかし、多くの場合、互いに参照できない 2つのプロジェクトで再利用する必要がある小さなメソッド（10〜15行のコード）を記述します。この方法は、ネットワーク/文字列/ MVVMなどに関連するものである可能性があり、元々のプロジェクトに固有ではない一般的に有用な方法です。 このコードを再利用する標準的な方法は、再利用可能なコード用に独立したプロジェクトを作成し、必要なときにそのプロジェクトを参照することです。これに伴う問題は、2つの理想的ではないシナリオのいずれかになってしまうことです。 最終的に、数十/数百の小さなプロジェクトになります-それぞれが再利用する必要のある小さなクラス/メソッドを収容します。.DLLほんの少しのコードだけでまったく新しいものを作成する価値はありますか？ 関係のないメソッドとクラスのコレクションが増え続ける1つのプロジェクトになります。このアプローチは、私が以前働いていた会社がやったことです。彼らには、base.common前述のようなネットワーク、文字列操作、MVVMなどのフォルダーを持つプロジェクトがありました。それは信じられないほど便利でしたが、不要なすべての無関係なコードを不必要にドラッグして参照しました。 だから私の質問は： ソフトウェアチームは、プロジェクト間で少量のコードを再利用するのに最適な方法を教えてください。 特に、この分野でポリシーを持っている会社で働いている人や、私のように個人的にこのジレンマに直面している人に興味があります。 注：「プロジェクト」、「ソリューション」、および「参照」という言葉の私の使用は、Visual Studioでの.NET開発の背景から来ています。しかし、この問題は言語とプラットフォームに依存しないと確信しています。

102 project-management  code-reuse  projects-and-solutions  dry 

ほとんどのインタビューの質問は、候補者の現在の知識に焦点を当てているか、アルゴリズムの問​​題を解決するために彼/彼女のスキルをチェックしていますが、プログラミングに情熱のある開発者を雇いたいと思います。 次のような質問をする代わりに テクノロジー「X」について何を知っていますか？ ソフトウェアエンジニアリングの問題の解決に直接関係しない知識をチェックしますが、ITに興味があることを示します。 たとえば、Java開発者を探している場合、Javaの世界で最も影響力のある人を尋ねたり、基本的なScalaスニペットを見せて候補者にコードの解釈を依頼したりできます。 アラン・チューリングの写真を見せて、インタビューした人に写真に写っている人を推測させることさえ考えました。この練習は意味がありますか？

102 interview 

最近のバグ修正では、他のチームメンバーによって記述されたコードを調べる必要がありましたが、そこで見つけました（C＃です）。 return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0; さて、これらすべてのキャストに正当な理由があるので、これを理解するのは非常に難しいようです。計算に小さなバグがあり、問題を解決するためにそれを解く必要がありました。 私はこの人のコーディングスタイルをコードレビューから知っていますが、彼のアプローチは、短い方が常に良いということです。そしてもちろん、そこには価値があります。私たちはすべて、適切に配置されたいくつかの演算子で整理できる条件ロジックの不必要に複雑なチェーンを見てきました。しかし、彼は明らかに、私よりも単一のステートメントに詰め込まれた一連の演算子に精通しています。 もちろん、これは最終的にはスタイルの問題です。しかし、コードを簡潔にするための努力が役に立たなくなり、理解の障壁となる点を認識することに関して何か書いたり、研究したりしましたか？ キャストの理由はEntity Frameworkです。データベースはこれらをnull許容型として保存する必要があります。小数？C＃のDecimalとは異なり、キャストする必要があります。

102 c#  coding-style  code-quality  clean-code 

私のキャリアの過程で、一部の開発者はデバッグツールを使用しないことに気付きましたが、問題が何であるかを把握するために誤ったコードをチェックします。 多くの場合、デバッガーなしでコード内のエラーをすばやく見つけることができるのは良いスキルですが、デバッガーがタイプミスなどの小さな間違いを簡単に見つける場合、問題を探すのに多くの時間を費やすことは生産性が低いようです。 デバッガなしで複合システムを管理することは可能ですか？お勧めですか？「サイキックデバッギング」を使用することで得られるメリットは何ですか？

101 debugging 

「車輪の再発明」アンチパターンは非常に一般的なものです-すぐに使えるソリューションを使用する代わりに、独自にゼロから作成してください。コードベースは不必要に成長し、同じことをするわずかに異なるインターフェースがわずかに異なりますが、わずかに異なりますが、すぐに利用できる関数を書く（そしてデバッグする）時間は無駄になります。私たちは皆これを知っています。 しかし、スペクトルの反対側に何かがあります。2行のコードである独自の関数を作成する代わりに、フレームワーク/ API /ライブラリをインポートし、インスタンス化し、構成し、フレームワークで受け入れられるようにコンテキストをデータ型に変換し、必要なことを正確に行う1つの関数を呼び出します。ギガバイトの抽象化レイヤーの下の2行のビジネスロジック。そして、ライブラリを最新の状態に保ち、ビルドの依存関係を管理し、ライセンスの同期を維持する必要があります。また、インスタンス化のコードは、「車輪を再発明」した場合よりも10倍長く複雑です。 理由はさまざまです：コストに関係なく「車輪の再発明」に厳密に反対する経営陣、要件とわずかに重複しているにも関わらず、彼らの好みの技術を押している人まだ到着していないフレームワークの使用、またはいくつかのインポート/インクルード/ロード命令が「舞台裏」で伝える「重み」を誤解している。 この種のアンチパターンに共通の名前はありますか？ （それが正しいか間違っているか、それが本当のアンチパターンまたは意見に基づいたものである場合、私は議論を始めようとはしていません。これは単純で客観的な命名法の質問です。） 編集：提案された「重複」は、外部システムとは完全に離れて、「すべての準備を整える」ために独自のコードをオーバーエンジニアリングすることについて語っています。このことはある場合にはそれから生じるかもしれませんが、一般的には「車輪の再発明への嫌悪感」に由来します。問題に対する「既製の」解決策が存在する場合、それがどの程度適合しておらず、どのような費用がかかっても、それを使用します。新しいコードの作成とメンテナンスのコストと比較した場合、これらの依存関係の統合とメンテナンスのコストを完全に無視して、コードの重複よりも新しい依存関係の作成を独断的に支持します。

101 naming  anti-patterns 

オープンソースフレームワークのソースコードを調べていたところ、変数「ペイロード」が何度も言及されていました。「ペイロード」が表すアイデアはありますか？

101 terminology  variables 

現時点では、Webページが最初にロードされるときにデータベース接続を作成します。次に、ページを処理し、その接続に対してクエリを実行します。これが最善の方法ですか、クエリを実行するたびにデータベース接続を作成する必要がありますか？ ps 1つの接続を作成して使用する方が理にかなっていますが、これが他の問題を引き起こす可能性があるかどうかはわかりません。 MSSQLでC＃（ASP.NET）を使用しています。

101 c#  database  sql-server 

CおよびC ++コードでは、次の規則がよく見られます。 some_type val; val = something; some_type *ptr = NULL; ptr = &something_else; の代わりに some_type val = something; some_type *ptr = &something_else; 最初は、これはスコープの最上部ですべてのローカル変数を宣言しなければならなかった時代から残された習慣だと思っていました。しかし、私はベテラン開発者の習慣をすぐに却下しないことを学びました。だから、1行で宣言し、その後に割り当てる理由はありますか？

101 c++  c