良いこと（悪いこと）Typescript：UI開発者の経験

こんにちは、私の名前はアレクサンダー・チェルニコフです。 私は、法人向けのインターネット銀行であるSberbank Business Onlineの更新版であるUIプロジェクト「Digital Corporate Bank」の開発を担当しています。 スタンドアロンクライアント、モバイルアプリケーション、そして実際にはWebクライアントを開発していますが、これについては後で説明します。 私の記事では、チームの貴重な経験を共有します。特にこの投稿では、テクノロジースタックについて説明し、Typescriptをメイン言語として選択した理由に焦点を当てます。









Sberbank Business Onlineの新しいバージョンを2.5年間作成しています。 来年、Sberbankのすべての法人クライアントをそれに移管する予定です。



それでは、スタックから始めましょう。 TypeScript、React、Reflux（レガシー）、Redux、Bluebird Promise、およびBootstrapを実装しました。 LESSにスタイルを記述します。 Babel、Webpack、およびそのプラグインを使用して、これらすべてを収集します。 Webpackは最初のバージョンですが、2番目に切り替える予定です。 多くの人が尋ねるかもしれません：なぜTypescriptとBabelが同時に必要なのですか？ 第一に、TypeScriptの前は、誰もが転置の方法を知っていたわけではなく、この機能でバベルに追いついたのはごく最近でした。 第二に、TypeScriptはキャッシュできません。 また、babelは既製のES5スクリプトをフォルダーに保存できます。 ソースが変更されていない場合、彼はすぐにそこからそれらを取ります。 プロジェクトに数分かかる場合、この時間の節約は非常に楽しいです。



技術スタックはかなり新鮮です。 連中はいくつかのことを一度に掘り下げなければなりません。例えば、TS、React、Redux、プロジェクト自体、そして銀行の観点からです。 50〜60人のうち、州で働いているのはわずか20％であり、残りはベンダーから接続されており、頻繁に変更されます。



このような状況でのコードレビューの対処方法 以前は、最も経験豊富な開発者の一部がすべてのチームのコードを見ていましたが、そのような小さなピラミッドがありました。 現在、チーム間で均等に分散しようとしています。 いわゆる専門家が多くのチームに登場しています（彼らはプロジェクトに精通していて、彼らがどこにいてどこにいるかを知っています）。彼らは自転車などを発明しません。 したがって、彼らはチームのメンバーだけでなく、他のメンバーもレビューします。



レビューは少し自動化されており、プルリクエストで一致する必要のあるラベルを追加します。 その後、緑色に変わり、PRは自動的にマージされます。 コードスタイル、エキスパート、アーキテクト、CSS、E2Eテストなど、さまざまなラベルがあります。 .lessファイルが変更された場合-CSSが追加され、カーネルコードまたは低レベルのものが変更された場合-Architectが追加されます。 エキスパートを取得するには、少なくとも2人のエキスパートを募集する必要があります。

また、プロジェクトに初めて参加する人やJSにあまり強くない人は、コードレビュー前のコードとは大きく異なります。

TypeScriptとJavaScript

多くの人がTSについて書いて、ES5で置き換えられた新しい機能を使用した瞬間を見つけました。 しかし、それでも、エラーコードの静的分析のために、入力にTSを使用しました。 はい、JSでコードを正しく作成できますが、TSのように保証することはできません。 誰かがあなたがたくさんのTSコード（オーバーヘッド）を書かなければならないという短所を入れます。 「古い」コードJS> TSをリファクタリングしたときに、ランタイムでのみ機能する基本的なエラーが検出されました。 コンマが存在しないか、ポイントが忘れられているか、ブラケットが早期に閉じられているかなど、到達不可能なコードや未使用の引数などは言うまでもありません。 3000-4000スクリプトでは、TSなしでどのように生きるかを想像するのは一般的に困難です。



もちろん、JavaScriptでコードを記述する場合、型付き言語があるかのように、コンパイラを支援してコードを記述できます。変数を再定義せず、変数に異なる型を書き込まず、常に同じ型を返します。 問題は、babel.jsが使用されている場合、TypeScriptを学習することに意味はありますか？



私たちはしばしばこれについて議論します。 一部の同僚は、「なぜTSが必要なのですか？ 私たちは、コードを適切に作成し、徹底的なコードレビューを実施し、インタビューする人を選び、実際にJSジェダイを紹介します。 しかし、だれも人的要因、怠laz、速攻、不注意をキャンセルしませんでした。 TSをJSコードに接続することを妨げるものは何もありません。 本当にエラーが1つもない場合、コンパイラは何も見つけられません。すばらしいチームがあり、星が本来どおりに形成されていることを喜ぶことができます。 しかし、TSを安全に使用することは依然として妨げにはなりません。 さらに、特別な費用は必要ありません。



さらに、今年のバージョン1.8 TSでは便利な機能を作成しました。 これで、純粋なJSで型を確認できます。プロジェクトに「.js」ファイルを追加し、allowJsフラグを設定するだけです。 チェックしたくないコードがある場合は、@ ts-nocheckアノテーションを使用して無視しても問題ありません。 コードのレビュー中、小さなバグをキャッチすることはほぼ不可能であり、TSは時間とエネルギーの節約に役立ちます。 または、リリースブランチを追加して、100個のファイルで競合が発生するようにします...冷血の状態でMERGEボタンを押す方法を確認したいと思います。

TypeScriptとフロー

「フローはどうですか？」と尋ねます。 ES6とTypescriptのどちらかを選択しましたが、Flowについては誰も知りませんでした。 静的コード分析の違いに興味がある人のために、TypeScriptとFlowを比較するHolyJS 2017 PiterカンファレンスのIlya Klimovによる興味深いレポートをお勧めします。

軟膏で飛ぶ

オーバーヘッドに加えて、Typescriptには他にもいくつかの欠点があります。

1. プロジェクトのアセンブリの大幅な減速。 しかし、これもまた、ビルド固有のWebpack + TS + Babelに限定されています。 同じ構成（+-babel）のユーザーは、transpileOnlyフラグを指定してts-loaderローダーを使用し、TSCを並行して実行することをお勧めします。 また、インクリメンタルビルドモード（--watch）では、webpack --watchとtsc --watchの2つのプロセスを分離します。
2. OutOfMemory nodeJSエラーには問題があります。プロジェクトを組み立てて3〜4日後にリリースをリリースする必要がある場合、このような驚きは特に不快ですが、すぐに解決することはできません。
3. 外部ライブラリの.d.tsバージョンを更新する必要。 tsd>タイピングで時間は終わりました。 そして、npm> @typesを介してすべてをすぐにダウンロードできるようになりました。 しかし、新しいバージョンのライブラリ（lodashなど）がリリースされ、.d.tsがまだリリースされていない場合はどうでしょうか？ 次に、選択する必要があります：自分で追加する（リポジトリに追加するか、DefinitelyTypedリポジトリのgithubにPRを置く）か、この機能をまだ使用しないでください。
4. TypeScriptの経験がある開発者を検索します。 これらは私たちの人事の個々の涙です。 私の知る限り、市場の誰もが深刻なSPA、Angularを書いた経験がある「高度な」フロントエンド開発者を見つけるのに問題があります。 反応する| Vue、Typescript、Reduxなど