大規模なコードベースのプロジェクトでどのようなスキルを引き出すことができるか

歴史のあるプロジェクトで生き、発展する方法。開発者に大規模なコードベースでの作業の経験を与えるもの、および本当に必要な場合でも、すべてを最初から書き直す必要がない理由。

コンテンツ

1. このテキストは誰のためのものですか
2. ストーリープロジェクトから学べること
3. インタビューで尋ねる質問
4. レガシープロジェクトでの作業を始めたばかりの人のためのヒント
5. 簡単に

私はPavelNovikovです。モバイルアプリケーション「MyOfficeDocuments」と「MyOfficeMail」の開発に携わっています。これは、2013年に作成が開始されたドキュメントやメールクライアントとの連携のためのアプリケーションであり、レガシーを含む場所が存在する大規模なコードベースのプロジェクトと呼ぶことができます。



ここで説明する経験は、モバイルアプリケーションでの作業だけでなく、アプリケーション開発全般に適用されます。

小さな子供のための免責事項

この記事では、これまでの経験に基づいて、自分の仕事についての考察を集めました。この種の記事は常に非常に主観的です。私の観察と矛盾する経験を持つ人々がいると確信しています。コメントでこれらの不一致について話し合っていただければ幸いです。

このテキストは誰のためのものですか

このテキストは、自分自身をジュニアレベルと考える人と、ミドル/シニアカテゴリに分類される人の両方を対象としています。



開発のあらゆるレベルで長期的なプロジェクトを扱うことから学ぶことはたくさんあります。レベルを理解する上で同じ波長になるには、Vastrikaの投稿を読んでください：ログインとK-チーム。私は彼の開発者層の分類が好きで、将来はそれに固執します。



次のブロックでは、長いプロジェクトの各レベルの用途を簡単に分析します。

ジュニア

ジュニア開発者の仕事は、技術スキルの開発を最大化することです。言語、フレームワーク、ライブラリ、開発アプローチなど、すべてが使用されます。強力なチームを持つプロジェクトでは、さまざまな問題を解決する方法を学ぶことができます。



しかし、成熟したプロジェクトでは、第一に、あらゆる領域を深く掘り下げる機会があり、第二に、成功した決定と失敗した決定の例を研究することができます。他人の過ちから学ぶことは費用がかかります。特に、これらの間違いの意味とそれらを回避する方法を詳細に説明できる経験豊富な同僚が近くにいる場合は特にそうです。

中間

中間開発者の仕事は、その自律性を高めることです。プロジェクトのほぼすべてのタスクで信頼できるチームメンバーになる必要があります。これは、プロジェクトのタスクが多ければ多いほど、潜在的な成長分野が増えることを意味します。

上級

シニア開発者の仕事は、あなたがコードに対して支払われるのではなく、問題を解決するために支払われることを完全に理解することです。時には（これまでのところさらに頻繁に）コードを書くことを通して、時には他の開発者を管理することを通して、時には非開発者とのコミュニケーションを通して。成熟したプロジェクトは、解決できる、または解決する必要のあるタスクの単なる保管場所です。



次に、既存のプロジェクトから学ぶことができるいくつかのことについて詳しく説明します。

そして、ここでレガシー？

まず、用語を理解する必要があります。「レガシー」の概念はずっと前に否定的な意味合いを獲得しましたが、レガシーコードは正確に何が悪いのでしょうか？



R7K Research＆Conveyanceの創設者であるMichael Feathersは、レガシーコードはテストでカバーされていないコードであると主張しています。このアプローチの利点は、一見、客観的であると主張することです。しかし実際には、2つのシナリオが考えられます。

• テストはありますが、記述が不十分です。混乱し、壊れやすく、明確に構造化されていません。
• ベンチマークはありませんが、コードは非常によく設計されています。これにより、比較的安全に変更することが可能になります。その場合、将来的にテストをすばやく作成できます。

開発者DrorHelperからのレガシーとは何かを もう一度見てみましょう。もはや設計されていません-継続的にパッチが適用され、ハッキングされています。 ..。



Web開発者のNicolasCarloは、レガシーコードは扱いにくいコードであると考えています。



これらすべてから、レガシーはコードの主観的な特性であると結論付けることができます。コード自体は機能する場合と機能しない場合がありますが、効果的に変更できない開発者が現れると、レガシーになります。



レガシーを評価するためのもう1つの比較的客観的な特徴は、「プロジェクトにサポートされていない依存関係がありますか」という質問への回答です。コードは、特定の廃止されたコンパイラバージョンでのみビルドできます。または、作成者自身が外部ライブラリにパッチを適用し、それがメインプロジェクトの一部になりました。この場合、確かに、プロジェクトは具体的になり、それをサポートするために追加の努力が必要になります。



