とあるエンジニア系ライダーの日常

Webエンジニアの話、バイクの話

マーチン・ファウラーのリファクタリングを読んで(第1〜4章)

マーチン・ファウラーのリファクタリング
とりあえず第1章から第4章のリファクタリングの始め方的なのを読んだので、
一旦まとめてみる。

まだ実際のリファクタリングの方法より、なぜするのかとか、どう始めるのかの辺りですが。

なぜリファクタリングをするのか

リファクタリングすると何がいいの?動いてるからいいじゃん。

ってよく言われますが、

  • コードを理解しやすくなる
  • → バグを見つけやすくなる
  • → より早くプログラミングできる様になる。
  • → スケジュールがスムーズに進む

というところで、結局みんながHappyになれる!

「スケジュールを気にする管理者は、
スピーディな方法を望むが、どうやってやるかは知らない。」

結局はこれなので、もし管理者を説得するなら、

この流れで説得するのがいいのかも。

確かに。

最近コードを書くときは、設計はざっくりで、

まず書いてリファクタリングして設計に戻るほうが穴がない。

結局、ウォーターフォール的に先にがっちり設計するよりも、

書いたコードは想定以上のことを見つけられる。

「最初の設計は穴だらけなはず」
まさにこの通り。

  • 変更しにくいコードから離れられる

「読みにくい」
「ロジックが重複」
「既存の修正が多い」
「条件分岐が複雑」

こういうコードは変更しづらい、

だから、リファクタリングによって変更を容易にする。

それによって開発効率は上がる。バグは減る。

リファクタリングって、

エンジニアのこだわりとかじゃないんです!

いつリファクタリングをするべきか

この中で書いてあったのが、

リファクタリングリファクタリングだけの時間で切り出さない」

というところかな。結局行う時間が確保できずに借金になりがちだし。

リファクタリングをしてはいけない場合
  • 変更するより書きなおしたほうが早い
  • 期間が迫っている場合

ちょっとこれは本に書いてあるけど、あまり納得できないかな。

このパターンでリファクタリングできないことが多いんじゃないかと。

まぁ、僕は書き直しますが苦笑。

ただ、

「未着手のリファクタリングは借金」
とはいえ、今はしないけど借金ですよというのも書いてあった。

これ、測れるとリファクタリングをちゃんとできる様になりそうだな。

どうやって測るかな。。。

リファクタリングをする時に最初にすること

テストを書く!

ってまぁあたりまえというか、これをしないと安心してリファクタリングできないですね。

PHPだとFixtureとかPHPUnitで、JavaだとJUnitとかですね。

そのテストを書く時に注意するべき点は2つ

  • 実行されない完全なテストより、実行される不完全なテストの方が良い
  • 例外のテストを忘れない

無駄にpublicなメソッドのテスト全部書いても、リファクタリングには無意味ですね。

でも、最近思うのは、先にテスト書いておかないと、テストしにくいメソッド構成とかになってて、結局テスト前にリファクタリングが発生したり。。。

テスト大事!

 

リファクタリングを始める(まずやってみること)

でも、ここで何行以上とか決めちゃうと無駄にメソッドが分割されて結局読みにくくなりそうなので、そういうのはやめておいた方がいいんじゃないかなと。

  • そのメソッド内でしか使われないローカル変数はメソッドへの問い合わせによって書き換えられる。

確かに無駄に一時変数が多いと読みにくいしバグになりやすい。

変数を無駄に増やさない!

ローカル変数を問い合わせによる取得にすれば、その部分だけテストできるし。

使用するデータを持つオブジェクトにメソッドは定義されるべき。

ポリモーフィズムを取り入れるのもいいかと。
「そのメソッドが呼び出されたとき、どう振る舞えば良いかはそのオブジェクトが知っている」

例:Switchは自分自身に対して行うべき

この時、わかりやすい様に、メソッド名とか変数名の変更を躊躇しないのも大事。

ここはまだ導入部分だけど、これだけでもリファクタリングの概念はつかめるかな。

早く先が読みたい(*´Д`)ハァハァ

ここまでのまとめ

リファクタリングを行う必要性をこの辺りまではかなり説明してくれていて、

もし、「リファクタリングしたいけど管理者を説得できないし・・・」とか

思っている人がいれば、まずここを読んでみるのはいいかと。

さて、やっと実際のリファクタリングの方法論に入っていけるヽ(=´▽`=)ノ

 

