社会人2年目をエモめに振り返る

エンジニアとして2年めが終わったので振り返り。今思うことは今書いておかないと忘れちゃう。あと根がネガティブなので記しておかないと「私1年何やってたんだろう・・・」とすぐなっちゃうので。

ちなみに1年目の振り返りエントリは以下。

chiiia12.hatenablog.jp

今年度の主なトピックは以下。

  • Androidアプリエンハンス&その中で学んだ諸々。
  • スクラムチームの再立ち上げ
  • プライベートでのアプリ開発
  • 外部イベントの参加

が大きな出来事だったかと思います。

Androidアプリのエンハンス

1年目は新規アプリの開発がメイン&かなり短いスパンでチームを移動していたので、同じチームで一つのプロダクトを開発し続けるという経験は初めて。新規ではなくエンハンスをする中でただAndroidの実装スキル以上のことを学ぶきっかけになった気がする。

ライブラリの導入

今までのチームはモダンなライブラリをいれよう!という話があまりなかったので、今のチームに異動してきてから同じチームの先輩にはすごく刺激をもらった。

Realm、ActiveAndroid、Retrofit、などまだ使ったことなかったライブラリなどを、今年初めて触ったり。導入を進める先輩にライブラリの特徴・思想を聞いたり、何が便利なんだっけ?を考えたりするきっかけになった。特に先輩がRetrofitにプルリク送っているところを隣で見れたりして、すごく刺激になった。 その後、自分でチームにLightStreamAPIを導入したりできて、ちょっとだけチームのプロダクトどういう風にしていきたい?という気持ちが芽生えてきた気がする。 ライブラリを導入すると、何をどうやって便利にするライブラリなの?を考えるようになるので、自分で設計を考えるときにも参考になるなーと感じる。リスクの方が語られがちだったり学習コストなども考えるとライブラリの導入などはハードルが高かったりするけど、設計方針などのインプットにもなるのを考えるともっと導入すべきだなーとも思うようになった。

変更に強い・バグを生みにくい設計

先輩にココらへんの話のインプットはすごくしてもらった。あまり今まで設計のことを考えたことがなかった。正確にいうと、既にあるアーキテクチャに従う練習はちょっとしてきたけど、アーキテクチャを選択する練習をしてこなかった。なんでこういうアーキテクチャになっていてなぜそれを選ぶ?という観点がなかったので、そこを養えたのはよかった。デザパタとかクリーンアーキテクチャの話とかなどなど。 以下の記事は色々インプットしてた時で整理してた頃。

chiiia12.hatenablog.jp

chiiia12.hatenablog.jp

あーちょっと恥ずかしくて見たくないエントリ…

テスト自動化

スクラムを再立ち上げした頃にユニットテストコードを書いていこうというルールになって初めてテストコードというのを書くことになった。 社内のアプリチームではテストコードを書いているチームがあまりなかったので良い経験になった。色々社内の先輩などに相談できる機会があったりなど、ただテスト自動化すごい!じゃなくてメリットやデメリット考えつつどう進めていったらよい?なことは考えるようになったかも。最初はデグレをなくしましょうという話からテスト自動化の話が始まった気がするけど、設計やリファクタの話につながっていくところまで考えられるようになった。 かなりここの分野も楽しくてこれからももっと知りたいなーと思ってる。

chiiia12.hatenablog.jp

スクラムチームの再立ち上げ

スクラムチームをどう立ち上げてどうなったかはこちらのエントリで。

chiiia12.hatenablog.jp

上のエントリに書いたとおりスクラムチームの再立ち上げを2回経験していて。2回やってようやくスクラムの良さみたいのを感じれた気がする。すごく今はアジャイルの考え方の虜になっていてここの分野ももっと知りたいなと思っている。 元がコミュ障で人の言うことをすごく気にしてしまうので、チームの環境によって自分のキャラを出せなかったりパフォーマンスも左右されてしまうんですよね。そういうところをスクラムとかのアジャイルフレームワークは多少でもカバーしてくれる気がしている。なので自分にはすごく合っていたのかも?と思ってる。

コーチの人に言われたことで印象に残っているのは 「問題解決は簡単だ、解決方法はいろんなひとが試しているからそこらじゅうに転がってる。大事なのは問題発見する能力。ここが長けている方が価値の高いことなんだよ」 というようなことを言われたこと。問題発見したからやばい、もうダメなチームだ、じゃなくて問題が見つかったってことは今まで見つからなかったことが問題として見つかったのは良いこととポジティブに言われたことが自分の中でも改善に対する捉え方が変わった出来事だったと思う。

プライベートでのアプリ開発

2年目になって1年目のように資格勉強に時間取られることもなくなったので、プライベートでサービス開発しているチームにjoinしました。Androidアプリ作りたいけどちょうど人がいないという時に誘ってもらって、タイミング良かった。 これまで社外でこういったコミュニティがなかったので、違う会社の話を聞けたり視野も広がったり。

