銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

エンジニア3年目の2020年振り返り

こんにちは。2020年ももう終わってしまいますね。
気づけば、エンジニアになって2年半が経っていました。

去年と一昨年も年末に振り返り記事を書いているので、今年もやってきたことをまとめておこうと思います。

去年の記事:エンジニア2年目の2019年振り返り - 銀行員からのRailsエンジニア
一昨年の記事:エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り - 銀行員からのRailsエンジニア

仕事のことはあまり詳細に書けないので、主に仕事以外でやってきたことを書いていきます。

f:id:ysk_pro:20201231081124p:plain

振り返り記事なので、アイキャッチは振り返ってるうちの猫です。かわいい 😻

個人開発

2つサービスをリリースできました 🎉

楽々ゴルフ

移動時間で絞り込めるゴルフ場検索サービスです。

今年のお正月(約1年前)に、妻と2人で作りました。

「既存のゴルフ場検索サービスでは、自宅からの車での移動時間で絞り込めない」という僕の思っていた課題を解決できて嬉しかったです。

フロントエンドにはReactを初めて使いましたが、妻に手取り足取り教えてもらったのでだいぶ理解できるようになりました。

バックエンドはAWS Lambda(言語はRuby)、API Gateway、DynamoDBでサーバレスの構成にしてみました。

ysk-pro.hatenablog.com

Golf Medley

ゴルフ練習場の口コミサイトです 🏌️‍♂️

「楽々ゴルフを見たのですがこんなもの一緒に作らないですか」というTwitterDMをいただいたのがきっかけで生まれたサービスです。楽々ゴルフを作って公開したことで、このサービスに繋がりました。

現在はゴルフ練習場の口コミ機能のみですが、ゆくゆくはゴルフにまつわる総合サイトにするため、様々な機能を検討・実装中です。これまで僕はサービスを作って終わりというのが多く、継続的に開発している個人開発のサービスは初めてなので、少しずつ良いものにしていきたいです。

開発は妻と僕、機能の検討やデータ入力等は声をかけていただいた方が行う、3人チームで進めています。

技術的にはフロントエンドにNext.js、Typescript、認証にAuth0(JWTトークン認証)、バックエンドにRailsという構成で、Rails以外ほとんど触ったことのない個人的に攻めた構成にしました。

元々フロントエンドはReact SPAで作り始めたのですが、SNSシェアされた時に展開される情報を動的に変えられないことが辛く、SSRができるNext.jsに切り替えました。ページごとにSSR, SSGを切り替えられたり、SSGでも(ほぼ)動的なサイトを実現できたりとNext.jsが便利すぎて驚きました。

golf-medley.com

AtCoder

2019年にハマった競技プログラミングを継続していました。
今年の前半は、ほぼ毎週オンラインでのコンテストに出場していました。

基礎的なアルゴリズムは習得できたと思います。

念願だった水色になってからレートが停滞して、徐々にやらなくなってしまいました。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

CTF

CTFとはセキュリティ系のコンテストで、Web、暗号化、ネットワーク幅広い分野が対象です。詳細を知りたい方はこちらがとてもわかりやすいです。
CTF(Capture The Flag)とは?概要から基本ルール、メリットデメリットまで徹底解説

AtCoderと入れ替わりで始めてみました。

主にWeb分野の過去問に取り組んでおり、SQLインジェクションなどで攻撃するのが楽しいですw(そういう問題なので攻撃OKです)

デザインパターンの勉強

2019年から始めたデザインパターンの勉強を継続していました

Rubyによるデザインパターン を読んで、紹介されている16のパターンを1パターンずつオリジナルのサンプルコードと共にブログにまとめました

かなり時間がかかりましたが、デザインパターンをざっくり理解することができ、コードの良し悪しが少しずつ分かるようになった気がします。
まとめた自分のブログを見ながらコードを書くことが多くなりました。

ysk-pro.hatenablog.com

仕事

APIを一から作ってパフォーマンスの問題に苦しんだり、スクラム難しいなーてなったり、Kubernetesを触ったり、大きめの障害を起こしてヘコんだり、新しいサービスの技術選定・設計をし始めたりしてました。

現職で2年半以上経ちましたが、メンバーに恵まれているのと、次々に初めて経験する難しい課題が現れるので全く飽きずに楽しめています。

おまけ(プライベート編)

3月からフルリモートになり家の環境整えました

よくあるデスク環境紹介ブログを書いてみました。

ysk-pro.hatenablog.com

広い家に引越して、猫を飼い始めました

リモートワークになり、会社の近くに住む意味がなくなったので、広くて猫飼育可の物件に引っ越して猫を飼い始めました。
めっちゃかわいいです...!

ジムは解約し、家トレを毎日継続してます

コロナの影響でジムに行きづらくなったので、家でトレーニングできる環境を整えました。