www.amazon.co.jp

 

Software in 30 days

「Software in 30 days」を読んだ感想を徒然と。

おもしろかった所

予測型プロセスの駄目な所

確かに計画なんて上手くいくはずがない。

それなのに長期的な計画を立ててやろうとするなんて。。。

スクラムチームが上手くいくために必要なこと
  • 個人の尊重

  • 開発チームに大きな裁量

エンジニアに裁量がある時が一番良いものが作れる!

詳細まで考えられていて「こういう風に作って!」

って言われたものはだいたいもっと簡単にできたり、

実際に作った後に「違う」って言われたりするなぁ。

スクラムチームの作り方
  • 召集兵より志願兵であること

  • チームメンバーを惹きつけるメッセージを作る

メンバーの入れ替えとか自発性とかを重視している本だなぁ。

チームメンバーを惹きつけるメッセージとか、

スクラムを導入しているチームに採用する時に使えるし、

考えてみようかな。

ロール毎の役割
  • プロダクトオーナー

バックログを明確に表現できる

作業の価値を保証できる

優先順位をつけれる

  • 開発者

肩書はない

自己組織化されている

チーム全体で責任を持つ

効果的なプロダクトバックログの管理方法を探す

プロダクトバックログを明確に説明できる

長期のプロダクト計画を理解している

おー。なかなかスクラムマスターとしてやっている!

良かったw

ちょろっと時間ができた時とかに

よくホワイトボードのタスクとか貼り直してみたり、

プロダクトバックログをどういう風にスクラムチーム用にするかとか、

しょっちゅうやってるなーと。

まだまだできてないことも多いしがんばろう!

プロジェクトの中止
  • 損失を限定し、機会を浪費しない価値もある。

ほんとこれがわかっていないプロジェクトが多い気がする。

ダメだってわかったらその時点で一旦破棄するべきだろう。

モチベーション

上がる時:仕事を自ら管理できている時

下がる時:もっと働けというプレッシャーがある時

結局、裁量が多ければそれだけモチベーションは上がるかなー。

まとめ

ウォーターフォールが駄目、スクラムがいいっていうだけの、

よくあるスクラム本と違って、

モチベーションのこと、チームづくり、スクラムの組織への導入について

とかがおもしろかったな。

「文化に合わせてスクラムを変えるのではなく、上手くやるために文化を変える」

とか、すごく大変そうだけど、必要なことだなと。

1時間で読めたし、オススメです!

www.amazon.co.jp

AWS Road Showまとめ

全体を通して

なんか入った時からスーツの人ばっかりだなーと思ってたけど、
どちらかと言うと既存企業向けの導入の話が多かったかな。
エンジニア的な話は少なくてちょっとがっかり。 でも、

  • ワークショップ

  • Chat Worksの話

  • AWS re:Invent速報

  • 企業ブース

は楽しかった!

基調講演

固定費、変動費、大企業への導入の話ばっかりだった。
正直おもしろくなかった。。。

ワークショップ

EC2上にAMIインスタンスを作って、
ELBでバランシングするとこまでできた!
普段だったら3000円ぐらいの1レッスンをタダで受けれた。
これでスケールアウトしやすいWebサービスを簡単に作れる。
...でも、他にもいっぱいAWSの機能あるし、
もっといろいろ勉強しないとなと思った。

Chat Worksの話

最初は社内ベンチャーで、
一人で開発したってすごいなと思った。

という順当な感じで進化したのだな。
企業が成長するにつれてAWSの機能の意味がわかってくるらしい。
AWSで始めることで、将来まで安心できる感じいいなー。
いろいろと参考になった。

大きくなるとAWSの地雷を踏むから注意

  • ELBは暖気申請しないと落ちる
    これぐらいの負荷がくるから準備してねってやつらしい。
  • RDSはProvisionedIOPSは必須
    IO保証してもらわないとたまに遅くなるらしい。

S3へのユーザーからのダイレクトアップロード、ダウンロード機能

この機能があるとWebサーバー通さなくていいからいいなー。

現在のインフラの構成

User->ELB->AutoScalingEC2->ElasticCache(Session),DynamoDB->S3(Log)  
         ->RDS->ColudSearch  
         ->SQS->EC2(Back End)  
      S3->Glacier(Backup) 直接Upload,Download  

