戻る
このエピソードは、クリスマス休暇前の12月に公開する予定だったので、遅れたのは私がボトルネックになっているようだ。優先順位の高い仕事がいくつか邪魔をして、週ごとに公開を遅らせ続けてきたが、今日がその日だ。
前回のエピソードでは、職場におけるユーモアの重要性を取り上げた記事についてコメントするよう予告したが、その一方で、この記事はもっと評価されるべきだと思ったので、近々（たぶん）ブログ記事全体を書くつもりだ。
ここ数週間、忙しかったこと：
a)クリスマスの前に、私は『虹色デイズ』のプレミア・エピソードで幕を開けた。 「防弾CTO」ウェビナー・シリーズ (SaaSを取り上げた2月の第2回にご期待ください CTOs詳細は私のLinkedInで近日公開）。
b) 2021年に向けての成長計画を調整中で、RubyとJSの中核事業を超えて、Magentoと 製品 設計能力 社内.
自己宣伝はこれくらいにして、#TheCodestReviewシリーズ第5回にご招待しよう。
トピックス チーム はこの時のために準備してきた：
今週は、Reactのエンジニアがフロントエンドアプリケーションに関するコメントと従来のコミットを、RubyドリームチームがRuby 3.0.0を配信します。
今日、多くの開発者は時間節約のために、すでに作られたUIライブラリや再利用可能なコンポーネントを使用しています。それは良い習慣であり、多くの時間を節約するのに役立っているが プロジェクト で処理するだけでは十分でないことを理解するだろう。 コード.
ドメイン駆動開発（DDD）とコンツェルン分離（SoC）だ。フロントエンドのアーキテクチャでも使うことができる。
DDDでは、似たような機能をグループ化し、他のグループ（モジュール）からできるだけ切り離そうとしている。
一方SoCでは、例えばロジック、ビュー、データモデルを分離する（例えばMVCやMVVMデザインパターンを使う）。
良いやり方やパターンはたくさんあるが、私にはこのやり方が合っている。
このパターンを使うと、このようになる：
最初に、ユーザーはアプリのルーティングによって正しいモジュールにリダイレクトされます。すべてのモジュールは完全に含まれている。しかし、ユーザーはいくつかの小さなアプリケーションではなく、1つのアプリケーションを使うことを期待しているので、いくつかのカップリングが存在する。このカップリングは、特定の機能やビジネスロジックに存在します。
そして、我々はこのような構造を持っている：
appフォルダ - アプリケーション層
assets - 写真、フォント、アイコンなどのフォルダ。
コンポーネント - 複雑なロジックを持たない、再利用のためのコンポーネントであるべきだ。
config - ここにグローバルな状態を保存します。
lib - 複雑な関数やロジックを計算するためのフォルダです。
モジュール - これが我々のモジュールだ
pubsub - データ構造を記述するスキーマを格納する場所。
styles - css/scss コード用
この構造は、成長するアプリケーションに対応し、バグを少なくするのに役立つだろう。また、別々のモジュールでより快適な作業部分を作り、それらをテストし、リファクタリングとデバッグをより簡単にするのに役立ちます（別々のモジュールのため）。
モジュールのアーキテクチャやAPIとのつながりをもっと深く見ていけば、そのようなものが得られるだろう：
app'フォルダーがあれば、API呼び出しのコードとデータを'config/store'に保存した'api'フォルダーを作成する。ここには、アプリケーション全体で使用する静的で不変なデータを保存します。
また、'pubsub/schema'フォルダでは、以下のような特定のデータ型について説明します。 JavaScript オブジェクトがある。
すべてのモジュールは、私たちが使う必要のあるデータ（ユーザー、ルート、テーブル、アクションなど）を内部に含んでいます。すべてのモジュールはアプリケーションレイヤーと接続され、すべての必要なデータを受け取ります。
フロントエンドはユーザーにとって最初の入り口です。私たちのフロントエンド・プロジェクトの機能が増えるにつれて、バグも増えていきます。しかし、私たちのユーザーは、バグがなく、新しい機能が迅速に提供されることを期待しています。これは不可能です。しかし、優れたアーキテクチャーを使うことで、私たちは可能な限りこれを達成しようと努力するしかないのです。
あなたが入社したばかりの会社にいるとしよう。JavaScriptが言語になる前のコードベースや、Netscapeがページを読み込むのに何年もかかったようなコードベースを紹介されるまでは、すべての人があなたに親切で、すべてがうまくいっているように見える。
コードの継承は、新しい開発者をプロジェクトに導入する際に大きな問題となるようだ。コードを読むことは一つのことだが、アプリケーションがどのように開発されたかを理解することは全く同じではない。多くの場合、コミットは有用であり、なぜこのconsole.logがlinterによってキャッチされなかったのか、なぜその厄介な// TODOが最初にアノテーションを作成した開発者の子供たちのためにあるのか、といった文脈を与えてくれる。
まず、標準化されていないコミットルールよりも、従来のコミットの方が優れている理由から説明しよう。
もし私たちが新しい開発者をプロジェクトに雇い入れたとして、そのプロジェクトのコミットのほとんどが、「これはうまくいくはずだ」とか「フッターのスリーピーを至急修正してくれ」といった内容のメッセージで構成されているとしたら、あなたの頭の中には何が浮かぶだろうか？
赤旗の理由はこうだ：
チームが変更をコミットする際にカスタムルールを適用することができるため、コミットがしっかりしたものである必要があり、ミスの余地が少なくなる。もはやチェックアウトするだけの手段ではありません。あなたがコミットの内容を知っていたことを他の人に伝える署名なのだ。あなたが行った作業が正しく署名されていない場合、ほとんどの場合エラーとなり、次のようなメッセージが表示されることは言うまでもありません。
あなたのチームは、ASAPや汚い言葉をブラックリストに載せることができるように、特定のキーワードを禁止するルールを設定したい可能性があります。
プロジェクト開始時に本当に役に立つのは、自分のチームがどのようにプレーしているのかを皆に紹介することだ。 開発チーム 新しい開発者に変更をコミットしてほしい。そして、あなた方全員が合意したことを彼らが維持するのを助けるツールをセットアップしてください。
私が仕事をする機会があったツールのひとつは、次のようなものだった。 コミットリント そのおかげで、ルールがない新しいプロジェクトに参加し、チームがルールの導入に前向きである場合、従来のコミットを実践するようになった。
設定を扱い、それをチーム全体に広げる場合は、単にnpmパッケージを作成し、各プロジェクトでmpn i -Dするだけでいい。そうすることで、プロジェクト内の全員が常に同じ見解を持つことができ、必要であれば、プロジェクト間で最後に何が変更されたのか（なぜ変更されたのか）を理解しながら歩くことができる。
さて、すべてをセットアップし、なぜCCを使い始めるのが良いアイデアなのかを理解したら、今適用したルールに沿ってプログラミングするのが一番良いだろう！私たちはコミット方法を標準化し、コミットの真意にもっと注意を払うようにしています。フラグが存在する場合、ステージング上で素早くテストできるようにフックをセットアップしてはどうでしょうか？私たちはサービスを過剰に利用したくないし、必要なときにコストを削減したい。
あなたがPWAに取り組んでいて、その可能性をフルに試すためにSSLが必要で、テストプラットフォーム上にSSLがあると仮定しましょう。今必要なのは良いコミットだけです。feat(PWA):マニフェストアイコンworkboxセットアップアップアップロードのラインに沿った何かが、テストと歯車を動かす機械全体のトリガーになるでしょう。manifest.jsonのような静的なデータをアップロードするだけならその必要はないので、コミットのpostfixとしてフラグ[TEST_SKIP]を追加します。これにより、CIは新しいアセットをテスト環境にアップロードするだけで、テストをスキップできるようになります。詳しくは これ
しばらくすると、CHANGELOGの生成のしやすさや、以下のようなバージョン管理の改善など、他の利益も見えてくるはずだ。 セマンティック・バージョニング.それでもコミット・メッセージの書き方を変える気にならないのなら、足の指を冷たい水に浸して、しばらくプライベート・リポジトリで使ってみれば、考えが変わるかもしれない。
ハッピー・コンベンショナル・コミット！
コミュニティで長い間待ち望まれていたRuby 3.0.0のリリースが、クリスマスに日の目を見た。The Codestでは毎週開発ミーティングを開催し、エンジニアが技術トレンドや注目すべき新発見について議論することで、知識を共有する文化を育んでいます。以下は、Ruby 3.0.0の重要な変更点について、シニアRubyエンジニアが彼の主観的な視点から議論したデモ・デーのスライドへのリンクです：
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
さらに、私たちのRubyメンターがプルリクエストで新バージョンに貢献し、無事マージされました。プライバシー・コントロールの方法についての詳細は、開発責任者の短い記事をご覧ください。
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
LinkedInや私のEメールでのフィードバックも大歓迎です。
次回は2月末、ShopifyのCTOにインタビューしたポッドキャストのレビューをお届けします！
また会おう。
続きを読む
TheCodestReview #4 - 週刊ソフトウェア・エンジニアリング・ジュース
Japanese 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Korean 
Spanish 
Dutch 
Estonian 
Greek