ソフトウェア工学

最近、人気のPythonスタイルチェッカーであるpylintのバージョンをアップグレードしました。 コード全体で弾道的になり、完全なパッケージパスを指定せずに、同じパッケージ内のモジュールをインポートする場所を指摘しました。 新しいエラーメッセージはW0403です。 W0403：相対インポート％r、％rである必要があります パッケージディレクトリに関連するインポートが検出されたときに使用されます。 例 たとえば、私のパッケージが次のように構成されている場合： /cake /__init__.py /icing.py /sponge.py /drink そしてスポンジパッケージに私は書いています： import icing の代わりに import cake.icing このエラーが発生します。 すべてのPylintメッセージが同等に重要であるとは限らないことを理解しており、それらを却下することを恐れていませんが、そのような慣行が悪いアイデアと見なされる理由はわかりません。 私は誰かが落とし穴を説明できることを望んでいたので、この明らかに見せかけの警告をオフにするのではなく、コーディングスタイルを改善することができます（現在の予定です）。

89 coding-style  python 

私は、自分が存在するとは思わない問題を修正するコードをレビューするように頼まれた立場にいます。 私よりも上級のフィクサーは、彼の修正が必要であると主張しますが、それは私にとってはC ++のso弁にすぎないようです。展開プロセスの一部はコードレビューであり、小規模企業で2番目に高いエンジニアとして、変更をレビューすることが期待されています。 レビュー担当者は元のコーダーと同じようにコードの変更に責任があると思いますが、この変更の責任を受け入れるつもりはありません。このレビューを拒否するにはどうしますか？

89 code-reviews 

私のマネージャーは最近、生産性の目標と尺度として速度を使用することを本当に推し進めています。現在、平均速度50ストーリーポイントで作業しています。私のマネージャーは、ストーリーポイントを40％増やして70ストーリーポイントにすることを望んでいます（チームメンバーの増加はありません）。この増加が達成されない場合、彼はその理由を説明する完全な内訳を提供することを望んでいます。 チームのパフォーマンスを速度で測定し、それをターゲットとして使用するという考え全体は間違っているように思えますが、その理由を説明するのは難しいと感じています。助けがありますか？なぜ生産性を測定し、インセンティブを与えるのにこれが適切な方法ではないのですか？

89 agile  scrum 

CマスターのDennis RitchieがCにポインターを導入したのはなぜですか？そして、なぜVB.NETやJavaやC＃などの他のプログラミング言語がそれらを排除したのですか？Googleでいくつかのポイントを見つけました。あなたのコメントも聞きたいです。なぜ現代の言語でポインターの概念を排除するのですか？ Cは基本的な言語であり、ポインターはCを強力で際立ったものにし、Cをより現代的な言語と競争させる概念であると人々は言います。それから、なぜ彼らはより近代的な言語のポインターを排除したのですか？ 新しいプログラマーにとって、ポインターの知識はまだ重要だと思いますか？最近人々はVB.NETまたはJavaを使用していますが、これはCよりも高度な機能をサポートしており（ポインターの概念を使用していません）、現在見ている多くの人々（私の友人）は、高度な機能をサポートするためCを無視してこれらの言語を選択します。Cから始めるように伝えます。Cでは不可能なVB.NETまたはJavaの高度なことをしているときに、ポインターの概念を学ぶのは無駄だと言います。 どう思いますか？ 更新： Googleで読んだコメントは次のとおりです。 初期のコンピューターは遅すぎて最適化されていませんでした。 ポインターを使用すると、アドレスに直接アクセスできるようになり、関数呼び出しでアドレスのコピーを作成する代わりに時間を節約できます。 ポインターを使用するとセキュリティが著しく低下するため、JavaとC＃にはポインターが含まれていません。 これらと、さらに私が見つけたもの。私はまだいくつかの貴重な答えが必要です。それは大歓迎です。

89 java  c#  programming-languages  c  pointers 

私は、主にWebプロジェクト（W / LAMP）と、時には平均規模のC / C ++（非GUI）プロジェクトに取り組んでいる個人開発者です。 私はしばしばソースコードツリーの構築に苦労しています。実際、通常、ツリー全体をダンプして3〜4回再配置することなくプロジェクトを完了することはありません。 時々、ソースの分類が過剰になります-フォルダとサブフォルダの非常に長いツリー。それ以外の場合は、それらが提供するより大きな目的に基づいてすべてのファイルを特定のフォルダーに集中させ、ソース内の「無秩序な」フォルダーに導くことになります。 私は尋ねたい： ソースツリーの構造化に役立つ原則/論理/ベストプラクティスはありますか？ プロジェクトの分析に基づいてソースツリーを事前に視覚化するのに役立つグラフィック/ダイアグラム技術（データフローの場合はDFDなど）はありますか？ プロジェクトに関連するマルチメディアファイルツリーを構造化するために採用する戦略は何ですか？ 報奨金について：メンバーが独自の実践を共有している既存の回答に感謝しますが、より一般的で有益な回答（またはリソース）とメンバーからのより多くの回答を奨励したいと思います。

89 code-organization  solo-development 

最近、さまざまな抽象化技術に関連する多くの質問に気づきました。そして、基本的に問題の技術は「あまりにも賢い」と言っている答えがありました。プログラマーとしての私たちの仕事の一部は、解決するために与えられた問題に対する最良の解決策を決定することであり、そのためには賢明さが役立つと思います。 ですから、私の質問は、特定の抽象化手法が賢明さ自体にあまりにも賢明であると考える人たちですか、それとも異議の理由は他にあるのでしょうか？ 編集：このパーサーコンビネータは、私が賢いコードだと思うものの例です。これをダウンロードして、約30分間見ました。それから、私は紙の上でマクロ展開を進め、光を見ました。理解できたので、Haskellパーサーコンビネーターよりもはるかにエレガントに見えます。

