2014年8月12日火曜日

PHPerの書くコードの保守性・管理性が劇的に上がるのスマートな方法

みなさんお仕事の進捗どうですか？
今日は



こんな軽はずみな発言をしてしまったが故にネットで触れては行けない3大炎上案件について触れる。

※ネットで触れては行けない3大炎上案件とは？
  • Excel関連（スクショとか）
  • 宗教（エディタとか）
  • PHP
のこと。

で今話題の元ネタを既に@sue445さんが魚拓してくれてる。

（炎上したら即魚拓とれるとか世の中ホントに怖い便利になったもんだ。）
なのでもしかしたら炎上して灰になるかもしれないけど勇気出して対抗記事を書く。

■はじめに

まず最初に言っとくけどPHP特有のずっと変わらないスマートな書き方ってあんまり無い。
ずっと変わらないのはPHPとか関係なく世間一般的に読みやすいコードの共通事項。
そういうのは世の中にいっぱいあるのでそう言うところで学ぶと良い。
例えばまずリーダブルコード読む。



これを読んだら
  • 変数のスコープは小さくしよう
  • わかりやすい名前を付けよう
  • ロジックはシンプルにしよう
とか自然と考える。
そしたら使いまわされるたった一つの変数に全部配列で突っ込んで管理とか数千行あるメソッドとか無くなるはず。
これだけで保守性とか管理性が劇的に上がると思う。
こういうのは言語関係ないのでみんなが学んでいくべき。
そして先人が知の高速道路を用意してくれてるのでありがたく活用するといい。

結論これで8割くらいの問題が解決すると思う。
けどそれ言うと終わっちゃうので読みやすいコードを書くことを踏まえた上でPHP特有の事を書いていこうと思う。

1. PHPの今を知る

まずPHPの最近の事情を知るべき
当たり前だと思うかもしれないけどまずホントこれ。
例えば非推奨の関数のereg()使ってる人とかまだ見かける。
そういうのを知りたかったら

PHP：The Right Way

を見ると良い。
原文はGithubで最新情報に常に更新されてる

Githubのリポジトリ

基本の項目を読むだけでもヒアドキュメント構文や三項演算子にも触れているので初級者PHPerにはとても有効だ。

PHP：The Right Way　基本の項目

ただ個人的には変数の宣言については一概に宣言を省略すれば良いとも言えないと思ってる。
たとえば
$fuga　= hoge();
みたいな既存のコードで変数もメソッドも一見して意味がぜんぜんわかんないコードと出会った時。
ホントはちゃんとテストコードがあってリファクタリング出来ればベスト。
だけどこんなコードがあるようなプロダクトはテストコードも無い。
しかも$fugaのスコープが長すぎて消すことすら不安。
そんなときに
$users = $fuga;
として$usersを使うのは良いと思う。
これはコメントでもいいけどこういうちゃんと自分なりに意図があってすることには意味がある。

と話が脱線したね。
PHP：The Right Wayを全部読んだら大抵のことは出て来る。
コーディング規約のPSRなんかは新規案件なんかは積極的に取り入れた方が良い。
でも
  • PHP のオブジェクト指向
  • クロージャなどの関数型指向
  • PDO
  • Composer
なんかは読んだだけじゃすぐにはわからないかもしれない。
そういう時はわからない箇所にフォーカスした本を呼んだり実践で試したりを繰り返しやると良い。
オブジェクト指向とかデザインパターンとかいきなり全部スーッと入って来ない。
PHPの良い所はそういうことに対しての正しい情報（ドキュメント）がちゃんと用意されてる。
そして同じくらいダメな情報も用意されてる…
ここで大事なのは情報の選択。
なのでPHP：The Right Wayを更新してるエンジニアのTwitterをフォローしたりすると良い。
（正直自分も完璧である自信はないから今繰り返してる途中）

2. フレームワークを使う

もし今から新規開発をするとしてプレーンなPHPだけで開発をするのはやめた方がいい。
工数もかかるけどそれ以上にオレオレで実装した箇所を保守するのが大変になる。
だからオープンなフレームワークを使うこと。
ただ残念なことにPHPにはRuby On Railsみたいな標準となるフレームワークは無い。
しかしPHPにはオープンなフレームワークが沢山ある。
そんな中でちょっと前までは4大フレームワークは
  • CodeIgniter
  • CakePHP
  • Symfony
  • Zend Framework
