zukkeyの技術奮闘記

”当たり前”が誰かのためになる、はず

RxJava: 登録画面でcombineLatestを利用するのはなぜか

はじめに

こんばんは!お久しぶりです。

固定回線がいまだに繋がっておらず、著しくテンションが落ちてブログをお休みしていました、zukkeyです!

 

今回は、Rx関連で登録画面においてcombineLatestを利用するのはなぜか、ということについてメモを残しておきます。

 

個人的な見解で間違っている部分もあるかもしれないので、その場合は申し訳ないです。

間違いあればコメントで指摘していただけると幸いです。

 

充分ハードルが下がったところで説明していきます。

 

よくある登録画面

今回はサンプルとしてデザインは適当ですが、以下のようなよくある登録画面を作りました。

 

f:id:rozkey59:20180526193344p:plain

 

 入力する項目を三つ作り、入力がされないと一番下のボタンを押すことができないようになっています。

 

 今回はcombineLatestだけに焦点を当てているので、正規表現を使って文字列とマッチしているかといった処理は行わずに、ただ単に三つの入力項目に対して文字列が空かどうかを見てボタンの選択状態が変わるようにしています。

 

作っている最中に以下のリンクとほぼ同じもの作ってた!と気づいたのですが、色々な結合オペレータがある中で、なぜcombineLatestかについては触れられていなかったので、書いていきます。

今回は、combineLatestとzipを比較していきます。

もしかして需要無かったりするのか。。。。

 

dev.classmethod.jp

 

 

combineLatestの時の挙動

combineLatestのときの挙動が以下になります

f:id:rozkey59:20180526194931g:plain

各項目で入力された文字列のデータが通知されてきて、一つのデータの流れが変わることによりボタンの状態が変化します。

 

zipの時の挙動

zipの時の挙動が以下になります

f:id:rozkey59:20180526205202g:plain

各項目で入力された文字列のデータが通知されてきて、全てのデータの流れが変わることによりボタンの状態が変化します。

 

サンプルのアプリの中で起こっていること

画像でサンプルで起こっていることについて説明していきます。

 

combineLatestのとき

 

f:id:rozkey59:20180526201043p:plain

 

RxJavaの結合オペレータのmerge、zip、combineLatestでは複数のデータの流れが来た際に1つのデータの流れに合わせる作用があります。

 

各々のオペレータでの違いはあるのですが、combineLatestだけに限定して言うと下記のような流れになります。

 

f:id:rozkey59:20180526201632p:plain

combineLatestの場合は一つのデータが変更されるのに合わせて、結合されたデータの流れに入っていきます。

 

 zipのとき

f:id:rozkey59:20180526211231p:plain

zipはcombineLatestと同様に複数のデータが合わさったタイミングで新しいデータの流れを作ります。

 

 

f:id:rozkey59:20180526211241p:plain

挙動のgifをもう一度見直してもらうと分かるのですが、一つの項目を変えてもボタンの状態が変化していないことが分かります。

zipとcombineLatestの違いはここにあります。

 

 

f:id:rozkey59:20180526211255p:plain

全ての入力を変えることではじめて新しいデータの流れをつくります。

 

まとめ

登録画面などの複数の入力をRxで処理する際に、combineLatestがよく利用されるのは一つのデータが変わった際に状態が変わってほしいからだと僕は思っています。

 

zipの場合を見ていただけると分かるように、一つの入力を変えるたびにすべての入力に対して、何かしら通知を行うようなアクションを行わないと状態が更新されません。

 

 なので、登録画面のような場合にはcombineLatestを積極的に使っているのだと思います。

 

おわりに

最後まで見ていただきありがとうございます!

疑問等、指摘などありましたらコメントしていただけると幸いです!

今回のサンプルは以下のリポジトリをクローンすることで試せるのでよかったら試してみてください!

 

github.com

Androidアプリにシェイクアクションを入れるための簡単な実装方法

