2018-10-13

今後

今後自分はどうするべきかみたいな悩み、多分答えはでないような気がしている。たぶんこの話は変化するものだと思っているから。以前は〇〇するべき、と考えがちだったサバイバル規則に選択肢を与える、その変換がうまくいくようになってきている感じもしている。どう転んでも最終的には自分でけつをもつ、ただ、まぁなんとかなるさくらいの気持ちの持ちようで、肩の力を抜いてやっていきたい。今は魅力と感じるミッションを持った会社さんで、その実現に向けて切磋琢磨するチームメンバと働けていて本当に幸せである。早く貢献できるようにがんばりたい（風邪を治したい）。

2018-10-11

戦略

Netflixの本を読んだ。実例という点もあって読みやすく、一気に読むことができた。改めて感じたことは一貫したストーリーの大事さとそれを実現するために必要な仕組みづくりという点。ビジネス上掲げる勝ち戦略があり、サービス、技術、採用を含めた戦術を思考し実行へ移す。決めただけで物事がスムーズに進むことはなく、明文化から、コミュニケーションの設計（権限委譲含む）、小さく継続的に行う仕組みも大事になってくる。目標を合わせることの重要性についてはピープルウェアでも同じようなことが書いてあった気がする。実現するにあたってここまで振り切った意思決定を行える企業はそうないだろうと感じた、特に人事にいたっては。日々の課題は尽きないし、できることも少ない。だからこそ根から考え優先順位の決定を行っていく。課題が起きると目がそこにだけ向きがちになる、時に一歩引いて全体を俯瞰してみることを忘れないようにしたい。

2018-10-06

定期的に何かを作る場

最近またイベントの開催を始めている。以前までconnpassさんを利用させて頂いたけど、ドッグフーディングがてら自分のサイトで告知と募集を行っている。メンテらしいメンテをしていなかったので、諸所忘れている部分が多い。告知場所が今は自分のSNS中心になっているけど、町の掲示板に貼ったりとか、身近な人が気軽に参加できるような場所になればいいなとも思っている。開催場所は武蔵小山にあるスクエア荏原という施設で品川区民の人は少し安く借りれる。平日の仕事終わりだとあまり時間とれないけど、定期的に時間をとってコツコツやっていきたい。

event.makewith.jp

夜飯だけでも一緒にとかでも全然構わないので、お時間があれば是非。

2018-07-16

結局人である

どんな仕組みであれ、どんな機能であれ、どんな技術であれ、最終的には人が利用する。

そういった考慮もなく進めるときっとうまくいかないんじゃないかなと思っている。

2018-05-19

文書ツール

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

2017-12-18

小さくコードを保つ指針

WIP プログラミング

この記事は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();
     }
}

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

その他念頭に置くこと

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