一般に、プロジェクトが6か月以上経過している場合は、レガシーが含まれている可能性があります。

ストーリープロジェクトから何を学ぶことができますか？

それで、あなたは決断を下し、あなたの前にすでにコードが書かれていて、他の多くのことが起こっていた会社に就職しました。プロファイルをアップグレードするために新しい場所に行く必要はないことを付け加えておきます。レガシーはすべてのプロジェクトで最も可能性が高いです、あなたはそれを評価する方法を知る必要があるだけです。そして、私が話していることは、あなたが今取り組んでいることに確かに当てはまることができます。



ポンピングはどの分野であなたとプロジェクトに等しく役立ちますか？ここで、プロジェクトが痛いところを開発するときの状況は、相互成長にとって理想的な環境であることを理解する必要があります。なぜなら、あなたがいくつかの左派的なことに取り組むことで成長するならば、これはあなたにとって個人的にプラスかもしれませんが、同時に、会社がこれであなたを助けるべき理由を説明するのは難しいでしょう。

プロジェクトを分析する

遺産プロジェクトから最初に学ぶことができるのは、それを分析することです。ドキュメントとのギャップがある、またはまったくないプロジェクトに来たとしましょう。この場合、プロジェクトのソースコードしかないため、プロジェクトを分析し、その構造と本質をすばやく理解できることが重要です。ナビゲートする方法を学ぶのが早ければ早いほど、プロジェクトの利益になり始めるので、これは重要です。



プロジェクト分析をより深く理解するために私がお勧めできる最も重要なことは、MichaelFeathersによる「WorkingwithLegacyCodeEffectively」という本を読むことです。彼女は年をとって有名です。レガシーコードを操作するための多数のプラクティスについて説明します。



もう1つのヒントは、Understand LegacyCodeのWebサイトにアクセスすることです。..。これは、レガシーの操作という1つのトピックに特化したブログです。そこでニュースレターを購読できることが重要です。多くのAndroid開発者は、AndroidWeeklyとKotlinWeeklyのメールについて知っていると思います。ULCニュースレターも非常に役立ちます。リファクタリングとコーディングに関するハウツー記事があり、邪魔になりません。

リファクター

レガシープロジェクトは、リファクタリングスキルを練習するのに最適な場所です。問題が発生している可能性が最も高いプロジェクトにたどり着き、それを変更するだけでなく、改善、拡張、および新機能を確認する必要があります。どの程度適切かつ効率的にリファクタリングできるか（迅速かつわずかな回帰で）、開発者がどれだけ有用で優れているかが決まります。



健全なエンジニアリング文化を持つ成熟したプロジェクトでは、リファクタリングは開発の継続的な一部である必要があります。



あなたはあなたが取り組んでいる製品が好きでなければなりません。自分で使えば完璧です。この場合、あなたは長い間その品質を改善することに取り組むという内部の動機を持っているでしょう。

アーキテクチャの設計と作成

この点は前の点に続くものです。必然的に、ソフトウェアの設計とアーキテクチャを強化する必要があります。適切な開発文化があれば、厳しい締め切りで主要な建築上の決定を下す必要はありません。アーキテクチャを設計する時間があり、それをうまく行うのはあなたの責任です。私はいつもここで何をお勧めしますか？本を読む。



本は他の情報源と同じくらい重要だと思います。本から得られる経験が多ければ多いほど、一般的な問題を解決する方法をより早く理解できるようになります。本に見られる典型的/典型的な問題に対する典型的な解決策は常にあります。あらゆる種類のレガシーを扱うには、典型的な問題を解決することも含まれます。

(Robert C Martin). « », « »

(Martin Fowler). «. »

UML — .



PlantUML (PUML) — , UML-. git, , .

あなたが完全に理解していない製品で作業するとき、あなたはどういうわけか行われるべき作業を評価する方法を学ぶ必要があるでしょう。そして、あなたはいつもあなたが知らない何か、いくつかの落とし穴を持っているでしょう。



大きくて複雑なタスクを相互接続された小さなピースのセットに分割する機能は、非常に貴重なスキルです。それを開発する1つの方法は、分解と推定のエラーに継続的に遡及的に取り組むことです。分析の過程で、頻繁に発生するエラーからチェックリストを作成できます。将来、彼はあなたがこれらの間違いを再び防ぐのを手伝うことができるでしょう。

自動化してCI / CDを適用できるようにする

コードを書いた瞬間からユーザーのデバイスに到達する瞬間まで、コードに何が起こるかを理解する必要があります。また、CI / CDを自動化してカスタマイズ、保守、および改善することができます。専用のインフラストラクチャチームがない企業では、これらの操作はコア開発チームのメンバーが決定することができ、決定する必要があります（私はこれを確信しています）。最新のツール（クラウドCI、Docker）はそれほど複雑ではありませんが、チームの生活を大幅に簡素化します。これらのスキルを習得すれば、彼女のために多くのことをすることができます。

