文書ツール

機能を実装する前に課題とか解決案とか整理する時にGoogleドキュメントがすごく整理しやすいなぁと思うようになった。 箇条書きしていって、各センテンスで深掘りしていくときのタブ、多分ここが使いやすさにつながっているような気もしている。 最初はまだ整理が出来ていなくてネストが深くなりがちになるから、ページ設定から用紙サイズをA3とかにしておく。 見出しがあったら抜き出して再整理のループという感じ。以前までは、Markdownとかで書けるツールがいいなとも思っていたけど、 文書がどう表示されるか頭のなかで考えたりとか、プレビューを押しての確認とかがとにかくめんどくさい。年のせいかもしれない。

小さくコードを保つ指針

この記事はRelux Advent Calendar 2017 18日目の記事です。

qiita.com

Webアプリケーションのフレームワーク上で小さくコードを保つ指針的なものを自分へのメモとして記載した。
昨今の横文字は一旦忘れる、問題は大体そこじゃない。

前提. コードの歪みは仕様の歪み

要望は要望であって鵜呑みにすると痛い目に合う。考えられていない前提を持つ。仕様とコードの依存関係は密であって、コードが複雑化しているのは仕様だったというケースがある。仕様を精査する過程で、代替となる機能を発見できたり、そもそも作らないという選択が出来ることもある。実装前にまずは精神を落ち着かせて、仕様に向き合うこと。何かしらの要因で向き合うことが出来ていない状態であれば、根本の課題を探り、その解決に向けて動く必要がある。

メソッド名に迷ったら

「これお願いね!」
「いやいや俺じゃないって」
「お前か!」
「ガハハハ」

オブジェクトに対して話しかけるメッセージングが不自然になってないかを考える。実装しようとしてるパブリックのメソッドが既存にあるオブジェクトにあると違和感を感じたり、他に適切なオブジェクトが閃いたら、積極的に新規でクラスを作っていくのも手の一つ。メソッド名が長くなってしまったり、適切な名前が浮かばなかった時は、そのクラスの責務ではない信号かもしれない。

請求書の封筒に貼るラベルをPDFとして一括ダウンロードする機能があったとする。

// app/Controller/InvoiceLabelsController.php
class InvoiceLabelsController extends AppController
{
     public function index()
     {
         // 一覧を取得してPDFとしてレンダーする処理
     }
}
// app/Model/InvoiceLabel.php
class InvoiceLabel
{
     private $somethingA;
     private $somethingB;

     // ラベルに必要なオブジェクト
     public function __construct(
         SomethingA $somethingA,
         SomethingB $somethingB
     ) {
         $this->somethingA = $somethingA;
         $this->somethingB = $somethingB;
     }

     public function listAll()
     {
         //ラベル取得に必要な処理をゴニョゴニョ書く
         // $this->somethingA->doSomething();
         // $this->somethingB->doSomething();
     }
}

既存のコントローラーやモデルに書く形でも勿論問題ないが、これ以上太らせちゃいけないものもある。コントローラーやモデルとなるクラスを新規に抽出していくことで、既存クラスに影響を与えず、小さい責務のクラスを作っていくことが出来る。大体後から追加仕様が入ってくることを念頭におく。

一つのクラスに依存するオブジェクトが多い時

上記モデルの実装例だと、二つのオブジェクトへ依存していることが分かる。 追加の要件で封筒に入れる送付状も合わせPDF出力したいという要望があった場合、どう実装していくべきか。その送付状へ記載する内容は別のオブジェクトが必要だと仮定する。

// app/Model/InvoiceLabel.php
class InvoiceLabel
{
     private $somethingA;
     private $somethingB;
     // 追加で必要となったオブジェクト
     private $somethingC;

     // ラベルや送付状に必要なオブジェクト
     public function __construct(
         SomethingA $somethingA,
         SomethingB $somethingB,
         SomethingC $somethingC
     ) {
         $this->somethingA = $somethingA;
         $this->somethingB = $somethingB;
         $this->somethingC = $somethingC;
     }

     public function listAll()
     {
        //ラベルや送付状に必要な処理をゴニョゴニョ書く
        // $this->somethingA->doSomething();
        // $this->somethingB->doSomething();
        // $this->somethingC->doSomething();
     }
}

既存コードを流用すると上記のようなコードを書いてしまいそうだ。オブジェクトの依存関係に着目する。送付状という別のモデルを抽出して、送付状に必要なデータ取得のメソッドを生やす形か、そもそも分割を行ったクラスが誤った依存関係を生み出してしまってないかを検討する。請求書のモデルに対して、ラベル取得、送付状取得のメソッドを生やし、オブジェクトのリレーションを辿る方法もある。難しく考え過ぎていると感じたら、既存にあるオブジェクトでその責務を果たせないかも検討する。

その他念頭に置くこと

  • 歴史を振り返る。
  • チームの状態はどうだろうか?他に優先して潰すべき課題はないだろうか?技術だけで解決できない問題があることを知る。
  • やりすぎると大体失敗する。小さく積み上げることを意識する。
  • 時にはスピードも意識する。ただ、最低限守るべき事項をチームで明示化し、厳守する。
  • 機能の改修でリファクタリングの必要性を感じた時は、しない形でまずは実装を行う。実装後に、リファクタリングのブランチを切って、積み上げる。何故なら大体深みにはまってしまうからである。
  • 既存コードがさっぱり分からない時は、捨てるという選択肢を視野にいれる。一から作り直す方がコストが小さく済む場合もある。
  • フレームワークのレールから外れることを検討したとき、その役割を明確にし、チームで共通の認識を持つことが必須である。説明機会から、クラス設計・コードへのレビューコストをかける、また、今そこにいない仲間の受け入れがすぐ可能な状態にすることも必要である。その前提を受け入れて、本当に導入すべきか、今一度考え直す必要がある。大体破綻する。