はじめに

こんばんは!

1日更新が遅れてしまい申し訳ない。。

引っ越しが来週なので、引越しの家電買ったり、諸々準備があったため遅れてしまいました。

 

今日は前回お話しした、以下の記事の技術面でシェイク機能を簡単に実装する方法をご紹介します。

rozkey.hatenablog.com

 

 シェイク機能を実装するために使用したライブラリ

上の記事にも書いてあるアプリの中で、シェイク機能を実装するために次のライブラリを使用しました。

 

github.com

 

こちらを利用することでシェイクした際の動作を追加するのを簡単に実現することができます。

 

導入方法

appのgradleファイルの中に以下のものを追加してください。

 

// shake
compile 'com.squareup:seismic:1.0.2'

 最新のバージョンは、1.0.2です。(2018年5月現在)

 

導入はたったこれだけです

 

つかいかた

 

実装したいActivityに下記のようにShakeDetector.Listenerを継承させます。

今回はMainActivityに持たせたいので下記のように実装しています。

class MainActivity : AppCompatActivity(), ShakeDetector.Listener

 

次に、onCreateの中でリスナーにセットします

val sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
val sd = ShakeDetector(this)
sd.start(sensorManager)

 

Context.SENSORの中身を見ると下記のようになっていて、


/**
* Use with {@link #getSystemService} to retrieve a {@link
* android.hardware.SensorManager} for accessing sensors.
*
* @see #getSystemService
* @see android.hardware.SensorManager
*/
public static final String SENSOR_SERVICE = "sensor";

 

sensorManagerというハードウェアのセンサーにアクセスするために必要なので上のようにしています。その後、リスナーをセットしてstartを呼び出すだけでシェイクを検知するようになります。

 

リスナーを継承させた場合にhearShake関数をオーバーライドする必要があります。

override fun hearShake() {
// やりたい処理を書く
}

 

この中にシェイクの動作をした際にやりたい処理を書くことでシェイク機能を簡単に実装することができます。

 

検知しているかどうかを簡単に試したい場合は、この関数の中で、下記のように実装することで振った際にToastが出るようになるので簡単に試すことができると思います。

override fun hearShake() {
Toast.makeText(this@MainActivity, "Everybody Shaked!", Toast.LENGTH_SHORT).show()
}

 

自分のアプリの場合には、データベースからランダムにデータを取って来たものをadapterに新たに追加する処理を行っているので、シェイクした際に新しくランダムな順番で10件のTweetを読み込むようにしています。

 

 

おわりに

今回はアプリにシェイク機能を簡単に実現する方法について紹介しました!

一週間開いた割には軽い感じでしたが、引っ越して時間ができたらもっと質を意識して書いていこうと思います。

 

最後まで見ていただきありがとうございました!

質問や疑問点などありましたらコメントに書いていただけると嬉しいです!

10日間でアプリ作ってリリースした話

はじめに

皆さんこんばんは!お久しぶりです。

開発をやっていたのでブログの更新を1週間お休みしていました、zukkeyです。

 

GWはいかがお過ごしでしょうか?

連休中に遠出した方も多いと思います。

 

僕は、引っ越し間近なので内見に行ったり引っ越しの準備をしたりしながらアプリを作ってリリースしました!

 

やったー!

 

ちなみに作ったのは以下のモノです。

f:id:rozkey59:20180505213616j:plain

 

今日は、その際に勉強になったことや学んだことについて書き残しておこうと思います。

 

全体で書いてある流れは以下の通りです。

  • はじめに
  • はじめたきっかけ
  • アプリを完成させるのに意識していたこと
  • どうしてこのアプリを作ったのか
  • 個人開発のすゝめ
  • 今後について
  • おわりに

ちょっと長くなると思いますが、しばしおつきあいください。。

 

一応先に、今回は技術的な話はあとでまた記事にする予定なので開発の感想と個人アプリ開発のすゝめをエモい感じで書いていきます。

 