と言われていた。
でも最近は
が勢いのある。
ただCakePHPも3系に上がったりSymfony2も2.5が出たりとしてる。
既にそっちを使ってる人が無理に乗り換える必要はない。
でも僕はFuelPHPが好きだからここを読んだ人にはFuelPHPを薦めておく。
LaravelとかPhalconとかYiiがすごくいいよ！って人が居たら是非とも良さをエントリーを書いて伝えて欲しい。
（それを見て僕も、もしかしたら乗り換えるかもしれないｗ）
でここから先は便宜上FuelPHPを選んでくれたとして話する。
まず知っておくことは
これらが必ず助けてくれるはず。
これらを見てまずはインストールして試してみるとFuelPHPの良さにすぐ気づくはずだ。
え、もっと親切なHow Toが欲しい？
そういう人はこれを読むといい。
FuelPHPの使い方だけじゃなくてIDEやPHPUnitを使ったユニットテストとか開発環境の使い方まで網羅してる。
「最近のモダンなPHP開発を知りたい！」って人も読んでみるといいと思う。
なんかFuelPHPの宣伝になってしまったけど開発をするならなんらかのフレームワークは使った方がいい。
その中でも人気のモノは人気の理由があるからそこに乗っかった方がいい。

3. なんでもかんでもCMSを辞める

さっきのフレームワークの延長上にCMS（コンテンツマネジメントシステム）がある。
これは完成されたアプリケーションを利用するというものだ。
もし、今必要とされてるプロダクトが完全にマッチしてるならCMSを使うといい。
けどPHP界隈では

  • ECサイトはとりあえずECCUBEのカスタマイズ
  • フレームワークのようになんでもWordPressを使って制作

みたいなことを見かける。
それぞれ優れたCMSだけど得意不得意はある。
これはフレームワーク以上に明確にある。
たとえばECCUBEは確かにECサイト向けのCMSだけど注文カートをカスタマイズは大変。
WordPressは本来ブログを作るものだ。
それを無理矢理カスタマイズしてECサイトや複雑なWebサイトにするのはイケてない。
例えばポータルサイトならMagic3が適してるしECサイトはZen Cartだってある。
もちろんブログ付きのホームページを作ったりするのにWordPressは抜群の効果を発揮する。
つまり適材適所が大切。
そしてどれもマッチしないならどれかを無理矢理カスタマイズするよりはフルスクラッチで作ったほうが良い事が多い。

まとめ

結局のところ



これ。
そうすると自然と自力も上がるし保守性・管理性も上がる。
自力が上がれば他の言語に手を出したり（そしてPHPを卒業したり）PHPの良し悪しを汲んであげれるはず。
ということで


コレ最強。
以上がそーだい的な保守性・管理性を劇的に上げる方法。





おまけ

PHPの保守性・管理性とは関係ないけどおまけ。


1. PHPの苦手なことは他に任せる


もう身も蓋も無いけどPHPはみんなの知ってる通り万能な言語ではない。
CMSと一緒で得意不得意があるし特に不得意なところに関しては滅法弱い。
これは変数の扱いが曖昧とか関数の命名規則が統一されて無くてイケてないとかじゃない。
こういう言語としてイケてないところが致命的と感じる場合はPHP以外の言語を書くしかないかな
（「他の言語を書く」の選択肢には転職とかも含めてね）

ここでの苦手なことは「実際にPHPでこれをやろうとしたら苦行」みたいな事。
例えば
  • 並列処理
  • 複数プロセス間（複数アクセスに対してとか）のリアルタイムなデータ共有
とかはもう言語仕様としてそうなってるのでそこを超えるのは大変なのは当たり前なんだけど大変。
プロセス間通信が必要な処理とか書いてもCと変わらない。
（Cが簡単と言う人には簡単かもしれないけど僕は違った）
マルチスレッドとかもそうだけどこういうのはC#とかJavaで書いた方が幸せになれると思う。
（最近だとErlangなのかな？）
他にもinputとoutputがハッキリしててアクセスが多くて速度が重視するような場合（RESTAPIとか）はPHPで書くよりScalaで書いたが絶対幸せになれる。
WebSocket使うような非同期処理ならNode.jsとか使ったほうがいいと思う。
型安全とかもそうだけどプロダクトとしてそちらが適してるならそっちを使ったほうがいい。

