タグ付けされた質問 「development-process」

私は1年の経験を持つプログラマーです。最近、プロジェクトを正しく開始することはほとんどないことに気付きました（ほとんどのサイドプロジェクト）。通常、プロジェクトサイクルは次のようになります。 いくつかのユースケースから始めます コーディングを開始 うまく処理できず、現在のコードベースにうまく適合しないいくつかのことを理解してください。 コードの大部分を書き換える そして、これは数回行くかもしれません だから私の質問は そのような慣行は一般的ですか、またはそれは私が能力がないことを意味しますか？ この面でどうすれば自分を改善できますか？

64 programming-practices  development-process 

あなたは彼らが誰であるかを知っています。彼らはプログラミングのロックスターです： 10倍速くコーディングされます。 彼らのコードは機能します。 彼らは、主要な言語の内外を知っているだけでなく、それが内部でどのように機能するかを知っています。 あなたが尋ねる前に、彼らはほとんどの質問に対する答えを知っています。 それらのいくつかは、私たち全員が使用するプログラミングの原則を発明しました。 そして、彼らも同様に謙虚になる傾向があります。 これらの人々についてはどうですか？彼らの思考プロセスについて、平均以上のプログラマーと根本的に異なるものはありますか？それとも、彼らは一生懸命働く非常に才能のある人々ですか？ 別の言い方をすると、どうすれば彼らのようになれますか？そんなに良いことを学ぶ必要があると思うことは知っていますが、それを学ぶには今後10年かかると思われ、それから私の知識は時代遅れになります。

59 learning  experience  development-process 

私が働いているところでは、3週間の反復でスクラム駆動のアジャイルを実践しています。はい、繰り返しが短くなればいいのですが、それを変更することは現時点では選択肢ではありません。 繰り返しの終わりに、私は通常、最終日が非常にゆっくりと進むことに気付きます。実際の作業はすでに完了し、受け入れられています。いくつかの会議（回顧と次の反復計画）がありますが、それ以外はあまり進行していません。 チームが最終日まで勢いを維持するためにどのようなテクニックを使用できますか？欠陥に対処する必要がありますか？とにかく次のイテレーションの作業を早期に開始しますか？他に何か？

56 agile  development-process  scrum 

TDDの赤-緑-リファクタリングサイクルは十分に確立され、受け入れられています。失敗した単体テストを1つ作成し、できるだけ単純に合格させます。クラスに対して失敗する多数の単体テストを記述し、それらすべてを一度に合格させることに対するこのアプローチの利点は何ですか。 テストスイートは、リファクタリング段階で誤ったコードを記述したり、ミスを犯したりすることからあなたを保護します。クラス（またはモジュール）のすべてのテストを「ブレインダンプ」の形式として最初に記述して、予想されるすべての動作を一度に書き留めることが簡単な場合があります。

55 unit-testing  development-process  tdd 

最近のインタビューで、私はインタビュアーに「新しいテクノロジーやライブラリ（SignalRなど）を評価し、それらを使用するためにどのように取り組みますか？」と尋ねました。彼らはそうではなく、代わりに自分ですべてを書くので、他の誰かに頼る必要がないと言った。 同社は政府や防衛請負業者、または安全重視のプロジェクトなどに従事していません。彼らはあなたの平均的な中規模のソフトウェア開発会社でした。 私の質問は、チームがすべてを自分で書くのはどれくらい一般的ですか？そうするチームに心配する必要がありますか？ 編集-ほとんどすべての回答が、これは懸念事項であると述べています。二度目のインタビューは、家の中にすべてを書く際に自分の立場を明確にする/繰り返すように頼むのに適切な時間でしょうか？

53 interview  development-process 

