大学生と開発プロセスを実装する方法

ソフトウェア開発者としての最初の仕事で、私のチームはアジャイル/スクラムを使用してプロジェクトのワークフローを管理しましたが、それはかなりうまくいきました。経験豊富なメンターが私を正しい方向に導いてくれました-私は彼らに大きな感謝の気持ちを抱いています。私はそこで数年間働いた後、数か月前に新しい機会に移りました。

現在の仕事に早送りします。私は大学の教授のもとで働いています。私は大学にいるので、ほとんどすべてのプログラマーは学生です（彼らは安価で豊富です！）私の上司には管理経験がありますが、ソフトウェア開発の経験はなく、ソフトウェアチームは常に上司の頭にいるわけではありません。 。これらの条件は、いくつかの非常に質の悪いソフトウェアを作成するための完璧な環境を作り出しました。ソフトウェアプロジェクトは少し悪党であるように見え、設計することを考えておらず、いくつかの本当に恐ろしい慣行を採用しています。物事が良くなることを知っています。

開発プロセスを実装して、全員を軌道に乗せ、コードの品質を向上させ、より安定したソフトウェアを展開したいと考えています。どこから始めればいいのかわからない。

私は、言うまでもなく、「スクラムを使用する」、「かんばんボードを設定する」、「アジャイルを見てください」などの回答を探していません。（アイデアは高く評価されますが）。具体的には、この作業環境の開発プロセスを実装する方法について洞察を得たいと思っています。従業員は通常、次に進む前の1〜2年の間に働き、一般的に経験が浅く、全員を含む毎日のスタンドアップミーティングをスケジュールすることはほとんど不可能です。

そのような職場では、品質、効率、コミュニケーションをどのようにして育てるのでしょうか。

更新：いくつかの回答とコメントを読んだ後、私はいくつかの追加の背景を提供すると思いました。

私は自分自身のソフトウェア開発の芸術のマスターを検討していないだろうが、私は思います、私はそれを見たときに悪いプログラミングを認識するのに十分な経験を積みました。開発者が1〜2分で作業した後、開発者が才能があるかどうかを判断できます。私は問題をスマートに解決する方法を見つける自分の能力に満足していますが、本当に経験が足りない領域は、他の開発者が関与するプロジェクト管理です（そのため、私はここですべての素晴らしい人々に助言）。

私は、このオフィスに来るすべての学生が完全な弱者であるように聞こえました。ここには悪い卵がいくつかありましたが、私が会った学生の大多数は知的で、学びたいと思っており、仕事に熱心です。一部はまだ始まったばかりで、何を知らないのか分からない。そして、それは大丈夫です。私がプログラミングを始めたとき、私は元気がありませんでした！

ミスをクリーンアップするには、事前にチェックするよりも時間がかかります。（おそらく）熟練していないか、良い習慣に気付いていない開発者を扱っている場合は、経験豊富な人がコードを見るまで、（マスター）コードベースを変更できないはずです。

方法論の説明が欲しくなかったので、その部分をざっと見てみましょう。アジャイルタスクを使用して、独立して開発できるさまざまな機能をセットアップします。

機能ブランチの使用を開始して、全員が別のブランチで作業できるようにします。タスクが終了すると、開発者はコードをマスターブランチにマージできなくなります。Gitを使用している場合でも、プルリクエストを起動できます。それ以外の場合は、完成したタスク（/ブランチ）を追跡する方法を使用してください。

次に、レビュープロセスに進みます。あなたが質問しているのは少し漠然としていて、学生の判断よりも信頼できる経験豊富な開発者もいるのかどうかです。したがって、どちらかの方法で詳しく説明しましょう。

経験豊富な開発者がいる場合は、完了したタスクのコードを確認してタスクを実行してください。それが良ければ、マスターブランチにマージできます。そうでない場合、彼らは自分でリファクタリングするか、何を改善する必要があるかについて開発者にフィードバックを与えることができます。

経験豊富な開発者がいない場合は、常に問題が発生します。悪いコードから良いコードを見つける人がいない場合、コードの品質を維持することは不可能です。
あなたができる最善のことは、開発者が他の開発者の前で彼らの実装を発表して説明するレビュー会議を開くことです。これはすべての問題を防ぐことを保証することはできませんが（たとえば、すべての開発者が優れた実践について同じ誤解を持っている場合）、それでも問題の大部分を防ぐことができます（たとえば、少なくとも1人の開発者が正しいアイデアを持っていて、それを明確にすることができる場合、または問題が発生した場合）お互いに異なる問題を理解している開発者から）