ただPHPも得意なことはある。
シンプルなWebサービスを作るときは簡単だし高速。
開発環境はライセンス費を掛けずにIDEもあるしvagrantなどツールも充実してる。
TDDやBDDもできるしテストの自動化みたいなひと通りの流行りの事は出来る。
それとPHPは別にセキュリティが苦手なわけじゃない。
セキュアなWebアプリって観点だと最近のモダンなフレームワークでちゃんと作れば問題ない。
セキュリティに関しては言語関係なくセキュリティに対する知識とフレームワークやミドルウェア含めバージョンアップ出来る状態の維持が一番大事だと思う。

2. 保守性はコードも大事だけどデータも大事


コードの保守性も確かにとても大事なんだけどそれと同じかそれ以上にデータも大事。
具体的にはクソなDB設計の上には何を作ってもクソ。
例えばどんなに綺麗に設計してもtext型で巨大な文字列とか入ってると*を使うORMが死ぬ（速度的に）
他にも1テーブルに100カラム以上みたいなSQLアンチパターンがあるとクエリビルダでも死ぬ（つかSQLが死ぬ）
でアプリケーションの寿命よりデータの寿命の方が長いからデータの闇は深い。
あるあるネタだけど5年前くらいのアプリケーションのリプレース案件。
コードは綺麗に出来るけどデータは既存から持って来ないといけない。
そこで立ちはだかる数百のテーブルと複雑に絡み合うViewとトリガー…みたいなとき（この場合は担当者が死ぬ）


ということでコードに対する向上心と同じようにデータ設計に対する向上心も持ってほしい。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2014年8月4日月曜日

IT勉強会について本気出して考えてみた

なんか広島が誇るスーパーハッカーひむらさん（以下：ひむひむ）が広島の未来に憂いてるみたい。

地方のIT勉強会ってこのままで大丈夫なのかな


僕から見たひむひむはこの一年で中国地方を代表するエンジニアのポジションを築き上げたのは間違いない。
元々彼自身に色んな魅力があった上に彼の行動力で為した結果だと思う。
そこに大きな影響を与えたのはオープンセミナー広島やすごい広島を始めとする勉強会の存在。
そんな彼だからこそ勉強会の良さとか大切さとか、そしてこのままでは無くなっていく危機感みたいなモノを感じてるのかなと思う。
実際にそれは勉強会ブームの終息と共に僕も強く感じてる。
例えば去年、こんな話題でJJUG CCCに登壇させていただいた。


■当日のTwitterまとめ
JJUG CCC 2013 Spring R2-6 [BOF] 地方における勉強会事情

■当日のふりかえりブログ
JJUG CCCに参加&セッションしてきた

■当日の資料



僕はこの資料のとおり、勉強会はコミュニティに育ててもらってるしすごく楽しいものだと思ってる。
だけどこの前後くらいからゲーセンの格ゲーと同じ「緩やかな死の足音」みたいなモノを感じてた。
実際に今まで主力で勉強会に来てた人が少しづつ勉強会から離れてる。
例えば


  • 結婚したり子供が出来た
  • 転職等で遠方に転居した
  • コミュニティの取捨選択の判断が厳しくなった
  • 交友関係が成熟していて発展がなく、勉強会として集まる必要があまりない
  • そもそも勉強会に対するリソースやコストが割に合わない


などなど。
他にもいっぱい理由があると思うけど何らかの理由で人は減ってる。
で更にこの後、Twitterでこんなことがあった。

「Twitterまとめ - 勉強会について本気出して考えてみた」

この時、第二回 中国地方DB勉強会は正直コンテンツとかタイミングとしては自信があった。
（どれくらい自信があったかと言うと100人入る部屋借りたくらい）
だけど結果としては思ったよりも集客は少なかった。
これは

・ターゲットに対するアプローチが下手だった
・コンテンツの魅力を自分が伝えきれなかった
・そもそもDBというコンテンツ自体がみんなの興味を獲得できてないのかもしれない

などなど他にも沢山色んな理由があるんだろうけど僕は

とりあえずで勉強会に参加してくれる時代は終わった