コミュニケーションをとること

責任が多ければ多いほど、より多くの人とコミュニケーションをとる必要があります。ソフトウェア開発は長い間個人の多くではなくなりました。ほとんどすべての大規模なプロジェクトはチームによって行われます。繰り返しますが、周囲の人々との交流をより効果的に学ぶほど、より多くの利益をもたらすことができます。



あなたはあなたより賢くて経験豊富な人々とコミュニケーションをとる必要があります。大規模なプロジェクトでは、多くのことを学ぶことができる「昔の人」が常にいます。また、あなたはあなたよりも愚かな人々に会うでしょう。良いニュースは、あなたが自分の精神的能力について間違っている可能性が高いということです-そのような知覚の誤りを訂正できることは非常に役に立ちます。



コミュニケーションスキルの開発は、共感の開発に還元できると思います。あなたがあなたの周りの人々の動機と目標を理解することをよりよく学ぶほど、あなたは彼らに早く役立つことができます。たとえば、リファクタリングと技術的負債への取り組みのメリットをビジネスに説明するときは、プログラマー用語ではなくビジネス用語を使用する必要があります。一見当たり前のことですが、賢い人が他の賢い人とコミュニケーションを取り、お互いを理解できないことを繰り返し見てきました。

インタビューで尋ねる質問

ここでは、私があまり知らないプロジェクトに取り組む前に、どのような質問をするかから始めます。

ワークフローの仕組みとその理由

通常、現在はスクラムまたはカンバンシステムで動作します。しかし同時に、彼らはしばしば彼ら自身のためにそれらを適応させます：「彼らは最善を尽くし、不必要なものを捨てました」。問題は、彼らは正確に何を捨て、何を残したのかということです。開発プロセスの基礎となるスクラムガイドには、非常に興味深く有用なプラクティスがいくつかあるためです。



それらは、最初に、意識的に、そして次に、すべてが適用されるときに適用されるときに意味があります。それらはそれ自体を制御するシステムを構成し、プロジェクトだけでなく独自のプロセスも繰り返し改善できるようにするためです。



たとえば、チームがスクラムに取り組んでいる場合、前回の回顧で何が議論されたかを尋ねます。この会議でチームはどの程度活発ですか？提起された問題は解決されていますか？



内部プロセスに関するもう1つの興味深い質問は、チーム内でコードレビューがどのように実行されるかです。時間を短縮するのに役立つレビューを実施するための内部ルールはありますか？毎回満足しないようにホリバーの結果を入力する共通の知識ベースはありますか？

計画の仕組み、関与者、チームの積極性 

これは、チーム内のエンジニアリング文化がどれほど強いかを確認するために私が尋ねる質問です。チームリーダーのみが計画していて、チームが彼の側にいる場合のオプションがあります。

もう1つのオプションは、チーム全体が計画に参加する場合です。そして、タスクが来ると、それはこの問題について十分な専門知識を持っている誰かによって取り上げられます。そして、彼ら全員が話し合い、決定を下します。これにより、チームはより自己組織化され、ワー​​クフローがより楽しくなります。

チームの何人が全体像を把握していますか

ここでは2つの極端な可能性があります。最初の極端な例は、過去2〜4年間製品に取り組んできたチームに来たときです。同時に、チームがあまり変わらず、拡大しただけの場合、これは非常に良いことです。なぜなら、助けを求めることができる人々が常にいるからです。彼らは何かを提案し、理由を説明し、プロジェクトの歴史を教えてくれるでしょう。コンテキストと、すべてがこのように配置されている理由を知ることは非常に重要です。



2番目の極端な例は、最初に参加した人がいないチームに来たときです。たとえば、プロジェクトは凍結され、凍結されておらず、大きなコードベースが残っていました。最初から書き直すことはできません。したがって、開発を復旧する必要があります。つまり、すべてをもう一度掘り下げる必要があるプロジェクトを取得します。



この情報に基づいて、そこに行きたいかどうかについてより多くの情報に基づいた決定を下すことができ、答える必要のある提案に対する要件のいくつかを過大評価する可能性があります。

技術債務のバックログはどのように維持されますか

どのプロジェクトにも問題があり、チームがどのように協力しているかを理解することが重要です。私は技術的な負債を扱うことについて非常によく書いたalexanderlebedev記事「ラニスターは常に借金を払う！（そして技術的にも） "。