AWS関係ないけど、groongaは1億レコードで潰れるらしい。。。 やばいなそれは。

AWS re:Invent速報

玉川さんのAWS関連の本買いたいなー。

増えてるサーバー数

8000億円規模の企業時代のサーバー数と
同じ数のサーバーを毎日増やしてるとかやばい!
45回も値下げできたのは、
規模の経済が起きてるからなのか。

新機能

仮想デスクトップ

ファイル共有

  • AWS Directory Service

共有ディレクトリ

数PBまで使えるデータウェアハウス
すかいらーくで実績があるらしい。

データを24時間だけ保持するサービス
スシローはリアルタイムで15分後の売上を解析しているらしい。
すぐに捨てるデータにはもってこいだな。

現状のRDB複数のレイヤ(SQL,Transaction,Caching,Logging)
が一枚岩になってしまっているのでDBはスケールしずらいけど、
こいつだと簡単にできるらしい。
こんな感じらしい。

  パフォーマンス : MySQL5.6の5倍の性能
  ストレージ自動拡張 : 最大64TBまで  
  S3へ自動バックアップ
  データ暗号化
  • EC2 Container Service

Dockerコンテナ管理サービス。
今までEC2上に自分でDockerとかはよくある話だったけど、
それをサービスとして提供するらしい。
コンテナそのままデプロイいいなー。

  • Deployまわり

Cloud Formation : プロビジョン
Cloud Watch : モニター
Code Commit : プライベートGitリポジトリ
Code Pipeline : ビルド、テスト、デプロイの自動化
Code Deploy : デプロイツール,Gitとかからでも使える
Service Catalog : 複数サーバーのシステムをテンプレートの管理をして構成できる

この辺に関しては、Gitとか、Jenkinsとか、
今までAmazon以外に他の技術を使ってやらないといけなかったことが
全部On Amazonでできるようになるって感じ。
おもしろい方向性だな。

AWS上のイベントをトリガーに独自のコードを実行させられる。 簡単な処理なら、もうサーバーなんていらないじゃんって考えらしい。
Lambda function(Java Script)をデプロイするだけで動作する。

企業ブース

そんなビジネスもあるんだーっていろいろと参考になった。
おもしろかったブースはこれかな

  • Splunk

Splunkのロゴの入ったキットカットもらった!
ステッカーもいっぱいもらった。
無料でダウンロードしてAWSのログ収集して、
サポートだけ有料っていうのがいいなー。

  • cloudpack

今までAWSって、小さい会社のサイト作るときとかは変動費だからって
結構導入しぶったりされることが多かったけど、
このサービスはAWS上のサーバーを定額提供するらしい。
他のVPSでも別にいいんだけど、
裏のサーバーがAWSっていうのが安心できる。

総括

まぁ、総括すると、これでタダとは、楽しかったなー。 次はもっとエンジニア的なカンファレンスとかに行きたいな。 がんばろうっと!
あ、ノベルティーいっぱいもらった。
f:id:kensanty:20141202170612j:plain

認定プロダクトオーナー研修を受けてきた

認定プロダクトオーナー研修を受けてきた。

Minimize build and First release, Maximize outcome and impact.

のためにどうやって

  • ストーリー作りをしていくのか
  • イデアを出すのか
  • イデアを形にするのか

といったことが学べた。

印象に残っていること

プロダクトオーナーは、プロダクトチーム側のスクラムマスター

プロダクトオーナーは

そういった人たちをチームとしてまとめ、

ストーリー、バックログを作成していくというのを

あくまで手助けしていくロールで、

決してプロダクトオーナーだけでストーリーを作るのではない、

というところは、Ah ha!(なるほど) と思った。

スクラムマスターもスクラムチームをとりまとめはするけど、

別になにかを決めるってわけじゃなくそれらをサポートするのが仕事

だから、似てるなと。

User Story Mapping

プロダクトバックログを作っていくにあたっては、

MVP : Minimize Vaiable Product(最低限生存可能なプロダクト)

を見極めるのが大事で、

それをチームで考える為に”ユーザーストーリーマッピング”という

手法を学んだ。

これらの考えと手法を生かしていくためにアピールがんばらないとな。

がんばろー。