www.service-safari.com

play.google.com

業務で試せてないライブラリやツールを試せる機会になったり、業務とプライベート複数同時にプロジェクトを進められる良さを知れた。一つ自分が作ったプロダクトができたのもうれしい。 その後自分一人でもう一個アプリ作ってみたのも勉強になった。CI自分で回したり自分でストアにあげたり。アイコンも自分で作ったり。自分が作ると他のアプリも注意深く見るようになるなー。自分だけでやってるので放置になりがちなのが反省点。

外部イベントへの参加

これも2年目になって業務都合をつけやすくなったので、ちょこちょこ外部のイベントにも参加するように。同じ年代の人がLT登壇とかしていてやばい!!!と良い刺激にも。

chiiia12.hatenablog.jp

去年も行きたかったけど行けなかったDroidKaigiにも今年初参加! 他の会社がどんなことに取り組んでいるのか、最新技術等やっぱり行かないとわからないことがたくさんでとてもよかった。登壇にも挑戦してみたいなぁ。

今年はDroidKaigiの公式アプリにもコントリビュートすることを目標にしていて、本当にちっっちゃなBugFixだけど英語でプルリク出してみたり。いつもtwitterで見るアイコンの人がコード見てくれて当日のContributersスライドにアイコンが載ったり。かなりうれしかった出来事。

今年度の最後にはJJUG CCCの登壇も決まり準備をそろそろ始めなきゃという感じ。去年はおっかなくて周りの人に投票なんてお願いできなかったけど、背中を押してくれる先輩もできて、いろんなコミュニティに投票をお願いできたり、良い関係のコミュニティが増えたんだなぁと感じて、前向きに色々がんばれてるなと思う。

その他

そういえば応用取ったし次は高度受けるかっつってネスペを受けたけど午後で落ちた。情報処理試験はいつも勉強がつらい。

後はちょっとしたクリエイティブ。

chiiia12.hatenablog.jp

chiiia12.hatenablog.jp

後は会社でOSS勉強会なるものに参加したり(先輩のコードでnodeにプルリク送ってみたり)、外部の会社のエンジニアとTDD的な勉強会でGo触ったり。 刺激!な1年だったのかも。

まとめ

会社の先輩にこんなこと言われたのが印象的でそう信じてる言葉。

「エンジニアはやればやる程知らない事が増えていく。知らない事が減るってことは成長していないということだから、知らないことが増えていくことは良いことだと思って!」

この1年も色々新しい世界を知れて楽しかった!特に周りの人には恵まれていたなと思っていて、良いまさかりをたくさんもらえたなー。相談できる人も増えたしかなりのびのびやらせてもらえたと思っている。まだまだ技術力は低いと言われているのが悔しいところで、そこはこれからも伸ばしていきたいところ。

今年は取り組んできたことをブログなりなんなりにアウトプットすることを重視してきた気がする。ちょっとブログを読んでくれる人が増えたりして、自分のことを知ってくれる人がいるのはうれしいなーと思ったり。あと精神安定的にも◎。 今年は、ブログだけじゃなくてもっとコード書いてアウトプットしなきゃな。

次はどんな1年になるんだろう!3年目もがんばるぞー!

テストについて相談しにいった内容をまとめる

チームのテストについての進め方についてアドバイスをもらう機会があり、これからの進め方についても参考になったのでまとめる。

前提・背景

  • アプリ開発チーム。
  • Model,Controllerは必須で単体テストを書くというルールで開発している。
  • 振る舞いテストも一部コード化してリリース前に自動で回している。

今のチームでの課題

  • 単体テスト書いてきたが、なかなかメリットが享受できていない気がする
  • ふるまいテスト書いてみたはいいが、この先どう展開していくのが良いのだろう?
  • viewにビジネスロジックが積まれていてなかなかテストが書けない。構造見直ししたいがアーキテクチャの指針なくできない。

viewにビジネスロジック問題

viewにビジネスロジックが書かれていてテスト書きづらい。 どうにかしたいが、リファクタするにはテストがいる。 じゃあテスト書きたいけど書きづらい!の堂々めぐりになってしまう問題。

実装の構造に依存する・実装に近いテスト(例:ユニットテスト)は書きづらいので、実装から遠いテスト(例:ふるまいテスト)を書いてリファクタする準備をまずしましょう、というのが次のアクション。なるほど!

振る舞いテストで安心してリファクタできるようになれるのか

たしかに、怖くてリファクタできない!けど構造変えなくては!の打ちてに対して実装に依存しないようなシステムの外からのテストを書けばよい!というところには納得。 現状、今のチームではアプリをリリースする前に毎回行っているアプリの根幹の機能(主に遷移周り)のテストを書いている。でも、粒度もすごく大きいテストケースなので、それで安心してリファクタできるイメージが湧きません!

それに対してのアクションは、まずカバレッジをとりましょう。まずどこがカバーされているテストがあるのか、どこのコードが通っているテストがあるのかを可視化する必要がある。テストが通っているところから構造変えていくようにすればよい。