ジムは2日に1回行く程度でしたが、家だとすぐに取りかかれるのが楽で毎日筋トレをする習慣がつきました。

マンガをたくさん読みました

リモートワークになって自由な時間が増えたのもあり、マンガをたくさん読みました。

技術書もそうですが、妻と2人で読めば実質半額でお得です。

僕が今年読み始めたマンガでの個人的なTOP3は、1位:ワールドトリガー、2位:七つの大罪、3位:呪術廻戦 です。

(今Amazonで調べてたらワールドトリガーが2021/1/11まで1巻〜9巻 Kindle版無料で読めるらしいすごい)

妻とゴルフレッスン通い始め、夫婦でゴルフ旅行に何度か行きました

夫婦でゴルフ旅行という、ゴルフを始めた頃の夢が叶いました。最高です。

おわりに

ここまで読んでいただきありがとうございます。

今年も色々取り組めていい年でした。

来年は Golf Medley を成長させつつ、興味の赴くままに新しいことに色々チャレンジする1年にしたいです。

ご興味あれば、去年・一昨年のブログも合わせてご覧ください。

ysk-pro.hatenablog.com 

ysk-pro.hatenablog.com

良いお年を!

【読書まとめ27】Atomic Design 〜 堅牢で使いやすいUIを効率よく設計する

個人で開発しているサービスに Atomic Design を採用しているのですが、雰囲気で使っており一度体系的に学びたいと思いこの本を読みました。

Atomic Design やその周辺知識をまとめて得ることができたので読んで良かったです。

後から見返せるように、ポイントを簡潔にまとめました。 

f:id:ysk_pro:20200825083937p:plain

Atomic Designとは

 

コンポーネントベースでのUI開発のメリット

  • 再利用性が高い
  • 再利用されることで、統一された使い勝手をユーザーに提供できる

 

各階層について

小さい方から1つずつ説明します。

Atoms

  • これ以上UIとしての機能性を破壊しない最小単位。使い回しやすいように、抽象的な機能だけを持つように作られる
  • (例)ボタン、テキストフォームなど
  • (関心事)デザインの統一性

Molecules

  • 機能を組み合わせてユーザーの具体的な行動に応える機能の単位
  • (例)Atomsのボタン、テキストフォームなどを組み合わせた検索フォームなど
  • (関心事)行動を阻害しない操作性

Organisms

  • 独立して成立するコンテンツを提供する
  • (関心事)ユーザーの行動を促すコンテンツ

Templates

  • 具体的なコンテンツを持たないページの雛形。OrganismsやMolecules、Atomsのコンポーネントを実際のページの通りに配置する
  • (関心事)画面全体のレイアウト

Pages

  • Template層のコンポーネントに実際のコンテンツを流し込んで、ユーザーが実際に触れるもの
  • 各ページに1つ作られ、この層は再利用されない

 

コンポーネントを階層化するメリット

  • 全体を考慮する必要がなく、1つの層の関心事に集中できる
  • 同一層に属するコンポーネントであれば差し替えやすく、A/Bテストなどもスムーズに行うことができる
  • 更新頻度の高い上位層(Pages、Template)のUIコンポーネントの変更が、下位層に影響しない

 

知っておくと役に立ちそうなこと

  • MoleculesとOrganismsの分け方
    • どちらに含めるか悩むケースは多いので、次のような判断基準で分けるのがよい
    • Organisms:独立して存在できるコンポーネント単体で見たときに意味が分かる
  • 命名について
    • 命名の基本は「コンポーネントが持っている機能に対して、過不足ない名前をつける」ことであるがとても難しい。以下の命名のサンプルが参考になる
    • Atoms:Button, Image, Text
    • Molecules:SearchForm, Pagenation
    • Organisms:Header, NotificationList
    • Templates:MyPageTemplate, ContactTemplate(Orgainsms層との名前の重複を避けるため、共通してTemplateを後ろにつける方法がよく使われる)
    • Pages:MyPagePage, ContactPage(Template層のコンポーネントに実際のデータを適用したものがPages層なので、Template層のTemplateをPageに変えると分かりやすい)
  • ReactはコンポーネントベースでUI開発することに特化したJavaScriptライブラリで、Atomic Designと相性がよいため一緒に使われることが多い

 

おわりに

ここまでお読みいただきありがとうございます。

本書ではReactを使った豊富なサンプルがあり、さらにテストにも言及しており学ぶことがとても多かったので、ご興味ある方はぜひご覧ください。

この本を読んで、個人開発しているサービスのコンポーネントの分け方で改善したいところが色々と出てきたので、どんどん実践していこうと思います。

自己yieldについて【Ruby】

こんにちは。

最近 メタプログラミングRuby を読み印象に残るところが多かったので、1つずつブログにまとめています。