そのような職場では、品質、効率、コミュニケーションをどのようにして育てるのでしょうか。

• 品質 -経験豊富な開発者によるコードを確認します。経験豊富な開発者がいない場合は、少なくとも自分の拠点をできる限りカバーするようにグループレビューにしてください。
• 効率性 -独立したタスクを正しく設定すると、人がお互いに待つ必要が最小限になります。全員が同時に対応できるとは限らない環境では、「Aを待つ」遅延の多くに対処していると思います。進歩を遂げていない開発者をフォローアップし、支援が必要かどうかを確認するか、または単に不満を発散させます（不満は回避可能な問題についての誤解を明らかにする可能性があります）。
• コミュニケーション -オープンドアポリシーを設定して、開発者が誰かに助け、フィードバック、またはインスピレーションを求めることができるようにします。有資格のメンターがいない場合は、チームの相互作用を促進するようにしてください（もちろん、メンターがいる場合でもこれを行うことができますが、メンターがいない場合はそうすることの重要性が増します）。特に、人々がリモートで異なるスケジュールで作業している状況では、開発者は同僚の近くにいないことが多く、相互にコミュニケーションをとらない傾向があります。ほんの一握りの懇親会でも、仕事に関連したコミュニケーションを改善するために不思議に思うことがあります。

人々が新しく、去る可能性が高いこのような環境で最大のことは、必須のコードレビューです。

彼らは何をすべきかについての知識を広めるのに役立ちます。最悪のコードがコードベースに侵入するのを防ぐのに役立ちます。それらは実装の一貫性を促進します。

それだけ多くの離職率と経験がないため、コミュニケーションは通常よりも重要です。

解決策というよりはアイデアですが、学生の開発者が行う可能性のあるプロジェクトと同様の機能や要素を含むコードベースの重要なセクションを1つ見つけて、それを非常によく整理してください。新しい開発者の大きな問題の1つは、コードベースの規範や規則を知らないため、他のコードを調べて独自のコードを設定する方法を理解することです。厄介なコードベースで作業している多くの新しい開発者がいるということは、彼らが混乱を見て、それが許容できる、または最善の方法であると考えることを意味します。悪い慣行は、高回転の環境でも永続します。

少なくとも1つの手付かずの適切に記述されたコードセクション（または1つのファイル）を用意することで、学生の開発者にそれをベストプラクティスの例として使用するように指示できます。彼らがそのようなコードを書くことができて、他のコードの多くが物事を行う正しい方法の良い例ではないかもしれないとわくわくすることを彼らに伝えてください。

コメントや他のドキュメントを追加して、なぜ特定の方法で物事が行われるのかを説明することも、新しい開発者がより良いコードプラクティスでより迅速に理解できるようにするのに役立ちます。

継続的な統合 -

これは、チームツール、スキル、プロセスを段階的かつ柔軟に実装するための実用的で概念的なフレームワークです。

CIは、コードの記述からデプロイメントまでのワークフローのアイデアです。これらのタスクは、概念的にも実際にも独立しています。

特にCIは自動化です。これは、画面にコードが入力された時点から、品質と生産性に大きな影響を与えます。

• CIタスクの実装は、個別に、詳細に、同時に対処できます。必要に応じてフォーカスを移動できます。
• スープからナッツへのCIツールを導入しない
  • Y'allはプロセスに気を取られ、カプセル化されたタスクスキルをホワイトウォッシュする傾向があります。
• お金をかけずに物事を紹介する

• フルタイムの変更エージェントになることを期待してください。リーダーになります。単なるマネージャーではなく、単に上級コーダーではありません。