この話をふまえると、これから構造よくしていきたいところにユニットテストを書いていくより、ふるまいテストの拡充を優先度を上げた方がいいのだろうな。まずは外から、だんだん中に入っていってカバレッジなどをあげていく。 今までカバレッジなどは気にしないで「書けるところを書いていこう」の指針でずっと来てしまったので、きちんと数値とっていかないとダメですね。

振る舞いテスト(≒スモークテスト)の運用

今チームの中で振る舞いテストと言ってるものは「スモークテスト」と呼ばれる「このテストが落ちると、リリースしてはいけないというレベルのもの」になる。 このスモークテストを今までリリース前に最後のチェックとして行ってきた。本当はリリース前に煙が出てもしょうがないので、普段から本当は回すべき。プルリクがマージされた時などに自動でテストが回るような仕組みにしておくと早めに重大な問題に気づくことができてGood!

アーキテクチャ決まってない問題

アーキテクチャに関しては最初は「王道なもの」を採用してやってみると良い。同じ挑戦している人の人数も多いし、ぶつかった人も多いので、導入もしやすいだろう。MVPならMVPと決めてやってみると処理を書く場所があらかじめ決まっているのでテスト書かなきゃいけない処理も決まってくる。一回入れてみて問題が出てきたらまた考えても遅くなさそう。

[おまけ]テスト自体は品質をあげるものではない

テストコードを書くこと自体は 品質をあげるものではない。 テストコードを書くことで、プロダクションコードに影響を与える(リファクタできれいになる、使いやすいように引数の種類変えてみようかとか)ことで品質があがっていく。なので、テストコード書いてプロダクションコードが変わらないのは別に品質あげてないよ。もちろんデグレを防ぐみたいな役割もあるかもしれないけど、品質はあがってないよね、下げるのを防いではいるけど。 という思想があるので、テストファーストに越したことはないが、テストファーストをするためにはプロダクトの実装の仕方(構造が悪いとか)にも寄るしある程度のスキルが必要なので、テストファーストにこだわらなくてもよい。大事なのはプロダクションコードにプラスの影響を与えられているか。

[おまけ]mock使う派?使わない派?

テスト駆動開発界には流派が2つあるらしく、mock使う派(テストは分離した方がよい)と使わない派(本物のデータを使う方がよい)とがいるらしい。

mockする派

テストしたいクラスを狭めることができる。mockしていなかったら依存しているクラスの中もテストしていることになるけど、mockすると純粋にそのクラスのロジックをテストできる

mockしない派

自作自演のテストになる可能性がある。mockしている実体が変わったら意味がなくなっちゃうから。テストは通るけど結合したらうまくいきませんーみたいなことが起きてしまう。 最近のmockライブラリは強力なので、なんでもできてしまう。そもそもmockが必要になるというのは設計としていかがなものか?を気づく基準にもなるけど、強いmockライブラリがいるとスルーしてしまう可能性。この話は先輩からも聞かされたなぁ〜。

さいごに

今までどう打ちてを打っていいかわからないところをアドバイスもらえて次の一手が見つかった気がする。テストの世界では当たり前の考え方なのかもしれないけど、ぺーぺーの自分にとってはすごく有益なアドバイスをいただける機会でした。

#droidkaigiに行ってきて思ったことをダラダラ書いてみる

初めてDroidKaigi参加したので、ちょっとまとめるのが遅くなってしまったが記憶が新鮮なうちに考えていたことを残しておきます。 https://droidkaigi.github.io/2017/timetable.html

参加したセッション

参考までに参加したセッションは以下。

How to apply DDD to Android Application Development
リリース自動化と効率のよいリリースフローを求めて
インスペクションとAndroid Lint Custome Ruleによる、単一責任実装の実践
Data Bindingで開発を気持ちよくしよう
Android Resources Refactoring
オフラインファーストなアプリケーション開発
How to remodel current testing environment
What's New in RxJava 2.0
Android ORMの選び方
How to implement material design animation
Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ
2つのアプリ、1つの設計のデザイン指針
エンジニアが武器にするMaterial Design
LayoutManagerをつくろう

特に強く印象に残ったこと

特に印象に残ったテーマを以下に記していきます

オフラインファーストなアプリケーション開発

https://speakerdeck.com/zaki50/ohurainhuasutonaapurikesiyonkai-fa Realmすごい…。今のチームでもRealmいれてるけどバージョンが昔すぎて全然キャッチアップできてないことがわかった。 オフラインの時の体験を考えるってアプリならではの観点だから新鮮&そこにも踏み込んで考えていけるのがアプリのいいところ。

実際今のアプリってどれくらいオフラインファーストにされているんだろう

