Extreme Programmingは、軽量でスマートなソフトウェア開発方法であると同時に、非常に厳密で徹底的な方法でもあります。その基盤と価値観は、コミュニケーション、シンプルさ、フィードバック、勇気です。つまり、ソフトウェアプロジェクトは、コミュニケーションの強化、シンプルさから始める、フィードバックを求める、事実から真実を求める勇気の4つの側面から改善できます。-バイドゥ百科事典
エンジニアリング実践の重要性
前回の記事では、アジャイルとは何か、スクラムフレームワークを紹介しましたが、本日はエクストリームプログラミング（XP）を取り上げます。名前から、XPとスクラムの焦点は明らかな違いがあります。XPはエンジニアリングの実践に重点を置いています。これは、多くの初期の機敏な方法の中でソフトウェア開発の分野で適用される実践でもあります。もちろん、著者は、XPの多くの方法と実践がソフトウェア開発で議論されていると信じていますが、いくつかの考えがあります。また、スキルは他の業界から学ぶ価値もあります。アジャイルの源泉はソフトウェア開発の分野に焦点を当てることです。これはアジャイルマニフェストにも明確に反映されて います。「ソフトウェアを開発し、他の人がそれを行うのを支援することで、ソフトウェアを開発するより良い方法を発見 しています。」さらに、アジャイル分野の多くのシニアリーダーは、エンジニアリングプラクティスに焦点を当てる必要性を繰り返し強調しており、チームが正しいアジャイルパスにいることを保証するには、プロセスと管理モデルの変更だけでは不十分です。それでは、XPが今日私たちに提供できるものを見てみましょう。
エクストリームプログラミングの推奨プラクティス
図に示すように、XPは13の非常に古典的な実用的な方法を提供します。最も内側のレイヤー、つまりリファクタリング、シンプルなデザイン、ペアプログラミング、テスト駆動型開発を見てみましょう。この部分の4つのプラクティスはより個別的です。このレベルでは、リファクタリングは設計の継続的な最適化を強調し、シンプルな設計は無駄を避けるために「十分な」設計を提唱し、ペアプログラミングは製品品質を最適化するためのペアでのメンバーの開発を強調し、テスト駆動型開発は開発を確実にするために新しい開発アプローチを使用します。従うべき法律があります」;
第2層は、チームが従うコーディング標準を確立し、チームが持続可能な開発速度（40時間）を維持できることを期待し、継続的な統合を通じて多数の統合エラーが蓄積して開発の後の段階に進むのを回避することを含む、チームの実践に焦点を当てます。所有権はオープンで透明性のあるチームの雰囲気を確立し、最も理解しにくいのはMetaphorです。Metaphorはデザインと理解を促進するようなものであり、eコマースWebサイトでのショッピングなど、誰もが理解しやすいコンテンツをシステムデザインに追加します。車は比喩の良い例です。この名前を見ると、誰もがその役割をすぐに理解できると思います。どのような機能が必要ですか？デザインは何ですか？すぐに合意に達しました。
最外層にはより広い範囲が含まれます。これらのプラクティスには、製品、ビジネスリーダー、およびゲームの計画、小規模バージョンのリリース、顧客テスト、完全なチームなど、その他の主要な利害関係者の参加が必要です。スペースは限られています。私たちは正しくありません。それぞれのプラクティスについて詳しく説明し、次にいくつかの典型的なプラクティスを選択して、私の理解と見解を皆さんと共有します。
リファクター
リファクタリングとは、コードの外部動作を変更せずにコードを変更して、プログラムの内部構造を改善することです。つまり、システムによって提供される機能は変更されません。必要なのは、内部最適化です。このように、フォローアップの技術的な滑走路のための道を開く、再構築が理解することは難しいことではないではありませんが、実際の作業環境では、多くの企業が復興の文化を持っていない、と次のように特定の理由を要約することができます。もう時間 これは責任の蹂躙のように思えるかもしれませんが、それは議論の余地のない事実でもあります。多くの組織で、R＆D担当者は996の試練に直面しており、日々の厳しい過剰需要に対処するのに苦労しています。この「無力でありがたい」の再構築については物事を行う時間もムードもありません。リスクの高い リファクタリングとは、既存のコードロジックを変更する必要があることを意味します。つまり、リファクタリングが失敗につながる場合は、元のロジックと設計を完全に理解する必要があります。必要な問題、特にチームメンバーのレベルが不均一で古いコードが大量にある場合、R＆D担当者は落ち込んでいるだけで、逃げる場所がありません。リファクタリングのリスクを予測するのはより困難です。それに注意を払わない 多くのリーダーは、リファクタリングが良い習慣と実践ですが、リファクタリングをビジネスデリバリー、コンプライアンス要件、製品イノベーションなどの一連の要件と組み合わせると、リファクタリングがリストの一番下にあることが多く、リファクタリングが認識されます。しかし、急いでいないことは一般的な見方ですが、いわゆる「作業は最初にツールを研ぎ澄ます必要があります」、リファクタリングはあなたに良い基盤と前提を与え、問題のあるデザインに基づいて拡張と更新を続けることができます。このプロジェクトの累積は、いわゆる技術債務であり、技術債務にも関心があります。期限内に返済できれば、納期と技術債務のバランスをとることができます。期限内に返済できない場合は、デフォルトになります。長ければ長いほど耐え難くなり、最終的には破産に直面します。リファクタリングは無意味です。 今日のソフトウェア開発やインターネットの分野では、ジョブホッピングが頻繁になります。現在人気のある方法は、ある会社に数年間混ぜてから次の会社にジャンプすることです。会社の給与は上がるか、さらには2倍になります。研究者としての私の目標は、できるだけ早く次の会社にジャンプすることです。リーダーからの辞任をいつ申請するかはわかりません。私は時間と労力をかけて再構築に費やしています。どうして？リファクタリングは賃金を上げません。うまくいかなくても、責任を負わなければなりません。これはR＆Dの人が持つべき精神ではありません。職人技、ジョブホッピングは短期的な目標を達成できるかもしれないとよく言われますが、長期的には、優れた職人技と優れた技術とデザインがさらに前進するための基礎となります。研究開発の経歴もあります。長年研究開発をしていなくても、技術の初期の研究開発を常に手伝うことができました。これは、研究開発担当者とのコミュニケーションを円滑にするだけでなく、より重要なことでもあります。仕事に対する真の姿勢と卓越性の原則を育むことができたのは、テクノロジーへの熱意と追求です。リファクタリングは良いのですが、どのようなタイミングでしょうか。マーティン・ファウラー（アジャイルマニフェストの起草者の1人）「リファクタリング：既存のコードの設計の改善」では、リファクタリングの良い機会がいくつか与えられています。それらのいくつかをあなたと共有します。
- 3回のルールは 、いわゆる2回繰り返し、3回なしです。1回で2回間違えることはありますが、3回目は間違えないでください。間違えたときは経験を積む必要があります。コード設計についても同じことが言えます。もう一度1か所書きましたが、3回目も同様のロジックを書き直す必要がありますか？現時点では、共有可能なメソッドを抽象化するためのリファクタリングを検討してください。
- 関数の追加 既存の関数にメソッドを追加する場合、元の関数が要件を満たしてはならないことを意味します。これは、元のデザインを改善する良い機会であり、その後の関数の追加にも便利です。後で機能を追加するのはあなたではないかもしれませんが、フォローアップ担当者による元のデザインの認識と評価を考えると、これが職人の幸せの源です。
- エラーの修正 コードにエラーがある場合、元のデザインでこのエラーを見つけるのが簡単ではない理由を教えてください。私のデザインを最適化して、そのような問題があることがわかるように簡略化できますか。これは誇張かもしれません。 、しかし、これはあなたが働く必要がある場所です。
- レビューレビュー コードレビューは非常に効果的な品質改善活動ですが、提供する機能をパートナーにすばやく理解してもらいたい場合、レビュープロセスをより効率的にしたい場合は、コードレビューで常に見つけることができる場合は、リファクタリングを検討してください。コードに問題がある場合は、問題が修正されたときにリファクタリングアクションを追加してください。
ペアプログラミング
结对编程进行起来也比较简单，一个人写代码一个人看，但是不是简单的看，是要思考、要能够发现问题、要互相讨论，而且这个过程要进行角色互换，笔者觉得结对编程的时间不宜过长，我们可以选择在每天的工作时间中选择几个小时进行结对，如果全天都做结对编程，这个是比较难以开展的，而结对编程能够带来的好处可以概括为如下的几个方面：工作备份 结对编程的形式，可以让两个人对工作都有充分的理解，如果一个人休假或离职，另外一个人可以完美对的接替工作，如果遇到任何问题也可以互相讨论，加速问题的排查和处理；持续评审 代码评审的重要性不言而喻，而结对编程是把评审工作做到极致的一种体现，每写一段代码都有人帮你做检查，有问题就可以互相讨论并进行优化，这样的效果一定是好的，但如果您的团队暂时无法做到结对编程，那退而求其次在线的结对评审或许可以尝试一下。知识共享 结对编程不仅仅是保证质量的手段，同时也是知识共享的好机会，两个人结对的过程可以学习对方的编程思路和设计模式，通过讨论也能够加深对设计的理解，长此以往在能力提升的角度也会产生很好的效果；互相监督 或许从敏捷的角度来说我们并不提倡监督，以为敏捷强调信任和尊重，但是不得不说，这样的实践确实也起到了监督的效果，想象一下旁边一直坐着一个人你还哪里好意思偷懒呢，但是毕竟这样会让人觉得被监视，会产生疲劳，所以像开头我们说的，推荐的做法是每天结对一段时间即可，没必要长期结对。但是结对编程其实是有前提的，通过上面的描述大家一定会有一个疑问，这样的方式领导会认可吗？确实在实际的工作当中很多组织都不太认可这种方式，因为领导的直观感受是结对是浪费资源，两个人做一个人的事效率太低了，所以结对编程的第一个大前提就是领导要认可。
而第二个非常关键的前提是结对双方的能力差距要小，这个其实很好理解，一个大神写代码菜鸟认真的看可能也会看不懂，而菜鸟写代码大神看到后可能会抓狂，最合理的是结对的双方能力可以接近一些，避免上述尴尬情况的产生，想象一下你考驾照的时候教练为什么骂你骂的那么凶？当然，也有一种特殊情况，就是老人带新人，当公司有新人加入时，结对编程是让新人快速了解的好手段，这个时候就可以忽略能力差距这个事情了，不过为了新人的成长大佬要有足够的耐心，否则几天之后新人被你骂走了又得不偿失。
测试驱动开发
“什么！还没开发就要测试？”
想象一下，工人在砌墙的时候，是要先拉一根绳的，作为参考可以确保砌的墙是直的，而我们的研发过程呢，是研发人员先花费大量的精力写代码，写好之后丢个测试，让测试量一量墙是不是直的，为什么研发过程不能先给出标准再按照标准进行开发呢，测试驱动开发就希望能够构建这样一种模式。测试驱动开发意味着你要先写一个单元测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续。这个步骤中有两点是需要注意的：恰好够用的代码是指我们写的代码要足够精简，冗余的代码即为浪费；重构 代码测试通过之后就要进行重构，是因为最开始的目的只是为了让测试能够快速的通过，而并没有过多的考量设计，重构的动作就是为了优化设计，这样想的话上面说的重构的时机是不是又可以增加一条了？经过上面的描述，我们初步认识了什么是TDD，那为了加深大家的理解我们通过下图的总结来对比下传统模式和TDD的区别：
- 传统方式是：编写方法→编写测试案例→执行测试案例→修复缺陷;
- 而TDD的模式是：编写测试案例→运行测试案例（注定失败）→编写方法以满足测试案例→执行测试案例→如果失败则修复缺陷→成功则进行重构。
所以我们上述的TDD更确切的叫法应该是UTDD。那既然有UTDD还有没有别的TDD呢？当然有，还有ATDD(验收测试驱动开发)，验收测试驱动开发相比UTDD来说更加强调客户合作，既然是验收测试那一定是客户给出的验收条件才具有说服力，我们需要通过与客户协作确定验收标准，这个标准具体来说要体现在用户故事的验收条件中，而关于ATDD的进一步延伸就不得不提到BDD（行为驱动开发）【读者现在应该已经表情失控：还有完没完了？】；行为驱动开发帮助我们把验收条件标准化，要求遵循GWT模型（Given-When-Then），并且现在已经有一些工具可以支持BDD开发，结合工具的使用我们可以实现按照规定的格式用自然语言描述需求，工具帮我们转化为代码，在此基础上我们可以完善测试用例和功能实现，做到了需求与测试案例和功能的一致性，虽然听起来是美好的，但是业务和产品真的能按照你的工具要求描述需求吗？这也是一个需要深入讨论的问题。
持续集成
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。--Martin Fowler
从狭义的角度来说，持续集成是让研发人员之间的代码能够持续的集成在一起，以便能够快速发现问题，从广义上来说，持续集成也代表了研发、测试和运维各个团队之间工作的集成，如下图所示
研发人员从仓库获取最新的代码版本后进行编码，完成后应该在本地进行测试验证，没有问题后要拉取仓库中最新代码进行二次验证，完成上述步骤后可以将代码提交到版本库当中，根据提前制定的触发机制，持续集成服务器会进行代码构建，除此之外这个过程中可能还包括了代码质量扫描、自动化单元测试和一定量的验收测试任务，待任务执行完成后将结果通知给研发人员，这个结果不管是成功的还是失败的，通知的动作都不可忽略，而当构建失败之时，团队需将修复失败的构建作为第一优先级的任务，也就是精益生产中安灯拉绳的概念，一切要停下来，待问题解决后才可以继续，避免在存在问题的代码基础上持续更新，造成问题的积累，而之所以叫持续集成肯定是希望这个集成的周期越短越好，短的集成周期可以带来如下好处：
提高产品质量
缩短交付周期
建立团队信心
为持续部署打好基础
上記のメリットはわかりやすいので、ここでは詳しく説明しません。継続的な展開について説明したので、継続的な統合、継続的な配信、継続的な展開の違いについて簡単に説明します。継続的な配信は、提供された機能を開発環境、テスト環境、および実稼働前環境に展開するための継続的な統合に基づいています。継続的な配信を提供する能力があることの証拠であり、継続的な展開は私たちをより強調します実稼働環境への機能の展開を自動化し、フィードバックを高速化し、実装の程度に関係なく、配信機能から顧客の要件を迅速に満たす機能に注意の焦点を変更する機能。各リンクはフィードバックの問題を強調します。統合、建設、配備の結果は、責任者に適時に通知する必要があります。このプロセスを多くの効率的な方法と組み合わせて、アラームなどで建設結果を表示したり、電子メールで担当者に通知したりするなど、情報の適時性を実現できます。インスタントメッセージを送信するためのインスタントメッセージングツールは、すべて可能な方法です。著者の観点からは、多くの従来の企業（金融など）での継続的な展開は依然として理想的です。結局のところ、本番環境とリリース環境は、承認フロー、コンプライアンス要件、企業に共通のセキュリティ要件など、多くの制約の影響を受けます。同時に、グレースケールリリースやブルーグリーン展開などのメカニズムも考慮して、プロダクションリリースのリスクを制御できるようにする必要があります。つまり、理想が必要です。それが実現されたらどうなるでしょうか。上記の内容から、上記の内容に加えて、自動テスト、完全構成管理、環境管理、バージョン管理など、プロセス全体の管理において改善が必要な多くの基本的なタスクがあることもわかります。ツールだけの問題もメカニズム確立の問題です。近年普及しているDevOpsのコンセプトと相まって、文化、プロセス、考え方などの変化を考慮する必要があります。XPでの実践については、最初にこれらのタイプを簡単に紹介するので、最後にトピックに戻ります。エクストリームプログラミングの限界は何ですか？1.コードレビューが役立つ場合は、任意のタイムペアプログラミングでレビューします。2。テストが役立つ場合は、さらに多くのことを行い、早期自動テスト、TDD、ユーザー受け入れテストを行います。3。デザインが役立つ場合は、定期的に行う-リファクタリング; 4。統合が重要な場合は、継続的に行う-継続的な統合。
したがって、あなたはエクストリームプログラミングを持つに値します！