チームが問題について知っているが、体系的にそれらを処理する方法を知らない場合、これは悪い兆候です。しかし、あなたはこれを、これらの問題を解決するのを助ける人になる機会として見ることができます。

レガシープロジェクトでの作業を始めたばかりの人のためのヒント

急いですべてを一から書き直そうとする誘惑に抵抗する

一般的な状況：既存のアプリケーションで作業を開始し、すべてが「間違って」行われていることを確認します。そして、この「そうではない」場合は、さらに作業する必要があります。この場合、それをもう一度やり直して書き直すのは非常に自然な欲求です。これは正常な反応です。



他人の過ちに答えたがらないからだと思います。結局のところ、変更後に新しい欠陥が発生した場合は、それを把握する必要があります。それを完全に書き直す方が良いです、そしてすべてがうまくいくでしょう。



そのような考えを持っていることに気付いた場合は、いくつか質問

してください。コードに間違いなく十分な問題があるのか​​、それともまだ理解していないのか。

書き直されたコードのすべての統合ポイントを正確に理解していますか？

今後の作業時間を正しく予測するのに十分なプロジェクトを知っていますか？



すぐにすべてを一から書き直すつもりは悪い考えだと私は確信していますが。改善は反復的で管理しやすいものでなければなりません。

チームが「それはすべてでたらめだ、書き直そう」と言ったのを目撃した後、6か月間書き直し、書き直さなかった。その結果、古いチームが脱落したために、新しいチームを採用するためにプロジェクトを最初からやり直す必要があったときに、かなり興味深い状況が発生しました。すべてを最初からやり直したいというこの完全に自然な衝動を消してみてください。

プロジェクトの変更を予測する

あなたは少しオラクルになることを学ぶ必要があります。プロジェクトで長い間作業することで、その製品コンポーネントを理解し、ビジネスを理解し、このプロジェクトがどのように収益を上げ、どのように生きるかを学ぶことができます。これは、あなたが下した決定の長期的な視点を評価する機会を提供します。



これは非常に便利なスキルです。製品の所有者があなたのところに来て、彼の観点から簡単なことをするように頼むのは悪い状況だからです。たとえば、リストを並べ替える新しい基準を追加します。そしてあなたの側から、これはあなたがこのコンポーネント全体を書き直す必要があることを意味します。そのリストをソートするさまざまな方法が完全に論理的な機能であると事前に考えていた場合、これは起こりませんでした。彼女はそもそもそうするように頼まれなかったけれども。



極端に行かないで、常に最も普遍的な決定を下すようにしてください。これは、時間の延長と、そのようなソリューションのさらなるサポートに関する問題への直接的な道です。このスキルの要点は、正確にバランスを見つけることです。

研究を行う

長いプロジェクトに取り組んでいる場合、ビジネスがチームをどれだけ信頼しているかが重要です。主要な機能を開発する前に、私たちは確実に主題分野の本格的な調査を行います。キャプテンのキャプテンのように聞こえるかもしれませんが、人々がすぐに頭を抱えて大渦に突入し、一見単純なタスクが、開発前に調査を行うだけで回避できた長いリファクタリングに変わった場合を知っています。

時間をかけて文書化する

交渉内容、プロセス、アーキテクチャを文書化します。ここで私は、あなたがそれを書き留めなかったなら、あなたは同意しなかったというアプローチに固執しようとします。半年以上かかるプロジェクトでは、情報を失わないことを学ぶことが重要になるからです。



あなたが建築上の決定をするとき、それはあなたにとって明白であるように思われます。なぜそれをどうにかして説明するのですか？ 6か月または1年後、このアーキテクチャソリューションで問題が発生します。そして、あなたはこう思います。「なぜ私はそれを受け入れたのですか？コンテキストは何でしたか？」これらのアーキテクチャ上の決定を書く方法を学ぶことは大きな投資であり、将来あなたの手に渡るでしょう。



このような記録を維持する方法の1つは、アーキテクチャ決定記録です。..。その主なアイデアは、重要なアーキテクチャソリューションごとに、タイトル、日付、コンテキスト、ソリューションの説明、意図した結果など、いくつかの要素を含むファイルを作成する必要があるということです。このファイルはコードとともに保存され、作成後に変更されません。その主な価値は、このアーキテクチャソリューションを変更するときが来ると、それをもたらした動機を理解するのがはるかに簡単になるということです。

簡単に

• 歴史のあるプロジェクトは、開発者がコードの記述だけでなく、プログラマーとしての開発に役立つタスクにも興味を持った場合に成長するのに適した場所です。
• バックグラウンドのあるプロジェクトでは、問題を引き起こすのはコードではなく、人々、つまり、たとえばゲーム開発のように、非常に高速かつ継続的に何かを要求する場合のそのような管理です。
• . , , , .

GDG.