ソフトウェア工学

非常に簡単ですが、同じプロセスをいくつかの小さな調整で数回繰り返すだけで、すべてのケースとスケーラブルなデータで機能するコードを作成したいのはなぜですか？ すぐにこれを再度編集する必要はないでしょう。 行くだけで仕事が減るみたいです... function doStuff1(){/*.a.*/} function doStuff2(){/*.b.*/} function doStuff3(){/*.c.*/} そして、何かを追加する必要がある場合... function doStuff4(){/*.d.*/} 削除する必要がある場合は、削除します。 すべてをすべてのケースにデータを供給して処理できる1つの単純なパターンにすべてを作り、私がこれまでにないような気がしない多くの変更を行う方法を理解することは困難ですする。 クイックカット+ペーストで作業が大幅に減るのに、どうしてDRYになるのですか？

81 code-quality  dry 

製品が生産される前の最後のステップとして開発者が自分の作品をテストできるようにするのは悪い考えである理由についていくつかの議論を集めたいと思います。 、ほとんどの人が他のことで忙しすぎて、プログラムのその部分に別の人を慣れさせる時間がないという議論は要約されました-それは非常に専門的なソフトウェアです）。 この場合のテスト計画はありますが（常にではありませんが）、テストされた変更を行わなかった人が実際に最終テストを行うことを非常に支持しています。ですから、次回議論する際に持ち出せる議論の良いしっかりしたリストを提供していただけないかとお願いしています。または、特にテストする正式なテストケースがある場合にこれが完全に問題ないと考える場合に、反論を提供するために。

81 testing  development-process 

プログラミング言語の文法に取り組む各方法の具体的な長所と短所は何ですか？ なぜ/いつ自分のロールをする必要がありますか？なぜ/いつ発電機を使うべきですか？

81 language-design  compiler  parsing 

私はまだ高品質のコードを書くには経験が浅いので、Robert C. MartinによるClean Codeなどの問題に対処する本を読み、よく知られているライブラリのコードをチェックしてスキルを向上させます。 多くのオープンソースライブラリは長年にわたって維持されていますが、正しいパスにないことはほとんどありませんが、それらの多くのコードは、クリーンなコードを記述するための原則からはほど遠いことがわかりました。数百行のコード。 だから私の質問は次のとおりです。きれいなコードの原則はあまりにも制限されていますか？そうでない場合、これらの原則の多くを考慮せずに巨大なライブラリをどのように維持していますか？ 簡単な説明をいただければ幸いです。質問が初心者の人からばかげていると思われる場合、私は謝罪します。 編集 Butterknifeライブラリでこの例を確認してください。Androidコミュニティで最もよく知られているライブラリの1つです。

80 architecture  code-quality  libraries  clean-code  code-reuse 

なぜgitはリビジョン番号よりもハッシュを好むのかといつも思っていました。リビジョン番号ははるかに明確で簡単に参照できます（私の意見では）：リビジョン1200を見てもらうか、92ba93eをコミットするように誰かに言うことには違いがあります！（1つの例を挙げます）。 それでは、この設計には理由がありますか？

80 version-control  git 

多くのスクラムの本や記事では、スプリントの失敗（チームがスプリントバックログの一部の機能を完了できなかった場合）はそれほど悪いことではなく、時々発生します。そして、次のスプリントで何かを改善します。そして、チームは彼らがコミットした仕事を完了しないことで罰せられるべきではありません。 これは開発者の観点からは素晴らしいように見えますが、深刻なクライアント向けに何かを開発しているソフトウェア会社「Scrum-Addicts LLC」（「Money-Bags Corporation」）があるとします。 Scrum-Addictsマネージャーは、Money-Bags用のソフトウェアを作成することを提案しています 彼らは機能のリストに同意し、Money-Bagsは出荷日を提供するように頼みます スクラム中毒マネージャーはスクラムチームに相談し、チームはすべての機能を完了するには3週間のスプリントが必要だと言っています Scrum-Addictsマネージャーは、安全のために1週間を追加し、1か月でソフトウェアを出荷することを約束し、Money-Bagsと契約を結びます 4回のスプリント（出荷期限）後、スクラムチームは機能の80％しか提供できません（新しいシステムでの経験不足、本番環境の以前の機能の重大なバグを修正する必要性など）。 スクラムが示唆しているように、この時点で、製品は潜在的に出荷可能ですが、Money-Bagsは契約で述べられているように機能の100％を必要とします。だから彼らは契約を破って何も支払わない。 スクラム中毒者は、マネーバッグからお金をもらえず、投資家は結果に失望し、それ以上会社を助けたがらないため、破産寸前です。 明らかに、スクラム中毒者の立場になりたいソフトウェア会社はありません。アジャイルとスクラムについて私が理解できないのは、チームが上記の状況を回避するために計画と期限に対処することを提案する方法です。要約すると、2つの質問があります。 誰が悪いのか？ 適切な計画を立てることが彼らの仕事だからです チーム。彼らができる以上の仕事をすることにコミットしたから 他の誰か 何を終わらせるべきなのですか？ マネージャは、期限を元のチームの推定値の2倍（または3倍）遅らせる必要があります。 チームメンバーは、何をしてもコミットしたすべての作業を行うように奨励する必要があります（失敗したスプリントに対してペナルティーを発行することにより） 会社の締め切りポリシーに適合しないため、チームはスクラムを削除する必要があります 私たちは皆、ソフトウェア開発をやめて修道院に参加すべきです ???

