大学生と開発プロセスを実装する方法
ソフトウェア開発者としての最初の仕事で、私のチームはアジャイル/スクラムを使用してプロジェクトのワークフローを管理しましたが、それはかなりうまくいきました。経験豊富なメンターが私を正しい方向に導いてくれました-私は彼らに大きな感謝の気持ちを抱いています。私はそこで数年間働いた後、数か月前に新しい機会に移りました。
現在の仕事に早送りします。私は大学の教授のもとで働いています。私は大学にいるので、ほとんどすべてのプログラマーは学生です（彼らは安価で豊富です！）私の上司には管理経験がありますが、ソフトウェア開発の経験はなく、ソフトウェアチームはいつも上司の頭にいるわけではありません。 。これらの条件は、いくつかのvery低品質のソフトウェアを作成するための完璧な環境を作り出しました。ソフトウェアプロジェクトは少々悪党であり、設計することを考えておらず、本当に恐ろしい慣行を採用しているようです。物事が良くなることを知っています。
開発プロセスを実装して、全員を軌道に乗せ、コードの品質を向上させ、より安定したソフトウェアを展開したいと考えています。どこから始めればいいのかわからない。
私はnotで、「Use Scrum」、「Set a kanban board」、または「Take look at agile！」などの回答を探しています。 （アイデアは高く評価されますが）。より具体的には、実装これの作業環境の開発プロセスを理解することを望んでいます。従業員は通常、次に進む1〜2年前に働き、一般的に経験が浅く、全員を含む毎日のスタンドアップミーティングをスケジュールすることはほぼ不可能です。
そのような職場で、品質、効率、コミュニケーションをどのように促進しますか？
更新：回答とコメントの一部を読んだ後、私はいくつかの追加の背景を提供すると思いました。
私はソフトウェア開発の技術の達人だとは思わないでしょうが、私はam目にしたときに悪いプログラミングを認識するのに十分な経験を積んでいます。開発者が1〜2分で作業した後、開発者が才能があるかどうかを判断できます。私は問題を解決する方法を見つける自分の能力に満足しています賢く、しかし、私が本当に経験のない領域は、他の開発者が関与するプロジェクト管理です（それが私がここにいる理由です）すばらしい人たち全員にアドバイスを求めます）。
私は、このオフィスに来るすべての学生が完全な暗闇のように聞こえるようにしました。ここで悪い卵がいくつかありましたが、私が会った学生の大部分は知的で、学びたい、そして仕事に情熱を持っています。いくつかはまだ始まったばかりで、彼らは自分が知らないことを知りません。そして、それは大丈夫です。私が最初にプログラミングを始めたとき、私は元気がありませんでした！
ミスをクリーンアップする場合は、事前にチェックする場合よりも時間がかかります。（おそらく）熟練していないか、良い習慣に気付いていない開発者を扱っている場合は、 （マスター）コードベースを、経験豊富な誰かがそのコードを見るまで変更します。
方法論の説明は必要なかったので、その部分をざっと見てみましょう。アジャイルタスクを使用して、独自に開発できるさまざまな機能をセットアップします。
機能ブランチの使用を開始して、全員が別のブランチで作業できるようにします。タスクが終了すると、開発者はコードをマスターブランチにマージできなくなります。 Gitを使用している場合でも、プルリクエストを起動できます。それ以外の場合は、完成したタスク（/ブランチ）を追跡する方法を使用してください。
次にレビュープロセスに進みます。質問が少し曖昧なのは、学生の判断よりも信頼できる経験豊富な開発者もいるのかどうかです。だから私はどちらかの方法で詳しく説明しましょう：
経験豊富な開発者がいる場合は、終了したタスクのコードを確認してタスクを実行してください。それが良ければ、マスターブランチにマージできます。そうでない場合、彼らは自分でリファクタリングするか、何を改善する必要があるかについて開発者にフィードバックを与えることができます。
経験豊富な開発者がいない場合は、常に問題が発生します。悪いコードから良いコードを見つける人がいない場合、コードの品質を維持することは不可能です。
あなたにできる最善のことは、開発者が他の開発者の前で彼らの実装を発表し説明する検討会議を開くことです。これはすべての問題を防ぐことを保証することはできませんが（たとえば、すべての開発者が優れた実践について同じ誤解を持っている場合）、それでも問題の大部分（たとえば、少なくとも1人の開発者が適切なアイデアを持っていてそれを明確にすることができる場合;または問題が発生した場合）は防ぎますお互いに異なる問題を理解している開発者から）
そのような職場では、品質、効率、コミュニケーションをどのようにして育てるのでしょうか。
- 品質-経験豊富な開発者によるコードを確認します。経験豊富な開発者がいない場合は、グループのレビューを作成して、少なくともできるだけベースをカバーするようにしてください。
- 効率-独立したタスクを正しく設定すると、人々がお互いに待つ必要を最小限に抑えることができます。全員が同時に対応できるとは限らない環境では、「Aを待つ」遅延の多くに対処していると思います。進歩を遂げていない開発者をフォローアップし、支援が必要かどうかを確認するか、不満を解消できるようにします（不満は回避可能な問題に関する誤解を明らかにする可能性があります）。
- コミュニケーション-開発者が誰かに助け、フィードバックまたはインスピレーションを求めることができるように、オープンドアポリシーを設定します。有資格のメンターがいない場合は、チームの相互作用を促進するようにしてください（もちろん、メンターがいる場合でもこれを行うことができますが、メンターがいない場合はそうすることの重要性が増します）。特に、人々がリモートで異なるスケジュールで作業している状況では、開発者は同僚の近くにいないことが多く、相互にコミュニケーションをとらない傾向があります。ほんの一握りの懇親会でも、仕事に関連するコミュニケーションを改善するために不思議に思うことがあります。
人々が新しく、去る可能性が高いそのような環境で最大のことは、必須のコードレビューです。
彼らは何をすべきかについての知識を広めるのに役立ちます。最悪のコードがコードベースに侵入するのを防ぐのに役立ちます。それらは実装の一貫性を促進します。
それだけ多くの離職率と経験がないので、communicationは通常よりも重要です。
解決策というよりはアイデアですが、学生の開発者が行う可能性のあるプロジェクトと同様の機能や要素を含むコードベースの重要なセクションを1つ見つけて、それを非常によく整理してください。新しい開発者の大きな問題の1つは、コードベースの規範や規則を知らないため、他のコードを調べて独自のコードを設定する方法を理解することです。厄介なコードベースで働いている新しい開発者がたくさんいるということは、彼らが混乱を見て、それが許容できる、または物事を行うための最良の方法であると考えることを意味します。悪い慣行は、高回転の環境でも永続します。
少なくとも1つの元の適切に記述されたコードセクション（または1つのファイル）を用意することで、学生の開発者にそれをベストプラクティスの例として使用するように指示できます。それらに似たコードを書くことができるとワクワクすることを彼らに伝え、他のコードの多くは物事を行う正しい方法の良い例ではないかもしれないと言います。
コメントやその他のドキュメントを追加して、なぜ物事が特定の方法で行われるのかを説明することで、新しい開発者はより良いコードプラクティスでより迅速にスピードアップできるようになります。
継続的な統合-
これは、チームツール、スキル、プロセスを段階的かつ柔軟に実装するための実用的で概念的なフレームワークです。
CIは、コードの記述からデプロイメントまでのワークフローのアイデアです。これらのタスクは、概念的にも実際にも独立しています。
CIは特に自動化です。これは、画面上でコードが入力された時点から、品質と生産性に大きな影響を与えます。
- CIタスクの実装は、個別に、詳細に、同時に対処できます。必要に応じてフォーカスを移動できます。
- Soup-to-nuts CIツールを導入しないでください
- Y'allはプロセスに気を取られ、カプセル化されたタスクスキルをホワイトウォッシュする傾向があります。
- お金をかけずに物事を紹介する
フルタイムの変更エージェントであることが期待されます。リーダーになります。単なるマネージャーではなく、単に上級コーダーではありません。
戦略的になる
- CIの聖杯は、展開の自動化のためのハンズオフ、コンパイルです。彼らはそれに触れることができない場合、彼らはそれをFUBARできません。
- トレーニングおよびトレーニング資料。
- プロセスを文書化します。
- プログラマーズマニュアルを作成し、有機的に進化させます。
- 必須。
- 探査では、特定のスキルとコードベース自体を対象とした概要を説明します。
- 次のようなプロのプログラマーの価値観を植え付けます。
- TDDは絶対に品質を生み出します
- コードレビューにはすべてのアーティファクトが含まれます：コメント、コメント化されたコード、単体テストなど。
- 「バグがいくつ見つかったのか恥ずかしい」
- 客観性は、個人コードの所有権の感覚や所有者を「気分を害する」という恐怖によって妨げられることはありません。
戦術的になる
- 個別のCIタスク自体を自動化することができます。たとえば、バージョン管理コミットがコンパイルおよびユニットテストをトリガーします。
- コードのフォーマットなど、自動化されたルール。
- あまりにも多くの知識のある細目に注意してください。ツールは無視され始めます。ルールの施行を調整して、圧倒されないようにします。
- テスト駆動開発をすぐに実装する
- 各変更に優先順位を付けて強調する
- 主要な知識とスキルの飛躍が単純に発生するとは限りません。
- 緊急性が適切な実装を覆すことを許可しない
- 変更を主導し、それに従ってください
- 新しい男のオリエンテーションといくつかの最小限のトレーニングが必要です。
- 新しいことに対する明示的なトレーニングと明確なガイダンス
- 少なくとも、いくつかの最低限の概念的な基準に合わせてトレーニングします。正式な形式である必要はありませんが、YouTubeをランダムに歩くことはトレーニングではありません。個人的に確認する-再び形式を避けます。
- コードレビュー担当者になり、すべてのコードを確認してください。
- 困難なバグ修正を明示的にガイドし、注目すべき学習体験を共有します。
- 堅固な柔軟性。すみません、それを言わなければなりませんでした。しかし、それは本当です。
- 文化を作る
- プロの期待を持っている
- ツールを標準化する
- 生産指標に関する学習を強調する
- メンターになる
- 変更を導入するとき、単に「そうする」という個人のイニシアチブに単純に依存していると、チームの発展を微妙に破壊してしまいます。結束力のあるチームのアイデンティティには、ツール、知識、およびスキルレベルという共通点が含まれます。相互の尊敬は、各メンバーが価値のある値としてこれらの論文を採用する程度まで成長します。チームリーダーがモデルであり、避けられないものです。 「何でも」の態度と期待をモデル化しないでください。
品質への道
ユニットテスト
- テスト駆動開発の鍵
- それについて本全体を読む必要はありません
- これはtheコーディングパラダイムになるはずです
- リーダーとして、あなたは誰もが「信仰の単体テストの飛躍」をするまでそれを守らなければなりません。そのパラダイムは、「コードを2度書いている！」からシフトしています。その素晴らしい生産性を受け入れるために。
- 当店ではユニットテストが必須でした。しかし、彼らは望んでいないので、多くはそれをしませんでした。経営陣の信念の欠如は、ユニットテストが実際には機能しないというメッセージを送りました。
- そのため、コードレビュー中にユニットテストが無視されることが多すぎて、コードベースへの誤った、効果のない、バグのあるテストが可能でした。 不完全な単体テストは全体の作業を破壊します。
- テスト駆動開発の鍵
バージョン管理
- 私はこれを最初に置きますが、ユニットテストを始めるのが簡単です
- バージョン管理はそれほど簡単ではないため、他のイニシアチブを遅らせないでください
- バージョン管理計画を作成します。
- あなたはそれを書き留めなければならない。
- 「トランクにすべてを投げ、分岐はしない」という単純な場合でも、これを行ってください。
コードレビュー
- これは、コード品質を詳細に改善するための最大の可能性を秘めています。
- 2つのレビュープロセスを使用します。
- 2回目のレビューでバグがいくつ発見されるかは非常に驚きました。
- 信頼するが検証する。コードを実行します。なぜこれを言わなければならないのですか？すぐ上を参照してください。
- 最初はあなただけがレビュー担当者になります。 「ライブ」のレビューをチームに見てもらいます。彼らは他の方法で考える方法を学ぶことは決してないでしょう。
- 間もなく2人目のレビュアーになります。個々のスキルに応じて、レビューしてもらいます。最終的には両方の査読者。もちろん、あなたは例外なく、常にコードを見ています。
リファクタリング
- これは明確で正式な規律です。
- Refactoring：Improving the design of existing code by Martin Fowler
- コード化されたリファクタリングレシピにより、バグの発生を抑えてコードを変更できます。
- この本でプロの図書館を始めましょう。
- フォーマルはさておき、コードレビューを通じてアドホックに導入する
環境をキャプチャする
- ベースラインツールの構成：バージョン管理、IDE、CIツール、OSなど.
- ソースコード、ドキュメント、設定はバージョン管理で同期する必要があります。
プロセスについての言葉
アジャイル（およびそのスクラムなどのサブジャンル）：忘れてください。 「あなたは機敏です、あなたは機敏ではありません。」 Agile Manifestoの元の署名者の1人であるDave Thomasの記事をご覧ください。
- The Corruption of Agile -Dr. Dobbs Journalからのインタビュー
- Agile is dead（long live agility）
- アジャイルは死んでいます -会議の基調講演。
小規模で経験の浅いチームを考えると、Visual Studio Team Servicesのようなチーム統合ツールを見ると、私のスパイシーな感覚が消えます。私の経験はここで限られていますが、私は、ぎくしゃくした、余分で、厳格なプロセスの強制を感じています。私は多くの人がこれらのものを非常に効果的に使用していることを知っていますが、問題を探すソリューションを購入する可能性があることに注意してください。
ツールについての単語
私だけ。それらの「今すぐ最高のソフトウェアツール...」のクリックベイトハニーポットではありません。
ジェンキンス
CI統合ツール。 Webベースで広く使用されています。基本的に、Web GUIを使用して、コンパイル、単体テストの実行、バージョン管理の更新など、さまざまなタスクと実行順序をカスタム構成して自動化します。これは非常にA-La Carteなので、初期のCI環境に適しています。
バージョン管理
私はGitよりもMercurialを好みます。このブログ投稿が、私が最初にMercurialを選んだ理由です。 GitはMacGyver、MercurialはJames Bond
Subversionは良いです。 MercurialとGitには、Subversionよりも優れた異なるアーキテクチャがあります。
統合開発環境
誰もが異なるコーディングツールを使用している場合、ここに大きな脂肪の考慮事項があります。 プレーンテキストのようなものはありません
専門図書館に関する一言
インターネットは広く、浅く、まとまりがありません。
- コード完了by Steve McConnell
- 全員に真ん中3分の1を読んでもらいます。
- 提案された専門書に関する付録があります。
- リファクタリング：既存のコードのデザインの改善
- コード化されたリファクタリングレシピにより、バグの発生を抑えてコードを変更できます。
- ソフトウェア障害。特定の推奨事項はありませんが、論文に対する物語でなければなりません。
まだ使用していない場合は、ソース管理を使用することをお勧めします。これにより、各開発者がチェックインした内容を確認でき、バグが発生した場所を後退できます。
なんらかのテストスイートをセットアップします。これは、コミットする各機能のテストを作成するテスト駆動開発、またはアプリケーションを実行して結果をファイルに出力し、目的のファイルと比較できるようにする自動化された方法です。出力。これをすべてのコミット後に実行するか、少なくとも1晩に1回実行すると、リグレッションがすぐに見つかります。
最後に、2つのポリシーを実装します。1）すべてのビルドで警告をエラーに設定し、すべてのエラーをオンにする必要があります。2）すべてのコードは、コミットされる前にエラーまたは警告を生成せずに静的アナライザーを通過する必要があります。これをコミット前のアクションにすることもできます。これら2つのことにより、多くの一般的な方法でコードがすぐに恐ろしいものになるのを防ぎます。 （すべてをキャッチするわけではありませんが、たくさんキャッチします。）
これにより、生徒は「現実の世界」での仕事にどのように対応するかを準備し、ある程度の良い習慣を身につけることができます。
あなたが言うように会議をスケジュールすることは不可能であるため、別の方法論を使用してプロセスを管理することを提案します（これはスクラムにとって絶対に重要です！）。良いコンセプトを作るのにまだ悪いことは何もないので、誰もが何が起こっているのか（おそらくvertプロトタイプも使用しています）を知っており、ウォーターフォールモデルを使用しています。いずれにせよ、コミュニケーションは仕事の最大の部分です。