今回は第2弾で、自己yield についてまとめました。

f:id:ysk_pro:20200711095214p:plain

自己yield とは

Rubyはメソッドにブロックを渡すことができます。
メソッドに渡されたブロックは、メソッド内で yield とすることで実行できます。

自己yield は、メソッド内で yield を使ってブロックを呼び出すときに、yield self としてオブジェクト自身(self)を引数としてブロックに渡すことを言います。

これがどのように使えるのか、サンプルコードを見ていきましょう。

サンプルコード

自己yield を使っていないコードを自己yield を使って書き換えていきます。

まずは、自己yield を使っていないコードです。

class PC
  attr_writer :name, :os, :price

  def initialize(name, os, price)
    self.name = name
    self.os = os
    self.price = price
  end
end

mac_book_air = PC.new('mac book air', 'mac', 150_000)
p mac_book_air #-> #<PC:0x00007fcf05863158 @name="mac book air", @os="mac", @price=150000>

インスタンス作成時にインスタンス変数をいくつかセットするだけのシンプルなコードです。
インスタンス変数が3つだと問題はなさそうですが、数が増えると引数の順番に気をつかう必要が出て分かりづらくなりそうですね。

このコードを自己yield を使って書き換えると次のようになります。

class PC
  attr_writer :name, :os, :price

  def initialize
    yield self
  end
end

mac_book_pro = PC.new do |pc|
  pc.name = 'mac book pro'
  pc.os = 'mac'
  pc.price = 200_000
end
p mac_book_pro #-> #<PC:0x00007f8015017128 @name="mac book pro", @os="mac", @price=200000>

PCクラスのインスタンスを作る際にブロックを渡しており、PCクラスの initializeメソッドでそのブロックを呼び出しています。

ブロックでインスタンス変数をセットしていることで、どのインスタンス変数にどの値を入れているか分かりやすくなりましたね。

さらに、メソッドにブロックが渡されたか判定できる block_given? メソッド を使えば、どちらのインスタンス作成の方法にも対応することができます。

class PC
  attr_writer :name, :os, :price

  def initialize(name = nil, os = nil, price = nil)
    if block_given?
      yield self
    else
      self.name = name
      self.os = os
      self.price = price
    end
  end
end

実際に使われているところ

自己yield が実際に使われている例を見てみましょう。

Faraday

よく使われている HTTPクライアントライブラリ Faraday で自己yield が使われています。

Faraday は次のように、分かりやすく HTTPリクエストを行うことができます。

resp = Faraday.get('http://sushi.com/search') do |req|
  req.params['limit'] = 100
  req.headers['Content-Type'] = 'application/json'
  req.body = {query: 'salmon'}.to_json
end
# => GET http://sushi.com/search?limit=100

このコードは 公式ドキュメント からの引用です。

ブロックを使うことで、クエリパラメータやリクエストヘッダ、ボディに直感的に値をセットすることができます。

Faraday のコード内で yield self が実行されています。

tap

tap はメソッドチェーンの途中で値をチェックしたい場合などに使われるメソッドです。

次のようによく使われます。

a = ['r', 'u', 'b', 'y'].map(&:next).pop
puts a #-> z

# メソッドチェーンの途中で値を確認する
a = ['r', 'u', 'b', 'y'].map(&:next).tap{|x| p x}.pop #-> ["s", "v", "c", "z"]
puts a #-> z

実際の tap はRubyで書かれていませんが、Rubyで実装すると自己yield を使った次のようなシンプルなコードになります。

class Object
  def tap
    yield self
    self
  end
end

おわりに

ここまでお読みいただきありがとうございます。

自己yield は色々なところで使われており、ソースコードを読む際にも必要になるので、知っておいて損はないと思います。

今回紹介した自己yield はメタプログラミングRuby の「付録A よくあるイディオム」に記載されていました。

メタプログラミングRuby 第2版

メタプログラミングRuby 第2版

次回もまた、メタプログラミングRubyを読んで印象に残ったところをまとめていこうと思います。

アクセスメソッドの注意点について書いた前回の記事も是非合わせてご覧ください。
ysk-pro.hatenablog.com

Waiting for table metadata lockとオンラインDDLについて【MySQL5.6】

MySQLで「Waiting for table metadata lock」のエラーが発生して、詳しく知りたくなったので、関連しているオンラインDDLとともに調べ、手元で試してみたことをまとめました。

MySQLのバージョンは 5.6、ストレージエンジンは InnoDB です。

この記事の多くは、MySQL 公式ドキュメントの以下のページを参考に書いています。
公式ドキュメント①:14.11.1 オンライン DDL の概要
公式ドキュメント②:14.11.2 オンライン DDL でのパフォーマンスと並列性に関する考慮事項

f:id:ysk_pro:20200708084439p:plain

DDLとは