すごくこのセッションの内容に刺激を受けたので、オフライン状態で今のアプリがどれくらい使えるのか触ってみた。

  • Facebookinstagramgoogleフォト、メッセンジャーGoogle Play Musicはオフラインでもだいたい使える
  • instaは前に読み込んでいた10件くらいはオフラインでも見えるようになってる。追加読み込みだけできない。
  • twitterは微妙。ツイートはできる(iphoneのみ)けどタイムラインは見れない
  • Google Play Musicはすごくて、自分の評価した曲はオフラインでも聞けるようになってる。おかげで端末が圏外であることに気づかなかった。

今のチームのプロダクトはどうなんだっけ

アプリの業務仕様上最新の情報を常にリクエスト投げて確認しなくてはいけないので、通信エラーにすごく厳しいアプリになってる(オフライン時は通信エラーダイアログが出てで画面遷移できない)。オフライン時にアプリを立ち上げるとマジでなにもすることができないアプリになってた。

今まで「通信状況の悪さ」はアプリでは担保せず、ユーザーの状況が悪いんだよというふうに伝えてきた。けどこういう簡単に実装できるプラットフォームが出てきたりすると、通信状況というのはユーザーの責任ではなくアプリの責任になっていくのではないか?本当は通信エラーで画面遷移できないとかは、こっちの勝手な仕様のためにユーザビリティ落としているってことになるんだよなぁ。

なのでこれからはより通信状況に依存しないアプリの操作体験を作っていかなきゃいけなさそう、作っていきたい。 実際有名なトップレベルのアプリはオフラインでもある程度操作できるようになっているし、通信状況がないこともとても控えめに伝えるようになってる。気づきそうで普段意識してない観点を考えるきっかけになってよかった。

エンジニアが武器にするMaterial Design

https://speakerdeck.com/seto_hi/enziniagawu-qi-nisurumaterial-design webと比較してアプリのデザインてグラフィカルなスキルだけでなくOSの標準の挙動とかOSが推奨しているデザインも把握していなきゃいけないよね→かなり負担なのでは?というところからアプリのユーザー体験みたいなところにエンジニアがもっと関わっていこうよ、というお話。特に、Androidは「iOSのデザイン、これAndroidにして」事件が多発しているし同じ課題を持っている人は多そう。

KPIの置き方のはなし

企画の人にとってはKPIに直つながる案件をしたいというのは当たり前なんだけど、時たま「ユーザビリティを多少落としてでも」アクションがあがる施策をやる判断になってしまうことがある。そういう時にわかってはいるんだけどもやもやするという経験があって、そういう時に「いやいや、ユーザビリティ落とすのはダメでしょ、なぜなら」を言えるエンジニアになりたい、けど言えない&うまく説明できない自分。この答えの一つが「エンジニアが武器にするMaterialDesign」なんだと思っている。本当はユーザビリティがKPIにつながっていること&重要さを証明できればいいのだが、現状難しいのかも。

キャリア戦略として

自分の会社はいわゆるグラフィカルデザイナーとUXデザイナーが別職種としているので、エンジニアがUXのところまで踏み込む武器のつけかたを見たことがなかったので、すごく刺激的だった。自分も興味がある分野だったので、これからどこ武器にしていくんだっけ?の参考にとてもなった。もうすごくステキな話で本当に聞きに行ってよかったと思った。

その他

他の会社の開発環境が聞けるの、すてき

なかなか会社内にいると開発環境も似たり寄ったりなので、他の会社の開発環境が聞けてとても刺激的だった。世の中のプロダクトがこんなにRxJavaやDaggerなどの今時のライブラリを使って開発してるとは…。ライブラリを入れる入れないはちゃんと判断が必要だけど、若干の悔しさを感じて帰ってきた。

企業ブース、すてき

CyberAgentのブースで看板サービスのbuild.gradleを公開します!という企画をやっていて、開発イケてます!ということがよく伝わってうまいプロモーションだと思った。転職考えてたら絶対候補にはいると思う笑

他にもいっぱいノベルティもらってとにかくはしゃいできた。

アプリのOSS化、すてき

あとは今年はDroidKaigiのアプリにコントリビュートするぞ!と決めていて、なかなかレベル高くてひよっていたけどちっちゃいバグフィックスでコントリビュート達成した。いつもネットで見ているアイコンの人たちにコメントしてもらえたり、コントリビューター一覧に名前が載ったり、はかなりモチベーションあがった(マージされた夜は興奮してしまって眠れなかった)。ただの参加者からDroidkaigiに自分も関わってるんだぞ!と思える感じ、最高。

まとめ

DroidKaigiのセッションはスライドも動画も後で見れるのだがやっぱり当日行って全部の時間なにかしらセッションを聞きに行くのがすごく良いことだよなと思っている。後で動画で〜だったら自分の知っている範囲で課題感持っているところしか見ないと思うので、新しい分野を聞きに行く点で生で参加するメリットはあると思う。アフターパーティに出れなかったのが残念。

ということですごく良い経験をしました。来年も参加したい。今後は登壇にもチャレンジしていきたい!

スクラムごっこからガチスクラムになって変わったこと

