数年ぶりに「リーダブルコード」を読むとやっぱりイイ
はじめに
数年ぶりにエンジニアなら読むべきと言われている「リーダブルコード」を読みました。
前に読んだのは少なくとも学生のときなので、がっつり仕事をやり始めてからは初めて読みました。
バイブルと呼ばれている通り、「エンジニア 読むべき」でググると上位10件中7件で、★5だったりオススメ1位だったりでリーダブルコードが紹介されていました。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者:Dustin Boswell,Trevor Foucher
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
リーダブルコード
概要
副題にもあるように、より良いコードを書くために必要なことが載っています。
命名、コメント、変数や関数、テストなどについて、章立てされていて、それぞれが独立しているので掻い摘んで読んでも構わないような構成になっています。*1
感想
学生当時は「ふーん」という感じで読んでいたイメージがあります。
が、改めて読んでみるとやはりイイなと感じました。
良いコードは何かと言われれば難しいですが、読みやすいコードは何かと言われればリーダブルコードに沿ったコードと答えても問題なさそうです。
実際、副題には「より良いコードを書くための」となっていますが、はじめにの章では「本書の目的は、読みやすいコードを書くことである。」という一節があります。
そして、その次で述べられている以下のような内容が、本書の全てを体現している気がします。
読みやすいコードを書く → コードは理解しやすいものであるべき → コードを読んで理解する時間を最短にする
良いコードの定義は難しいですが、今後は読んで理解する時間が最短であるようなコードの書き方を目指したいと思います。
特筆すべき感想はあまり無いのですが、命名やコメントに関しては、基本的にそのとおりだと思うことばかりでした。
やはりコーディングする人全員に読んでもらって共通言語として意思統一が図れれば最高だなという思いです。
疑問
そんな中、今になっていくつか疑問も出てきました。
1つ目は、「4章 美しさ」で紹介されている視覚的な手すりのためのコードの整列です。
例えば、以下のようなものです。
details = request.POST.get('details') location = request.POST.get('location') phone = request.POST.get('phone') email = request.POST.get('email') url = request.POST.get('url')
個人的には、これは嫌いで、本文にもあるように「差分」が増えるからです。
上記ならまだしも、以下はもっと嫌いです。
checkFullName("Doug Adams" , "Mr. Douglas Adams" , ""); checkFullName(" Jake Brown ", "Mr. Jake Brown III", ""); checkFullName("No Such Guy" , "" , "no match found"); checkFullName("John" , "" , "more than one result");
ここまでやる必要があるのか?と思ってしまいます。
嫌いな理由として、ずっとPythonをやっていて、PythonではPEP8で悪い例としてあげられていて悪いものだという認識が強いからかもしれません。
もちろん、見やすくなる場合もあるので、コードを書く人にはせめてコミットをわけてほしいと思う次第です。
2つ目は、「14章 テストと読みやすさ」で紹介されている独自のミニ言語を実装するという点です。
確かにある程度はメソッド分割して、場合によっては独自のミニ言語のようなものを作り読みやすくすることも必要だと思います。
ですが、ミニ言語レベルのロジックがテストコードに入ってしまうと、テストコードのためのテストが欲しくなってしまいます。
極論、独自のassertを定義し、その中で常にtrueになるようなassertの呼び出し方をしてしまうと、テストコードの意味がなくなります。
命名やコメントに関してもそうですが、「良い塩梅」というのが大切なのでしょうか。
おわりに
疑問もあげましたが、バイブルと呼ばれるだけあって今でも勉強になる部分は多々ありました。
共通言語として使っていきたいので、みんなに読んでほしいです。
2週連続で本の話になってしまいました...
*1:「本書の読み方」参照
「現場で役立つシステム設計の原則」を読んで
はじめに
先日、増田亨さんの「現場で役立つシステム設計の原則」を読んだので感想を。
しばらく前に買っていたのですが、年末で余裕があったのでやっと読了しました。
現場で役立つシステム設計の原則
概要
全10章で構成されていて、総じてDDDやオブジェクト指向メインの話になっています。
なぜそうするのかという理由とサンプルコードと一緒に説明がなされていて、イメージがわきやすくなっています。
感想
1番の感想は、「新卒1年目で読みたかった」ということです。
納得できるできないは別として、オブジェクト指向を単なる知識ではなくシステム設計として適用するにはどういうことなのか、何をどうすればわかりやすいのか、ということがよくわかりました。
特に、今となっては当たり前にやっていますが、第3章「業務ロジックをわかりやすく整理する」で紹介されている、三層アーキテクチャ+ドメインモデルの例はとてもわかりやすく、もっと早く新卒1年目あたりで知りたかったです。
第1章は値オブジェクトに関することで、第10章はオブジェクト指向設計の学び方に関することで、徐々にミクロからマクロにスケールが大きくなっていくような構成になっていて、目の前のことからより俯瞰したことまでを順番に紹介していきたい意図がある気がします。
それもあって、自分の中で視野?が広がる感覚があり、とても読みやすかったです。
ただ、いくつか疑問もありました。
例えば、第8章で細かい粒度でAPIを作成して必要なデータだけを取得するという話がありました。
これに関しては、確かにそういうやり方もありますが、本当にそうしたいならGraphQLを採用して必要なデータだけを要求するという方法もあるかなと思いました。
全体を通してDDDやドメインエキスパートといった言葉は出てきませんが、DDDを平易な言葉で言い換えているということがよくわかります。
いかにも英語を日本語に直しましたという文章ではなく日本語で日本語らしく説明されているのでとてもわかりやすくなっている気がします。
上述のAPIや、DBやビューに関して言及している箇所など、いくつか簡単には納得できないこともありますが、総じてとても良い本だと思います。
どう読むか
やはりこういう本は視点が変われば意見も変わると思うので、普段の会社のメンバーで読み合い、議論までできると業務に生きてくるのかなと思います。
最近は読んで終わりということも多いので、良し悪しだけでなく皆の考えを知るためにもそういう機会を用意してみようかなと思う今日このごろです。
令和2年はどんな年になるのだろうか
遅くなりましたが、あけましておめでとうございます。
実は1月5日は誕生日でして、ちょうど而立の年となりました。
三十路ではなく而立と言っていこうと思います。
もう過ぎていますがまだ間に合います(しつこい)
まだ間に合いますよ!
— おおしげ🎲 (@_ohshige) 2020年1月5日
いろいろhttps://t.co/ybUKgvHwSm
ボドゲ https://t.co/bQzgY3hABx
本https://t.co/jkzWki1zwo
さて、令和2年になりましたが、今年はどんな年になるのだろうかと思いを馳せています。
周りがやっている100のリストを作ろうと思いましたが、簡単に作れるものでもないので、年始め早々諦めました。
とりあえず簡単な目標としては、下記を掲げようと思います。
今年もよろしくおねがいします!
2019年を振り返ってみるとブログと日常がリンクしていることがわかった
はじめに
正確にはまだ届きませんが、ブログを始めてから約1年が経ちました。
しょぼい内容でもいいから毎週月曜日に公開するようにしようと決めてから無事に続けることができて、完遂間近です。
そんなブログを始めた2019年でしたが、自分のために振り返ってみます。
振り返ってみて
1月〜4月
2019年が始まったばかりだからか、色々な新しいことをスタートしました。
継続という観点で言うとやりきったと言えるのはこのブログだけかもしれません...
ブログ
このブログを開始したのは1月でした。
ohshige.hatenablog.com
記念すべき1回を改めて見てみると、やっぱりなんか恥ずかしい。
過去の記事の焼増しではありますが、どんだけ気合い入れてるんだと。
言語処理100本ノック
新しいこと2つ目。
やりたいと思いつつやっていなかった言語処理100本ノックに挑戦を開始しました。
ohshige.hatenablog.com
頑張って進めてみようと思っていましたが、現在止まっています。
いずれ再開したいです。
競技プログラミング
新しいこと3つ目。
これまたしっかりとやってこなかったので今年はやってみようかなと始めた競技プログラミング。
ohshige.hatenablog.com
毎日解くということとコンテストに参加するということの2つを意識していました。
頑張ってやっていましたが、毎日解くということについてはパタッとやらなくなってしまいました。
コンテストへの参加も土日に予定が入ることが多くなってしまい、なかなか参加できずにいるので勿体ない気持ちでいっぱいです。
技術カンファレンス初参加
実はカンファレンスなるものに参加したことがなく、あまり興味がありませんでした。
しかし、カンファレンスへの参加に関する風潮が社内で出てきて、会社の同期も登壇するということで、初めて参加してみました。
ohshige.hatenablog.com
初めて参加した技術カンファレンスはPHPer Kaigiでしたが、大変面白く、今後も色々なものに参加しようと思うようになりました。
5月〜8月
最初はGASに触り始めた頃だったのでそのネタが連続しています。
が、途中から仕事としてPHPでBEAR.SundayとLaravelをがっつり触ることになったタイミングだったので、PHP関連の話が多いような気がします。
GASで色々
知り合いに依頼されて初めてGASを触り始めました。
ohshige.hatenablog.com
特別にサーバを用意しなくても色々とできるので夢が広がったときです。
今でもちょいちょいGASで何かを作ることがあるので、いい依頼だったかもしれません。
PHP
仕事の影響でPHPでのAndroidのレシート検証やLaravelを使った実装など、PHPを全面に押し出していたときでした。
ohshige.hatenablog.com
ohshige.hatenablog.com
このときだけでなく普段からずっとPHPは触っていますが、仕事が忙しくて仕事以外に新しいことに挑戦できなかったため、仕事で得たことをそのままブログにしている典型的な例です。
9月〜12月
やっぱり仕事でやってることが如実に表れてしまっていますが、AWSやTerraformをずっと触っているときでした。
また、LTではありますが、初めて技術カンファレンスで登壇することもできました。
AWS
PHPを触りつつ、AWSもがっつり触るタイミングでした。
ohshige.hatenablog.com
これまではほとんどAWSの経験はなかったため、新しい気付きの連続でした。
下手するとずっとAWSの記事を書いてしまっていたかもしれません。
Terraform
AWSをやったあとはTerraformを触る機会もありました。
ohshige.hatenablog.com
もちろん初めてだったので試行錯誤することも多く、ブログネタにも困りませんでした。
ですが、AWSにしろTerraformにしろ初心者なので、記事の内容が伴っていないことも多く、不甲斐ないです。
技術カンファレンス初登壇
2月に初めて技術カンファレンスに参加してから10ヶ月後、LTではありますが、PHP Conferenceで登壇することができました。
ohshige.hatenablog.com
1年前までは「技術カンファレンスなんて」と思っていた自分が発表する側になるとはという気持ちでいっぱいです。
せっかくなら一般のセッションに登壇することも目指したいです。
その他
いくつか読んだ本についてもまとめました。
ohshige.hatenablog.com ohshige.hatenablog.com ohshige.hatenablog.com
おわりに
露骨に過去記事へのリンク集になってしまいましたが、1年続けられた嬉しさが表れてしまっているということで許してください。
まとめて思ったのは、結構同じ時期には同じようなブログになってしまっていて、普段の仕事や生活がそのまま表れているなということです。
日記は絶対に続かないのでやらないのですが、定期的なブログを書くだけで当時のことを思い出せるので良いものですね。
来年もできる限り続けようと思います。
良いお年を。
Gitでリモートブランチをチェックアウトするときってそんなに難しいことをする必要があるのか
Gitでリモートブランチをチェックアウトしたいときがよくあると思います。
他のエンジニアのGit操作をたまたま見る機会があり、そこで行っていた操作が気になってしまってこのブログに至ります。
git fetch
でも git pull
でも、とりあえずローカルにリモートブランチの方法を反映させます。
$ git branch -r origin/HEAD -> origin/master origin/new-branch
そのあと、
$ git checkout -b new-branch origin/new-branch
と実行していました。
が、「え、こっちでいいんでは」と自分は思っていて、基本的にこちらを使います。
$ git checkout new-branch
リモートブランチ名とローカルブランチ名を明示的に変えたい場合は前者で良いかもしれないですが、そうでない場合は後者でいいではないかと思っています。
何か他に違いがあるのでしょうか...?
もちろん、Git 2.23.0以降は checkout
ではなく switch
を使っていきたい所存です。
Gitの新しいコマンドのswitchとrestoreに慣れたい
しばらく前にGitの新しいバージョンがリリースされ、そこで git switch
と git restore
なるコマンドが使えるようになったことは知っていました。
しかし、これまでの慣れというものがあり、どうしても git checkout
を使ってしまっていました。
先日、ふと新しい環境(つまり新しいGit)を操作していて、 git status
を打つと以下のように表示されました。
$ git status On branch hoge-branch Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory)
git restore <file>...
と表示されています。
古いバージョンだと git checkout -- <file>...
だったはずです。
これを見た瞬間にいつまでも git checkout
だけを使っていたらダメだなと思い、使い方を調べた次第です。
ただ、switchもrestoreも THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
らしいので、注意は必要そうです。
git switch
ブランチを切り替えるためのコマンドです。
旧: git checkout another-branch 新: git switch another-branch
めちゃくちゃわかりやすい名前になっていると思います。
なぜ最初からこうじゃないのか。
新規でブランチを作ってそのままそのブランチに切り替えることもできます。
旧: git checkout -b new-branch 新: git switch -c new-branch
これまで、 git checkout
は git c
、 git checkout master
は git cm
、 git checkout -b
は git cb
になるようにエイリアスを設定していました。
これを機に、 git s
とエイリアスを張りたいところですが、switchのsがstatusのsとかぶって微妙につらいところです。
git restore
変更を復元するためのコマンドです。
旧: git checkout README.md 新: git restore README.md
ステージングにインデックスされた状態からadd前に戻すためには以下のようにします。
旧: git reset HEAD README.md 新: git restore --staged README.md
変更をなかったことにするのは git resrote
でわかりやすい気がしますが、addを取り消すのは git reset
のままの方がなんとなく好きです。
文句を言っても仕方ないのですが。
PHP Conference Japan 2019 でチームに設計を取り入れた話についてLT登壇しました
これは エキサイト Advent Calendar 2019 の9日目の記事です。
はじめに
先週の12/1(日)に PHP Conference Japan 2019 があり、そこでチームにクリーンアーキテクチャっぽい設計手法について導入してみた話でLT登壇してきました。
そのときの総合的な(?)内容に関しては前回ブログを書きました。 ohshige.hatenablog.com
社内等でのLTはよくやっていて好きな方ではあるのですが、外部の大きなカンファレンスに登壇するのは初めてでした。
経緯
これまではLTであれ登壇は一切考えていなかったのですが、同期が登壇したり、弊社に技術カンファレンスの文化を根付かせようと後輩が一生懸命が頑張ってくれたり、そういう風潮になってきたので、「俺もやりたいぞ」と考えるようになりました。
そんなこんなで、プロポーザルを出して無事に採択されたので、登壇することになりました。
その後輩の文化形成の頑張りはこちらにまとまっています。 qiita.com
「運用経験ばかりのメンバーと新規開発で初めてしっかりと設計から開発までを経験した話」
LTの内容はこちらです。
新規開発の際にクリーンアーキテクチャを導入するためにチームで取り組んだことを紹介するような内容で、詳細なクリーンアーキテクチャの設計論に関しては発表していません。
背景
しばらく前に「cocorus」というリラクゼーションアプリをリリースしました。
これは寝たまんまヨガというアプリをフルリニューアルしたアプリで、裏側としてはほぼ新規開発と同じような感じでした。
今回の話は、このcocorusアプリのAPIを作成したときの話です。
なぜ取り入れようと思ったのか
せっかく新規開発をするなら、これまではしっかりとやってこなかった設計をしっかりやれたらと思ったのがきっかけです。
これまでは既存サービスの運用・開発が多く、どうしてもファットコントローラーになってしまい、密結合でテストが書きづらいものばかりでした。
このようなアプリケーションとは決別したいという思いが強く、Webの世界やDBとの分離をしっかりと行い、本質的な処理に集中できるような設計にしようとチームメンバーを説得しました。
そこで出てきたのがたまたまクリーンアーキテクチャでした。
そのため、クリーンアーキテクチャだったのは本当に偶然で、上述した通り基本的にはポート&アダプターの思想であれば良く、もしかしたらヘキサゴナルアーキテクチャや独立したコアレイヤーパターンなどになっていたかもしれません。
チームに受け入れてもらうために何をやったか
チーム発足時にクリーンアーキテクチャの良さを熱烈にアピール
本質的な処理に集中できたり、テストが書きやすくなったり、なぜクリーンアーキテクチャを採用すると良いのかということをアピールしました。
全エンドポイントのモックを事前に作成
リリース日は決まっていてアプリサイドの実装ももちろんあるので、事前に全エンドポイントのモックを作成して提供することで、アプリサイドの進捗に影響が無いようにしました。
アプリサイドがモックAPIを使って作業を進めている間に、サーバサイドは慣れないクリーンアーキテクチャで実装を進めたり議論を進めたりするようにしました。
導入しやすいように基礎部分のサンプルを自ら実装
APIの基礎部分のサンプルを最初に自ら実装して、チームメンバーにはそれを参考にして実装を進めてもらいました。
率先してすべての Pull Request に目を通す
サンプルを参考にして実装を進めてもらいつつ、そこで出てきたPRは自らすべて目を通すようにしました。
これによって、チームメンバーが理解出来ているか、方向性が間違っていないかなど、早い段階で気付ける体制にするようにしました。
わからないことがあればその都度議論する
設計やクリーンアーキテクチャに明るいメンバーは自分も含めていないため、正解というよりもベターな解を求めるために、何かわからないことがあればその都度チームメンバーで必ず議論するようにしました。
これによってベターな解を得るだけでなく、納得感も得るようにしました。
非クリーンアーキテクチャ至上主義
クリーンアーキテクチャは採用していますが、必ずしもクリーンアーキテクチャにこだわりすぎないようにしました。
良いところはもちろん採用しますが、難しいところ合わないところは無理に採用せず他の方法を使うようにしました。
最終的にどうだったか
新規開発だったためゼロベースで設計から開発まで進められたのはとても良かったと思います。
これが、既存サービスへの導入であれば、もっとかなり苦戦したはずです。
基本的にいろんなタイミングで議論するようにしましたが、その議論を受け入れてくれるようなチームメンバーであったのは大変助かりました。
「議論してる暇があれば実装を進めた方が良い」などの思い違いがあればもっと苦労していたかもしれません。
今回はAPI作成で返却値はJSONと決まっていたので、プレゼンターの設計は妥協しJSON決め打ちにしました。
最初からモリモリでやると大変なことになってしまうのが常なために、妥協して進めることに決めたのは良かったですし、今のところ特に問題も置きていません。
わからないことがあればその都度議論するようにしましたが、トランザクションやバリデーションなど結局何が正解でどうすれば良いかわからないということもいくつかありました。
そういう点では設計やクリーンアーキテクチャに明るいメンバーがいないチームに導入することの限界も感じてしまいました。
とは言え、総合的に見れば成功したように感じます。 が、このような設計は日々の運用の中で何かしら生きてくるものがあるものなので、新しい設計に挑戦して良かったクリーンアーキテクチャで良かったと思える日が来ることを信じています。
おわりに
今回は初めて大きな技術カンファレンスにLTとして登壇しましたが、とても良い経験になりました。
こういうカンファレンスなどの懇親会はぼっちが怖くて参加に苦手意識があったのですが、登壇者だと意外と皆さんから話しかけていただけるのでぼっち回避にもなりとても良かったです。
次はLTではなく普通のトーク枠で登壇したいところです。