2014/06/01 このエントリーをはてなブックマークに追加 はてなブックマーク - 【ウォーターフォール】工程にリファクタリングを入れようよ

【ウォーターフォール】工程にリファクタリングを入れようよ

カテゴリ:




※前提として、この話は
SIでの、僕周辺の狭い話です。





古典的なSIerというのは、とかくウォーターフォールにこだわりを持っている。
プロジェクトによってはスパイラルモデルや
(バズワード化している)アジャイル的な手法というのも取られているけど、
やっぱウォーターフォールって多いと思うんです。





TDDは死んだとか言われてるけど、
テストファーストな考え方とかは浸透すらしていないというのが現状ではないでしょうか。

なんなんだろうね、この現場とネットに溢れている新技術との時差は。





僕の感じるところでいうと


  • ウォーターフォール
  • SVN
  • Java6
  • 打鍵のテスト



  • あたりは古いものに感じる。


  • アジャイル的なもの(幻想も含め)
  • git
  • Java8
  • Web Driver(Selenium)


  • とかだとテンション上がるんだけどな。
    色々と難しさがあるのは承知の上だけど。





    SIでの会社としての力というのは
    プロジェクトをどう回すかってところに集約されるんだろうな。

    そういったプロジェクトを回すノウハウ(ソフトウェア工学)的なところで蓄積があるのだろう。

    それが顕著なのがウォーターフォールという手法なんだろうと思う。




    まぁ、そういう業界体質だから、
    ウォーターフォールが多いのはしょうがない。
    それに、ウォーターフォールに自体は悪ではない。


    「なんでもかんでもウォーターフォールで」というのが怖いだけだ。




    ウォーターフォールってすごい大雑把に言ってこんな感じだと認識してます。


    要件定義
                            ↓
    基本設計
                            ↓
    詳細設計
                            ↓
    製造
                            ↓
    単体(UT1、UT2とか)
                            ↓
    結合(ITa、ITbとか)
                            ↓
    総合
                            ↓
    保守



    僕が最近強く思うのは、ここにリファクタリングという工程を付け加えたいということ。
    つまり、こうです。


    要件定義
                            ↓
    基本設計
                            ↓
    詳細設計
                            ↓
    製造
                            ↓
    リファクタリング
                            ↓
    単体(UT1、UT2とか)
                            ↓
    結合(ITa、ITbとか)
                            ↓
    総合
                            ↓
    保守


    製造・リファクタリング工程としても良いんだけど
    リファクタリングの重要性をプロジェクト全体としても、お客さんとしても認知していただきたい。
    そういう思いを込めて、「リファクタリング」という独立工程としたい。





    リファクタリングってホント大事だと思うわけです。


    簡単に並べると以下の通り。

      情報の私物化の回避


    クロスチェック的な効果もあるんじゃないかなと思う。
    それに、自分しか分からないようなソースを書かないということにも繋がる。
    リファクタリングには客観性と統一性が必要。


      可読性の向上


    整えるわけだから、読みやすくなる。
    繰り返しになるけど、大事なのは他人が見て読みやすいか。
    クラス名、変数名、メソッド名で大体決まる。
    ちょうど良い名前がつけられないものは良い実装じゃない。


      テストの生産性向上


    整っているものは直すのも速い。テストコードも書きやすい。
    試験で発生した障害を直すのがスムーズになるので、結果的に試験での遅延を防止出来るわけです。

    逆に、散らかってるものを直すのは一苦労。
    ジェンガみたいに相互の依存度が高くなってることが多いから
    単純に直すと他が崩れる可能性がある。
    ジェンガと向き合う作業には時間がかかるのです。


      机上でのバグ発見(早期改修)


    整っているものからは、眺めるだけで問題が見えやすい。


    汚い例えだけど、
    散らかった部屋の中からゴキブリを探すのと
    整理された部屋に現れたゴキブリを見つけるのはどちらが簡単ですか、ということです。

    こんがらがったコードだと
    ゴキブリ倒したと思ったら、もう一匹いた!なんてことはよくある。(個人的な話ですが、ゴキブリ超嫌いです)







    ここからは、想像も入ってきます。
    問題点があるとすれば、以下二点。



    1.デグレード

    2.製造時に糞コードが出来上がる






      1.デグレード


    言葉の通りですが、
    製造工程で仕様を満たすものが出来ていたとして、それを変更したことで仕様を満たさなくなる、不具合が発生するということ。
    対策として、間違っても
    「製造で出来たものを丸々書き直す」という荒行に出ないことが重要です。

    これに関しては
    「プログラマが知るべき97のこと」
    の受け売りです。
    ベースはあくまでも製造工程で作ったものを利用する。
    新技術を無駄に使いたがらない。
    理路整然としたものなのに、古いから新しいものにしようという理由は良くないのです。





    プログラマが知るべき97のこと
                    プログラマが知るべき97のこと




      2.糞コード


    リファクタリングがどうこう以前にウォーターフォールでありがちです。
    後工程でなんとかするという「先延ばし」は本当に恐ろしいものだと思います。(TO 関係者各位、、、!)

    技術的負債とか言われるものです。
    スラング的な言い方をすると
    糞コードとかゴミドキュメントのことです。

    リファクタリング工程を設けることで予想されるのは
    「製造ではとりあえず動けばいい。リファクタリング工程で整えるから」
    という思想です。


    製造当初からリファクタリング不要なコーディングをする意識を持つべきです。
    その上で、リファクタリング工程でよりブラッシュアップをかけるというのが僕の目指す理想です。








    今回は、SI事業ではウォーターフォールが多く、
    新技術の流入には時差が発生しているという現状があるということ。

    それに端を発して、リファクタリング工程ってあったら幸せになれそうじゃないですか?
    というお話でした。

    ウォーターフォールやるなら、そういう新しい(?)取り組みをいれてもいいんじゃないかしら。
    もちろん、工数とか予算とかの問題がついて回るんだよなぁ。うがぁ。



    とりあえず、言いたいのは
    「動けば良い」思想はやめて欲しいんだ!笑

    確かにスピード感求められるのは分かるんだけどね。

    あまり幸せになれない気がしますね








    0 件のコメント:

    コメントを投稿

    GA