自分のチームは以前からスクラム体制を取り入れていましたが、今年同じスクラム体制でもやり方をガラッと変えたことで感じたこと・変わったことをまとめてみたいと思います。ちょっとタイトルはキャッチーに書いちゃったけど当時は本気でやってたよ!

プロセス改善前の状態

  • アプリの開発チーム
  • iOS 4Android 4人 スクラムマスター1人の体制
  • 2週間スプリント 自分がジョインする前から「スクラム」で開発を進めていた。「スクラム」で開発するのが初めてだったので、元からあるやり方で先輩に聞きながら開発を進めていた。

プロセス改善

転機は有名なアジャイルコーチの方がアドバイザーの形で入ってくれることになったこと。その時色々選択肢はあったのだが、色々あってスクラムで続けていきたいとなって、もう一回スクラムをやり直すことになった。

チームの再立ち上げ

新しくスクラムチームを立ち上げる時にやったことが以下。

開発チームできめたこと

それまでのプロセスとは変わったところ

1週間スプリントになった

今まで月曜はじまりの2週間スプリントだったけど火曜始まりの1週間スプリントにした。 火曜日始まりの理由は月曜は休みが多いから。水曜始まりでもよい。 火曜日の予定は 午前中にスプリントレビュー、レトロスペクティブ。 午後にスプリントプランニング。 火曜日にスプリント切り替えを全部行う。火曜日は一日会議になる。会議の日と実装の日が完全にぱきっと分かれる。最初はうげーとなるけど結構よい。

タスク分解の仕方

案件を実装タスクに落とす際は0.5~1hになるまで粒度を細かくする。 「調査」というタスクは入れない。影響調査などはすべてプランニング中に終わらせる。 プランニングの時に徹底的なプランニングをすることで、あとの日は徹底的に計画されたタスクをこなすだけという狙い。これも最初むりでしょーて思うけどできるようになるしそれがとても良いことだと気づく。

要件を受け入れ基準として定義する

ここは開発チームだけでなく企画側にもお願いするお話。要件をもらうときにAcceptance Criteria(受け入れ条件)を決めてもらいこれを元にエンジニア側で設計・実装をするし、このA.Cをもとに受け入れをしてもらう。なんとなくの案でもらうと、受け入れる人によっても基準が変わってしまう。開発側はA.Cに書いてあることだけ実装する(それ以外の挙動は変えないが前提)。そこに漏れた要件は企画側の責任になる。ここで今まであいまいになっていた責任分解点ができた。

結果変わったこと

チームの中でプロセス変えてどうだった?という話をだべったのでその内容を。

常に緊張感が出る

2週間スプリントの時は前半だれていた、後半がんばる、というサイクルに自然となっていたみたい。 1週間スプリントは緊張感がある。提出まで中4日しかないので、ちゃんと時間通りタスクを消化していかないと終わらない。例えば1日何かがあって遅れてたら、2週間スプリントだと最大8日かけてリカバリできるけど、1週間スプリントだと最大でも3日しかリカバリにかけられない。

開発の奴隷化の解消

どうしても企画側の企画があってから開発があるので、以前は開発工程で出た問題は開発の問題になりがちで責められがち。本当は開発の問題じゃなくても。 案件を受け入れ基準駆動で行うことで、企画側と開発側どっちの責任かがはっきり分かれ、全部開発の責任になるということが減ったと思う。 どこまでがどちらの責任と決めたこと、決めたことに対して公平な立場で厳しく言ってくれる人がいたことで、開発側も「悪いって言っていいんや!」と、ちょっと安心した面はあったと思う。企画側にも物言える開発チームに変わりつつある。 実際に仕様が詰められていない案件については企画側の責任範囲になるので、開発側が詰められていない案件のカバー&実装みたいなことはなくなって開発は幸せになったと思う

問題発見フレームワーク

スクラムというプロセスは何かの問題を解決するプロセスというより「問題を発見するためのフレームワーク」と習った。これをやってみるまではあまり実感できなかったが、計画スプリント内に行うタスクを0.5~1hまでの粒度まで落とすという作業は、細かく指定する分計画と違いが出たときにわかりやすい。 今までは「実装4h」などとざっくり見積もりでよかったのかもしれない。けど本当は問題が隠れていたのかもしれない。 また、ここまでタスクを切るということはプロジェクト内の影響調査のしやすさにも関係があると気づいた。この方法をしてから「簡単にタスク分解しやすい」案件と「どこをどう直せばいいかをつきとめるのに時間がかかる」案件に分かれる。じゃあ後者ってこれあんまり良いコードじゃないのでは?と問題を問題と気づくきっかけをくれた気がする。

その他

以下はスクラムをいれたからというより今のチームの状況で得たものも参考までに書いておく。

スクラムマスターの不在