80 agile  scrum  sprint 

かなり失礼なバグレポートを受け取りました。ユーザーは基本的に、あちこちで大文字を使用してそれをすべて間違っていると言いますが、実際には1つのバグを指しているだけです。 一方で、私はユーザーを大切にし、アプリの良好な関係と評価を維持したいと考えています。一方、過度に丁寧に返事をすれば、完売のように感じます。 適切な対応方法は何ですか？何を心に留めておくべきですか？どのような考え方が必要ですか？ ユーザーは24歳のCS学生のようであり、当社の製品は無料で配布しているAndroidアプリです。

80 customer-relations  bug-report 

最近、C＃プログラミングの仕事を始めましたが、Haskellにはかなりのバックグラウンドがあります。 しかし、私はC＃がオブジェクト指向言語であることを理解しています。丸い釘を四角い穴に押し込みたくありません。 私は、Microsoftからの例外のスローに関する記事を読みました。 エラーコードを返さないでください。 しかし、Haskellに慣れているため、C＃データ型を使用してOneOf、結果を「右」値として返すか、エラー（ほとんどの場合は列挙）を「左」値として返します。 これはEitherHaskell の慣習によく似ています。 私には、これは例外よりも安全に思えます。C＃では、例外を無視してもコンパイルエラーは発生しません。例外がキャッチされない場合は、プログラムがバブルアップしてクラッシュします。これはおそらく、エラーコードを無視して未定義の動作を生成するよりも優れていますが、クライアントのソフトウェアをクラッシュさせることは、特にバックグラウンドで他の多くの重要なビジネスタスクを実行している場合、まだ良いことではありません。 を使用してOneOf、パッケージを展開し、戻り値とエラーコードを処理することを明確にする必要があります。呼び出しスタックのその段階でそれを処理する方法がわからない場合は、現在の関数の戻り値に入れる必要があるため、呼び出し元はエラーが発生する可能性があることを知っています。 しかし、これはMicrosoftが提案するアプローチではないようです。 OneOf「通常の」例外（File Not Foundなど）を処理するために例外の代わりに使用するのは合理的なアプローチですか、それともひどい習慣ですか？ 制御フローとしての例外は深刻なアンチパターンと見なされていると聞いたことは注目に値します。したがって、「例外」がプログラムを終了せずに通常処理するものであれば、その「制御フロー」はある意味ではありませんか？ここに灰色の領域が少しあることを理解しています。 OneOf「メモリ不足」のようなものには使用していないことに注意してください。回復が期待できない条件でも例外がスローされます。しかし、解析されないユーザー入力は本質的に「制御フロー」であり、おそらく例外をスローすべきではないなど、かなり合理的な問題だと思います。 その後の考え： この議論から、私が現在取り上げていることは次のとおりです。 すぐに呼び出し元がcatch例外を処理し、ほとんどの場合例外を処理し、別のパスを介して作業を続行する場合は、おそらく戻り型の一部である必要があります。OptionalまたはOneOfここで役立ちます。 すぐに呼び出し元がほとんどの場合例外をキャッチしないと予想される場合は、例外をスローして、手動でスタックに渡す手間を省きます。 直近の発信者が何をしようとしているのかわからない場合は、Parseとなどの両方を提供しTryParseます。

80 c#  exceptions 

