Clever Geek Handbook

テクライドの役割について

この記事の対象者



これは主に、ソフトウェア開発チームの技術的リーダーと、1つになろうとする人々向けの記事です。 そして、もちろん、トピックに興味を持っている残りのために。 技術リーダーの役割に関する意見に興味がある人、およびこのテーマに関する自分の考えを共有したい人のために。



次に何を議論しますか？ 基本的に、これらは技術リーダーの役割、彼の仕事の重要なポイント、およびアーキテクチャとモジュール性についてのかなりの部分についての考えです。



画像



私についてかなり


ソフトウェア開発で15年以上。 外国企業とロシア語の両方で、食品会社とアウトソーシングの両方での実務経験。 テクニカルリーダーやアーキテクトなど、さまざまな役割。



テクライドとは



会社とプロジェクトに応じて、技術リーダーの役割について異なる理解があります。 技術的な面で有利な場合もあれば、管理面で有利な場合もあります。 通常、この人は、アーキテクチャ、コードレビュー、技術的な問題の解決、開発者の作業の調整に従事し、自分で何かを実装することもできます。 建築的側面は、建築家、調整者、管理者が部分的または完全に引き継ぐことができます。 それはそうかもしれませんが、あなたの同僚があなたに何を期待しているのかを明確に理解することが重要です-マネージャーと他のすべての関心のある人々の両方。 期待の不一致は、あなたに対する自信を低下させ、その結果、あなたとチーム全体の両方の作業効率と動機付けを低下させる可能性があります。 期待に応える方法の1つは、問題の責任者がわからない場合、マネージャーを演じ、適切な人を見つけることです。 彼がそれをすることを確認してください。 また、いくつかの質問を引き継ぐことができ、また引き継ぐ必要がありますが、常に能力を評価し、自分自身に過負荷をかけないでください。スプレーしすぎると、効果が低下する可能性があります。 この柔軟なアプローチにより、プロジェクトの全体的なステータスをよりよく理解することもできます。



チームメンバーの役割を理解することは、コミュニケーションが少なければ少ないほど重要です。 言い換えれば、同僚の一部が別の都市や国で働いている場合、仕事のスケジュールがあなたのスケジュールと重なっていない場合、誰かが異なる言語でコミュニケーションをとる場合、これらすべてが非公式に問題の解決を妨げます。 この場合、どの問題について誰に連絡するかを理解することが、効果的な仕事のためにさらに重要になります。 この場合、チームが受け入れて理解できる便利なプロセスの重要性も高まります。



テクニカルリーダーとして何をすべきかを判断しましょう。





この役割に非常にうまく対処することを学び、次に何をするかを考えたとします。 直観は、経営陣に移行するか、自分のビジネスを開始するように促すこともできます。 おもしろそうなものをすべて試してください。 1日の限られた時間を覚えておく必要があるのは、そのため、1つのことでより多くのことを始めた場合、他の何かでより少なくすることを強制します。 より管理的な作業-技術的ではありません。 別の開発オプションはアーキテクトです。 あなたは少なくとも部分的には技術的リーダーとしての彼の役割を果たさなければなりません。 したがって、条件付きで言えば、管理の瞬間を減らして技術的な瞬間を増やすと、建築家の方に移動します。 これらの動きを上昇または下降としてではなく、あなたにとってより興味深い活動の領域に焦点を当てるように見てみてください。



プロセス



今日、ほとんどの人はプロセスが何であるかを知っており、彼らは柔軟な方法論を使用しているか、少なくとも聞いています。 なぜプロセスが必要なのですか？ たとえば、チームをより効率的および/または予測可能にするため。 プロジェクトのタイミングを予測するのは難しいですか？ 異なる開発者がランダムに独立して同じタスクを引き受けますが、1週間後に他に何を学びますか？ 解決策がチームの他の誰かに既に知られている問題に埋もれていることもありますか？ これらの質問または類似の質問のいずれかに「はい」と答えた場合、プロセスの改善を検討する必要があります。 そして誰もがこれに興味を持つべきです。 技術的リーダーは、技術的な面でいかにクールであっても、プロジェクトが失敗した場合、賞賛を待つことはできません（最初は陰湿な計画でない限り）。



プロセスの重要性を理解し、何らかのプロセスセットも持っているとします。 まあ、それは素晴らしいことですが、すべてが変化していること、タスク、ツール、人々を忘れないでください。 まだ改善できるものを分析します。 技術者として、自動化のトピックは私たちに近いはずです。 サーバーの更新に多くの時間を費やす-自動更新を検討してください。 多くの場合、コードを中断します-コミット時に自動的にビルドして検証します。 自動化により、プロセスが大幅に促進され、効率が向上します。



複雑さとの闘い