スクラムマスターの不在というとちょっと意味が違うのだが、スクラムマスターの方が異動になり、チーム内でスクラムマスターという肩書を持った人がいなくなってしまった。事実上、アジャイルコーチの方がスクラムマスターのような役割をしてくれていたのだが、週に1度程度の頻度でしかコーチングに来れないため、セレモニーのファシリテーションやレトロで出た施策の管理などはチームメンバーがやっていた。 今考えると当たり前だと感じる点もあるのだが、前の体制は全部スクラムマスターにお願いしてしまっていたのだ。あとは他のコミュニティで「ファシリがうまいね」と言われたことがあって、それはここでの経験だと思っている。

QAの不在

これは自分の会社であるあるなのかもしれないが、だいたい開発チームはQAの方がいて、テストを担当してくださる。うちのチームはなぜか(スクラム導入時にそのような体制にしたと話は聞いた気がする)QAが不在のチームだった。従って当たり前に自分達でテストをすべて行う。 自分たちで開発→テストを行うので、テスト工程まで見越した考え方ができるようになったと思う。 QAがいてくれる安心感からは、「不具合を出しにくい設計とは?」という観点が出てこない気がする。QAがいて不具合を見つけてくれることで大変なのはQAだから。テストの中だけの改善、開発の中だけの改善だけでなくて、テストの改善のために開発を改善するみたいなことが起きる、考えられるようになる。自分にとっては考え方がかなり変わったところだ。

まとめ

結局事業には貢献したの?と言われるとなんといっていいかわからない。この体制にしてからプランニング時間内にで1つの案件しかプランニングできてなかったチームが今はだいたい20この案件をプランニングしそれを実装までこなせるようになったのは設計・開発スピードが改善したのだと思うけど、厳密に見れば色々他にも要因はあるからね。 個人的には、アジャイルの考え方やプロセス改善の方法を学べたことはとても成長になったと思う。 新卒1年目ウォーターフォール→新卒2年目スクラムとやって、もうウォーターフォールのチームには戻りたくない。なかなか大きい会社でスクラムをやることは難しいけど、気合や残業で解決することなく、人じゃなくて問題に目を向けるという意識が根付く。この意識が根付くことだけでも開発者が幸せになるフレームワークになるんじゃなかろうかと思っている。実際今年一年楽しかった。という振り返り。

リーン開発の本質

リーン開発の本質

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

Visitorパターンと他のデザインパターンを比較してみる

会社の先輩からインプットもらったので、理解定着させるためにも整理してみます。知識0前提はは承知を。

発端

この話になった背景は会社でやってもらってるコードレビューの場で、前からずっと継ぎ足されていたレガシーコードどう直す?となった時に出てきた話。

if(){

//処理。めっちゃ長い

}else if(hoge){

//処理。めっちゃ長い

}else if(huga){

//処理。めっちゃ長い

}else {

//処理。めっちゃ長い

}

こんなコードが出てきたら、StrategyパターンやCommandパターンが適用できないか検討するといいよーと。 今回はVisitorパターンで書けないか考えてみたと先輩が言ってたので私もそれで書いてみます。と書いてみることに。

Visitorパターン

visitorパターンとは http://www.techscore.com/tech/DesignPattern/Visitor.html/ https://ja.wikipedia.org/wiki/Visitor_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

Visitorパターン調べてると、Strategyとか色々出てきてよくわからない。 どんな時に使うパターンかというと、工程のような処理がいくつかあって種類によって工程が変わったり、なかったりする、みたいのをきれいに直せるよーらしい。

なので、以下みたいなコードが出てきたらVisitorパターンで書けないか検討すると良いみたい。

if(){

}

if(){

}
if(){

}

Visitorパターンにもいくつか種類があってinternalVisitorパターンとexternalVisitorパターンがあるんだって! http://qiita.com/lyrical_logical/items/bc6126f34a571a2c4f97

Visitorパターンは「データ構造」「走査方法」「処理」を分けて書くのがコアな考え方。 走査方法て何って感じだったけど「案内」と変えて聞くとちょっとイメージしやすかった。 案内係と実際の処理係。何を処理すればいいのかは処理係が知っているので、案内係は処理の順番だけ案内すればよい。ってイメージつけてる。

FactoryやStrategyとの比較

  • Factoryは生成に関するパターン
  • アルゴリズムを切り替えるのがStrategy
  • データ・走査方法・処理を分けるのがVisitor と一言で書くと、こんなかんじ?

例えばシャツの工程の話

例えばシャツを作りますー!の話をVisitorと例えばFactoryで考え方を比較してみる図。 f:id:chiiia12:20161212002120j:plain Visitorは一つの工程を順番にvisitしていく。工程の中の一つだけ変えたものを作りたい!ってなった時に一つの工程を入れ替えるみたいなことが可能。

f:id:chiiia12:20161212002056j:plain Factoryと比べると縦切りなのか横切りなのかで違うことがわかる。 どっちを使うかは、どういう仕様かによって変わってくるのかと思った。

結局デザインパターンって