技術的な部分に興味がある方はブラウザバック(推奨)

 

はじめたきっかけ

兎にも角にも、個人アプリを前々から作ってみたい!と思っていて、今年中に何とかリリースさせてグロースさせていくことを目標にしていました。

 

グロースさせる前にまずはいくつかリリースしなきゃじゃん!と思って、やる機会を狙っていたんですが、、、、

 

中々平日は仕事が忙しく余裕の持てる時間がなかったために、GWで引っ越しのこともあるから遠出しないだろうし、お金も使うのももったいないと思っていたので、この機会にマイクロリリースまでもっていこうと考えていました。

 

そういうわけで、前々から作ってみたい!と思っていたアプリを作ることに。。

 

一応、最初のコミットを遡ったところ、次のようになっていました。

f:id:rozkey59:20180505213417p:plain

 

10日前に初めてのコミットをしていて、10日間で一つのアプリを無事にリリースしました。

 

ストアの画面は次の感じ!

f:id:rozkey59:20180505214124p:plain

 

play.google.com

 

 

 

こんな感じでリリースすることはできたので、ここまでで意識していたこととか何を目的にしてやっているのかとかお話していきます。

 

アプリを完成させるのに意識していたこと

短期間で、一人でかつ技術的に未熟な人がアプリをリリースさせるために意識していたことは以下の三点です。

  • 色々と考えすぎない
  • 最低限必要な機能に絞る
  • 完成すること、が最大目標

 

一点目は、色々と考えすぎない、ということです。

 

アプリを作る前は、設計はMVPもしくはMVVMでモダンな設計にして、モダンなライブラリ使って、ソースコードも公開して次につなげられるようにしよう。。。とかいろいろと余計なことを考えてしまいがちです。

 

確かに、こだわることであったり次につなげようとか言う意識は大事ではあると思うのですが、僕はそういった考えはすべて捨てました。

 

こだわってしまうと、自分の実力と時間的に完成しないというのと普段の仕事とは違ってUIのデザインであったり仕様であったり考えることが多いので使えるリソースが限られています。なので、設計であったりアーキテクチャである部分は次からのリリースで修正していくことにして、取り合えず形にすることを大前提にして取り組んでいました。

 

もうひとつ、次につなげようとかは単純に今の仕事には満足しているので単純に考えてませんでした。

 

二点目は、最低限必要な機能に絞る、ということです。

 

色々とやりたいことが多すぎて、機能をたくさんつけたくなってしまいがちなのですが、機能が多いと工数がかかるしデザインだけでなく裏側も作っていかなくてはならないので10日間では無理!と思って、自分は次の三つの機能に絞り込みました。

  1. 投稿機能
  2. スワイプでGoodとBad評価できる機能
  3. 振ってランダムにデータベースから取ってくる機能

これさえできれば、今回のリリースでは完成と決めて取り組んでいたので無事に予定よりも一日早く終えることができました!

 

三点目は、完成することが、最大目標、ということです。

 

個人アプリって、結局のところ、自己満足なんですがリリースさせないとまずは誰かに使ってもらったり評判聞けたり出来ないですよね。

 

昔は、ローカルで渡して使ってもらうだけで嬉しかったけど、やっぱり顔も名前も知らない誰かにリアルな評価を受けてやっていきたい!という気持ちがあったので何があってもリリースにこぎつけることを目標にしていました。

 

以上が、僕がアプリを完成させるのに意識していたことになります。

 

 

どうしてこのアプリを作ったのか

 

なんで、このアプリを作ったのかという疑問に対していうと、一つは勉強のため、もう一つは匿名型SNSを前々から作ってみたかったから、というのがあります。

 

やっぱり個人アプリを作ると、今までの技術の復習にもなるし、今回はDataBindingとFirebase Realtime Databaseといった新しく触った技術も取り入れているので学びが多くなり、視野が広がったなぁと感じました。

 

