ソフトウェア工学

私は、全員が1年未満のソフトウェア開発経験を持つ小さなチームのリーダーです。私は決して自分をソフトウェアの第一人者とは言いませんが、ここ数年でソフトウェアを書いていることをいくつか学びました。 コードレビューを行うとき、私はかなりのミスを教えて修正します。「これは非常に複雑で複雑であり、これが理由です」または「このメソッドを別のクラスに移動することについてどう思いますか？」質問や意見の相違がある場合は大丈夫ですので、話し合う必要があることを伝えるのは特に慎重です。私は誰かを修正するたびに、「あなたはどう思いますか？」と尋ねます。または類似のもの。 しかし、意見が合わない場合や理由を尋ねることはめったにありません。そして最近、私は彼らが私の声明に盲目的に同意し、彼ら自身の意見を形成していないというより露骨な兆候に気付いています。 指示に従うだけでなく、物事を自律的に正しく行うことを学ぶことができるチームが必要です。ジュニア開発者をどのように修正しますが、それでも彼が自分で考えることを奨励しますか？ 編集：ここに、彼らが彼ら自身の意見を形成していないというこれらの明白な兆候の1つの例があります： 私：拡張メソッドを作成するというあなたのアイデアは好きですが、大きな複雑なラムダをパラメーターとして渡す方法は好きではありません。ラムダは、メソッドの実装について他人にあまりにも多くのことを強制します。 ジュニア（私を誤解した後）：はい、私は完全に同意します。ここで拡張メソッドを使用しないでください。これは、他の開発者に実装について多くの知識を強要させるためです。 誤解があり、それは対処されました。しかし、彼の声明には論理のOUNCEさえありませんでした！彼は私の論理を逆流していると思い、なぜ彼がそれを言っているのか全く分からないときに理にかなっていると思った。

54 learning  teamwork  team-leader 

オープンソースコミュニティの多くの人々は、採用時に候補者のGithubプロファイルを強く検討すると言います。 私はGithubで積極的に活動しており、私自身のプロジェクトと他のプロジェクトへの貢献がいくつかあります。しかし、自分が雇用主であるかのように自分のプロファイルを見ると、クローンを作成したが貢献したことのないプロジェクトなど、多くのノイズが見えます。誇りに思っているプロジェクトやパッチは目立ちません。 人々のGithubプロファイルを評価する場合、どのように行いますか？そして、開発者として、何か別のことをする必要がありますか-例えば、私が積極的に取り組んでいないクローンリポジトリを削除しますか？

54 open-source  github 

仲間の開発者が新しいDrupalプロジェクトの作業を開始し、システム管理者は「更新を簡単にスクリプト化できるようにする」ため、sites / defaultサブディレクトリのみをソース管理に配置することを提案しました。このやや疑わしい主張を別にすれば、別の疑問が生じます。どのファイルをソース管理下に置くべきでしょうか？また、いくつかの大きなファイルを除外する必要がある状況はありますか？ 私の意見では、プロジェクトのツリー全体を制御する必要があり、これはDrupalプロジェクト、レール、またはその他のすべてに当てはまります。これは簡単なように思えます。作成するカスタムコードの場合と同様に、フレームワークのバージョン管理が明らかに必要です。 とはいえ、これについて他の意見を聞きたいと思います。すべてを制御下に置いていないという議論はありますか？

54 version-control  drupal 

