5年くらい前に書いたVBAのプログラミングを現在の形に合わせて直すことがありました。
当時もある程度わかりやすくつくろうとした結果のプログラミング。
メンテナンスはしやすかったですが、もう一歩と感じるところもところどころありました。
そうやって、過去の自分を見返すことで、未来の自分のわかりやすいかが大切だと改めて感じます。
昔書いたプログラムの修正
プログラミングの修正において今回気になった点は
- 変数の名称
- プログラムの基本構造の明示
- 細かなセル指定の意味の明示
の辺りです。
まずは、変数。
変数の名称はある程度の役割でルールを決めているので、変数名を見ることで何のための変数かはわかるようにしています。
それでも、プログラムが複雑になると、構造を後付することも出てきます。
個々の変数の意味合いはわかっても、変数同士の関係性がはっきりしないところがあるなぁと。
数個の変数を一度の使って処理するべき点に関して、変数同士の関係性をもう少し明示できるようにするとメンテナンスがしやすいだろうなと感じました。
次に、プログラムの基本構造を最初に明示しておくと良かったと感じました。
自分で書いたプログラムなので、そのままガンガンと修正できるかと思いきや、かなり前につくったものなので、構造を頭に入れることから時間がかかりました。
何のためのプログラムなのか、どこからRawデータを持ってきているのか、どういった加工をしているのか、などなど明示しておくと、その後のメンテナンス性を上げられます。
3つ目に、セルに対しての細かい指示の意味合いをもう少しコメントしておくと修正しやすいです。
VBA自体は他の人が見てもいいようにと考えてつくっていました。
その分、余計なコメントは避けていたのですが、その避けたコメントをもう少しだけ記載しておく方が、プログラム全体の関係性が見えやすかったです。
昔書いたプログラムを修正するのは、とても面倒です。
やり終わったしごとをもう一度見返す感じなので。
でも、昔の自分の考え方との対話ができるので、新しい発見につなげることができます。
他の人に対してシンプルを目指す
将来の自分は、今の自分とは別物です。
そこに対して、シンプルでわかりやすいものをつくることは、プログラミングに限らず重要なことです。
引き継ぎをする場合にも、手順だけではなく、なんのためにその処理をしているのか、全体としての問題は何なのかを指摘しておけると、しごとの質が上がりますよね。
引き継ぎを受けた際に、手順ばかりにこだわって対局として何がしたかったのかよくわかっていない担当者というのを感じるのと似ています。
今の論点や問題点がなにかを明示することや、細かな部分について補足してあげるのは、意外と大切です。
時間を置くとわかるシンプルさ
つくったときには、問題点は明確です。
そのときの喫緊の必要性があるからこそ、そのプログラムをつくっています。
でも、時間が空けばそこに存在した意味や問題点が薄れていきます。
どこに問題があってそのことをしていたかという、基本前提を示さないと、プログラミングにおける行動の意味合いがわかりにくくなるものです。
時間があけば、どこを厚く示すべきか、シンプルに伝えるべきかが見えてきます。
「他の人へ」という点がわかりにくければ、少なくとも未来の自分に送るといいです。
未来の自分に送る練習は、過去において文章などをつくる、それを見返す機会をつくるというセットでしょう。
時間を置いたことでシンプルさをどこにおいておくと一番いいのか、見えてくることがあります。
億劫かもしれませんが、つくったプログラムをたまに見返すのはこういった勉強になります。
気になった方は、過去につくったものを少し見返すといいですね。