私の履歴書はもはや関係ありません。技術的な能力の適切な説明を含めることはできなくなりました。GitHubリポジトリ、Stack Exchangeプロファイル、およびUdacityとCourseraで受講しているさまざまなコースを見ると、自分が何ができるかをよりよく理解できます。問題は、私ができることの正確な説明が必要な場合に、それらを探す場所であることを雇用者に伝える方法がわからないことです。 リクルーターが私に連絡するたびに、私は先ほど述べたすべてのリソースにそっとそれらを押し付けます。また、公開されているGoogleドキュメントへのリンクを提供します。それでも、彼らはより説明的な履歴書を求めて戻ってきます。 誰かが私を雇いたいのなら、いくつかのリンクをクリックして閲覧するだけで多くのトラブルを自分で救うことができるということを、もっと露骨に明らかにすることができますか？

80 interview  github  resume 

ノイズがプログラマの生産性にどのように影響するかを示す研究へのリンクはありますか？具体的には、騒音レベルが低下したときに生産性がどのように/上昇したかを確認したいと思います。 以下のようなコメントで指摘し、プログラミングのワークフローの性質は、あなたがすべての時間に、フォーカスの外に出るようなものである-それは仕事の他の行とは異なるノイズの影響を受ける可能性があります。 これがプログラマー特有のものだと思う理由は、数学にも興味があるからです。騒がしい場所で、数学のことを考え始めると、ノイズが消え、写真の世界で迷子になります。実際、私の好きな数学をする場所は、いつも忙しい観光地であるThe Copper Kettle cafeでした。 プログラミングの場合はまったく異なります。プログラミング中、私は通常口頭で考えており、話すことはすべて私の思考の流れを破壊します。私は文字通り、会話が聞こえる場所ではプログラミングできません。 私は、私を無力にするノイズにさえ気づかない他のプログラマーと話しましたが、彼らは主に写真で考えていると言います。だから、数学や弁護士と比較して、プログラミングが特にノイズに影響されるかどうかについて、実際の学術的研究があるのだろうかと考えています。

80 productivity  noise 

私は最近、急成長しているスタートアップに参加しました。過去3か月で、開発チームは4から12に成長しました。これまでは、開発者が作業に使用していたものについて非常に自由放任主義でした。実際、私が会社について最初に魅力的に感じたものの1つは、ほとんどのプログラマーがLinux、または彼らの努力に最も適していると感じたOSを使用したことです。 今では、議論なしに、皆がEclipseに切り替えることになっています。素晴らしいエディター。私はSublimeText2を好みますが、それは私の個人的な好みです。 明確にするために、私たちはBackboneを使用するJSチームであり、EclipseはBackboneコードの理解が得意ではありません。これは、/ good / IDE（PHP Storm）を使用するチームのメンバーは、多くのsearch-find-oh-wait-where-was-I-three-steps-agoのようなことを何度も実行する必要があることを意味します単にCtrlキーを押しながらクリックして戻る/進むのではなく、おそらく生産性を15％、楽しさを50％低下させます... これは赤旗ですか？開発者（MS以外）が既に定着し、生産的である場合に使用するIDEまたはツールセットを伝えることは、気まぐれで不合理に制御しているようです。

80 management  tools  ide  startup  eclipse 

人々がコンピュータサイエンスについて話し始めるたびに、C、C ++、Javaについて毎日耳にしますが、最初のコンピュータサイエンスクラスでは、Scheme（DrRacket）で書くように求められます。 何故ですか？ これはプログラミングの将来の理解にどのような違いをもたらしますか？ 更新：最初の任期は終了しましたが、Schemeで完全には完了していません。2番目の用語（現在）では、Cプログラミングに取り組みました。最初はポインターを覚えるのはいらいらしていましたが、今では気分が良くなりました。 それ以上のことは言いません。私は私が行方不明になっているOOP部分のためにJava（またはC ++？）を自分で教えようとしています。これまでのところ、私はまだ関数型プログラミングが最も好きです。ラムダはただ魅力的です。:)

80 scheme 

