動いてるからいい、じゃ済まなかった
バグを直してもバグが出る。
その繰り返しが続いていた時期がありました。
ふと、思いました。
コードがごちゃごちゃなんじゃないか、と。
ちょうどその頃、「スパゲティコード」という言葉を目にしました。
多分これだ、と思いました。
足の踏み場がない部屋では、作業がしづらくて失敗しやすくなります。
まっすぐ置けるはずのものが、斜めになってしまう。
コードにも、そういうことがあるんじゃないかと思いました。
「作って」しか言ったことがなかった
素人なりに、不要な機能が細かいところに点々としているのはわかっていました。
「このままでいいのかな」とは思っていました。
ただ、どのように頼めばいいかわからなかったのです。
「作って」と言ったことはあっても、「消して」と言ったことはなかったからです。
そんな悩みをAIに聞いてみると、プロの人たちも定期的にメンテナンスを行っているということを知りました。
たとえば「リファクタリング」というのは、動きはそのままで見やすいコードにすることだそうです。
日本語でいうと、冗長な文章を削るような感じでしょうか。
ファイルを分割するという作業もあります。
たとえば、ブログ10記事を同じファイルに書いていたものを、1記事ずつ分けていくようなイメージです。
そうすると「このファイルにはこの記事」と一目でわかるので、特定の記事にエラーが出たときに対応しやすくなります。
多分、そういうことだと思います。
初心者すぎて、メンテナンスなんて一ミリも考えたことがありませんでした。反省しています。
バグを見つけたら「バグメモフォルダ」へ
私はバグがあると聞くと、ものすごく焦ってしまう性格です。
「どうしよう」「どうにかしなくちゃ」と。
ただでさえわからないことだらけの初心者が焦っていたら、正常な判断ができるわけがありません。
以前は、バグを発見すると焦って「全部直して」と言っていました。
バグの内容もよくわかっていないのに、です。
今はいったん「バグメモフォルダ」に入れておいて、後から冷静に振り返って修正するようにしています。
システムが一応動いているのであれば、すぐ直さなくてもいいのです。
今のところシステムエラーは少なく済んでいるので、このやり方でいいんじゃないかと思っています。
この記事のまとめ
Office-Chronosの開発を通じて、メンテナンスについて学んだことをまとめます。
- 「作って」だけでなく「消して」「整理して」もAIに頼める
- リファクタリング=動きはそのままにコードを読みやすくすること
- ファイル分割でどこに何があるか把握しやすくなる
- バグを見つけたらすぐ直さなくていい。メモしておいて冷静なときに対処する
- 見やすいコードはミスをしにくいコード