古いコードとの闘い

こんにちは。福岡です。

WebClass の画面は一昨年にデザインを改めましたが、まだまだ古いままの画面も残っています。利用者からは統一感のなさを指摘いただく機会も多々あり、至らなさを感じるところです。

ここでは画面の置き換え、もしくは機能の入れ替えについて、開発チームで共有しておきたい全体的な方向性についてまとめておきます。一番に想定している読者は開発チームです。また新機能の開発についてはここでは扱いません。

直すつもりはあるのか?

もちろんです。使いやすい・わかりやすい画面、もしくはより便利な機能に改めていきたいと考えています。

ただし、小さなチームでの開発ですのでリソースの問題は常に付きまといます。また、いざ取り掛かるにあたり、どう直したらいいのかというのが次にぶつかる問題です。

残念ながらやみくもに手当たり次第に取りかかれるわけではない中で、どう切り崩していこうかと常に考えたり、情報収集しています。

改善の方向性

WebClass の開発で常に意識している点は以下です。

  1. できる限り多様な環境で利用できること
  2. わかりやすく汎用性の高い、シンプルな画面・機能であること
  3. 素早く変化し続けること
  4. 安くあること
  5. 連携

コース画面のデザインを改めた際に目指した、主に利用者目線の点は以下です。

  1. スマホ・タブレット・PCといった現在の利用環境へ対応
  2. あっさり使う利用者がすんなり使えるように単純化

画面を直すにあたり、コードの設計も改めていっています。開発目線の点は以下です。

  1. 画面・機能とURLのマッピングの整理
  2. パラメータチェックやセキュリティ対応の詳細化

2000年代のころは大学で LMS を使っていただく方は、eラーニングや LMS の活用に積極的な方が多くありました。このような利用者から多数のご意見・ご要望を頂きながら WebClass も様々な機能をそろえることができました。

2010年代にはいって大学での LMS 利用が浸透し、先生方に教育でのシステム利用に興味があるなしに関わらず、学校設備の1つとして広く授業で使われるようになってきています。また、学生の方もとりあえずスマホでアクセスするのが当たり前になってきています。また、普段から利用する先生が増えるに従い、システムの不具合があった時に与える影響も大きくなっています。こうした変化に伴い、WebClass が先に取り組んでいたのは学生のスマホ利用への対応、ソフトウェア開発工程とソフトウェアテストの改善、セキュリティ実装でした。

そこからさらに一歩進める改善が、一昨年からの新画面の取り組みです。今ではあまり高度な機能がありすぎても、普段ちょっと使うにはかえって扱いづらいと感じられるケースが増えています。また、利用端末もスマホだけでなくタブレットが加わり、学生が使うかと思いきや先生もタブレットで利用するケースがあり、とても多様化しています。セキュリティについても、ますます重大なテーマとなっています。

コードベースの改善

先月、松川さんが「ソフトウェア設計 勉強の手引き」という記事をちょうど書いてくれました。

例えばある機能の画面をきれいに直すにあたり、見た目だけ直せればいいやと考えて HTML と CSS + Javascript だけの書き直しでうまくいくかというと、経験的にはそう簡単に行きません。見た目の整理は取り扱う情報の整理になるので、結果的にはプレゼンテーション以前のデータ構造やデータの受け渡し経路を見直す必要が出てきます。特に Ajax を使った SPA にしたい場合、JSONデータインタフェースの実装が必要になるので、当然ながらインタフェースの拡張が必要になります。これらはセキュリティ実装でも同じことが言えます。したがって多かれ少なかれリファクタリングをすることになります。

利用者から見えないリファクタリングに時間を食われるのをもどかしく思うこともありますが、私は画面の改善でリファクタリングが必要になるのは好機と見ています。素早く確実にソフトウェアを改善し続けるためには、コードの保守性は重要です。これまで画面を変えられなかったのは、その様なコードの体制がなかったのも原因の1つです。ですがコードの問題は画面の改善だけでなく、テスト可能性やテストのコストにも反映されます。