色々なパターンを見ていくと、「○○パターンだけ!」を使って書ける、みたいのはない。 この観点だとStrategyっぽいしここはVisitorの要素が混じってるよねとか。実際今回Visitorパターンを書いたつもりが(理解しきってないのもあって)ここはFactoryの考え方、ここはStrategyっぽいってなった。 色々パターンがあるけど、どう分けるか?の違いなだけでどれが最適!ていう答えはその時々。 で、デザインパターンは「はしか」みたいなものだから、若い内に一回かかっておいた方がよいらしい笑 デザインパターンをいれよう!と思っていれるのは違うので、デザパタのメリットなどを知っておいて知らないうちにかこのパターンで書けてた!っていうのが一番良いコードになるのかなぁ。 一回極端にデザインパターンを書いてみるとそこら辺の塩梅がわかるようになるとのこと。

これ。私も書いてみたい。 https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

「テストが書きやすくなる」の意味を紐解く

Androidアプリの話です。MVPアーキテクチャAndroidにいれることでどういうリターンがあるんだろう?というのがもやもやしていて、「テストがしやすくなる」というメリットについてあまり実感持てずにいた。単体テストコードを書いていてなんとなくこういうことかなーと考えたことをまとめてみる。当たり前じゃん&間違ってるかもしれないけど、そこはご指摘いただければ…。

notMVPケース

前提

  • FragmentやActivityでAPIをたたいてたりDaoの呼び出しも書くケース
  • コールバックのinnerClassもFragmentに書いたり(privateで)
  • privateのinnerClassで持っているメソッドをテストしたい。
public class SampleFragment extends Fragment{


private static class hogeCallback {
    
    public void onSuccess(boolean ishoge){
            String testCase = ABテスト値取得;
            if(testCase==isA() && ishoge){
                hugaView.setVisibility(GONE)
            }
    }

}

書こうとするときにぶちあたる壁

その時確かめたいテストケースは「testCaseがhogeで、ishogeがtrueの時、hugaViewが表示されていること」だった。これを実現しようとして考えたことが以下。

  • privateのinnerクラスってどうやって呼ぶんだろう
  • assertは何でしたらいのだ?Espressoで表示中かどうかを確かめたらいいのか?
  • テストしたいケースはAPIを叩いた後のコールバック時のメソッド。どうやってその状況を再現する?
  • 単純なテストケースに見えるけど、なんか大変そうだということはわかった。

結局どう書いたのか

  • privateだったinnerClassをpublicにした
  • testCase変数の値によってテスト結果を確かめたかったので、testCase変数をメンバ変数でもたせる(コンストラクタで渡す)か、引数に追加する
@Test
public void hogeTest(){
    String testCase = "A";
    ViewGroup viewGroup = mock(ViewGroup.class);
    when(viewGroup.getVisibility()).thenReturn(View.GONE);
    SampleFragment.HogeCallback hogeCallback = new SampleFragment.HOgeCallback(context, viewGroup, 0, testCase);
    countCallback.onSuccess(0, true);
    verify(viewGroup, times(1)).setVisibility(View.VISIBLE);
}

だいたいこんな感じでテストケースを先輩に習いながら書いた。 正直、自分がこれを書こうと思ったら結構時間かかりそう。実際悩んだし。 結局、テストのためにプロダクトのコードを変える必要があってなんとなく良くないんじゃないか?と思っていた。

MVPで分けてみる

じゃあこれをMVPに書き換えて書いてみるとどうなるか? 簡単に、Viewじゃないところはpresenterにやってもらうようにした。

HogeCountTask task = new HogeCountTask(this).execute();

Fragment内で、API叩いてcallbackをもらう処理はpresenterに移す。

presenter.executeHogeCountTask();

presenterにlistenerをimplementsさせて、presenterの中でコールバックを受け取る

 @Override
    public void onSuccess(int count, boolean ableMoreSelect) {
        String testCase = getHelpMessageTestCase();
        boolean isShowHogeView = isShow(count, testCase);
        view.setVisibleHHogeView(isSHoe);
    }

    @Override
    public void onError(ResultDto resultDto) {

    }

こんなかんじ。で、ここでそもそも今回のケースではlistenerを継承したinnerClassは使わなくてよかったのでは?じゃあFragmentの中に書いてあってもテストの書き方は変わらないのでは?と思ったり。けどそれが気づけてシンプルにできたのならそれもまたいいところということで。

Presenterにロジックを移すということ

AndroidでFragment,Activityのテストをするのは気が億劫だ。(私だけなのだろうか) 正直正解がわからないし、どう立ち上げるのが正解かわからない。 presenterに移しておけば、Viewをモック化するだけでなんだかすごそうなツールを使わなくてもできる。

  @Before
    public void setUp() throws Exception {
        context = InstrumentationRegistry.getTargetContext();
        view = mock(SampleView.class);
        presenter = new SamplePresenter(view, context);
    }