89 abstraction 

JavaScriptでは、データ構造を不変として扱う最近の傾向があるようです。たとえば、オブジェクトの単一のプロパティを変更する必要がある場合は、新しいプロパティを使用して新しいオブジェクト全体を作成し、古いオブジェクトから他のすべてのプロパティをコピーして、古いオブジェクトをガベージコレクトしてください。（とにかく私の理解です。） 私の最初の反応は、パフォーマンスに悪いように聞こえます。 しかし、Immutable.jsやRedux.jsのようなライブラリは、私よりも賢い人によって書かれており、パフォーマンスに強い関心を持っているようです。そのため、ガベージ（およびパフォーマンスへの影響）の理解が間違っているのではないかと思います。 私が見逃している不変性にパフォーマンス上の利点はありますか？

88 javascript  performance  immutability 

プロジェクトに単一の標準コード形式（Eclipseでの保存アクションを伴う自動形式）を課すことを検討しています。その理由は、現在、複数（10人以上）の開発者が使用するコード形式に大きな違いがあるため、ある開発者が別の開発者のコ​​ードで作業することを難しくしているためです。同じJavaファイルが3つの異なる形式を使用する場合があります。 だから私は利点が明確であると信じています（読みやすさ=>生産性）が、これを課すことは良い考えでしょうか？そうでない場合、なぜですか？ 更新 私たちは皆Eclipseを使用しており、誰もがこの計画を認識しています。ほとんどの人が既に使用しているコード形式がありますが、一部の人は独自のコード形式に固執することを好むため、強制されていません。上記の理由により、強制することを好む人もいます。

88 java  eclipse  code-formatting 

私は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ファイルをで終わることとある程度比較できます?>。私は?>ほとんど空白スペースを出力するリスクのために終わることはありませんが、ファイルを終了することは論理的なことだと主張することができます。

88 programming-practices  switch-statement 

たとえば、過去のSysInternalsツール「FileMon」には、ソースコードが完全に1つの4,000行のファイルにあるカーネルモードドライバーがあります。これは、これまでに作成された最初のpingプログラム（〜2,000 LOC）でも同じです。

88 design  c  source-code 

テスト駆動開発（TDD）のロンドンスタイルとシカゴスタイル（デトロイトスタイルと呼ばれることもある）について聞いてきました。 ユタ州エクストリームプログラミングユーザーグループのワークショップ： インタラクションスタイルの TDDも呼ばれmockistスタイル、またはロンドン・スタイルを、それが人気となったロンドンのエクストリーム火曜日クラブの後。通常 は、より状態ベースのデトロイトスタイルまたはクラシック TDDとは対照的です。 ジェイソン・ゴーマンのワークショップ： ワークショップでは、両方のカバーシカゴ校 TDD（状態ベースの動作テストと三角測量）、とのロンドンの学校に特に重点を置いて、からかうとエンドツーエンドのTDD、相互作用のテストにもっと焦点を当て、責任駆動設計とスティーブ・フリーマンとナット・プライスの優れた成長オブジェクト指向ソフトウェアガイド付きテスト本で最近人気を博した、OOへのアプローチをしないでください。 ポストクラシックTDDまたは「ロンドンスクール」Jason Gormanによるものは役に立ちましたが、彼の例は私を混乱させました。なぜなら、彼は両方のアプローチで1つの例の代わりに2つの異なる例を使用しているからです。違いは何ですか？各スタイルをいつ使用しますか？

88 tdd  concepts 

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

88 programming-practices  language-agnostic  code-smell  operators 

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

88 web-development  programming-practices  development-process 

私の雇用主はプログラマーを雇っています-より具体的には、私はインタビューをして、その職に就く人を選択しています。 現時点で最高の候補者は、私よりもはるかに資格があり、年長で、経験も豊富です。 私が話した他の人々は、自分よりも資格のある人を雇うことは本当に悪い考えだと言っていました（私の家族も含まれています）。そして、私はここの他の技術スタッフも同様の態度を持っていると感じています（この申請者も彼らよりも資格があると考えています）。 彼らは、より優秀な人材を雇うことは、私と私の現在の同僚が会社に昇進しようとする努力を傷つけるか、またはジョニー・コメ・ラテリーがスポットライトと現在のスタッフを盗むことを恐れていると言っている、または考えているプロモーションが提供され、新しいポジションが開かれるため、取り残されます。 個人的には、この応募者と協力して、彼らから学びたいです。私は自分自身に十分に自信があり、新しくて経験豊富な誰かが入って来て、私を悪く見せ始めます。これを成長の機会として利用したいと思います。競争やこのような新しい人々を恐れることは合理的または有益だとは思いません。 それとも、私はただ素朴です。 どう思いますか？これに似た経験はありますか？あなたにとってはどうでしたか？

88 skills  experience 

私が参加した最後のインタビューで、容量のある2つのバケツ（それぞれ何と何と1リットル）を与えられたとき、何と何リットルの水を正確に測定することが期待されるパズルを解くように頼まれました。与えられた時間（〜5分）でパズルを解くことができませんでした。 インタビュアーは少しがっかりし、プログラマには「これらの」スキルが必要だと言いました。私は彼が話しているスキルを理解できませんでした。 私はいつもプログラミングの就職の面接で尋ねられるこの種のパズルについて奇妙に感じていました。私は、そのようなパズルとプログラミングの間の関係が、たとえあるとしても、何であるかを理解していません。インタビュアーはそのようなパズルで正確にどのようなスキルを評価するつもりですか？

88 interview  puzzles