comtecです。
案件を進めるうちにグローバルな変数や関数が散らばってることがある。
今回も「~してもいいですか?」というconfirmを出して、ユーザーのアクションによって、実行するかキャンセルするかといった処理を行った。
他のページではシステムからグローバルな変数に処理に必要なデータをいれてもらい、ページ固有のエレメントにbindしていて、外部ファイルではグローバルな関数を定義してた。
たしかにページによってbindするエレメントは違うし、処理する上で扱うデータは異なる。トークンを取得する上でのnameもそうだ。
しかし、それ以外のbindする部分やformとして生成して、hiddenタグを生成し、ユーザーのアクションによってsubmitする部分は大抵同じ処理である。
なのでそれらの同一処理をメソッドとしてもつ基底クラスさえ作っておけば、あとはページ毎に処理に使うデータやエレメントをプロパティとして指定する派生クラスさえ作ればいい。
実際に今回も基底クラスを作った後は、派生クラスでは先ほど挙げたようなプロパティと仕様としてリストの中からどれを選択したかのidを取得するメソッド1つで完結できた。
こういった他の案件でも円滑に作業が進むような基底クラスを作り共有していけば、グローバルな変数や関数を作る必要もなくなり、名前空間の問題も避けれる。
でもこの基底クラスを自分のチームや他のチームで理解して使える環境を作ることが重要なわけで。
作業効率化と新しい人がスムーズに案件に入れる様にコメントで説明するコードの書き方とガイドラインの充実をきちんとしないと!と再確認した。
iPhoneからの投稿
案件を進めるうちにグローバルな変数や関数が散らばってることがある。
今回も「~してもいいですか?」というconfirmを出して、ユーザーのアクションによって、実行するかキャンセルするかといった処理を行った。
他のページではシステムからグローバルな変数に処理に必要なデータをいれてもらい、ページ固有のエレメントにbindしていて、外部ファイルではグローバルな関数を定義してた。
たしかにページによってbindするエレメントは違うし、処理する上で扱うデータは異なる。トークンを取得する上でのnameもそうだ。
しかし、それ以外のbindする部分やformとして生成して、hiddenタグを生成し、ユーザーのアクションによってsubmitする部分は大抵同じ処理である。
なのでそれらの同一処理をメソッドとしてもつ基底クラスさえ作っておけば、あとはページ毎に処理に使うデータやエレメントをプロパティとして指定する派生クラスさえ作ればいい。
実際に今回も基底クラスを作った後は、派生クラスでは先ほど挙げたようなプロパティと仕様としてリストの中からどれを選択したかのidを取得するメソッド1つで完結できた。
こういった他の案件でも円滑に作業が進むような基底クラスを作り共有していけば、グローバルな変数や関数を作る必要もなくなり、名前空間の問題も避けれる。
でもこの基底クラスを自分のチームや他のチームで理解して使える環境を作ることが重要なわけで。
作業効率化と新しい人がスムーズに案件に入れる様にコメントで説明するコードの書き方とガイドラインの充実をきちんとしないと!と再確認した。
iPhoneからの投稿