    @Test
    public void 正常_isHelpMessageView() throws Exception {
        Method method = JobTypeSelectNewPresenter.class.getDeclaredMethod("isHelpMessageView",  boolean.class, String.class);
        method.setAccessible(true);
        boolean result = (boolean) method.invoke( true, "SHOW");
        assertTrue(result);
    }

だいたいこんなかんじ。privateメソッドだということ以外は結構スラスラかける。

結果「テストが書きやすい」ってこういうことなのでは?

  • 「これを渡したらこれが返ってくる」って思考をそのままコードにしやすい
  • viewのギリギリまでテストができる、しかも単純な。
  • とりあえずあんま難しいこと考えなくていい

雑なまとめになっちゃった。新しいアーキテクチャいれるって時、何が目的なんだろう、いれたらどんないいことがあるんだろう、って自分は今までアーキテクチャを理解するだけで考えられなかったので、少し違う側面が見えてきたかも?というお話でした。まる

ばあちゃんが残した800枚の絵をフォトブックにするまで

1年とちょっと前の8月15日、朝起きたらばあちゃんが亡くなってた。 葬儀や納骨が終わって少しだけ儀式が落ち着いた頃、母が部屋を掃除したところ、油絵が出てきた。しかも大量に。ばあちゃんの絵の部屋、倉庫、押入れ、どこ開けても絵が出てきた。だいたい800枚くらい。 まだまだばあちゃんの死を受け入れられなくて、何かこの絵をこのままにしておくのはもったいなくて、フォトブックにすることにした。

11月~2月 絵の撮影

まずは絵を写真ですべて撮影をする。 なるべく写真そのまま使えるよう、お家撮影セットを作った。 ホームセンターでベニア板と壁紙、何かをひっかけるアレを買ってきて、デスク用のライトで照らす。これで絵を撮影した。

f:id:chiiia12:20160829233442j:plain

だいたいばあちゃんが描いたジャンルは花、人物、人形、モノ(静物)、風景みたいだったので、ジャンルごとに撮っていくことにした。何に使えるかわからないけど一応番号をつけながら。

一枚ずつ番号をつけながら撮影していく過程で「この絵いいね」「これひいおばあちゃんのこと?覚えてる?」なんてひとつひとつ絵を見れた。 月1,2回実家に帰って少しずつ撮影していった。なかなかかかって結局ずいぶんかかってしまった。

6月~ 絵の整理・加工

だいぶ時間が空いてしまった。ちょっと絵を撮り終えて気が抜けてしまったがまだ仕事は終わってない。 写真を整理してみると、明るさはバラバラ。朝撮ったものもあれば夜撮ったものもあって。お家スタジオには入らない大きさの絵もあって、電球の暗い玄関で頑張って撮ったのもあった。 それに歪みがひどい。私が撮ったやつまじひどい。綺麗な正方形になってない。 ということで明るさ調整&歪み調整が必要になった。800枚。 f:id:chiiia12:20160821232412p:plain 明るさを調整した写真を… f:id:chiiia12:20160821232439p:plain 切り取る f:id:chiiia12:20160821232509p:plain 歪みを調整して f:id:chiiia12:20160821232544p:plain 長方形に修正。

photoshopで機械のように処理した2週間。 本当はスクリプトとか書いて自動化できたのだろうか?と思ったが私の実力ではわけわからず、ショートカットを設定するしかできなかった…。 なかなかに辛い&気が遠くなる作業だったが、また絵を一枚ずつ眺める機会ができてよかったと思う。

7月~ レイアウト&発注

気の遠くなる作業が終わった後は、レイアウトを作る作業だ。 発注はapple photobookサービス。 www.apple.com

apple photobookサービスは自動でレイアウトが組まれたのを選べるのだが、キャンバスのサイズが縦横比が自由すぎて、絵をだいぶ削る必要がありそうだった。また、7月末の一周忌に間に合わせたいという母の要望を叶えるため結構なタイトスケジュールであったため、自分でレイアウトを組んだ方が早いと判断し一枚ページとして作ることにした。 f:id:chiiia12:20160829232012p:plain イラレでなんとなくレイアウト組み… f:id:chiiia12:20160829232203p:plain こんな感じにして入稿!

混んでいる時期だと2週間くらいかかると聞いたので早めに急いで出したけど、結局5日で来てappleすごい。

完成

150ページくらいの大作になった。(デフォルトは20ページ) 同じページを2枚入稿してしまったことと若干の日付を間違えてしまうドジっ子は許してもらった。

f:id:chiiia12:20160829232611j:plain f:id:chiiia12:20160829232608j:plain f:id:chiiia12:20160829232604j:plain

手元にコンパクトで置いておけるフォトブックにできたこと、なによりばあちゃんの油絵キャンバスをデータ化できたことはちょっとホッとしたかもしれない。 結構好きな絵がみつかったこと。家に絵を飾るって結構いいかも。なんて。 せっかくだからもらってくれる人がいないかな、なんて。 せっかくたくさん家にある絵を活用したいななんて思う夏の終わりなのでした。