DDL は Data Definition Language の略で、データ定義言語です。
SELECT などのテーブルのレコードを操作するものではなく、データベース自体を操作するものを指します。
CREATE, ALTER, DROP などが DDL です。

対して、SELECT, UPDATE, DELETE などの、テーブルのレコードを操作するものは DML(データ操作言語、Data Manipulation Language)と呼ばれています。

オンラインDDLとは

MySQL5.6より前のバージョンでは、一部を除いたDDLは、テーブルの全ての行のコピーやDDL実行中のDMLのブロックを必要とするコストの高い操作でした。
そのため、DDLを行うためにはサービスをメンテモードにするなどの対応が必要でした。

これに対し、MySQL5.6で拡張されたオンラインDDLは、テーブル全体のコピーを行わず、実行中のDMLのブロックも必要とせずDDLを行えるようになりました。
テーブル全体のコピーとDMLブロックが不要なDDLをオンラインDDLと呼んでいますが、「テーブルコピーは不要だがDMLブロックは必要」などといったDDLも一部存在します。

公式ドキュメント① にオンラインDDLについての詳しい説明があります。

オンラインDDLを有効にするために特別なことをする必要はなく、オンラインDDLが可能な場合はオンラインDDLが適用されます。
このことは、MySQL公式ドキュメント 14.11.3 オンライン DDL の SQL 構文 に記載があります。

ただ、全てのDDLがオンラインDDLに対応している訳ではありません

オンラインDDLに対応しているDDL

公式ドキュメント① に、それぞれのDDLでオンラインDDLのどの操作が可能かが一覧表でまとまっています。

一覧表で「インプレース?」が「はい」になっているものがテーブル全体のコピーが不要なDDL、「並列DMLを許可?」が「はい」になっているものがDDL実行中にDMLの実行が可能なものです。

ざっくりですが、よく行う操作だと カラムのデータ型変更以外はほぼオンラインDDLに対応していると思って良いと思います。

便利な機能として、DDLに「ALGORITHM=INPLACE, LOCK=NONE」というオプションをつけて実行すると、オンラインDDLができない場合に実行せずにエラーを返してくれます
「ALGORITHM=INPLACE」は、テーブル全体のコピーが必要ない INPLACE 方式でDDLを実行することを指定し、「LOCK=NONE」はDDL中にロックせずに並列DMLを可能にすることを指定します。これらのオプションは、指定した方法でDDLが実行できない場合にエラーにします。
確実にオンラインDDLで実行したい場合は、このオプションをつけてDDLを実行すると良さそうです。
ALGORITHM=INPLACE は公式ドキュメント①、LOCK=NONE は公式ドキュメント② の中で説明されています。

また、DDLを実行した際にテーブル全体のコピーを行ったかどうかを確認できます。
DDL実行のレスポンスが「0 row affected」の場合、テーブル全体のコピーが行われずにDDLが実行されています。
こちらは、公式ドキュメント② で説明されています。

オンラインDDLができないカラムの型変換で、実際にオプションを試してみました。

まずオプションをつけずに実行すると問題なく成功しました。usersテーブルの age カラムを varchar(255) 型に変更しています。

mysql> ALTER TABLE `users` CHANGE `age` `age` varchar(255) DEFAULT NULL;
Query OK, 4800 rows affected, 2 warnings (0.19 sec)
Records: 4800  Duplicates: 0  Warnings: 2

レスポンスが「4800 rows affected」となっているので、テーブル全体のコピーが行われたと分かります。

オプションをつけて実行すると想定通りエラーとなりました。

mysql> ALTER TABLE `users` CHANGE `age` `age` varchar(255) DEFAULT NULL, ALGORITHM=INPLACE, LOCK=NONE;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

INPLACE 方式だとできないので、テーブル全体のコピーを伴う COPY 方式で実行してね、というエラーが発生しています。

Ruby on RailsのMigrationでオプションをつける方法

私は普段 Ruby on Rails を書いており、Rails の Migration で前述のオプションをつける方法を調べました。

私が調べた限り、execute で任意のDDLを実行する以下の方法で行うしかなさそうでした。この例は、usersテーブルに test というコメントをつけるDDLです。

class Test < ActiveRecord::Migration
  def up
    execute "ALTER TABLE `users` COMMENT 'test', ALGORITHM=INPLACE, LOCK=NONE"
  end
  def down
    execute "ALTER TABLE `users` COMMENT '', ALGORITHM=INPLACE, LOCK=NONE"
  end