あとは、大学時代からローカルで動くものなら作っていたものの、DBとやり取りする部分はサーバー立てたり、サーバー側の言語学んだりしないとたいへんだなぁとおもって何気に手を出せていなかったので、Firebase Realtime Databaseでできるやん!と気づいたので作ってみることにしました!

 

Twitterとかだと、皆で交流したり情報収集したりが目的だったりするのですが、なんでもいいから吐き出す受け口と新感覚のSNSが作れたらいいなぁと漠然と考えていたので作ってみることにしました。

 

こういった理由から、個人アプリ開発をやることにしました!

 

個人アプリ開発のすゝめ

個人アプリ開発は、いうなれば独りよがりの場でもあるので、普段できないことやサービスの質にあっていないことを試すことができる遊び場にもなるし、今まで学んできたことの復習にもうってつけです!

 

皆わりと小さいころからガツガツやってました!という人だったら、あんまり関係ないかもしれないけど、自分のように部分的にわからないことがあるとかだったら一旦一から全部ひとりでやってみると知らなかったことを知れるし、やっているのも楽しいのでオススメです!

 

大してコストもかからない上に、自分こういうのやってます!とかアピールにも使える(下心)し、もしかしたらうまくいけば広告収入でウハウハになるかもしれない(笑)ので、作りたいものができたらまずは完成させることを目標にしてやってみることが良いと思います!

 

みんなで試行錯誤して共有しあえるとプラスの方向に行ける気がする。。

 

今後について

取り合えず、今回作成したShakeTweetについては今後機能追加とインストールされるかとか様子見ながら試行錯誤して試していこうと思います!

内部的なアーキテクチャもモダンなものに変更したいのでそういうのもちょくちょくやっていこうと思います!

また、今回アプリを作るにあたって結構学びが多かったので技術的な記事も追加して今後書いていきます!

 

 

おわりに

今回は10日間でアプリ作ってリリースした話でした!

以前から、ブログで書いている、価格相場アプリ「Makepura」については、今回こだわるなーと言っているんですが急ぎじゃないので、アーキテクチャの部分でこだわって詰まっていてまだリリースは先になりそうですがちょくちょく作り上げてリリースまでもっていこうと思います!

 

最後まで見ていただきありがとうございました!

 

 

 

FloatingActionButtonを使ってみた #1

はじめに

みなさん、こんばんは!

お久しぶりです。

 

最近、ちょっと忙しいので更新が遅くなってしまい申し訳ありません。(言い訳タイム終了)

多分、これからは最低一種間に一度は更新していくペースでやっていきます!

 

さてさて、今回は、個人アプリでも使っているFloatingActionButtonについて書いていきます。

 

誰かに向けてというよりは、メモになりますがFABをあまり触ったことがない人が適当に調べてみたことについて書いていきます。

 

また、今回はDataBindingを使用しております。

DataBindingが分からない方は、先に次のリンクを確認したうえで読み進めていただけると幸いです。

 

ちょっとDataBindingの専門的なことではないですが、使えるようになるまでを書いているので参照していただけると嬉しいです。

 

rozkey.hatenablog.com

 

FloatingActionButtonとは

下記画像の赤枠の部分です!(画面は開発中の個人アプリのモノになります。いろいろ突っ込みどころはあると思いますが、無視してくださると嬉しいです。)

 

f:id:rozkey59:20180421220310p:plain

 

Androidだとよく画面の右下に配置されているボタンのことについて書いていきます。

 

ちなみに、公式にもドキュメントがあるので基本的なことを知りたい方は次のリンクを参照してください!

Add a Floating Action Button | Android Developers

 

FloatingActionButtonはこうやるんやで―的なことが書かれています

 

実装の仕方

一応先にですが、単純にサンプルを試したい方は、File > New > New ProjectをNextしていくと下記のような画面でBasicActivityを選択することで簡単にサンプルを試すことができます。

 