幸いなことに、コードの設計は手本になる本やオープンソースのライブラリやプロダクトが多数あります。したがって、何を実現するかがはっきりしていれば解は比較的見つけやすいです。また、基本的には良いパターンを使いまわしていきます。なので、一か所で何とかすれば、同じような個所を一気に片付けることができます。そして、その後は維持しやすくなると期待できます。

見た目・機能の改善

コードベースの問題を乗り越えて実質的な機能修正に取り組むにあたり、一番問題になるのは「本当に使いやすいのか?」という点です。

コードの良さは計測しやすく、開発チーム内でコンセンサスが得られればOKという意味で、評価しやすいです。一方、画面や機能について利用者がどう思うかは計測・確認がしにくく、いろんな利用者がいてコメントの方向性が定まらないケースもあります。また、仮にいい画面になったとしても、慣れの問題が付きまといます。この点について個人的に印象深いのは Microsoft Office 2007 のリボンUIです。出た当時はいろいろ言われていましたし、私も「なんで?」と思いました。従来のメニューでは一通りの機能を本当に扱いきれなかったのかどうか私には評価できませんが、今では慣れて特に問題なく使っていますし、スタイルの適用などはUI表示域の広さと表示される情報とが程よく、便利だなと思っています。

真似しやすいコード設計に対して、UIや機能の設計は基本は考えてひねり出すのが良いと思います。利用者のコメントはありがたい参考資料になりますが、そのまま受け入れるだけだとブレます。特定の利用シナリオにぴたりと寄り添うほど汎用性を失って、オプションを必要としてしまいます。オプションも加えれば加えるほど動きがわかりにくくなり、テストやマニュアルの周辺作業が積みあがってしまい、機能を洗練させる時間を取れなくなります。

ではどうしたら良い機能や画面をひねり出せるか、これは私もいつも悩む問題です。やはりここは、いろいろ聞いたり試したりするしかないと思っています。特に、先生がどんな状況でどんなことをしようとしているか、というあたりでしょうか。WebClass のあるなしに関わらない、もう少し根本的なシーンやシナリオが見えてくると、考えやすいです。でも、特定のケースに固執しすぎては汎用性を失います。ここが難しいといつも思います。

取り組み続ける

利用者がいてくれる限り、WebClass の開発は終わりません。その時ごとにテーマや課題があり、常に変化・対応し続けていきます。今いいものも、2年後には利用環境と乖離して使い物にならなくなっている可能性もあります。それどころか、後になって昔の機能の価値を再発見してしまうこともあります。そういう意味で、コードベースの改善も画面・機能の改善も果てがなく、あまり考えすぎてしまってもしょうがないところがあります。

なので私たちはアジャイルなソフトウェア開発の仕方を取り入れています。小さく手堅い修正を素早く重ねて行く作戦です。画面の置き換えも、表には見えないリファクタリングだけ先に進めたところもあります。その中で、試したけど捨てたコードも多数あります。いいと思って採用したけど、思ったようには行かなかったコードも多数あります。ですが、これらは「うまくいかない」ことがわかった成果として無駄ではなかったと思っています。

いずれにせよ、多くの利用者が使うシステムでは「パパッと作って何とかなる」とは行きにくくなります。タイムリーに新機能や改善を提供し続けるためにも、普段からリファクタリングや試行錯誤を常にやり続け、そして学び続け、堅実なコミットを積み重ねていきます。

ソフトウェア設計 勉強の手引き

この記事は弊社の後輩プログラマーを読者と想定して書いています。しかし一般的な内容でもあると思いますのでここに公開します。

なぜソフトウェア設計の勉強をしなければならないのか?

プロのプログラマーは、堅牢で、なおかつ要望を即座に実現するソフトウェアを構築するために、「プログラムの変更が容易である」状態を維持しなければならない。もう何十年も先達プログラマー達はそのためのノウハウを蓄積し、原理原則レベルまで抽象化して落とし込んでいる。これを学び体得することが、プロのプログラマーには必要である。

