投稿

10月, 2019の投稿を表示しています

文字列が適切か考える

はじめに初心者向けです。初心者にありがちなことと、TSに入りたてでありがちなことを書きました。文字列が適切でない選択である可能性を意識する文字列使いがち問題自分が以前見かけたコードに下記のようなものがありました。
Next.jsにも例としてこのようなコードが載っています(このコード自体は問題ないです)。<Linkhref="/about"><a>About</a></Link>このコード単体で見ると、問題ないですが、この書き方をそのままプロダクションでも行われるとすぐに面倒なことになります。自分が問題視しているのは、/aboutの部分です。自分が見たコードは、全て(どこでも)hrefの中身が文字列で書かれていました。そのため、タイポっていても実行時にしかわからず(どの部分でも実際にリンク踏むまで正しいかわからない)、再利用性はなく、TypeScriptを利用しているにも関わらず、型の恩恵も受けられない部分になっていました。本来は、
下記のようにパスを定義しておき、constaboutPath=()=>'/about'下記のように定義したパスを使うなどすべきです。<Link href={aboutPath()}><a>About</a></Link> こうすることにより、型の恩恵を受けられ、タイポすることもなくなります。* 前提として(当然ながら)リンクはどこからでも使われるというのがあります。一箇所でしか使わないならそのまま文字列を直接使っても良いかもしれませんが、整合性の観点からは全て、関数や定数にすべきだと思います(特にパスの場合は、idなどを埋め込むことになると思うので関数にすべき)。string型使いがち使用するものが決まっている場合には、enumを使うべき(TypeScriptならunion typeでも一応可)// enum版enum Color { red ='red', green ='gleen', blue ='blue'}constprintColor=(color: Color)=>{ console.log(color)}printCol…

開放閉鎖原則についてのまとめ

はじめに対象読者は初心者です。開放閉鎖原則とは定義Robert C.Martinの著書「アジャイルソフトウェア開発の奥義」では、ソフトウェアの構成要素(クラス、モジュール、関数など)は拡張に対して開いていて、修正に対して閉じていなければならないと説明されています。「拡張に対して開いている」とは、雑に言い換えると「機能追加がしやすい」です。「修正に対して閉じている」とは、雑に言い換えると「変更が他の場所に影響を及ぼさない」です。厳密ではないけどわかりやすいであろう言い方としては、「クラスや関数は機能追加しやすく、変更が他の場所に影響を及ぼさない作りになっているべき」です。例開放閉鎖原則の具体例として、自分が考えたものは、くじ引きです。一般くじとプレミアムくじというものがあり、それぞれが違う抽選ロジックを持っているとします。開放閉鎖原則に従って実装したくじ引きのコードは、下記のようになります(インターフェース(publicなメソッド)部分が重要なので細かい部分は除いています)。classGeneralLotteryLogic# 一般くじの抽選ロジックdefinitialize(params)@params= params enddef exec # 抽選ロジックの実装があるendendclassPremiumLotteryLogic# プレミアムくじの抽選ロジックdefinitialize(params)@params= params enddef exec # プレミアム抽選ロジックの実装があるendendclassLottery# 実際にくじ引きを行うクラスdefinitialize(logic)@logic= logic enddefdraw(count)raiseArgumentError.new('count must be positive integer')if count <=0Array.new(count).map do@logic.exec endendend# それぞれどこかで下記のような形で使用されているとする lottery =Lottery.new(GeneralLotteryLogic.new({}))# 一般くじのロジックを注入 lottery.draw(10)# 一般くじを引…

単一責任の原則についてのまとめ

はじめに対象読者は初心者です。個人的にいくつかの書籍を読んで、内容や自分の考えをまとめたものです。単一責任の原則とはRobert C.Martinの著書「アジャイルソフトウェア開発の奥義」では、クラスを変更する理由が複数存在してはならないと説明されていました。一方で、比較的最近の彼の著書である「クリーンアーキテクチャ」では、「モジュール1はたったひとつのアクター2に対して責務を負うべきである。」とも説明されていました。まとめると、「クラスを変更する理由は複数のアクター起因であってはならない」と言えると思います。単一責任の話の具体例として自分が考えたものは、よくある管理画面、ユーザー画面に別れているものです。作りとしては、見た目上分かれているが、アプリケーションとしては別れていない、モノリシックな構成です(たぶんRails採用しているところにありがち)。単純に捉えて、管理画面側のアクターとして管理者がおり、ユーザー画面側のアクターとしてユーザーがいるとします。商品の登録は管理者が行い、商品の予約をユーザーが行う場合に、下記のようなProductクラスがあった場合、単一責任の原則に違反しています。このProductクラスは、ユーザーが商品を予約できる機能と、管理者が商品を登録できる機能を別々のクラスに分離する対応が必要です。classProductdefregister(name, price)# 登録の処理enddefreserve(user_id)# 予約の処理endendなぜ単一責任の原則を守るべきなのかなぜ単一責任の原則を守るべきなのでしょうか?先程の続きで考えてみます。ある日、管理者側のメンバーが登録処理の実装の変更を依頼してきました。開発者は登録処理の変更を正しく行いリリースしました。ところがユーザー画面側で予約処理に不具合が出ているという報告を受けました。開発者は再度修正を入れ、管理画面側でもユーザー画面側でも影響がないことを確認した後リリースして事なきを得ました。この話を聞いてどう思ったでしょうか?
開発者が最初のリリースで予約処理への影響を確認しなかったのが悪かったのでしょうか?この話の問題点は、単一責任の原則を破ってしまったことです(テストコードをもっとしっかり書けばとか、例が適当すぎるのは一旦おいておきます)。registerメソッドとreser…