いつもよく見返している資料

最後に

自戒を込めて

「コード改善 meetup #1」を開催しました

kaizen.connpass.com

今まさに取り組んでいる事項です。

組織で推進していくにあたって、様々なアプローチや悩み、障壁などがあるという想定で
LT + 参加者同士で対話を行う時間を入れて開催を行いました。

開催前は「PHPコード改善 meetup #1」という名前を検討していましたが
言語に特定される話でもなく、特定したことでコミュニティに依存し
参加者が偏るのを防ぎたかったため、PHPというキーワードを外しました。

そして、コード改善は継続して行っていくもの、銀の弾丸はないと思っています。
#1 と記載した通り、本会を継続して行っていく所存です。

発表した内容について

前段はこれまでの経験による振り返り、そして、先月からお手伝いを始めた企業での取り組みを
最後へ簡単に紹介しました。

これまでの背景や結果をフィードバックせずに、改善を進めてもきっとうまくいきませんし
課題に対して主体的に動けていない状況であれば、そこにもまた何か別の問題があると考えます。

日々の業務に追われていて時間が取れないケースであれば、その時間を作るためにどうするべきか
提案で四苦八苦している場合であれば、その根拠をしっかり説明するためにはどうするべきか

推進できていない原因を自身で探り、その対処を自身で考え主体的に動いていくことで、
何かしら変化を起こすことができると信じています。

終わってみて

最初は正直どうなるか不安でしたが、意見交換が非常に活発で
率直に本当にやってよかったと思える会となりました。

blog.mogmet.com

@mogmet さんに内容をまとめて頂いて、本当に感謝です。
(次回はメモ取る係が必要ですね…)

hamuhamu.hatenablog.jp

などの感想も頂いて、本当に嬉しい限りです。

また、今回会場をご提供頂いた 株式会社Loco Partners さん、誠にありがとうございました!

次回は7月に実施の予定、テーマを少し絞るかもしれませんが
ご都合がよろしければ是非!

Rubyの会を久々やります

f:id:hondabin:20141029111919j:plain
※今回は和室ではありません

約1年振りの開催となりますが、実施します。


第6回『Rubyで何か作ろうかい(会)』@武蔵小山

11/14日(金)19:30〜 の実施となりますが、18:00から空いていますので
ご都合がつく方は早めに来て頂いて、一緒にもくもくしましょう。

場所は、品川区が提供するスクエア荏原さんの場所をお借りして行います。

施設が出来てからそれほど年数が経っていないため、館内は非常に綺麗です。
比較的安い料金で施設を利用できるため、仕事場やお住まいが近辺の方は、
勉強会などで利用してみるのもいいかなと思います(wifiはないのんですが)。

武蔵小山のパルム商店街終端くらいと少し駅から歩く場所となりますが、
名所となる商店街ですので、是非楽しみながら起こしください。
焼き鳥屋さんなどの誘惑に負けないよう..お願い..します..。

こちらの会は毎月1〜2回ほど定期的に実施を行う予定です。
仕事終わりに気軽に立ち寄って勉強できる場になればいいなと思っています。

と、またまだ空きございますので、ご都合がよろしければ是非!!

第6回『Rubyで何か作ろうかい(会)』@武蔵小山

オープンソースにて開発を一緒にしませんか?

5〜6名程度のグループワークにてオープンソースで開発を行うイベントをイノベーション東北さんと現在企画中です。
(おそらく10月〜11月のどこかで実施を予定しています。)

作るものは、とある事業者さんのサイトをリニューアルするという内容になりますが
開発現場の第一線で使われている技術を利用し、その技術習得をできる場となればとも思っております。

言語は今のところ未確定(Ruby on Rails or Go ..etc)となりますが、GitHub、CIツール、PaaSを使って開発を進めます。

  • Gitの理解を深めたい
  • GitHubでの開発フローを経験したい
  • CIツール、PaaSを使った開発フローを経験したい
  • テストコードの理解を深めたい(単体、結合と両方書く予定です)

方であったり

  • 普段ぼっち開発なので..チームでの..開発を..経験..したい..
  • テーマが決まらない..(作ろう会メンバーの方)

また、企画の段階から一緒に参加頂く事を予定していますので、開発プロジェクトを一から経験する場にもなると思っています。

興味のあるデザイナー・プログラマーの方、上記技術を得意とするエンジニアの方(是非サポート頂きたいです..)と、
本イベントをきっかけに、一緒にワイワイ開発を行いませんか??

尚、普段お仕事が忙しい方や、時間の都合がつかない方も沢山いると思いますので、
無理のないスケジュールで、かつ、リモートでもお手伝い頂ける環境を整えたいと思っています。

本会のイベント詳細が決まりましたら、別途、makewith.Eventにて告知を行いますが、
現時点で興味がある方がいましたら是非、honbinまで!!

Enjoy!!

私の作業場所

先日の合宿昨日の準備会にてプロトタイプができた。

f:id:hondabin:20140713175809j:plain

makewith.Place

  • 登録は誰でもできるけど管理者が承認
  • 情報に変更があったら、だれでも管理者に変更のリクエストを投げれる仕組み
  • 実際に行ってきた感想をコメントで共有できる仕組み

イメージはgithubに近いです。