f:id:rozkey59:20180421220934p:plain

 

基本的には、CoordinatorLayoutと併用して使うと個人的には思います。

FABを使う場合には、下記のような実装になります。

 

<android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="com.example.zukkey.groupiesample.MainActivity">
  
// 中間部分は省略

// ここから
<android.support.design.widget.FloatingActionButton
android:id="@+id/fab"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="bottom|end"
android:layout_margin="@dimen/fab_margin"
android:tint="@color/makepura_white"
app:srcCompat="@drawable/ic_camera_alt_black_24dp" />
// ここまで
</android.support.design.widget.CoordinatorLayout>

 

FABはCoordinatorLayoutの中に入れて使用してください。

また、よくある画面にする場合は、layout_gravityをbottom | endで指定することでできます。

 

また、FABは深く中身を追っていくとImageViewを継承しているのでsrcCompatで変えたいアイコンに変更することが可能です。

 

色を変更したい場合は、tintのattributeで変更することができます。

自分の場合は白色にしたかったので変更しています。

 

FABのサイズを変更する

fabにはサイズを変更できるattributeがあります。

app:fabSize="auto"

 

FABのコードの中身を見ていくと、下記のようにあります。

* <p>Floating action buttons come in two sizes: the default and the mini. The size can be
* controlled with the {@code fabSize} attribute.</p>

二つのサイズを選ぶことができ、defaultとしては次のコードがあるためautoが選択されているようです。

mSize = a.getInt(R.styleable.FloatingActionButton_fabSize, SIZE_AUTO);

 

attributeの選択肢としては、normal, mini, autoの三つがあるようですが、autoは画面サイズから変わらないようにしてあるっぽいです。

 

一応、fabSizeがminiの場合とautoの場合を見ていきましょう!

miniの場合

次のようになります

f:id:rozkey59:20180421225251p:plain

 

若干気持ち小さい感じがします。normalの場合も見ていきましょう!

 

normalの場合

こちらがデフォルトの選択になります。

 

f:id:rozkey59:20180421225228p:plain

 

さっきと比べて、サイズが大きいことが分かります。

 

次は、FABがScrollしたときによくある見え隠れする実装について書いていきます。

FABがScrollした時の処理について

もっとコンテンツを読み込もうと、画面を上にスクロールしたときにFABの挙動が変わることがあるのはよく体験していると思います。

実際には、次の通りです。

 

f:id:rozkey59:20180421230107g:plain

 

実装するのは意外にも簡単で、実際のコードは以下になります。


binding.mainItems.addOnScrollListener(object : RecyclerView.OnScrollListener() {
override fun onScrolled(recyclerView: RecyclerView?, dx: Int, dy: Int) {
if (dy > 0 && binding.fab.isShown) {
binding.fab.hide()
} else if (dy < 0 && !binding.fab.isShown) {
binding.fab.show()
}
}
})

 

binding.mainItemsはRecyclerViewで、DataBindingを使用していない場合はrecycler_viewとかでできると思います。

ここでやっていることとしては、y軸で見たときにhideとshowを呼び出すようにしています。

animationをつけたりする場合は、また変わってくるので後ほど記事にして共有しようと思います。

 

さいごに

 今回は、FABについて調べてやってみたことについての共有でした。

今回サンプルとして紹介しているアプリ、価格相場アプリ「Makepura」は4月下旬~5月上旬リリース予定で進めています。

また、報告できるようになったら記事にしようと思います。

最後まで見ていただきありがとうございました!

少しでもお役に立てたら嬉しいです。

では、また次回まで!

 

 

 

マテリアルデザインのガイドラインを読む #1

はじめに

こんばんは!

お久しぶりです。最近個人アプリをマイクロな機能に絞ってリリースする方向にシフトチェンジしたzukkeyです。

やりたいことがありすぎて、時間がほしいこの頃。

 

