こんにちは 最近、私は学生向けに、最新のWeb開発を行うことでどのような問題に対処できるかについてレポートを作成しました。 開発プロセス中に行うさまざまな決定は、テクノロジーの選択がチームの規模にどのように影響するか、チームの規模がテストへのアプローチにどのように影響するか、テストへのアプローチは会社全体の構造にどのように関係するか...
それは、分散プログラミングの選択を伴う探求のようなものになりました。どのプログラミング言語から選択するのか、そして誰にこれまでで最も有用な製品を作るチームを雇うほうがよいのか。 この投稿を読んで、オプションを選択し、クエストを完了して、何が苦しくなったかを話し合うことをお勧めします。
upd -katに小さなテキストを追加しました。
アイデアからプロトタイプまで
友人のValeraと私がスタートアップを始めることを決めたとします。 XのUberまたはそのような何か。 バーに集まって、このアイデアを議論した、クールなトピック。 それをしなければなりません。 3ヶ月間は眠らず、食事もせず、家を出ませんでした。 開発。 彼らは始めて、誰もそれを必要としていないことに気づきました。
悲しみ。 もう一度やり直しましょう。 今回は、市場を調査し、ユーザーのニーズ、問題を調査しました。 私たちは、完全に膝の上で、2晩で迅速かつ無料でプロトタイプを作成しました。 プロトタイプが離陸しました。 クールだ
技術の選択
これで、プロトタイプから大きなアプリケーションを取り出して作成し、開発することができます。 ただし、このためには、使用するテクノロジーの選択に対して、より深刻なアプローチを取る必要があります。
言語
順番に。 書く言語は？ あなたはファッショナブルな機能をとることができます：Haskell、Erlang、Lisp（70歳以上の祖父の間で非常にファッショナブル）。 または、JSにコンパイルされた非常にクールな別のキラーJSには、必要な機能がすべて備わっています。 しかし、次のキラーJSは離陸せず、再学習するかプロジェクトを書き直す必要があるため、おそらく1年で誰も雇うことができません。
2番目の試み。 時間によってチェックされたものを取ることができます。 たとえば、PHP。 これは良い言語であり、時には批判するのが流行であり、欠点もありますが、ビジネスロジックを実行するのは簡単で、十分に速く、拡張性があり、いつでもどこでも人を雇うことができます。 しかし、彼はあまり生産的ではありません。 そのため、FacebookやVKのように、大量の鉄を使うか、独自のコンパイラを作成する必要があります。
その他のオプション？ Perlを使用できますが、昨日は誰も雇うことができません。 もっと？
Java Javaは標準です。 私の主観的な意見では、言語としてはそれほどではありませんが、JVMは優れた仮想マシンであり、すべて問題ありません。すぐに動作しますが、依然として多くのハードウェアが必要です。 そして、私たちがJavaで戦略ファクトリの抽象的なビルダーを書いている間に、機能を作成する代わりに、ユーザーは競合他社に行きました。
さて、私たちにはまだPythonがあります。 原則として、すべてが大丈夫です。 しかし、私たちはPythonでアプリケーションを実行します。56個のコアのうち1つを使用します。それ以外の場合は...すべて問題ありません。 または、Go、Rust、その他のモダンなものを使用することもできます。 しかし、それらはあまりにも低レベルであり、私たちは長い間機能を実行しています...私たちはまだいくつかの言語を選択する必要があります。 最後にJSにしましょう。
データベース
ベース。 文書ベースのないJS-無駄遣いのないお金。 文書ベースには利点があります。 それらにより、スキーム、ソーセージデータをやり取りすることなく、プロトタイプを迅速に開発できます。 多くのプラス、マイナス1、データからの：があります。 3つではなく10、20、または40個のコレクションがある場合、スキームがなくてもそれらから良い消化可能なものを接着しようとすると、ますます困難になります。 繰り返しますが、私たちは長い間機能を作成しています。
では、リレーショナルベースを見てみましょう。 十分なお金がある場合は、MySQL、PostgreSQL、またはOracle。 リレーショナルデータベースを使用すると、いつか仕事に来て、トランザクションやストレージから地獄にいることができます。 これは、プロジェクトでは必ずしも発生しません。 しかし、そうなると、これらの複雑なロジックをテストすることは不可能になります。 また、データベースをホストする大規模なゴールドサーバーの垂直制限に突然達した場合でも、それらを分離することは非常に困難です。 長い間機能を提供しています。
わかった 彼らはいくつかのベースを取り、ORMをその前で叩き、SQLから別のSQLに簡単に移動できるようにしました。 いつか（ネタバレ：決して）。
建築
どのアーキテクチャを採用しますか？ HabréのGuysは、マイクロサービスはクールだと書いています。 オレグ・ブーニンは「マイクロサービスを利用する」と言います。
マイクロサービスから始めると、80％の確率で、ドメインモデルを十分に考慮しておらず、どこでカットすべきか、どこでカットすべきでないかを十分に理解していないため、境界が間違っています。 さらに、彼らはすべてマイクロサービスを取り、それらをクラスター全体にバッチで展開し、1か月後に「これをすべて今すぐテストできますか？」という疑問が生じます。 サービスは既に実稼働で機能していますが、テストは行っていません。 おなじみの方法論（テストピラミッド、手動統合テスト、エンドツーエンドテスト）を使用すると、マイクロサービスをテストすることは困難です。 したがって、私たちは長い間機能を実行しています。
では、モノリスを叩きましょう。 これはスタートアップにとって正しい考えです。 素晴らしいモノリスで非常に長い時間生きることができ、問題はありません。 しかし、チームを大幅に拡大することに決めた場合は、注意する必要があります。 開発者は20、30、50人ですが、モノリスは通常どおりスケーリングします。さらに、機能の配信速度は指数関数的に低下し、ユーザーを失います。
プロジェクトを開始する場所
すべてをどこかで起動する必要があります。 2018、クラウドでこれを行う最も論理的なオプション。 クラウドで実行しないでください-男の子は笑います。 しかし、第一に、連邦法152があり、ホストできるクラウドプロバイダーの選択が大幅に制限されています。 第二に、GithubのAmazonアカウントに誤って秘密鍵をコミットすることは非常に簡単です。誰かが間違いなく来てすべてのお金を使うでしょう。 そして、これが起こらない場合、ある時点でクラウド関税があなたを破産します。
データセンターをレンタルできます。 おそらく最初はそれほどリソース効率が良くないかもしれませんが、長期的にはおそらくクラウドでホストするよりも安くなるでしょう。 しかし、ここでそれをサポートする人が必要です。 私の経験では、それを愛し、それを行う方法を知っている人は、他のすべての人とコミュニケーションをとるのがあまり好きではないので、彼らは部署に組織されています。 そして、部門は分離主義です。 つまり、管理チーム内で経験を交換するのは簡単になりますが、将来的にはうまく機能しない可能性があります。 他の同僚からのタスクの優先順位付けと、同期についての質問があります。 他の専門家は、データセンターをサポートしている部門内で何が起こっているかを知りません。
一般的に、分離主義は私たちには向いていません。 論理的には、チームの募集の問題に取り組みます。
チーム
開発
言語、データベース、プロジェクトのホスト場所を把握したとしましょう。 チームを募集する時です。 あなたはすべての問題を解決する非常にクールな人を連れて行くことができます：百倍の開発者、バックエンドの忍者、あなたは理解しています。 おそらくそれは乗り心地を与えるでしょう。 しかし、実際には、招待されたスターは次のようになるでしょう：
- 何もしないでチームに悪い雰囲気を作る有毒な男たち、
- または完璧なアーキテクチャを少しずつ構築し、決して変更する必要のない基盤の前にORMを配置する理想主義者...
最後に...はい、私たちは長い間機能を提供してきました。 もう1つの選択肢は、コードを書くだけの普通の女の子や男を連れて、通常の機能を実行することです。 しかし、経験の浅い開発者の多くが異なるバックグラウンドを持っている場合、異なるスタイルでコードを記述し、異なる方法で作業することができ、十分な規模のチームで、全員がamp屈になり、誰もがお互いのプルクエストに中かっこを持ちます。 あまり効果的ではありません。 これはどのように解決できますか？ 上司はすべてのコードを読むことができます。 私はすべてのプルクエストを読むことができ、友人であり共同設立者でもあるValerkaは2度目にそれを読み直します（念のため、あなたは決して知りません）。 これがスケーリングしないことは明らかであり、誰もがゆっくりと機能を作成します。
より適切なオプションは、会社のコードスタイルを定義することです。 多くの言語では、すでに存在しているため、単純にそれに従うことができます。 または、誰かが本当にしたい場合は、既製のものを取り、それを少し締めてから、プルクエストを見て、中括弧が存在しないと言うことができます、それはコードスタイルに従って存在するはずです。 このような議論を議論することはできませんが、実際には以前のバージョンよりもはるかに優れているわけではありません。 最新のすべての言語の正しいオプションは、これを自動的にチェックすることです。
わかった 開発者、figコードを獲得しました。 しかし、本番環境で機能のリリースを開始しました。バグなしで機能をロールバックし、何も落ちないことを確認する必要があります。
品質保証
QAスペシャリストは必要ないと言えます。 多くの人がこれを行い、時には機能します。 しかし、すべての開発者がテストを書くことを好むわけではありません。 それらは理解できます。 そして、テストを書くように動機付けた方が良いのですが、現実は残酷です。ユニットテストはすべてのバグをキャッチするわけではありません。 また、一部の開発者がテストの作成を好まないのにテストの作成を開始した場合は、おそらく単体テストになります。
さらに、平均復旧時間ではなく平均故障間隔を最小化するアプローチもあります。 失敗の平均間隔は、QAスペシャリストが次のように言ったときです。「リリースしません。私は悪い雰囲気を持っています。バグがあります。2週間で展開しましょう」 そして、回復するまでの時間は、何かをロールすると、何かが壊れていることをすぐにメトリックで確認し、2分後にすべてがロールバックされ、修正され、すべてが正常になります。 ただし、プロジェクトを2分でロールバックするには、すべてを通常のメトリックでカバーする必要がありますが、これは必ずしも些細なことではありません。 そして、メトリックが嘆かわしい状態にあり、悪いリリースを展開した場合、すべてのユーザーが競合他社に任せた後にこれについて知ることができます。
別のオプション：引き続きQA部門を作成します。 あなたは覚えています：部門はあまり良くありません、それは分離主義です、それは私たちに合いません。 分離主義は、機能横断型チームの助けを借りて解決できます。 はい、彼らは私たちの管理者が別々に座っているという問題を解決し、テスターは別です。
しかし、それらは他の問題を引き起こします。 開発者、テスター、および職域を超えたチームの他のすべてのメンバーは、チーム内でより多くのコミュニケーションを取り、以前の問題を解決し始めるため、彼らの機能における同僚とのコミュニケーションが少なくなります。他のバックエンドおよびテスターは、車輪の再発明を開始し、同じことを並行して行い、チーム間の分離。 シャイロ石鹸：1つの分離主義があり、別のものになりました。
これを解決するには？ 趣味グループの同僚とコミュニケーションを取ります。 どこかでギルドと呼ばれ、どこかでコミュニティです。 チームが自己完結型にならないようにチーム間でチームを拡大する場合、単にバックエンド、関数型言語、セキュリティのファンの輪を組織します...
まとめ
実際、すべてがそれほど悪いわけではありません。 あらゆる状況から抜け出す方法、解決策を見つけることができます。 理想的ではないかもしれませんが、この状況で問題を最小限に抑えて最適です。 妥協は常に可能です。
そしてまだ-これはすべて興味深いです。 誰かがすでに解決した問題を解決することは興味深いです;新しい問題はさらに解決することが興味深いです。 知識を共有することは興味深いです。