XL1200Xフォーティエイトマフラー交換

フォーティエイトのマフラーをバンスアンドハインズの、ショートショットに交換。 パワービジョン(ECM書き換え)はとどいていますが、まだエアクリーナーは届いてないのでとりあえず、ノーマルで。

交換前

f:id:kensanty:20141108114147j:plain

外しました

f:id:kensanty:20141108114426j:plain 外す際手順としては - エキゾーストのカバーを剥がす - マフラーとエンジンをつないでいる部分を外す - マフラー下部、サイドのボディと固定している部分を外す - マフラーのステーが残るのでプライマリーカバーを外す ※この時デカイ六角が必要でなくて焦ってたら友達が突然ヘルプに来てくれました(笑) - ステーを外して、バンス用のステーに交換 あとは逆の手順で付けていくだけです!

交換後

f:id:kensanty:20141108114446j:plain

レビューとしては カナリ爆音。。。もはや爆発音。 で、インジェクションはチューンしてなくてもまぁふつうに、ギクシャクせずには走れます、(燃料濃い。。。)。 吹け上がりが良くなって気持ちよく加速します。 バイクは楽しい!

Mac上にVirtualBoxでLAMP環境構築

ふとWordpressで遊んでみたいなと思いMac上にUbuntuLAMP環境構築

今回の目的はずばり

[ Macローカル上にて編集したものをすぐに見れる環境構築 ]

下準備

Virtual Box

https://www.virtualbox.org/

公式サイトからインストールして言われるがままにインストール

Vagrant

おなじみ、仮想環境管理用の最強ツールです。

https://www.vagrantup.com/

これもダウンロードして言われるがままにインストール

Berkshelf

Chefのcookbookの面倒な依存関係を解消してダウンロードするのに使います。

下記コマンドでインストール

sudo gem install berkshelf

時間がかかるけど待ちます。

これにて下準備完了。さてさてさっさとやりますか。

調理

作業用のディレクトリをworkspaceとします。

まずはChefのcookbookを手に入れましょう

workspace/Berksfile

を作成し、下記を記述

site :opscode

cookbook 'mysql'
cookbook 'php'
cookbook 'apache2'

cookbookをopscodeから取得しちゃいましょう!

workspaceにて下記コマンドを実行

berks vendor cookbooks

これでworkspace/cookbooksに必要なcookbookが揃ったはずです。

今回PHPなのでローカルで編集したものをすぐに見たいので、

apacheの設定だけVirtualBoxとの共有ディレクトリに変更しておきます。

ローカルに workspace/webapp ディレクトリを作成。

確認用index.phpの作成

echo '<?php echo "Hello LAMP";?>' > webapp/index.php

さて、お次はVagrantの設定

vagrant init ubuntu/trusty64

Vagrantfileができあがります。

僕の場合は下記設定だけにしました。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/trusty64"
  config.vm.network "private_network", ip: "192.168.33.10"
  config.vm.provider "virtualbox" do |vb|
      vb.customize ["modifyvm", :id, "--memory", "2048"]
  end  
  config.vm.provision "chef_solo" do |chef|
    chef.cookbooks_path = "./cookbooks"
    chef.add_recipe "php"
    chef.add_recipe "php::module_mysql"
    chef.add_recipe "apache2"
    chef.add_recipe "apache2::mod_php5"
    chef.add_recipe "mysql::server"
    chef.add_recipe "mysql::client"
    chef.json = {
          apache: {
                      docroot_dir:  "/vagrant/webapp",
                      default_site_name: "default",
                      default_site_enabled: true
                  }
          }
  end
end

起動!

vagrant up

さてさてあとはカプメンでも食べながら待ちますか。

。。。

完了したらローカルからアクセスできる様にファイヤーウォールを切ってしまって

vagrant ssh
sudo ufw disable

http://192.168.33.10/index.php

にアクセス。

LAMP環境完成!

ディレクトリは下記の様になってるはずです。

workspace/cookbooks : Chefのクックブックたち

workspace/webapp/ : Document root

workspace/Vagrantfile : Vagrantの設定ファイル

workspace/Berksfile : Berkshelfの設定ファイル

あとはwebapp上でアプリをいじいじしていくだけですなー。

作業自体は10分ぐらいかな。

(2014/12/11 指摘があったchefのattributeの件修正しました!)