つまり勉強会ブームは完全に終わったって思った。
これは格ゲー時に既に通った道だったのですごくハッキリと感じた。
なのでこのまま放っておくと参加者の新陳代謝は無くなってどんどん人が減っていくと思う。
そこでこの時も言ったけど


と思ってる。
実際にゆるふわ系というか身内にまったりやる集まりはそれなり見かける。
だけどそれだけじゃあ勿体無いと言うか緩やかな死は止めれないと思ってる。
そこで自分が考えた一つが次のとおり。

1. 参加者の新陳代謝を上げる

そもそもなぜ僕がお金が使える勉強会も必要だと思ってるか。
まず色んなスタイルで色んな人が楽しめれば良いんだけど本当に聞きたいこと（日頃経験してない知識）って一日じゃあなかなか手に入らない。
だからやっぱすごい人に教えてもらうのが手っ取り早いしそういう情報を仕入れるアンテナを作る必要がある。
それに一番効果的なのは勉強会にその手の達人を呼んでコネクションを作ること。
（インプットを育てる）
その次に大切なのが自分のアウトプットを増やして知識の定着をすること。
だからまずビックスピーカを呼ぼう！！
ってのが建前。
実際のところ、兎にも角にも参加者の新陳代謝の活性化には新しい参加者が必要。
そこで勉強会に来たことが無いような人が来るきっかけになるような強い動機にはやっぱ

  • 即実践投入できる知識や経験の取得（ハンズオンとか）
  • 名前や概要を見ただけで聞きたくなるようなスピーカー

みたいなわかりやすい魅力だと思ってる。
（当然他にも　勉強会の色気　を出すような工夫も日々必要だけど）
そこで遠方の講師を呼ぶってなると最低限、交通費と宿泊費はかかる。

# いつもノーギャラで来て頂いてる皆様。
# そしてボランティアでやってくれてるスタッフの皆様
# 本当にありがとうございます。

で実際にそういう人たちに来てもらうセミナーとかは3000円～5000円とかする。
例えば第1回 中国地方DB勉強会の例を取ってみるけど

■第1回 中国地方DB勉強会
※当日の内容は動画も資料もあります