通常、アーキテクチャは高レベルのシステム構造であると考えています。 仕事の過程で事前にそれを解決するか、それについてまったく考えない-あなたが決める必要があります。 他の誰かがシステムを使用している場合、それを説明する最新のドキュメントを用意しておくと便利です。 一方、システムが小さく、ソースコードが理解できるほど単純な場合、他の人が追加のドキュメントを必要とすることはないので、ドキュメントの作成と保守に時間を無駄にしないでください。 なぜ私たちは通常、システムまたはアルゴリズムの高レベルのスキームを描くのでしょうか-おそらくいくつかの重要なポイントを研究するために条件付きでシステムを単純化するためでしょう。 簡略化されたスキームから、より詳細で直接的なソースコードスキームの研究に進むのがはるかに簡単です。 チームがアーキテクチャを理解することのプラスは、コンテキスト（開発されたコードが実行される条件）を知ることです。 場合によっては、これはシステムの販売にも役立つ場合があります。一部の顧客は、アーキテクチャが理解できるか、少なくとも隠されていない製品を信頼します。 しかし、一般的に、これはシステムの複雑さの増大に対処する私たちの方法です。 数キログラムの新しいコードがありますが、必要なレベルの品質、サポート性、拡張性、およびスケーラビリティを提供したいと考えています。



設計する際、実証済みのソリューションがすでに存在する問題に遭遇することがよくあります。 アーキテクチャのパターンと原則についてです。 あなたがそれらに精通していないか、それらに慣れていない場合は、それらを勉強することをお勧めします。 解決策だけでなく、これまで考えもしなかった問題もよく見ることができます。 さらに、チーム内および他のチームや企業の同僚と同じ言語を話すことができます。



モジュール性



いくつかの新しい機能に取り組んでいる間、回路やその他の情報をどれだけ覚えておくことができますか？ 彼らがいくらであっても、なんとかそこに置く必要があります。 つまり 必要な情報が多いほど、収集してスタックする可能性が高くなります。 これは、ビジネスの過程に入り、独立して仕事をする機会を得るために、以前に製品で働いたことがない人に必要なエントリーの時間になります。 プロジェクトの変更の頻度に応じて、今回はあまり気にすることもありません。 さらに、情報が多ければ多いほど、混乱したり、何かを忘れたり、何かを考慮に入れたりすることが容易になります。 この概念的にシンプルなアイデアは、しばしば十分な注意が払われず、拡張、維持、およびテストが難しいかさばるモノリシックモンスターになります。



モジュールとは何ですか？ これは、独自のプロセスで実行されるアセンブリまたはアプリケーション、ソースコードファイル、またはその一部です。 これが明確な境界と外部インターフェイスを備えた製品の一部であることが重要です。 私たちは通常、モジュールの独立性とモジュール間のインターフェースの最小化に努めています。



モジュールへの分離はどのように役立ちますか？





もちろん、アイデアは新しいものではありません。 もちろん、マイナス面もあります。 そしてもちろん、ここでは特定の行を探す必要があります。 いずれの場合も、彼女は自分のものにすることができます。 分析して試してください。



分解する1つの方法は、階層化アーキテクチャに私たちを動かします。 さまざまな意味を持つさまざまな数のレイヤーがありますが、一般的な考え方は、各レイヤーはその直下のレイヤーでのみ機能するということです。 たとえば、データアクセス、ビジネスロジック、およびプレゼンテーションのレイヤーがあります。 プレゼンテーション層は、ビジネスロジック層のみを使用し、データアクセスは使用しません。 ビジネスロジックはデータへのアクセスのみであり、表現ではありません。 また、データアクセスレイヤーは他のレイヤーを使用しません。 したがって、いくつかの外部インターフェイスと依存関係を持つ3つのモジュールを取得します。 これは垂直方向の分離です。



別の別の方法は、マイクロサービスに近づけることができます。 これらは、製品を形成する本格的なサービスまたはアプリケーションですが、互いに独立して条件付きで動作します。 これは、次のようにユーザーに対して完全に透過的です。 あるサービスはユーザーを別のサービスにリダイレクトする可能性があります。 ポータルがあり、その一部が注文に対応し、もう1つが顧客に対応しているとします。 異なるアプリケーションになる可能性があります。 これはまだ1つの製品であるため、何らかの方法で共通データを共有する必要がある場合があります。これは、たとえば、共通データベースを使用するか、あるアプリケーションのデータベースから別のデータベースにデータを複製することで実現できます。 これは水平分離です。



垂直および水平の両方の分離では、分離の複雑さがプラスの効果によって正当化されるように、必要な分離の程度を見つける必要があります。 システムのスケーラビリティ要件も考慮してください。 水平方向にスケーリングする必要がある場合、水平方向に分離することで柔軟性が高まります。 モジュールのテスト容易性により、垂直方向の分離を改善できます。 一方、モジュールへの深刻な断片化は、モジュールの統合、構成、および展開を複雑にする可能性があります。 製品に適した戦略を探してください。



おわりに



そのため、技術リーダーの役割と彼にとって重要ないくつかの問題について少し考え、アーキテクチャに少し触れました。 私たちの機能の1つは批判的思考ですので、受け取った情報をあなた自身の経験のプリズムを通して伝え、自分のために何かを引き出すようにしてください。 記事のトピックに関するあなたの意見やアドバイスも、私にとって非常に重要です-コンテンツとプレゼンテーションの方法の両方について。 今のところすべてです。


More articles:


All Articles