私はまだMicrosoft TechEdにいて、ソフトウェア会議で自分の時間を効果的に使用する方法についての質問への回答は、圧倒的に「ネットワークはソフトウェア会議で最も有用な部分です」でした。 問題：そのタスクにアプローチする方法すらわかりません。私はいつも内向的でした。学校でも職場でも、長年にわたって素晴らしい友人を作った外向性が十分にあるため、一般的に問題はありませんでした。しかし、会議では、ほとんどが私のように内向的であり、営業担当者ではないようです。 私は、部屋全体で健全な議論が行われたセッションの後、人々に近づいて大丈夫だと感じたことが何度かありました。 。 読むべき特定の本はありますか？アドバイスはありますか？知らない人に近づく限り、何かありますか？「私が試みるたびに、私はちょうど厄介な混乱のように感じます。:( （奇妙なことに、私は人々のグループと話すことに問題はありません-それは私をつまずかせるのは一対一のことです：P）（ああ、ところで、ここの誰かがそこにいて、物事について話すために会いたい、私はゲームだ：P） それでは、私のような内向的なプログラマーは、ソフトウェア会議でどのように効果的にネットワーク化するのでしょうか？

54 career-development  social-networks 

私が会った多くのプログラマーは常に「彼はUIの人ではない」と言っています。実際、最近の開発は、Web、Windows、Linux、OSX、またはその他の種類の開発に関係なく、見栄えの良いUIを備えたソフトウェアで構成されています。なぜこれほど多くの開発者がUIの動作を好まないように見えるのでしょうか？

54 user-interface 

あなたの意見では、平均的なプログラマーが見つけにくいバグを最小限に抑えて機能を出力できる言語は何ですか？これはもちろん非常に広範な質問であり、私は非常に広く一般的な答えと知恵に興味があります。 個人的には、JavaおよびC＃プログラムの奇妙なバグを探すのにほとんど時間を費やさず、C ++コードには明確な繰り返しバグのセットがあり、Python / similarにはコンパイラによって検出される一般的で愚かなバグのセットがあります他の言語で。 また、完全に機能的なコードで書かれた大きくて複雑なプログラムを見たことがないので、この点で関数型言語を検討するのは難しいと感じています。ご入力ください。 編集：見つけにくいバグを完全にarbitrary意的に明確化：再現するのに15分以上かかり、原因を見つけて修正するのに1時間以上かかります。 これが重複している場合はご容赦ください。ただし、この特定のトピックについては何も見つかりませんでした。

54 programming-languages  bug  problem-solving  functional-programming 

何人かのプログラマーがコードを何度も何度も微調整して、「うまく機能する」ようにするだけでなく、「見栄えよくする」ようにしました。 IMO、「きれいなコード」は実際、あなたのコードがエレガントで、完全に理解でき、保守可能であることを示す賛辞です。そして、見た目が魅力的なコードと、ストレスの多いコードを選択する必要がある場合に違いが生じます。 では、実際に「クリーンなコード」を書く人は何人いますか？それは良い習慣ですか？この他の利点または欠点は何ですか？

54 productivity 

構文として空白に悩まされていることを除けば、私は嫌いではありません。Pythonに魅了されることはありません。 Perlの詩に感謝し、bash＆kornおよびshebangで美しいWebサービスをプログラミングしましたgnuplot。私は文書を書きますがtroff、REXXは気にしません。何年も前にtclがこれ以上有用であるとは思いませんでしたが、Pythonの大きな悪臭は何ですか？私は求人情報とこれを採用した多くの候補者を履歴書の賞品とトロフィーとして見ています。 現実には、私は個人的にこれで売られるようにしようとしていると思う、ただ理由を見つけることができない。

54 python  perl  bash 

C ++には単純な多重継承があり、多くの言語設計では危険なものとして禁止されています。しかし、RubyやPHPなどの一部の言語では、奇妙な構文を使用して同じことを行い、それをmixinまたはtraitsと呼びます。ミックスイン/特性は、単純な多重継承よりも悪用しにくいと何度も耳にしました。 それらを特に危険性の低いものにしているのは何ですか？ミックスイン/トレイトではできないが、C ++スタイルの多重継承では可能なことはありますか？彼らとダイヤモンドの問題に遭遇することは可能ですか？ これは、多重継承を使用しているように見えますが、それらを使用できるように、それらがミックスイン/特性であるという言い訳をするだけです。

54 object-oriented  inheritance  multiple-inheritance  mixins 

2週間のスプリントの終わりに、タスクにコードレビューがあります。このレビューで、機能する、読み取り可能な関数を発見しましたが、非常に長く、コードの匂いがいくつかあります。簡単なリファクタリングジョブ。 それ以外の場合、タスクはdoneの定義に適合します。 2つの選択肢があります。 このスプリントでチケットが閉じないようにコードレビューに失敗します。チケットを渡すことができないため、士気に少し打撃を与えます。 リファクタリングは小さな作業であり、次のスプリント（または開始前）で小さなハーフポイントストーリーとして行われます。 私の質問は次のとおりです。レビューを失敗するのではなく、レビューの裏からチケットを上げることに固有の問題や考慮事項がありますか？ 私が見つけることができ、詳細コードのレビューを読んだことがあるリソースは、通常、100％または何もありませんが、通常は現実的ではありません。

53 agile  code-reviews 

私は言った友人がいました： Dockerは素晴らしいです。これを使用して、本番環境とそのすべての癖をローカルマシンに複製できます。その後、すべてのステージングワークフローを介して、そのインスタンスを超高速で直接展開できます。 これは、開発者がRuby、PHP、またはGoを記述している場合に当てはまります。オペレーティングシステムへの方向バイナリリンクがありました。 ただし、Javaを使用する場合は、オペレーティングシステムと言語の間に仮想層が既に存在するため、基盤となるオペレーティングシステムに関係なく、操作の一貫性が保たれます。 おそらく、この場合、開発者がローカルで運用環境を複製するためにDockerを実行する利点は無効になります。（Ruby、PHP、またはGoと比較）。 私はこれについて議論することを受け入れており、反対の見解を（証拠とともに）聞きたいと思っています。 Unixバイナリに近い他の言語と比較して、Javaを使用する場合、Dockerを使用する開発上の利点は無効になりますか？

53 java  deployment  jvm  docker 

バージョン管理から削除する必要があるソースファイルの処理方法が悪い習慣と見なされるかどうかを知りたかったのです。 その例に基づいて説明します。 基本的にデッドコードであるプログラムのJavaクラスを退屈に整理しなければならなかったので、最近非常に怒った。もちろん、それらは削除する必要がありましたが、私はそのような冗長なものを削除する前に-奇妙なことを言うかもしれません-習慣があります： 私はSVN-> Deleteを介してそのような冗長ファイルをすぐに削除しません（選択したバージョン管理システムの削除コマンドに置き換えます）代わりにそれらのファイルにコメントを入れます（私は頭とフッターの両方を参照します）削除されます+私の名前+日付-さらに重要なこと- それらが削除された理由 次に、保存してバージョン管理にコミットします。次回プロジェクト内の何かをバージョン管理にコミット/チェックインする必要があるとき、SVN-> Deleteを押すと、最終的にバージョン管理で削除されます-もちろん、修正によって復元できます。そのため、この習慣を採用しました。 すぐに削除するのではなく、なぜこれを行うのですか？ 私の理由は、少なくともそれらの冗長ファイルが存在した最後のリビジョンに明示的なマーカーを持ちたい、なぜ削除するに値するのかということです。それらをすぐに削除すると、それらは削除されますが、削除された理由はどこにも文書化されていません。私はこのような典型的なシナリオを避けたい： 「うーん...なぜそれらのファイルが削除されたのですか？私は以前はうまく動いていました。」（「元に戻す」を押す->元に戻す人は永遠になくなるか、次の週に利用できなくなり、次の担当者は私のような退屈なファイルの内容を知る必要があります） しかし、コミットメッセージでそれらのファイルが削除された理由に注意しませんか？ もちろんやりますが、コミットメッセージが同僚によって読まれない場合があります。（私の場合は死んでいる）コードを理解しようとするときに、最初にバージョン管理ログと関連するすべてのコミットメッセージを確認するのは、典型的な状況ではありません。同僚はログをクロールする代わりに、このファイルが役に立たないことをすぐに確認できます。時間を節約でき、このファイルはおそらく復元された可能性が高いことを知っています（または、少なくとも問題が発生します）。

53 version-control  svn  evidence-based 

なぜこれが大丈夫であり、ほとんど期待されているのですか： abstract type Shape { abstract number Area(); } concrete type Triangle : Shape { concrete number Area() { //... } } ...これはOKではなく、誰も文句を言いません： concrete type Name : string { } concrete type Index : int { } concrete type Quantity : int { } 私の動機は、コンパイル時の正当性検証のために型システムの使用を最大化することです。 PS：はい、私はこれを読んでおり、ラッピングはハッキングの回避策です。

53 type-systems  static-typing  strong-typing 

私は最近大学を卒業し、プログラマーとして仕事を始めました。「技術的な」問題を解決したり、1つの解決策があると言うことでデバッグしたりすることはそれほど難しいとは思いません。 しかし、明らかな解決策が1つもない問題のクラスがあるようです-ソフトウェアアーキテクチャのようなもの。これらのことは私を混乱させ、大きな苦痛を引き起こします。 私は自分のプログラムとシステムをどのように「アーキテクト化」するかを決めるのに何時間も費やしています。たとえば、このロジックを1つまたは2つのクラスに分割したり、クラスにどのように名前を付けたり、プライベートまたはパブリックにしたりする必要があるかなどです。プログラムを作成したいだけです。 アーキテクチャフェーズをより迅速に達成し、楽しんでいるコーディングおよびデバッグフェーズに到達するにはどうすればよいですか？

53 design  architecture 

不変の型、特にコレクションを使用する主な利点として、スレッドセーフが常に/しばしば言及されているようです。 メソッドが文字列の辞書（C＃では不変）を変更しないようにしたい状況があります。できるだけ物事を制約したいと思います。 ただし、新しいパッケージ（Microsoft Immutable Collections）に依存関係を追加する価値があるかどうかはわかりません。パフォーマンスも大きな問題ではありません。 したがって、私の質問は、ハードパフォーマンス要件がなく、スレッドセーフの問題がない場合に、不変コレクションを強く推奨するかどうかだと思いますか？値のセマンティクス（私の例のように）も要件である場合とそうでない場合があることを考慮してください。

53 immutability  semantics  collections  mutable