さて、今日はマテリアルデザインガイドラインを読んでいくということを数か月前からやっていたので復習もかねてメモを書き残しておこうと思います。

 

一気にやると途中で挫折するとおもうので、小出しで回数を増やしていく感じにしてやっていきます。

 

マテリアルデザインとは

 

2014年にGoogleが発表したデザインのガイドラインのことです。

詳しくは以下参照。

qiita.com

 

上の記事はうまくまとめられていて全体をさらうのによいのではと思います。

 

僕は復習として詳しく読んで記事に書き残しておこうかなと思った次第です。

 

今回読んでいくのは、マテリアルデザインガイドラインの日本語訳版です。

詳しく読みたい人は以下参照。

マテリアル – 日本語

 

読んでいて残しておこうと思った部分だけまとめていく感じにします。

一応、英語版の方がいいらしいようですが僕は日本語を取り合えず先に読破していく所存です。

 

1.マテリアルデザイン

目標

ガイドラインには次のようにあります。

時代を超えて共通する優れたデザイン
の原則と、科学技術の革新性と可能性
とを融合させた視覚言語を作り出しま
す。  

 うーむ、抽象的なのですがデザインの原則と技術の進歩を合わせた共通の考え方を持つってことでいいのかな。

 

基本原理

なかなか難しい単語を使っているような気がするので、一応自分なりの理解を書いていきます。

マテリアルはメタファー(比喩)である

マテリアルはモノであり一種の比喩で、紙とインクからインスパイアされ、現実世界をもとに人にとってなじみのある感覚を取り入れることで、直感的に操作することができるようになるということ

 

大胆で生き生きとした、意識的なデザイン

見た目を良くするだけでなく、鮮明な画像や意識して選んだ色や意図的な余白により、階層構造や意図、焦点を表すことができるデザインということ

 

動きには意味がある

ユーザーの操作から動きが始まり、デザインが変化し、ユーザー体験の連続性を損なわないようにし、かつユーザーの注意をひいたり効果的な意図を示すのに有効であるということ

 

マテリアルとは

光と影

マテリアル環境では、仮想の光が場を照らし、主要光が方向性のある影を作り、環境光がすべての角度からやわらかな影を作ります。

f:id:rozkey59:20180415214112p:plain

色を使うというよりかは、高度によって影を示しz軸の奥行によって影ができるかを決めるということを意識する必要がありそう。

 

さいごに

一応コンポーネントまで読み進めているのですが、復習もかねてこのシリーズは定期的に書いていこうかなと思います。

最終的にはAndroidのサンプルをもとにマテリアルデザインの例を作成してまた記事を書いていこうと思います。

今日のところはこれで失礼します。

 

 

プログラマが知るべき97のことを読んで #1

はじめに

こんばんは!

お久しぶりです。今日は久しぶりに本を読んだので所感を書いていこうかと思います。

 

今回読んだ本はこちらです。

 

プログラマが知るべき97のこと - オライリージャパン (2010/12/18) 

 

 ビルド時間中や空き時間に読み進めているのでまだ3分の1だけしか読んでないですが、今までの経験から気になった部分をピックアップして、読んだ感想を書いていこうと思います。

 

 

ちなみに、参考までに目次は下記リンクから見れます。

www.oreilly.co.jp

 

ユーザが何をするかを観察する(あなたはユーザーではない)

この章で書かれていることでなるほどなと思ったのは、「先入観」についてです。

 

開発している側(開発者)と開発していない側(ユーザー)で操作の仕方や考え方が大きく異なる点があるというのがなるほどと感じました。

 

開発者はある程度アプリを作ってきていたりするので、もし操作方法が分からなかったとしても多分こうだろうという経験則や知識に基づいて操作します。

 

一方、そういったバックグラウンドがない人が触ると操作方法が分からなくて頓挫してしまう可能性もあるし、効率化するための手段を考えようとしないので目的さえ達成されれば他の機能を使ってみようとか知ろうとはしないというのは確かにと僕は思いました。

 