end
== 20200706064613 Test: migrating =============================================
-- execute("ALTER TABLE `users` COMMENT 'test', ALGORITHM=INPLACE, LOCK=NONE")
D, [2020-07-06T16:15:50.402667 #2523] DEBUG -- :    (15.1ms)  ALTER TABLE `users` COMMENT 'test', ALGORITHM=INPLACE, LOCK=NONE
   -> 0.0155s
== 20200706064613 Test: migrated (0.0156s) ====================================

execute を使った任意のDDL実行については、こちらの記事を参考にしました。
Execute SQL in Rails migrations. You may come across the following… | by Josua Schmid | Medium

migration時に実行されるSQLを確認する方法は、こちらの記事を参考にしました。(デフォルトでは migration時に実行される SQL は出力されません。)
Rails で migrate 時に実行される SQL を確認する - volpe’s diary

オンラインDDLの注意点とWaiting for table metadata lock が発生するケース

オンラインDDLには注意点があり、オンラインDDLの開始前、完了前にそれぞれ短時間ではあるものの排他的アクセスが必要となります。
つまり、オンラインDDLの開始前と完了前にDDLの対象テーブルに実行中のトランザクションがあった場合、そのトランザクションがコミットまたはロールバックするまで待機する必要があります。

さらに、オンラインDDLトランザクションの完了を待機している状態で同じテーブルへDMLを実行すると、DMLの対象レコードがトランザクションの対象レコードと別であってもオンラインDDLと同様に待機状態になってしまいます。

このようなケースで、待機状態になっているDDLDML が Waiting for table metadata lock の状態になっています。
メタデータ(meta data)とは、カラム名、データベース名などのデータベースについての情報のことです。
トランザクション中のメタデータの変更を防ぐため、トランザクション中はメタデータのロックがかかるようになっており、DDLを実行すると Waiting for table metadata lock となります。

トランザクションが長引いたりすると、Waiting for table metadata lock がたまり続けて障害の引き金になる可能性もあります。

図にすると次のようになります。左の列がトランザクション、中央の列が DML、右の列がオンラインDDL を表しています。

オンラインDDLとmetadata lockの関係図

詳細は 公式ドキュメント② と、公式ドキュメント 8.10.4 メタデータのロック に記載されています。

Waiting for table metadata lock が発生するケースを実際に試してみる

トランザクション中にDMLのみを行うケース

まずはオンラインDDLを実行しないケースを試してみます。

トランザクションを実行します。

mysql> start transaction;
Query OK, 0 rows affected (0.01 sec)
mysql> update users set name='test2' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

別セッションで、トランザクションを実行しているテーブルに DML を行います。

mysql> select name from users where id=2;
+-----------+
| name      |
+-----------+
| taro      |
+-----------+
1 row in set (0.00 sec)

無事結果が返ってきました。

オンラインDDL を実行していない通常のケースでは、同じテーブルでトランザクション中であっても DML は正常に完了しています。

トランザクション中にオンラインDDLDMLを行うケース

トランザクションを実行します。

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> update users set name='test' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

別セッションで DDL を行います。(実行しているカラムへのコメント追加はオンラインDDLが可能なものです。)

mysql> ALTER TABLE `users` CHANGE `gender` `gender` int(11) DEFAULT 2 NOT NULL COMMENT 'test comment';

(応答なし)

結果は返らず、トランザクションの完了待ちになっています。

さらに別セッションで、トランザクションを実行しているテーブルに DML を行います。

mysql> select name from users where id=2;

(応答なし)

こちらもトランザクションの完了待ちになりました。

この時に、show full processlist を実行すると、応答なしとなっている2つのセッションが「Waiting for table metadata lock」となっています。

mysql> show full processlist;
+----+------+-----------------+------+---------+------+---------------------------------+------------------------------------------------------------------------------------------------+
| Id | User | Host            | db   | Command | Time | State                           | Info                                                                                           |
+----+------+-----------------+------+---------+------+---------------------------------+------------------------------------------------------------------------------------------------+
|  1 | root | localhost       | fril | Sleep   |   47 |                                 | NULL                                                                                           |
|  2 | root | localhost       | fril | Query   |   36 | Waiting for table metadata lock | ALTER TABLE `users` CHANGE `gender` `gender` int(11) DEFAULT 2 NOT NULL COMMENT 'test comment' |
|  3 | root | localhost       | fril | Query   |   24 | Waiting for table metadata lock | select name from users where id=2                                                              |
|  4 | root | localhost       | fril | Query   |    0 | init                            | show full processlist                                                                          |
+----+------+-----------------+------+---------+------+---------------------------------+------------------------------------------------------------------------------------------------+

そしてトランザクションを commit すると、応答がなかった2つのセッションで応答が返ってきました。

おわりに

オンラインDDLが可能なDDLだからといって、何も考えずにDDLを行うのは危険ですね。
ただ、トランザクションが長時間発生しないテーブルであれば、オンラインDDLを実行するオプションをつけて実行することでリスクはかなり小さく抑えられそうです。

公式ドキュメントを読み込み、手元で実際に試してみると理解がかなり深まりますね。

MySQLの理解がまだまだ浅いので、バージョンが古いですが、過去読んだこの2冊を読み直していこうかな、と思っています。

現場で使える MySQL (DB Magazine SELECTION)

現場で使える MySQL (DB Magazine SELECTION)

間違えている箇所や説明が分かりにくい箇所等あれば、コメントなどでご教示いただけると大変ありがたいです。

attr_accessor(attr_writer)でインスタンス変数をセットするときはselfを省略できない【Ruby】

こんにちは。

最近 メタプログラミングRuby を読んだので、印象に残ったところをブログにまとめています。

今回は、Rubyのアクセスメソッド attr_writer, attr_accessor でインスタンス変数をセットするときにレシーバ(self.)を省略できないことについてまとめました。

サンプルコード

かなりシンプルなこちらのコードを実行すると何が出力されるでしょうか?

class Sample
  attr_accessor :name

  def set_name
    name = 'デフォルト太郎'
  end
end

sample = Sample.new
sample.set_name
puts sample.name #=> ?

ほぼ同じ内容をTwitterのアンケート機能で聞いてみた結果がこちらです。

attr_accessor は Sample クラス内に以下のコードを自動で定義してくれるので、name= メソッドによってインスタンス変数がセットされて「デフォルト太郎」と出力されそうな気がしますが、実際は何も出力されません

def name
  @name
end

def name=
  @name = name
end

この予想に反した結果となっている原因は、set_name メソッドにあります。

「name = 'デフォルト太郎'」が、ローカル変数の name に値を代入しているのか、attr_accessor で生成された「name =」メソッドをレシーバを省略して呼び出しているかが Ruby に判断できずRuby では前者(ローカル変数への代入)を採用することになっています。

よって、set_name メソッドはローカル変数の name に値を代入しているだけとなり、sample.name は 定義されていない インスタンス変数 @name を参照しているため、何も出力されないという挙動になっていました。

set_name メソッドを以下のようにすれば「デフォルト太郎」と出力されるようになります。

def set_name
  self.name = 'デフォルト太郎'
end

先ほどは省略していたレシーバ(self.)を明記することで、「name =」メソッドを呼び出していることが明確になったためです。

また、アクセスメソッドを使用せず、インスタンス変数に直接値を入れる以下の形でも「デフォルト太郎」が出力される挙動にすることができます。

def set_name
  @name = 'デフォルト太郎'
end

おわりに

ここまでお読みいただきありがとうございます。

意図しない挙動を避けるためのコードを2種類紹介しましたが、実務のコードでは self. をつける形もインスタンス変数に直接値を入れる形も見かけるので、どちらを選ぶかは好みな気がします。

メタプログラミングRuby では、今回取り上げたような Ruby の小ネタ的な話も色々と紹介されており面白いのでおすすめです。

メタプログラミングRuby 第2版

メタプログラミングRuby 第2版

(追記)
メタプログラミングRubyを読んで印象に残ったところまとめの第2弾として「自己yield」についてまとめました。
是非合わせてご覧ください。
ysk-pro.hatenablog.com

【技術書まとめ26】リファクタリング Rubyエディション

こんにちは。

今回は、リファクタリング Rubyエディション を読みました。

本書は様々なリファクタリングのパターンについて、Rubyを使って説明している名著です。

学ぶことが多かったので、ポイントを定期的に見返せるよう記事にまとめました。 

特にいいなと思ったリファクタリングのパターンは、サンプルコードを使って解説したブログへのリンクを貼っていますので、気になるパターンがあれば合わせてご覧ください。

f:id:ysk_pro:20200611081009p:plain

リファクタリングについて

  • リファクタリングとは、外から見えるふるまいを変えずに、ソフトウェアの内部構造を変えること
  • リファクタリング目的は、ソフトウェアをわかりやすくし、安いコストで変更できるようにすること

 

リファクタリングの基本的な考え方

  • ほとんどのリファクタリングは、プログラムに間接的な階層を導入する。つまり、大きなオブジェクトや大きなメソッドを分解して、複数の小さなオブジェクトやメソッドにしている。間接化によって以下のメリットが得られる
    • ロジックの共有を実現する
    • メソッド名などで意図を説明できる
    • 変更箇所を他の部分から分離できる
  • プログラムが扱いにくくなる要因としては以下の4つがあり、これらが存在した場合はリファクタリングを検討すべき
    • 読みにくい
    • ロジックの重複がある
    • 機能の追加によって、動いているコードを書き換えなければならなくなる
    • 条件分岐が複雑
  • ソフトウェアでは、使われていない柔軟性は悪である。この柔軟性は、メンテナンスのために時間を食い、バグが入る余地を作り、リファクタリングをかけにくくする

 

リファクタリングの基本的な進め方

  • リファクタリングを活用してソフトウェアを開発するときには、機能の追加を行う時間とリファクタリングを行う時間をはっきりと区別した方がよい
    • 機能を追加するときには、既存のコードを書き換えない。ただ新しい機能を追加することに専念する。最初に失敗するテストを追加し、テストを成功させる
    • リファクタリングする時には機能を追加しないようにし、コードの改造だけに力を注ぐ。テストの追加も行わない
  • バグレポートを受け取ったら、まずバグが浮かび上がるようなテストを書く。バグを突き止めるとともに、同様のバグがテストをすり抜けないようにするため

 

パフォーマンスについて

  • システムの内部で何が行われているかを正確に知っていたとしても、パフォーマンスは推測せずに計測すべき推測の10回に9回は正しくない
  • パフォーマンスの面白いところは、実際に分析してみると、実行時間の大半がコードのごく小さな一部で消費されていることである。コード全体に平等に最適化をかけると、実行時間の短いコードを最適化することになり効率が悪い

 

具体的なリファクタリング

名前の変更
  • 名前の変更の価値は大きい。優れたコードは、自分がしていることを明快に伝えられなければならないが、変数名やメソッド名はそのための鍵を握っている
  • 分かりやすくするために、名前を書き換えることをためらってはならない

 

メソッド・フィールドの移動
  • メソッドは、そのメソッドが使用するデータを持つクラスに割り当てるべき
  • 条件分岐は、他のオブジェクトでなく自分自身のデータに基づくべきであり、他のオブジェクトのデータで条件分岐している箇所はクラスの移動を検討する
  • メソッドやフィールドをどのオブジェクトに管理させるかは、オブジェクトの設計でもっとも重要な判断の1つである。最初から正解にたどり着くのは難しいので、リファクタリングを使って設計を変えていけばよい

 

メソッドの抽出
  • 何かコメントを書くべきと感じる場合、コメントではなくメソッドに抽出することを考える。このときメソッド名はコードの仕組みではなく、目的に基づいてつける。メソッド名がコードの目的を説明しているなら、たった1行のコードであってもメソッド呼び出しに変える価値がある。コメントを探すとメソッド抽出すべきところが見つかりやすい
  • 値を返すことと、オブジェクトの状態に変化を与えることを同時に行なっているメソッドがある場合、問い合わせ用と更新用のメソッドに分割する。こうすることで再利用しやすくなる
  • ほぼ同じコードによる2つのメソッドがあり、違いはメソッドのちょうど中頃にある場合、重複部分を抽出してブロック付きのメソッドにして、違いの部分を yield で実行させると良い。この手法は「サンドイッチメソッドの抽出」という名前がついている(詳細をまとめたブログ記事

 

ポリモーフィズム
  • case文を見かけたら、ほとんどの場合はポリモーフィズムを利用することを検討すべき。case文の少なさは、オブジェクト指向らしいコードが持つ特徴の1つである。メリットとしては、新しい型を追加した時に存在している全ての条件式を探す必要がなくなり、新しいクラスを作って適切なメソッドを提供するだけでよくなる(詳細をまとめたブログ記事
  • 広い意味では同じようなステップを同じ順序で実行しているように見えるが、ステップが全く同じだとは言えない複数のメソッドは、共通部分をスーパークラスに移してポリモーフィズムに仕事をさせ、異なるステップはそれぞれがサブクラスで実行させる。この種のメソッドをテンプレートメソッドと呼ぶ。Rubyでは、モジュールのextendを使ったテンプレートメソッドの作成も可能である。モジュールをextendするクラスがーパークラスの役割を果たして共通部分を格納し、モジュールが特別なふるまいを実装する(詳細をまとめたブログ記事

 

クラス・モジュールの抽出
  • クラスが常に全てのインスタンス変数を使うわけではない場合がある。そのような時は、クラスの抽出、モジュールの抽出、サブクラスの抽出を検討する
  • 1つのクラスが異なる理由でたびたび書き換えられる時には、理由ごとにクラスを分けることを検討する
  • モジュールの抽出で、モジュールをインクルードするクラスを対象として呼び出したいクラスメソッドがある場合は、モジュールに included フックを作り、includedフックにクラスメソッドの定義を移す(詳細をまとめたブログ記事

 

ガード節
  • 条件分岐がネストされている場合は、まずはガード節が使えないかを検討する

 

ファクトリメソッド
  • オブジェクトを作成するときに単なる構築以上のことをしたい場合は、コンストラクタを取り除いてファクトリメソッドを作ると良い。例えば、作成するオブジェクトの種類を決めるために条件分岐を使っている場合などで有効となる(詳細をまとめたブログ記事

 

委譲
  • manager = john.department.manager というコードがあったとする。これだと、manager の管理は Departmant クラスで行なっているということを呼び出し側が知っておかなければならず依存が発生する。委譲メソッドを使って john.manager で取得できるようにすれば、余計な依存を解消することができる(詳細をまとめたブログ記事

 

その他
  • method_missing を使うとコードがわかりにくくなることが多いので、なるべく使わない方がいい
  • オブジェクトの代わりにnullを持っている可能性があり、コード中にnullかどうかの確認をしている箇所が多いとき、nullオブジェクトを導入するのが有効な場合がある(詳細をまとめたブログ記事

 

おわりに

ここまで読んでいただきありがとうございます。

 

この本は今まで読んだ技術書の中でもトップクラスに学ぶことが多かったです。 

また、値段もトップクラスでした(笑)

「これなんかリファクタリングできないかなー」という時にこの本が手元にあると役立ちそうなので、 手元に置いて少しずつ身につけていこうと思います。

抽象スーパークラスからモジュールへ【リファクタリング Rubyエディションまとめ8】

こんにちは。

最近 リファクタリング Rubyエディション を読みました。本書はリファクタリングの様々なパターンRubyのサンプルコードを使って解説している名著です。

実務でも活かせそうなパターンが多く紹介されていたので、いいなと思ったパターンを1つずつブログにまとめています。

今回はその第8弾で「抽象スーパークラスからモジュールへ」についてまとめました。
オリジナルの Ruby のサンプルコードを使って説明しています。

前回の「サンドイッチメソッドの抽出」のまとめはこちらです。
サンドイッチメソッドの抽出【リファクタリング Rubyエディションまとめ7】 - 銀行員からのRailsエンジニア

f:id:ysk_pro:20200602083536p:plain

抽象スーパークラスからモジュールへ とは

使えるタイミング

継承関係を持っているものの、スーパークラスインスタンスを生成させたくない場合に有効です。

リファクタリング方法

スーパークラスをモジュールに書き換えて、サブクラスで include します。

このリファクタリングを使用する理由

例えば、Java ではクラスに abstract というキーワードをつけることで、そのクラスのインスタンスが生成されないようにできますが、Ruby には同じ機能はありません。

コンストラクタが呼び出された時にエラーする処理を書いても同じことは実現可能ですが、モジュールを使う方がインスタンスを生成させたくないという意図をはっきり伝えることができます

サンプルコード

リファクタリング

まずはリファクタリング前のコードです。

class Item
  def initialize(name, origin_country = nil)
    @name = name
    @origin_country = origin_country
  end

  def description
    puts "商品名:#{@name} / 補足:#{additional_description}"
  end
end

class DomesticItem < Item
  def additional_description
    '国内産です'
  end
end

class ImportedItem < Item
  def additional_description
    "#{@origin_country}で作られました"
  end
end

商品(Item)クラスを、国内産商品(DomesticItem)クラスと輸入商品(ImportedItem)クラスが継承しています。

次のように実行すると

DomesticItem.new('イヤホン').description
ImportedItem.new('スマートフォン', 'アメリカ').description

次の結果になります。

商品名:イヤホン / 補足:国内産です
商品名:スマートフォン / 補足:アメリカで作られました

このコードの問題点としては、スーパークラスである Item クラスのインスタンス化は可能なものの、Item クラスのインスタンスで description メソッドを呼び出すと additional_description メソッドが定義されていないためエラーになってしまう点です。

意図していないインスタンス生成(Item クラス)は出来ないようにしておくのが安全なので、リファクタリングを行います。

リファクタリング

「抽象スーパークラスからモジュールへ」を使ってリファクタリングをすると下記のようになります。

module Item
  def initialize(name, origin_country = nil)
    @name = name
    @origin_country = origin_country
  end

  def description
    puts "商品名:#{@name} / 補足:#{additional_description}"
  end
end

class DomesticItem
  include Item

  def additional_description
    '国内産です'
  end
end

class ImportedItem
  include Item

  def additional_description
    "#{@origin_country}で作られました"
  end
end

変更点は、継承関係を解消して、モジュール化した Item クラスをそれぞれのクラスで include したのみです。

実行の仕方、結果は先ほどと同じになります。

おわりに

ここまでお読みいただきありがとうございます。

このリファクタリングデザインパターンの1つである「テンプレートメソッドパターン」で使えそうだなーと思ったので、今回のサンプルコードは、テンプレートメソッドパターンを使ったものにしています。
テンプレートメソッドパターンについて詳しく知りたい方は、合わせてこちらをご覧ください。
ysk-pro.hatenablog.com

リファクタリング Rubyエディションでは、この記事の内容に加えてクラスメソッドが存在する場合のリファクタリングの仕方についても触れられていて参考になったので、ご興味ある方は是非ご覧ください。

次回はまた違うパターンをまとめていきます!

前回の「サンドイッチメソッドの抽出」のまとめはこちらです。是非合わせてご覧ください。
ysk-pro.hatenablog.com