どう勉強したらいいか?

まず、設計スキルを完璧に身につけた!と言い切れる人は多分いない。プログラマーは皆、常に勉強し続けるのみである。設計スキルを向上させるための基本的な方法は、他人のコードや本で良い設計のエッセンスをインプットし、自分の書くコードにアウトプットする、これを繰り返すことである。
インプットの方法だが、まずは他人のコードを読む習慣があると良い。会社やサークルで、メンバーの書いたコードを読み、その設計の良し悪しについて話しあってみる。公開されているOSSはネット上に無数にあるので、興味があるプロジェクトを見つけてコードを読んでみる。できればOSSにコミットするコントリビュータを目指すといい。
設計に関する原理原則、体系だった情報を得るには、本を読むことになる。以下はどの資料をどういう順番で読むといいかを例示する。この通りに読まなくても、自分に合う本をピックアップして良いし、興味のあるところから取り組んでも良い。

レベル1. 何はともあれ読むべし

レベル2. 設計の原理原則を知る

設計の原理原則はプログラマーの教養であり、共通言語である。知らないと他の本が読みづらい。

レベル3. コードのテスト手法について知る

コードが正しく動いているかチェックするには?プログラマーは皆テストを「書いている」。それに伴い、テストをしやすいコードが良いコード、という指標が存在する。テストを書くとはどういうことか知らないといけない。

  • テスト駆動開発
    • テストファースト(コードより先にテストを書く)の手法をテスト駆動開発(TDD)と呼ぶ。テストしやすいコードを書きたいなら、最初にテストを書いてその通りに動作するコードを書けばいいじゃん、という考え方。(本当はもっと奥深い
    • テストを書くメリットを知るには、何より体感したほうが手っ取り早いと思うので、ステップバイステップで実際にテストを書くこの本を勧める。なによりテスト駆動開発の原典だし。
  • 自分の得意な言語、Webフレームワークで、テストを書く方法を調べてみる。
    • 例えばPHPなら、PHPの初心者向けの本で、テストについて記述のある本を探す。PHPUnitというライブラリを使うのが定番。
    • 例えばLaravel(PHPのWebフレームワーク)を使ったことがあるなら、Laravelのマニュアルや本にはLaravelでのテストの書き方を説明した章が必ずある。
  • 日本におけるテスト駆動開発の第一人者、@t_wada さんによる解説資料を読み漁る。

レベル4. オブジェクト指向をさらに深く知る

これ以降は、目的に応じて細分化していく。

既存の汚いコードと戦う

コードは書いたら書きっぱなしじゃない、常に改善を繰り返していくものだ。設計についてもそうだ。複雑で手を出しにくい設計に修正を加えないといけない時、どう立ち向かうか?

オブジェクトを改めて捉え直す:ドメイン駆動設計

関数型プログラミング

普段使っている言語とは異なる言語思想と文法を持つプログラミング言語を学ぶことで、その考え方の良い点を設計手法に反映できる。特に関数型プログラミングと呼ばれる思想は、最近勃興してきたプログラミング言語の基礎(の一部)として採用されている。既存のPHPのようなプログラミング言語でも、関数型プログラミングのエッセンスを活かした設計手法が存在する。

  • Elmで関数型プログラミングを学ぶ
    • ElmはWebアプリケーションを作るための関数型プログラミング可能な言語。
    • 関数型プログラミングに必要な厳選された文法・機能を備えているので、関数型プログラミングの学習のとっかかりとして使える。
  • Haskellで関数型プログラミングを学ぶ

とりあえずこんなところ。

最後に

この記事を書いている人ももちろん勉強の道半ばです。自分が書くコードの設計についてレビューでガンガン指摘してもらったり、話し合ったりしたいです。オススメの資料があれば教えてください。宜しくお願いします。