• 戦略的になる

  • CIの聖杯は、自動化されたデプロイメント自動化のためのハンドオフのコンパイルです。彼らはそれに触れることができない場合、彼らはそれをFUBARできません。
  • トレーニングおよびトレーニング資料。
    • プロセスを文書化します。
    • 作成プログラマーズ・マニュアルを、それが有機的に進化してみましょう。
    • 必須。
    • 探査では、特定のスキルとコードベース自体を対象とした概要を説明します。
  • 次のようなプロのプログラマーの価値観を植え付けます。
    • TDDは絶対に品質を生み出します
    • コードレビューにはすべてのアーティファクトが含まれます：コメント、コメント化されたコード、単体テストなど。
    • 「見つかったバグの数に戸惑いました」
    • 客観性は、個人コードの所有権の感覚や所有者を「気分を害する」恐れによって妨げられることはありません。

• 戦術的になる

  • 個別のCIタスク自体を自動化することができます。たとえば、バージョン管理コミットがコンパイルおよびユニットテストをトリガーします。
  • コードのフォーマットなど、自動化されたルール。
    • あまりにも多くの知識のある細目に注意してください。ツールは無視され始めます。ルールの適用を調整して、圧倒されないようにします。
  • テスト駆動開発をすぐに実装する
  • 各変更に優先順位を付けて強調する
    • 主要な知識とスキルの飛躍が単純に発生するとは限りません。
  • 緊急性が適切な実装を覆すことを許可しない
  • 変化を先導し、フォローする
    • 新しい男のオリエンテーションといくつかの最小限のトレーニングが必要です。
    • 新しいことに対する明確なトレーニングと明確なガイダンス
    • 少なくとも、いくつかの最低限の概念的な基準までトレーニングします。正式なものである必要はありませんが、YouTubeをランダムに歩くことはトレーニングではありません。個人的に確認-再び形式を避けます。
  • コードレビューアになって、すべてのコードをレビューしてください。
    • 困難なバグ修正を明示的に導き、注目すべき学習体験を共有します。
  • 堅固な柔軟性。すみません、それを言わなければなりませんでした。しかし、それは本当です。
• 文化を創造する
  • プロの期待を持っている
  • ツールを標準化する
  • 生産指標に関する学習を強調する
  • メンターになる
  • 変更を導入するとき、単に「そうする」という個人のイニシアチブに単純に依存していると、チームの発展を微妙に覆します。結束力のあるチームのアイデンティティには、ツール、知識、およびスキルレベルという共通点が含まれます。相互の尊敬は、各メンバーが価値のある値としてこれらの論文を採用する程度まで成長します。チームリーダーがモデルであり、避けられません。「何でも」の態度と期待をモデル化しないでください。

品質への道

• ユニットテスト

  • テスト駆動開発の鍵
    • それについて本全体を読む必要はありません
    • これはなるはずコーディングパラダイム
    • リーダーとして、あなたは誰もが「信仰の単体テストの飛躍」をするまでそれを守らなければなりません。そのパラダイムは、「コードを2度書いている」からシフトしています。その素晴らしい生産性を受け入れるために。
  • 当店ではユニットテストが必須でした。しかし、彼らは望んでいないので、多くはそれをしませんでした。経営陣の信念の欠如は、ユニットテストは実際には機能しないというメッセージを送りました。
    • そのため、コードレビュー中にユニットテストが無視されることが多すぎて、コードベースへの誤った、効果のない、バグのあるテストが可能でした。不完全な単体テストは全体の取り組みを破壊します。

• バージョン管理

  • 私はこれを最初に置きますが、ユニットテストを始めるのが簡単です
  • バージョン管理はそれほど簡単ではないため、他のイニシアチブを遅らせないでください
  • バージョン管理計画を作成します。
    • あなたはそれを書き留めなければならない。
    • 「トランクにすべてを投げ、分岐はしない」という単純な場合でも、これを行ってください。

• コードレビュー

  • これは、コード品質を詳細に改善するための最大の可能性を秘めています。
  • 2レビュープロセスを使用します。
    • 2回目のレビューでバグがいくつ発見されるのか、とても驚きました。
    • 信頼するが検証する。コードを実行します。なぜこれを言わなければならないのですか？上記を参照してください。
    • 最初はあなたが唯一のレビュー担当者になります。「ライブ」のレビューをチームに見てもらいます。彼らは他の方法で考える方法を学ぶことは決してないでしょう。
    • 間もなく、あなたは2人目のレビュアーになります。個々のスキルに応じて、それらを確認してもらいます。最終的には両方の査読者。もちろん、あなたは例外なく、常にコードを見ています。