■関東の講師(この時は奥野さん）を呼ぶ
・交通費　約4万円
この時、奥野さんは宿泊費しなかったけど宿泊費する場合はいつも上限１万円で宿泊費も出す

■設備費
・会場費 4,280円＋ 通信費 600円
大学の施設や県の施設を借りると安く済むので助かる
（この時は県の図書館を借りた）
広島市内で100人近く入る会場（例えばRCC文化センター）を一日借りると5万とか超えちゃう。

これは大垣さんには大変申し訳無かったけど交通費自費で来てもらった上でこの状態。
スタッフのみんなも交通費とかボランティア。
で参加者はスタッフ抜くと13人くらい。
単純に人数で割ったらこれでも参加費3000円超えちゃう。
こうやって考えると有料セミナーの参加費が3000円～5000円かかるのは適正価格だ。
しかも実際に地方から東京に行ってセミナーを聞く交通費を考えると格安だ。
と考えてくれるのは訓練された勉強会参加者だけ。
ちょっと興味があるくらいの人に3000円なんてハードル高い。
中国地方DB勉強会だって地元の人が参加費3000円だと参加しただろうか？
だから参加費はできるだけ低価格に抑えたいのが運営側の本音。
そうなると自腹を切るリスクとか大量の人数動員が必要になったりとかで本当にハードル上がる。
そこでお金を使える勉強会の存在が大事になってくる。
例えば中国地方DB勉強会はJPUGが予算出してくれるからコミュニティの援助のお陰で参加費を0円に抑えれてる。
オープンセミナー広島やオープンセミナー岡山は地元企業の協賛のお陰で参加費を0円。
こういう勉強会の実績をどんどん積み上げて勉強会を支援する動きがもっと活発になってくれば色んな取り組みが出来るようになるはず。
例えばTDDBCなんて超素晴らしいイベント。
だけど今年は開催されない…
（スタッフではないので詳しい理由は知らないので下記はあくまで推測）
例えばハンズオンは講師（TA）の数が必要になるし準備も大変だ。
さらに参加費で予算を賄うのであれば運営のリスクも大きい。
だから毎年大体的にやるのは大変だと思うので仕方ないと思う。
（TDDBCなんかは何回も参加するイベントでも無いので母数が少ないと需要がなくなるの早いし）
でもこれを支援する仕組みがあったら来年は開催されるかもしれない。
そしてそういう仕組を作るための基盤作りを今自分は頑張ってるつもり。
そしての基盤作りの中で新規の人が来るきっかけ作りをしてる。

2. 勉強会に来てもらった人を育てる

お金のかかった勉強会に来てもらった。
そしたら次はもっと勉強会を好きになってもらう必要がある。
そういう時にゆるふわ系の勉強会はすごく重要なポジションになってくる。
あの身内で同じ趣味の話をしてる時間は至高の時間と言っても過言じゃない。
だからそういう勉強会もすごく大切だと思うしそんなイベントの方が楽しいとさえ思う時がある。
そしてそういうのはひむひむがすごい頑張ってる。
だから僕は人を集めたら今度はひむひむのようなコミュニティに上手く誘導する必要がある。
なので僕は中国地方DB勉強会はPostgreSQLに限らないしエンタープライズもWeb系も題材に取り上げて色んな人に来てもらうし色んなコミュニティへの橋渡しをしてる。
中国地方DB勉強会やオープンセミナー以外の他にもWeb Touch Meetingとかオープンソースカンファレンス＠広島とかそういう集客の要素と橋渡しの要素がすごくあると思う。
そういう橋渡しを行いながらもっと勉強会を楽しむ人を増やして参加者の滞在率を伸ばしたりする必要がある。
そういう場所に来るのは100人集めて1人かもしれない。
だけどその1人が居なくなったらそれこそ緩やかな死から末期の状態になっちゃう。
だから懇親会だったり、日頃のコミュニケーションだったり、色んなところで何らかの楽しさが芽生えてほしいしそういうきっかけ作りは大事だと思う。
そういうところは岡山のコミュニティは上手だなって思う。

3. コミュニティ（勉強会）の一部になってもらう

一番わかりやすいのはスタッフ。
でもスタッフだけがコミュニティの一部じゃない。
ブログを書くまでが勉強会とか言ったりするけど「○○勉強会に参加しました！めっちゃ面白かった！！」ってブログ書くだけでもコミュニティの一部。
それを見た他の人は興味を持つし、それを見つけたスタッフは嬉しくてその日のビールは旨さ10倍。
そしてそんなコミュニティへの関わり方で一番簡単なのはひむひむ言う通り、イベント情報の拡散だと思う。
ひむひむも言ってるけどSNSでは今は色んなシェアの仕方もある。
僕はもっとレイヤー低くていいと思ってて職場の昼休憩の話題にしてくれるだけでもいい。
他のイベントとか飲み会でちょっと話のネタとして話題に出してもいいかもしれない。
他にもTwitterで話題が出た時にちょっとリプを飛ばし合うのも良いと思う。
そういう積み重ねが1をやってる自分や2をやってる人達の助けにすっごいなる。
だからひむひむはもっとみんなにコミュニティの一部になって貰いたいんだって伝えたかったんだと思う。




ということで感情に任せて一気に書いたからまとまってないけど無理矢理まとめる。
僕にはひむひむのような求心力はないけどコレを見てた人が少しでも自分たちの楽しい居場所とか好きな事について考えてくれたらなって思う。
今回はIT勉強会が軸だったけど実はこれは結構色々当てはまる。
例えば僕の所属する日本PostgreSQLユーザ会だってそう。
先輩方のすごい努力で日本のコミュニティとしてすごく大きいコミュニティになってる。
でもデータベースエンジニアって若い人が全然足りないからコミュニティの平均年齢がどんどん上がってる。
10年後、コミュニティが今と同じ状態になってるか正直わかんない。
だから僕は育ててもらってるコミュニティの恩返しの一つとして勉強会を通してJPUGの新陳代謝の活性化を目指してる。
他にも冒頭で触れた昔ながらのゲーセンとかもうほんとヤバイ。
どんどん潰れて無くなっていて地方だと絶滅危機種。
雀荘とかも今は随分見なくなったよね。
こういった事に流行り廃りは絶対あるんだけどその中で自分が好きな場所とかこれは大切だって思う事に対してはみんなもっと積極的になったほうがいいと思う。

と全然まとまって無いけどまとめとしてはこんな感じ。

投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)