メインスレッドがUIをほぼ瞬時に更新し、他のスレッドがネットワーク経由でデータをポーリングしているGUIアプリケーションや、ジョブの完了に5〜10秒かかることが保証されているGUIアプリケーションのようなものを考えてみましょう。 私はこれについて多くの異なる回答を受け取りましたが、統計的不可能の競合状態である場合、それをまったく心配しないと言う人もいますが、10-53％さえあればあなたは数字ではなく、これは私が聞いたものです）競合状態のために起こっているブードゥー教の魔法、常にそれを必要とするスレッドのロックを取得/解放します。 あなたの考えは何ですか？このような統計的に不可能な状況で競合状態を処理するのは、プログラミングの良い習慣ですか？または、読みやすさを妨げるためにコードの行を追加することはまったく不要であるか、逆効果になるでしょうか？

52 programming-practices  development-process  multithreading 

私は、大きなバックエンドコンポーネントを備えたAndroidおよびiOS用の新しいモバイルアプリに取り組んでいる開発者です。私たちはこのプロジェクトの3つのスプリントに参加しており、スクラムをそのすべてのセレモニー（洗練、計画、デイリー、回顧など）で使用しています。 2つのスプリントでは、チームは残業と週末に（無給で）働かなければなりませんでした。誰もが一生懸命働きましたが、外部の依存関係と楽観的な見積もりにより、すべてのスプリントストーリーを達成するのに苦労しました。 私の経験では、一部のスプリント中にストーリーの一部が完了しないことはある程度普通であり、次のストーリーで取り組むことができます。しかし、プロジェクトマネージャーは、自分で見積もりを行ったのは私たちのせいだと言っているので、スプリントのすべての項目を完了する必要があります。 これは、私が知らないスクラムの許容可能な/一般的なバリエーションですか？ これに基づいて行動することをどのように提案しますか？

52 agile  project-management  scrum  development-process 

私はスタートアップの開発リーダーとして働き、開発にVMを使用することを提案しました。各開発者がテスト/開発用のVMを備えたデスクトップを持っているということではなく、すべてのVMが管理され、ローカルまたはリモートからでもマイクロPC（ChromeOSの誰か）で開発者が作業するサーバーラックがあることを意味しますコンピューター。 私にとっての利点は、非常にスケーラブルで、長期的には安価で、管理しやすく、ハードウェアを最大限に活用できることです。短所については、セットアップをセットアップ/メンテナンスする人が必要になる以外、特定のショートッパーについて考えることはできません。 私はあなたの何人かがあなたの職場で同様の設定をして、あなたの意見に重みをつけることができることを望んでいました。ありがとう。

51 development-process  hardware  virtual-machine  virtualization 

最近は大流行です。「みんな」がそれをお勧めします。それ自体が疑わしいものです。 テストファースト（テスト駆動）開発を行うときに発見したいくつかの欠点は何ですか？私は知識のある開業医からの個人的な経験を探しています。私はインターネット上の他の場所にある百人の夢想家の仮説を読むことができます。 TDDが嫌いだからではなく、ソフトウェア開発プロセスを改善することが私の仕事であり、人々が遭遇する問題について学ぶことができれば、プロセスを改善できる可能性が高くなるからです。

47 development-process  tdd 

ソフトウェアエンジニアリングでは、バグを修正するコストが、バグが発見された後の開発で指数関数的に増加することはよく知られています。これは、Code Completeで公開され、他の多くの出版物で採用されているデータによってサポートされています。 ただし、このデータは存在しなかったことがわかります。Code Completeが引用したデータは、明らかにそのようなコスト/開発時間の相関関係を示しておらず、同様の公開された表は、いくつかの特殊なケースで相関関係を示しました。 これを裏付ける、または反論する独立したデータはありますか？ そして、もし本当なら（つまり、発見された最近のバグのためにこの指数関数的に高いコストをサポートするデータがない場合）、これはソフトウェア開発方法論にどのように影響しますか？

45 testing  development-process  debugging 

