保守性に関する学生のトレーニングを改善するには？
保守性は、専門的なソフトウェア開発の主要なステークです。実際、メンテナンスは、プロジェクトのリリースから基本的には終わりまで続くため、ほとんどの場合、ソフトウェアライフサイクルの最も長い部分です。
さらに、メンテナンス中のプロジェクトは、プロジェクト全体の数の大部分を占めています。 http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/ によると、メンテナンス中のプロジェクトは約2/3です。
私は最近これに遭遇しました 質問 、そこで彼の仕事は主にメンテナンスに関するものであることを発見して、男はかなり驚いて見えます。次に、フランスのソフトウェア開発専門家コミュニティのメインサイトに discussion（フランス語） を開くことにしました（ http://www.developpez.com/ ）。ディスカッションのタイトルは「学生は専門的なソフトウェア開発の現実に十分に訓練されているか？」そして主に保守性についてです。少なくともフランスでは、人々はそれの両方の面でメンテナンスに直面するのに十分な準備ができていないことが指摘されました：
- 既存のコードを維持する
- 保守可能なコードを作成する
ここでの私の質問はこの議論に忠実であり、保守性を教える良い方法を見つけることを目的としています。
- 保守性をどのように教えることができますか？
- どのような運動を提案しますか？
- 保守性についてよく訓練されている場合、どのようなコースを受講しましたか？
[編集]誤解した後、私は自分の質問を明確にする必要があると思います。私はプロジェクトリーダーおよびソフトウェア開発者として、研修生や新卒の学生と一緒に仕事をすることがよくあります。私はかつて自分で新卒でした。問題は、学生が通常、プロジェクトの保守性を向上させるSOLID）のような原則に不慣れであることです。私たちは、プロジェクトを発展させる（保守性が低い）重要な困難に直面することがよくあります。これは、保守性の重要性と、この特定のポイントに関してより良いコードを作成する方法、または学生のトレーニング方法を改善するための考えられる提案についての成功した教育の具体的な学術的な例です。
保守性をどのように教えることができますか？
それは練習の問題です。
制御された方法でそれを実践する最も簡単な方法私が考えることができるシミュレーションする典型的なメンテナンスをすることです次のようにプロジェクト。
いくつかのプロジェクトを取得します（Project A)これはうまくいき、いくつかの問題が発生します：いくつかのバグを挿入し、複製とデッドを適切に配置しますコード、いくつかの機能、単体テスト、およびドキュメントをあちこちにドロップします。Project A-破損バージョンのように、専用の名前を付けることもできます。
issue tracker を確立し、加えた特定の損害に対応するリクエストをそれに入力します。開発プロセスの基本的なルールとプラクティスを確立します-VCSコミット、コードレビュー、QAなど- The Joel Test で提供されるチェックリストからできることを検討してください。
- コースワーク1。
バグを修正し、不足しているユニットテスト、ドキュメント、機能を追加します。 - コースワーク2。
リファクタリング。 - コースワーク3。
来年の学生が使用するオリジナルプロジェクトのメンテナンス/改善
-プロジェクトAバージョン2.0およびプロジェクトA-破損したバージョン2.0。
破損したバージョンを改善することによって私はそれに対してより良い教育的ダメージを与えることを意味します。 :)
上記のプラクティスのうち、コードレビューのそれに特に注意してください。これは、たとえば 関連する質問のトップアンサー で示されているように、コードを保守しやすくするための最も効果的な方法です。
免責事項：私はCSの学位を取得しました。私は教師ではありません。
これは当たり前のように聞こえるかもしれませんが、コードメンテナンスを教える最善の方法は、学生にコードメンテナンスを実行させることだと思います。これが私がすることです：
- 中程度に複雑な問題と、意味的に同一である2つの実装を取り上げますが、一方は他方よりもはるかに保守しやすくなっています。
- 優れたコードベースで実装するのがはるかに簡単な変更/機能の追加をリクエストします。学生の半分は、より保守しやすいコードベースにこれらを実装し、残りの半分は、保守しにくいコードベースに実装する必要があります。
- 公平を期すために、役割を逆にしてこの演習を繰り返すことができます。
- 良いコードベースと悪いコードベースの間で正常に実装された変更の平均数と、それらの実装に費やされた時間を比較します。生徒に自分の経験を共有し、苦情を伝え、一般的に彼らが行った作業について話します。
アイデアは、学生に他の誰かのコードを操作させるだけでなく、設計スキルを向上させることができる保守可能なコードへの感謝を養うことでもあります。
保守性はスキルではなく美徳です。保守可能なプロジェクトを作成する方法はたくさんありますが、それらを確実に生成する公式はありません。
優しさや寛大さなどの美徳を大切にするなら、日常生活の中でそれを実践する方法を探します。保守性についても同じです。もしあなたとあなたの組織が保守性を重視しているなら、プロジェクトの設計と実装をしている間、それを心に留めておいてください。保守性が高く評価されていることを知っているので、少し時間をかけて何かを構築するのは正当な理由です。逆に、保守性を高めるために余分な時間を費やして、それを重視しない組織は推奨されません。
保守性を維持するように人々に教える場合は、まず組織が保守性を重視していることを明確にする必要があります。プロジェクトの要件で指定します。コードレビューを成功させるための基準の1つにしてください。要するに、保守性を文化の一部にするです。
次に、既存のプロジェクトの保守性を向上させるために、いくつかのリソースを費やすことをいとわない。バグが発生し続ける、またはバグの修正や変更が非常に困難で時間がかかるプロジェクトの部分を特定し、メンテナンスを容易にするために再設計またはリファクタリングします。
最後に、新しい開発者を保守性の文化に組み込むを、すでに毎日開発しているチームに割り当てます。誰かが価値観を採用するのを助けるには、たくさんの良い例とガイダンスを与えるより良い方法はありません。
ソフトウェア開発に関して、Maintainableという用語が嫌いです。現実には、すべてのソフトウェアは保守作業の対象となる可能性があるという点で保守可能であるため、本当の問題は、ソフトウェアの保守が高価であるか、安価であるか、ということです。これは回答の冒頭で非常に知識のある発言のように聞こえることは知っていますが、私のポイントはすぐに明らかになります。
ソフトウェア開発を専攻しているIT学位の問題は、学生がソフトウェアの作成について知る必要がある最低限のことだけを学生に教えることです。プロのスキルと知識は、学位の資格を得た後の最初の数年で行われる学習を通じて獲得されます。これは、卒業生が実際に顧客にとって重要なプロジェクトに取り組み始めるときであり、実行する大きなプレッシャーがある環境で、期待はプロフェッショナルな水準の製品を作成することです。悲しいことに、多くの企業は、ソフトウェアの専門的な標準が維持される文化を奨励しておらず、結果として、開発と維持にコストがかかることが判明したプロジェクトになってしまいます。残念ながら私たちの卒業生にとって、彼らはキャリアの初期にこのような環境で多くの悪い習慣を学び、彼らがこれらの習慣を克服する方法を学ぶまでに長い時間がかかる場合があります。
クリーンなコードの書き方や、通常は 技術的負債 が発生するソフトウェアの問題を特定する方法を生徒に教える方がよいでしょう。 クリーンコード 、 リファクタリング 、および リーンソフトウェア開発 に関する本を開始点として開始し、学生にユニットを書くように指導します高度なテストカバレッジがあることを確認するために、実装コードの前にテストします。コード内の重複した反復的なパターンを認識し、そのような重複を取り除くためにコードをリファクタリングする方法を生徒に教えます。生徒が [〜＃〜] solid [〜＃〜] や [〜＃〜] dry [〜＃〜] などの原則を理解して適用できるようにします。最も重要なのは、コードを維持する機能はコードの設計と実装のみに基づいて行われるものであり、代わりにソフトウェアの生産に職人技と品質の感覚を植え付けて、実装時にコードを改良して、技術的負債の影響を最小限に抑え、それによってソフトウェアを維持するためのコストを長期にわたって最小限に抑えます。
このようなスキルを学ぶには、コードレビューとペアプログラミングを行うのが一番だと思います。コードのレビュー中、経験豊富なスタッフは、コードをより保守しやすくする方法（通常はコードを読みやすくすること）を指摘し、特定の選択がより保守しやすいコードを作成できる理由を正当化できます。
ペアプログラミングは、この種のことを教えるためのさらに優れた方法です。経験の浅いスタッフには、コードの管理方法をすでに知っている人と直接コードを保守する経験があるためです。
クリーンでメンテナンス可能なコードの記述について読むことができる素晴らしい本もいくつかあります。 クリーンコード が思い浮かびます。
学生が大規模なコードベースを変更することはめったにないため、学界を通じてこの経験を得るのは困難です。これらのスキルのほとんどは仕事での学習から得られ、コードレビューとペアプログラミングはこの学習を本当に促進します。
適切なコード=メンテナンスが少なく、機能の拡張/追加が簡単。
悪いコード=メンテナンスの悪夢
基本的に私たちは、「プロジェクトにくだらないコードがあるときはいつでも、コードの元の作者が苦しみ、ソフトウェアがどのように影響を受けるので、会社に加わる新しい開発者であるということを学生に伝える必要があります。 」
したがって、ソフトウェアのメンテナンスについて生徒に教える最良の方法の1つは、良いコードと悪いコードの両方の例を示し、機能を追加するように依頼してから、優れたコードを書くことは自己満足のためだけでなく、コードを保守する人にとっては簡単です。
運動：
1）事前に作成された不良コード（例：重複コード）がある場合、「住宅ローンの支払いを計算する」というメソッドがプロジェクトに9か所と書かれている。
「すべての住宅ローンの支払いに1.2％の追加料金を追加する」機能を強化するように生徒に依頼します。
これで、学生は9か所すべてでコードを見つけて修正する苦労を感じるでしょう。 「住宅ローンの支払い」が計算された9か所すべてを見つけることができなかった多くの可能性があります。
2）次に、住宅ローンの支払いを唯一かつ唯一の場所で計算するこのメソッドを含むGoodコードを示します。よく書かれたコードを簡単に拡張できることを生徒に示し、コード/プロジェクトの保守性をどのように強化できるかを説明します。
ところで、私は学生にソフトウェアの保守性を公開するというあなたのアプローチが好きでした。