過去のシステム

下で書いた3年前のシステムだけども,ちょくちょく問い合わせが来たりする.その際にソースの手直しが必要になる場合があるんだけれども.かなり汚く他人が保守できるような代物ではない(自分も怪しいorz).当然動作も微妙に不安定かつ,UIも微妙(自分で作っといてなんだけど)
この場合技術者として取りたい衝動に駆られるのが,リプレースなわけだけども,こっちの都合でリプレースする場合にはお客さんはお金を払ってくれないわけで.問い合わせの度に場当たり的な変更を加えつつじっと我慢の子なのか,いっそのこと自社負担で今後のことも考えて作り替えちゃうべきなのか.経営的な尺度で行くと動いてるんだからいいんじゃね?な感覚なんだろうけど,保守する方としては溜まったもんじゃないってのがほんとのところ.作り替えたところで完全にバグがなくなるとは限らない(けど無くしていく努力は当然必要だ)けども今のまま保守していくよりはいいんじゃないかと思う.
現場的にはそっちの方がいいんだけども経営的にはやっぱ駄目な行為なんだろうな…そこんところどうなんでしょう.

とあるシステムで

自分とは違う人が書いたシステムのソースを保守しないといけなくなったわけですが,やばい.これはやばい.

  • まず当然のようにフレームワークは使っていない.
  • そして憎むべきregister_globalsがonの状態じゃないと動かない….
  • ORマッパーなんて夢のまた夢で,mysql_query連発.
  • SQL生成はregister_globalsで展開されたグローバル変数を直入れ.
  • 処理の分岐はif文で処理.しかもそのキーは日本語.
  • データベースの文字コードがばらばら.EUCだったり,SJISだったり,UTF-8だったり.
    • どうやって対応するかというと都度mbstring_convert_encoding.
  • 当然表示周りの文字コードもばらばら.
  • 処理は当然グローバル領域にてベタ書き.
  • データベース接続パラメータ(ユーザ名とかパスワード)もベタ.
  • ソース類は全てhtdocs以下.
  • ファイル名はローマ字.(検索画面がkenskau.phpになってたり)
  • インデントがばらばらで括弧の対応が分からない.
  • クエリの結果がなぜかカラム毎の配列.(普通は行毎な気がするけど)

そして久しぶりに自分が約3年前に書いたソースを見る.

クラスは切ってあっても一つのメソッドに処理べた書きorz.処理の分岐はswitchでorz.global宣言があったorz.
そしてなぜか

$this -> hoge = 'hoge';

な感じですき間がorz(なぜすき間があるかは謎.なんか特別視してたのか?俺)

どっこいどっこいのいい勝負してるなぁ…そして,上のソースは去年書かれたもの…

動いてるならいいじゃないと言われそうなもんだけど,よく分からん動き連発.まぁそりゃそうだよな….このphpフレームワークが雨後のタケノコのごとく出てる現状でこんなソースを書けるのはある意味すごい.ひょっとしてそういう状態だからこそフレームワークは使わずに作るんだろうか.フレームワークを使わないことの利点もあるんだろうけど,これはいくらなんでもちょっとと思った.

content_for_header

Railsでは"content_for"でヘッダ部分なんかの一部のソースを各ビューに委譲できるけど,Akelosでも同じようなことができる.(Railsクローンだし)

<?php $capture_helper->begin('header'); ?>
<style type="text/css"></style>
<?php $capture_helper->end(); ?>

phpでそのまま書く方法と

<%= begin('header') %>
<style type="text/css"></style>
<%= end %>

railsっぽい書き方の2通り.基本的にほとんどのヘルパ関数は上記のような形で書けるっぽい.javascriptの読み込みも

<%= javascript_include_tag('prototype') %>

みたいに書ける.

ちなみに上記のbeginで指定したソースは,ビューに"content_for_header"という変数名で渡されるので,

<?php if (isset($content_for_header)) echo $content_for_header; ?>

と書くも

{?content_for_header}{content_for_header}{end}

と書いてもよさげ.
こちらの表示部は恐らくlayoutファイルで書くと思うので,一応存在チェックを行なったほうがよさげと思いました.

パラメータ

の取り方は

$test = $this->params['test'];

みたいな形で取れるんだけど,これ配列から取ってるから,もしもこのパラメータがなかったらNoticeエラーが出る.

Notice: Undefined index: test in /www/projects/akelos/app/controllers/test_controller.php on line 14

これですね.
なので,基本的に存在チェックが必要.

$test =  (isset($this->params['test']) ? $this->params['test'] : null;

これを毎回書くのはめんどくさいということで,application_controller.php

    function get_param($key=null)
    {
        if (isset($key) && isset($this->params[$key])) {
            return $this->params[$key];
        }
    }

みたいなメソッドを追加してみた.

使ってみた

かなりいい.
ちょっと前から仕事の関係でRailsを使っていたので,すんなり入り込めた.ドキュメント関連がご多分に漏れず足りない気もするけど,その辺は愛と勇気を持ってソースを読む.
てなわけで気づいたことを出来るだけ書いていこうと思うます.

それはそうとRailsと同じように書けるからこそ気になる事が

$this->render(array('partial' => 'list'));

この"$this->"と"array"が非常にめんどくさい.
ビューに関してはハッシュのくくりに若干気をつけないといけないっぽいけど,概ねRailsの構文でかけるのでいい感じ.

Akelos

http://www.akelos.org/

Akelosというフレームワークを発見.id:bobchinさんの所で紹介されていたフレームワークだけども,screencastsを見るとRailsそっくり.しかもphp4で動くという.
早速使ってみたgeneratorもうまいこと動いて万々歳といきたいところだけど,一つ困った事が.このフレームワークはSintagsっていうテンプレートエンジンを使ってるみたいだけど,Railsのビュー的な書き方ができるのでいい.んだけど,どうもコンパイルされたファイルがうまく格納されてくれない.generatorでビューを作るところまではいいんだけど,なぜかコンパイルディレクトリがそのビュー直下に…で,ページを表示しようとしたらPermission deniedでcompiledディレクトリが作れない.

こいつは困ったということで,config.php

 define('AK_COMPILED_VIEWS_DIR', 'tmp/views');

してみるもコンパイル自体はされるんだけど,今度はこのファイルを読み込めないというエラーorz.
このあたりの設定は一体どこで宣言すればいいのかを現在調査中.

追記
解決
config.php内でboot.phpを読み込んだ後に

 define('AK_COMPILED_VIEWS_DIR', AK_TMP_DIR.DS.'views');

で,オッケーっぽい.