コードの匂い、テストの匂い、プロジェクトの匂いについてもよく耳にしますが、Joel Test以外の雇用主の「匂い」についての議論は聞いていません。不愉快な企業文化の匂いがする雇用主のために多くのフラストレーションを感じた後、私は積極的にもっと成熟した開発環境を探す時が来たと信じています。 私は就職の面接中に問題を特定することにより、獣医の雇用主を支援するために質問のリストを集め始め、追加のアイデアを探しています。雇用主はこのリストを簡単に修正して従業員を検査することもできると思いますが、インタビューの観点から答えてください。 一貫した答えが得られるかどうかを確認するために、複数の人々のこれらの質問の多くを尋ねることが重要だと思います。ほとんどの場合、質問を各セクションに質問順に並べようとしました。早期の質問に対する望ましくない回答は、しばしばフォローアップを意味のないものにします。 値 「よく書かれた」ソフトウェアとは何ですか？ 優れた開発者にはどのような属性がありますか？マネージャーにも同じ質問です。あなたの最も大切な従業員/マネージャーは誰ですか、そしてなぜですか？ 処理する 開発プロセスはありますか？ どの程度厳密にそれに従いますか？ 各プロジェクトに適用するプロセスの量をどのように決定しますか？ 典型的なプロジェクトのライフサイクルを説明してください。そうでない場合は、次の質問をしてください。 ウォーターフォール/反復：事前要件収集にどのくらいの時間がかかりますか？先行設計？ テスト中 テストの開発者（開発者または別のテストエンジニア） それらはいつ開発されますか？ テストはいつ実行されますか？ 実行にどれくらい時間がかかりますか？ 良いテストとは何ですか？ 十分なテストを行ったことをどのようにして知っていますか？ テストされるコードの割合 レビュー レビュープロセスはどのようなものですか？ レビューされるコードの割合は？設計？ コード/デザインレビューア/レビュー対象者として参加する頻度はどれくらいですか？ レビューに適用される基準は何ですか？基準はどこから来ますか？ 改善 過去1年間に評価または展開した新しいツールとテクニックは何ですか？ 過去1年間に従業員に提供されたトレーニングコースは何ですか？あなたの会社で最初の6か月間、私は何をしますか（もしあれば、どのような組織的なメンターシップ/トレーニングが検討されたかをヒンティングします） 過去1年間に開発プロセスにどのような変更が加えられましたか？ 組織としての間違いからどのように改善し、学びますか？過去1年間であなたの組織の最大のミスは何でしたか？ 最近、経営陣にどのようなフィードバックをしましたか？実装されましたか？そうでない場合、なぜですか？ あなたの会社は「ベストプラクティス」をどのように使用していますか？どのようにして外部または内部からそれらを探し出し、どのように互いに共有しますか？ 倫理 あなたまたはあなたの従業員が最近経験した倫理的問題について教えてください。 オープンソースソフトウェアを使用していますか？どのようなオープンソースの貢献をしましたか？ フォローアップ このStack Overflowの質問で@ jim-leonardoが言ったことが気に入りました。 本当に自問すべきこと：「この人は私を募集して興味を持たせようとしているように見えますか？」これは最も重要な部分の1つだと思います。面接を受けているのはあなただけだという態度を取っているように見える場合、彼らはおそらくあなたを粗末に扱うでしょう。良い面接官は、候補者が自分自身を売るのに必要なだけポジションを売らなければならないと理解しています。 @SethPが追加されました： Glassdoor.comは、潜在的な雇用主を調査するための優れたWebサイトです。特定の企業がインタビューを実施する方法に関する情報が含まれています...

45 development-process  development-environment 