私はプログラミングの初心者であり、本を読んだり、勉強したり、記事を読んだりしています。プログラミングを学び始めてから素晴らしい結果が得られており、初心者の頃はプログラミングに関するすべてを知っていたと思っていましたが、学習するにつれて、この分野の難しさを実感しました（実際、すべての分野は難しい、しかし、それはポイントではありません）。 今日、私は機能的なソフトウェアを書き、3つの言語の基本を学び、たった1つの言語で中級です。MYSQL、OpenGLプログラミング、またはVisual Studio C ++コードなどの高度なものを見ると、頭痛の種になります。また、多くのWebサイトのHTMLソースコードを視覚化するときでも（Google Chromeで見られるWebサイトのほとんどのソースコードは、非常に乱雑で整理されていないようです） ）それは私の脳の極限に私を混乱させます。最初はすべてシンプルに見えますが、これらの高度なものを見ると、どうやってそんなに学ぶことができるのかと思うようになります。 簡単に言えば、質問は、プログラマーがキャリアを進めるにつれて、これらのことがより明確になるかどうかです。上記のような複雑なトピック（OpenGL、MySQL、高度なhtmlサイト）は、学習するにつれて読みやすく、書きやすく、理解しやすくなりますか、それとも複雑になりますか？あなたがプログラミングの世界でアリであり、このようなものがあなたをつぶそうとしているという気持ちにどうやって対抗できるでしょうか？

80 programming-languages  programming-practices 

どこで学ぶべきかを尋ねているのではありません。私はオンラインでたくさんの良いリソースと本などを見つけました。 しかし、私はそれらにどのように取り組んでいますか。それの始まり、終わりはどこですか？正規表現プロセッサはいつテキストを進めますか、いつスタンドを保持して別の一致を試みますか？等 エジプトのピラミッドの象形文字を理解しようとしている気がします。

80 learning  regular-expressions 

この質問はしばらく私の頭の中で調理されてきたので、開発環境でアジャイル/スクラムのプラクティスに従っている人に尋ねたいと思いました。 私の会社はついにアジャイルプラクティスを取り入れることに挑戦し、トライアルベースでアジャイルグループの4人の開発者のチームから始めました。3回の反復で4か月が経過しましたが、他の人にとっては完全にアジャイルになることなく、それを続けています。これは、経営者がビジネス要件を満たすための信頼が、上記の非常に多くのアドホックタイプの要求であるという事実によるものです。 最近、私はこのイニシアチブの一部である開発者と話をしました。面白くないと言われます。彼らは彼らのスクラムマスターによって他の開発者と話すことを許可されておらず、作業エリアで電話を取ることも許可されていません（ある程度は問題ないかもしれません）。たとえば、アジャイルチームに所属するキックについて友人と話したい場合、スクラムマスターの承認なしでは許可されません。アジャイルチームのすぐ隣に座っています。 このすべてまたはアジャイルのアイデアは、アジャイル開発者に中断が生じないように完全な真空を提供し、6時間以上の生産時間を確保することです。まあ、私はアジャイルの第一人者ではありませんが、ヤフーのアジャイルロールアウトドキュメントや他の組織の同様の記事を読んだことから、アジャイルは安くないという印象を与えます。チームにアジャイルを浸透させ、到着した問題を修正して軌道に戻すには、リソースと予算が必要です。 まず、開発者向けのトレーニングとマネージャーなどのコーチングが必要です。現在のスクラムマスターは、管理者が支払うアジャイルトレーニングクラスを数日間受けたマネージャーで、現在このアジャイルチームを率いています。また、アジャイルマニフェストはアジャイルが石に設定されておらず、会社ごとにカスタマイズされていることを指示しないと会議で聞いたことがあります。まあ、それはすべて良いと理にかなっています。 結論として、私はアジャイルが開発チームに調和をもたらすはずだと常に思っていました。ただし、アジャイルチームの開発者と話をするとき、私は非常に反対の気持ちになります。彼らは仕事以外は何も話せないのに不満であり、一日中静かに座って仕事をしているだけであり、経営者が仕事をより良くするための別の方法だと感じています。 これがより多くのドルのために利己的な優位性の目的のために使用される良い習慣の例であるならば、私に教えてください？あるいは、私のような開発者だけがこのアジャイルチームであり、仕事をしているために仕事をするだけの環境で働くのは好きではないと感じています。 これは、全米にオフィスを持つヘルスケア分野の会社です。それは間違いなくカウボーイスタイルのアジャイルのように感じられるので、現在の会社では特に、アジャイルをまったく望んでいません。 それはすべて、管理が完全に安価であることと関係しています。安価なバージョンのために高価なコーヒーを切り取り、可能な限り無駄を省きながら、節約と生産性を重視します。 私は、ドアの後ろの経営陣がこのアイデアを捨て、アジャイルにより生産性が向上し、同じ人員でより多く生産している上司に見せることができると感じています。または、もしそうであれば、人員を減らすことができます。 彼らは毎日5分間の会議を開いています。ただし、チーム外の人とチャットや会話をすることはできません。すべての焦点は仕事にあります。

80 agile  scrum  methodology