背景
新しいプロジェクトが始まり、7人のスマートチームが編成され、ロードマップの概要が示され、タイムラインと予算が合意されました。すべてが計画どおりに進んでいるようで、開発者の幸福に制限はありません。 「最後に、書く必要はありません（代わりの角度1、jquery、バニラjs）。本当にモダンでファッショナブルで高速なフレームワークを使用できます。 このプロジェクトのすべてが正確になります。各メソッドが文書化され、100％コードカバレッジ、CI統合、リアルタイムデータ付きスクラム、webpack、babel、およびRektovskyスムージー付きグラス...誰もが本当にできない古いバグのあるアプリケーションをごまかす選別され、新しいものを賞賛します。 身近な状況ですね。 しかし、もしこのシナリオに出会ったことがあるなら、あなたは私なしで3-4ヶ月の活発な仕事の後に何が起こるか完全によく知っています -はい、モダンなデザイン、はい、私たちは反応します、はい、ホットモジュールの交換は非常に便利で、はい、フレックスボックスがあり、フロートが残っていることを忘れることができますが、これらは製品の品質を高めますか？ ドキュメント、テストなどはどうですか？
「はい、JSDocはes7デコレータでは正しく動作しません。 テストの実行は一般的に構成されていますが、今はテストを書く時間がありません...」そしてCIから、最良の場合のシナリオでは、gitフックと自動アセンブリのみが使用されます。 しかし、すべての恐怖は/ src / componentsフォルダにあります...多くの場合、チームに複数の人がいる場合、各開発者は独自の「正しい」構造と構文のビジョンを持っているため、コードは読みにくい麺に変わります。 これは、ある開発者が書いたコードを他の開発者が維持するのが難しいという事実につながります。
しかし、私たちにはフレームワークがあります
「しかし、フレームワークを使用し、そのガイドラインに従うだけです」と言うことができます-しかし、実際には状況はさらに悪くなります。それどころか、フレームワークは選択を促します。 例として、最も人気のあるものの1つであるReactを取り上げましょう。 彼はプロでもそれを記録しました！ 間違いなく、AJAXリクエストのテンプレートエンジンまたはライブラリを簡単に置き換える機能は優れており、アーキテクチャソリューションの柔軟性を示していますが、古いes5構文、JSX構文、または機能的なステートレスコンポーネント全般を使用する機会があると、怖がり始めます。 選択の豊富さは、ある構文から別の構文に目が常に投げられるという事実につながります
誇大広告を追求して
コンポーネント1
import React, {Component} from 'react' import PropTypes from 'prop-types' /** * Person component is used to show the first name and last name of the user */ class PersonComponent extends Component { static propTypes = { item: PropTypes.object }; static defaultProps = { item: {} }; render() { return ( <div className="item"> <p>{this.props.item.firstName}</p> <p>{this.props.item.lastName}</p> </div> ) } }
コンポーネント2
var createReactClass = require('create-react-class'); var PersonComponent = createReactClass({ /** * Person component is used to show the first name and last name of the user */ render: function() { return ( <div className="item"> <p>{this.props.item.firstName}</p> <p>{this.props.item.lastName}</p> </div> ) } }); PersonComponent.propTypes = { item: PropTypes.object }; PersonComponent.defaultProps = { item: {} };
はい、それはまったく同じコンポーネントです。 ドキュメントがあり、コンパクトで、信じられないかもしれませんが、テストも行われていますが、問題はまったく異なります... GoやC＃などの他のプログラミング言語では、コードパーツの厳密なシーケンスがあります。 たとえば、C＃では、すべてのサードパーティのライブラリとフレームワークで、ファイルの先頭に「使用中」が常に表示されます。 Goは常にモジュール名を持ち、最初にインポートします。 これらの言語の開発者はコンテキストを変更せず、常に同じ構造と構文で作業します。 javascriptでプログラミングする場合、この利点は失われます...私たちの多くは問題を見ることさえありません！ タイプスクリプトを再構築してライブラリの機能を拡張することにすでに慣れています。 別の場所でlodashを使用して継承を行います。 3番目では、「import」の代わりに古い「require」を使用します。 そして、es6に大部分のコードがあり、ファッショナブルなので徐々に非同期/待機を追加しながら...
しかし、あなたは何かをすることができますよね？
確かに、コードの検証にライブラリを使用できます（実際、通常のIDEが行うべきこと）が、このためには、数十メガバイトの追加のnpmパッケージをダウンロードし、ドキュメントを読んで、作業を正しく設定、設定、設定するのに多くの時間を費やす必要があります また、プリコミットフックを追加することもできます。これにより、一部のWindows開発者はパスの特性のために正しく動作しなくなります。 そして最後に、ケーキの桜-これをすべてwebpackに統合する必要があります。これには、互換性のないバージョンが6か月ごとにリリースされます。 はい...そのような瞬間、あなたは他の言語の開発者を特にうらやましく思います...
そして結論として
JavaScriptは絶大な人気を得ています。 nodejsのおかげで、スマートポット、電子レンジ、冷蔵庫の1秒ごとに既に追加されています。 靴用のスマートインソールを購入できます。SDKのヒップスターは、次の擬似言語で膨大な量の構文糖を使用して作成されます。 私の女性医師が言うように：「過剰な糖は糖尿病を引き起こす」...