仕事としてコードを書くようになって３週間が経ったので
ここらで所感をまとめてみたいと思う。
ベンチャーと大手企業の違いみたいなことを書いてもいいんだけど、
正直今のところ「あまり変わらない」印象。
それもそのはず、現職もエンプラ向けの仕事。
SIと仕事のやり方はかなり似ている。
ので、純粋にプログラマとして思ったことを。
スパゲッティコードとの出会い
この３週間で触ったのはウチの会社で改修・保守をやっているシステムの
バッチや管理画面の細かい修正など。
コードは全てPHPだった。
この辺は一番経験のある言語だったので助かった・・・と思った。
が、意気揚々とソースを見て愕然とした。
処理ベタ書きのずらずら続く手続き型の処理は序の口。
関数を定義する代わりにベタ書きスクリプトを外出しにしてrequire
意味不明な変数名
同じ処理をしているはずなのに名前だけ違う関数達
無計画なテーブル定義
業務でPHPを書いたことがない俺でも分かる
初心者が書いたのかと思うくらいの酷いコード達。
そして「前任の担当者は辞めた」
つまり「細かい仕様が分かる人」はおらず、
さらに悪いことにプログラマは自分しか居ない状況
仕方なく泣く泣くスパゲッティコードを読みといて
仕様書を自分で起こすハメになった。これが自分の初仕事となった。
が、お陰で「酷いコードとは何か」を身をもって経験することができた。
一番自分が問題だと思ったのが「処理のベタ書き」。
コードを改修する時に一番の弊害になるのがコレだと思った。
つまりクラスやメソッドを定義せず、ひたすら処理をずらずら書いていくことだ。
自分が見たコードは殆ど関数も定義せずにずらずらと処理を書いていく地獄のようなコードだった。
処理ベタ書きの問題点
処理ベタ書きだと何が起きるか？
少なくとも以下のことが起こることに気づいた。
- 仕様を追っていくのが大変
- require_onceで外部スクリプトを読み込んで実行している場合いちいち外部スクリプトを開いて読まないと処理の流れが分からず非常に読みづらい
- 変数のスコープがアホみたいに広いので読み解くのが大変
- コードを修正するときの影響範囲がわかりにくい。変な所で相当前に書いた処理が影響してたりする。
- 単体テストがしにくい
要するに「読みづらくて」「メンテしづらい」のだ。
そしてバグを生む。結果的に品質が悪くなりトラブルを起こして顧客がカンカン。
BtoBだと、障害はいとも簡単に損害賠償につながるのでかなりおっかない。
SIerが契約書や要件定義書を書く時に
ガチガチに前提条件を固めるのはそのためだ。
損害賠償はイヤだね。どうしようか
要件の不一致でモメた場合は営業が悪いということにして（ｗ、
プログラマとして何ができるかを初心者なりに考えてみた。
1.ショボくてもいいから必ず仕様書は残す
データのIFとテーブルの定義と大体の処理の流れだけでいい。
これがあると無いのでは、後任者がコードを読むときのスピードが全然違う。
この３週間で自分が関わった案件には全て仕様書がなく、手探りで仕様を確認しながら
修正する、というとても手間のかかることをやっていたが非常に時間のムダである。
必ず大体の仕様書は残していくようにしたい、ていうか社内全体で「残させる」ようにしたい。
2.オブジェクト指向を守る
PHPは手続き型とオブジェクト指向型の２つの書き方ができるが、
もう手続き型は忘れてしまったほうがいい。
PHPの標準関数の中にもオブジェクト指向スタイルで使用するものが5.x系で出てきていたり、5.3系で名前空間が使えるようになったりとPHPという言語の流れとしてはどんどんオブジェクト指向言語化しているのである。
時代の流れということで、手続き型の書き方は忘れて頂きたい。
間違っても数百行に及ぶ処理をひとつの関数内で書いてはならない。
かならずクラスとメソッドを定義して書き、
メイン処理が走る場所は一つの関数にまとめる。(CやJavaでいうmain関数)
このクセをつけるだけでコードを読み解く速度は格段に進歩する。
最初は良い設計じゃなくてもいいから
かならず２回以上出てくる処理はメソッドにして外出しにする。
ライブラリとなるクラスは外出しファイルにして最初にrequireする。
絶対にベタ書きにしない。
これならいくらrequireしても、newしてメソッドを呼ばない限り実行されない。
好きなだけrequireするがいいさ。
これだけで以下が実現できる
１．無駄な繰り返しの排除
２．修正による影響範囲の特定
３．関数単位での単体テストが可能になり全体の品質担保がしやすくなる
４．どこで何をしてるかが解りやすくなる
つまり「読みやすく」「修正に強い」コード体型を作れる・・と思っている。
ただオブジェクト指向を極めるにはそれこそ数十年が必要な勢いの奥が深い概念であり
自分は「オブジェクト指向道」に入門したばかりなので今後もその設計理念を学び続けねばならないと思っている。
Javaのようなオブジェクト指向言語をやってる人なら常識なのだろうが、
如何せんPHPしかやってないような人はこの辺を余り理解していないらしい。
なので延々とベタ書き処理をやりたがる。PHPで外注に出すときは注意せねばなるまい。
正直、『複雑な処理してる長いプログラムはJavaで書けよ！』
というのが個人的な本音（ボソ
オブジェクト指向の話といえば面白いエントリーが結構あるので紹介したい。
オブジェクト指向というと、用語だけ先走って
「隠蔽化が〜」「継承が〜」「デザインパターンが〜」という話ばかりが目立つが、
その目的といえば「読みやすくてメンテし易いコードを書くこと」だと思っている。
まずは「クラス」と「メソッド」という括り自分のコードを整理することが品質をあげるための第一歩だと思う。
※こんなこと書くと同業者の方々から「オブジェクト指向の本質はそこじゃない！」と怒られそうですが、レガシーコードと格闘した後だとクラスとメソッドで明示的にコードの中身を分類出来るだけで個人的には素晴らしいことだと思うのです。ハイ。