• リファクタリング

  • これは明確で正式な規律です。
  • リファクタリング： Martin Fowlerによる 既存のコードのデザインの改善
    • コード化されたリファクタリングレシピ。これにより、バグが発生することなくコードを変更できます。
    • この本でプロの図書館を始めましょう。
  • フォーマルはさておき、コードレビューを通じてアドホックに導入する

• 環境をキャプチャ

  • ベースラインツールの構成：バージョン管理、IDE、CIツール、OSなど
  • ソースコード、ドキュメント、設定はバージョン管理で同期する必要があります。

プロセスについての言葉

アジャイル（およびそのスクラムなどのサブジャンル）：忘れてください。「あなたは機敏です、あなたは機敏ではありません。」アジャイル宣言の元々の署名者の1人であるDave Thomasの記事をご覧ください。

• アジャイルの腐敗 -ドブスジャーナル博士からのインタビュー
• アジャイルは死んだ（長生きの敏捷性）
• アジャイルは死んでいる -会議の基調講演。

Visual Studio Team Servicesのようなチーム統合ツールを見ると、小規模で経験の浅いチームを考えると、私のスパイシーな感覚が消えます。私の経験はここで限られていますが、私は、ぎくしゃくした、余分で、厳格なプロセスの強制を感じています。私は多くの人がこれらのことを非常に効果的に使用していることを知っていますが、問題を探すソリューションを購入する可能性があることに注意してください。

ツールについて一言

私だけ。それらの「今すぐ最高のソフトウェアツール...」のクリックベイトハニーポットではありません。

ジェンキンス

CI統合ツール。Webベースで広く使用されています。基本的に、Web GUIを使用して、コンパイル、単体テストの実行、バージョン管理の更新など、さまざまなタスクと実行順序をカスタム構成して自動化します。それは非常にA-La Carteなので、初期のCI環境に適しています。

バージョン管理

私はGitよりもMercurialを好みます。このブログ投稿が、私が最初にMercurialを選んだ理由です。GitはMacGyver、MercurialはJames Bondです。

Subversionは良いです。MercurialとGitは、Subversionより優れた異なるアーキテクチャを持っています。

統合開発環境

誰もがさまざまなコーディングツールを使用している場合の大きな考慮事項は次のとおりです。プレーンテキストのようなものはありません

専門図書館についての一言

インターネットは広く、浅く、まとまりがありません。

• Steve McConnellによる コードの完成
  • 中央の3分の1を全員に読んでもらいます。
  • おすすめの専門書が付録になっています。
• リファクタリング：既存のコードの設計を改善する
  • コード化されたリファクタリングレシピ。これにより、バグが発生することなくコードを変更できます。
• ソフトウェア障害。特定の推奨事項はありませんが、論文に対する物語でなければなりません。

あなたが言うように会議をスケジュールすることは不可能であるため、別の方法論を使用してプロセスを管理することを提案します（これはスクラムにとって絶対に重要です！）。良いコンセプトを作るのに悪いことはまだ何もないので、誰もが何が起こっているのか（おそらくvertプロトタイプも使用しています）を知っていて、ウォーターフォールモデルを使用しています。いずれにせよ、コミュニケーションは仕事の最大の部分です。

まだの場合は、ソース管理を使用することをお勧めします。これにより、各開発者がチェックインした内容を確認でき、バグが発生した場所を後退できます。

なんらかのテストスイートをセットアップします。コミットする各機能のテストを作成するテスト駆動型開発の場合もあれば、アプリケーションを実行して結果を目的のファイルと比較できるファイルに出力する自動化された方法の場合もあります。出力。これをすべてのコミット後に実行するか、少なくとも1晩に1回実行すると、リグレッションがすぐに見つかります。

最後に、2つのポリシーを実装します。1）すべてのビルドで警告をエラーに設定し、すべてのエラーをオンにする必要があります。2）すべてのコードは、コミットされる前にエラーまたは警告を生成せずに静的アナライザーを通過する必要があります。これをコミット前のアクションにすることもできます。これら2つのことにより、コードが多くの一般的な方法ですぐに恐ろしいものになるのを防ぎます。（彼らはすべてをキャッチするわけではありませんが、たくさんキャッチします。）

これはまた、「現実の世界」での仕事がどのようなものになるかを生徒に準備させ、それらにある程度の良い習慣を植え付けます。