私は自分で「停止点症候群」と呼ぶ行動に気付きました...それは、「停止点」に到達するまで（または疲労するまで）作業を停止できないことを意味します。言い換えれば、機能の完了に取り組んでいるゾーンにいる場合、それが完了するまで停止しません。私が取り組んでいるバグの場合、この効果はさらに顕著になります。修正されるか、少なくとも理解されるまで停止しません。私はラップトップで仕事をしていて、VPNを持っているので、その夜遅くに家に帰って仕事に取りかかることができますが、その事実は仕事を辞めるのに役立ちません...バグを見つける前に死ぬのではないかと心配しています。 これを家族に説明するのは非常に苦労します。家族には、なぜ私が仕事から帰ってこないのか、時には午後11時に家に帰るのかを理解できません。マネージャーでさえもこれに戸惑っていて、同僚のほとんどが毎日同じ時間働くことに問題がないことに気付きました。 他の誰かがこの問題を抱えていますか？これを心配したり、変更したりする必要がありますか？もしそうならどのように？

44 development-process  productivity  time-management 

ライブショーをできないミュージシャンのように感じることもあります。プログラミングは非常にクールなスキルであり、非常に広い世界ですが、その多くは「カメラから離れて」発生します。頭の中、オフィス、観客から離れています。 もちろん、他のプログラマーとプログラミングについて話し合うことができ、ピアプログラミングがあり、人々に見せることができるものを作成することができますが、非プログラマーにそれが何であるか、またはどうだったかを説明することになると仕事でのあなたの一日は、ちょっと難しいです。 あなたの人生で非プログラマにどうやってあなたが何をしているのかを理解させるにはどうすればいいですか？ 注：これは、プログラマ以外の人に開発プロセスを理解してもらうことの繰り返しではありません。なぜなら、その質問はクライアントの期待を管理することに関するものだからです。

43 development-process  communication 

ボブ・ロスが今夜「ハッピー・ツリー」をペイントするのを見ていましたが、最近、自分のコードについて何が私にストレスを与えているのかがわかりました。 こことStack Overflowの人々のコミュニティは、不完全さのあらゆる気まぐれを拒否しているようです。私の目標は、スキルを向上させることにより、立派な（したがって、保守可能で機能する）コードを書くことです。それでも、私は創造的にコーディングしています。 「創造的にコーディングする」ことの意味を説明しましょう。 プロジェクトの最初のステップは、多くの場合、座ってコードを打ち消すことです。より大きなものについては、あちこちで少し計画を立てていますが、ほとんどの場合は飛び込みます。 プロジェクトで他のピースを作成している他の人と一緒に作業している場合を除き、クラスを図に示していません。それでも、それは確かに私が最初にすることではありません。私は通常、大規模なプロジェクトに取り組んでおらず、ビジュアルが非常に便利だとは思いません。 私が書いた最初のコードは、何度も何度も書き直され、元のハックをテスト、簡素化、やり直し、再利用可能、論理的、効率的なものに変換します。 このプロセスの間、私はいつも掃除しています。未使用のコードを削除し、明らかでないものはコメントします。私は常にテストしています。 私のプロセスは、プロの開発者コミュニティで受け入れられるものの粒に反するようであり、その理由を理解したいと思います。 悪いコードに関する不満のほとんどは、誰かが元従業員の混乱に巻き込まれていることであり、修正するには多くの時間とお金がかかったことです。私が理解していること。最終結果が最初からすべてを計画することで得られるものに似ていることを考えると、私のプロセスが間違っていることは理解できません。（少なくとも、それは私が見つけたものです。） この問題に対する私の不安は最近非常にひどく、私が取り組んでいる特定の問題を解決するためのすべての方法についてすべてがわかるまでコーディングをやめました。言い換えれば、私はほとんどコーディングを完全にやめました。 問題についてのあなたの意見がどうであれ、私はあなたの意見に心から感謝します。 編集： 回答ありがとうございます。私はそれらのそれぞれから何かを学びました。あなたはすべて最も役に立ちました。

42 development-process  code-quality 

ヘッダーコメント内のファイル自体にバグ番号を入れるのは良い習慣ですか？ コメントは次のようになります。 MODIFIED (MM/DD/YY) abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode cde 01/17/14 - Bug 2314558 - some other error description 役立つように思えますが、それは悪い習慣と見なされていますか？

40 version-control  development-process  source-code  comments