これは、どういうことかというと、結局苦労して開発期間を持ったにもかかわらず結局その機能を使ってくれなかったりそもそもユーザーが欲していない機能であればコストに変わってしまうのです。

とはいえ、ユーザーが何を考え何を欲しているのかを分かったら苦労しないよねって話なんですが、自分が最近思うのは重要な機能だけ絞ってしまいシンプルに動作を限ってしまえばいいような気もしています。

 

とはいえ、その考え方をプロダクトに活かすとなると難しいことはあるので、 作り出す前に、まずはユーザーを知りそれが本当に必要なんだっけ?というのを意識して再度確認していくという作業をしてから開発をやっていくというのがいいと僕は思います。

 

コードレビュー

コードレビューの目的と成功させる方法についてです。

僕がこの章を読んで感じたのは、コードレビューの本質といいますか認識しておいた方がいいなと感じました。

 

コードレビューの目的は次のように書かれています。

チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立すること

 

コードレビューというと、技術的に差があったりするとレビューを見られているときには、お互いの関係性が構築されていなければ、まるで公開処刑のように感じることになると思います。

 

文中にもありますが、建設的な議論に進めるためにもお互いに友好的であると良いというのは確かにそうだなぁと思います。正しいことがいいことではなくて、建設的な議論になることがいいことであると思います。

 

文章だけだとさらに冷たく見えてしまうこともあるので、僕はなるべく変な風に伝わらないように言い方に気をつけてはいます。実際どんなもんなのかはわからないですが。

 

また、ありがちなのが技術的に特化していたりして辛辣な批判をしたり、揚げ足をとるようなことはしてはならないです。ここに関して言えば、レビューに限らずやってはならないと僕は思います。

 

気をつけてはいるものの自分も完ぺきではないので、部分的にみて正しいことに執着しすぎて全体的に見たときに適切ではないといった経験はあります。

 

開発は楽しいものです。レビューも楽しくやっていくのがいいと思います。

 

そして、楽しくあるために今も気を付けてはいるのですが、個別の事柄に執着するのではなく全体を見るということを今後も心がけていきたいです。

 

 

 

コードに書けないことのみをコメントする

この章を読んで、思ったのは大学の授業をふと思い出しました。

 

大学のプログラミングの実習では、なぜその処理を書いたのかを逐一コメントにしたうえで提出しコメントの内容も含めて評価になるというのがありました。

大学は勉強をする場で、理論を学ぶ場所です。実践とはちょっと違います。

 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)にも確か似たようなことが書かれていたと思いますが、

 

コメントは不適切であればマイナスになりそういったコメントが多ければやがて読む人は読み飛ばすようになってしまう

 

というのは確かにそうだと思います。

 

初めての現場に入った時、自分は実習の癖が抜けず意識してはいたもののいらないコメントを書いたり、逆に必要なのに書かなかったりしていて良くなかったなぁと振り返ると思います。今も必要なのに書いてなくて指摘されることはあります。

 

見ればわかることは書かないし、ちょっと問題があってこうしているというのはコメントした方がいいというのは簡単そうではあるのですがたまにやってしまうこともあるのでなるほどなぁと思いながら読んでいました。

 

おわりに

今回は一応読んだ中で気になった部分について自分の経験も併せて共感できた部分についてピックアップしたものの所感でした。

 

この本に書かれていることは、駆け出しエンジニアや新卒エンジニアには勉強になることが多いと思います。

読んでいて、ああぁ、やったことある、、、とか、そういう観点もあったかといった気付きを得ることができるので読んで損はないと思います。

 

また、今後も読み進めていって気になった部分を適宜記事にしたいと思います。

 

 

お知らせ

ブログの更新ができていないのは、リアルの予定が埋まってしまっているので時間の取れる10日までお休みします。

 

見に来て頂いてる方には申し訳ないですが、10日から再開します。