親愛なる友人
私たちは、経験を共有するために、支払いシステムの開発について長い間話したいと思っていました。 最後に、連続コーディングの時間が過ぎ、情報を構造化する少しの時間が現れました。 だから、私たちはどのように私たちの製品を作ったか教えてくれます。
Paylerは、比較的短期間で開発されました。 さまざまなプロセス管理手法を試しましたが、チームの現実では、いくつかの管理システムに従います。
前文：「今日のPaylerとは？」
●主な製品コンポーネント：不正防止、ゲートウェイコア、パブリックおよび内部API、処理モジュール、販売者管理インターフェース、モバイルクライアント、内部ユーティリティ。
●製品は数か月前で、PCI DSSコンプライアンス証明書を取得し、最初の顧客が登場しました。
●使用されるテクノロジー：C＃、Python、Ruby、MySQL、Redis、Angular.jsなど。
●チーム：
○バックエンド：コンポーネントを定期的に切り替える3人の開発者。
○フロントエンド：1人の開発者。
○モバイル：2人の開発者-1人のiOS、1人のAndroid。
○システム管理者。
次に、開発プロセス自体について詳しく説明します。
1.非技術的な慣行
まず、作業プロセスの編成、チームメンバー間のやり取り、結果の評価などの観点から開発したプラクティスについて説明します。
タスクの追跡とドキュメントの保存
歴史的に、アトラシアン製品は当社にしっかりと定着しています。 タスクにはJira + GreenHopper、ファイルにはConfluence +ドメイン内のGoogleドライブの組み合わせを使用します。
サイクル
これには、かんばんを使用します。 チームはコンポーネント内のタスク間で変更する必要があるため、リリースとバグ修正を迅速にリリースする必要があるため、この方法論が最適です。 重大なバグ修正は日中にリリースされ、残りは深夜またはトランザクションアクティビティが実質的にない早朝に展開されます。 新しい機能は、週に1、2回程度登場します。
成績
支払いゲートウェイの開発は多くの要因に依存しますが、その主な要因は銀行とその処理センターとの相互作用です。 したがって、特定のタスクの一時的な評価を行うことは基本的に困難ですが、可能な場合、たとえばモバイルアプリケーション、管理室などでは、引き続き実行します。 他のケースでは、より重要なことに集中しようとします。
ラリー
一部の機能のフレームワーク内で必要な場合にのみ実行します。 それ以外の場合は、避けるようにしてください。
労働時間
従業員の時間は追跡しません。 スケジュールは比較的柔軟ですが、1つの必須ルールがあります-営業日の開始は11:00までです。 主なことは、割り当てられたタスクの履行です。そのため、この点に関して、自分自身を制御する方法を知っている人にとっては良い条件があります。
ミニチーム
タスクに応じて1-2人。 しかし、これでは不十分になりつつあるため、ミニチームで3〜4人の計算に基づいてチームを構築するよう努めています。
2.技術的な慣行
ここでは、技術タスクに関する開発に適用するいくつかのプラクティスについて説明します。
ペアプログラミング
まれに、複雑な問題を解決するために使用します。 2つのヘッド、2つのモニター。
バージョン管理
多くの企業と同様に、私たちはGitが大好きで、新しい機能を追加したり、バグを個別のブランチに修正したりします。 マスターでは、リリースバージョンが反映され、開発では、その日の変更を含むバージョンが反映されます。
テスト
私たち（開発者）は自分でテストを作成します。 C＃で記述されたシステムの一部については、TDD（XUnit）から始め、ゆっくりとBDD（SpecFlowなど）に移行しました。 また、銀行からの応答をテストするためのPythonテスト、API、Rubyプロジェクト用のBDD（RSpec、Cucumber）およびモバイルクライアントコード用のユニットテストも行っています。 現在、Angular.jsでフロントエンドのプラクティスを実装しようとしています。また、70〜80％のカバレッジを目指しています。
PSところで、ブリャンスクでは、サーバー開発者（C＃/ Java、Ruby / Python、Go）、JavaScript開発者、iOS開発者が非常に必要です。 ここに住んでいて、これらの専門分野で仕事を探している場合は、 hello @ payler.comまでご連絡ください 。
次の投稿では、Billingrad SMSゲートウェイの開発に専念し、ベストプラクティスを共有します。 コメント内のご質問にお答えいたします。
愛をこめて
支払人