「programing」カテゴリーアーカイブ

明日の自分を信じよう

プログラミングの際に、たまに自分自身に言い聞かせている言葉。使われなくなったコードを消すかどうか迷ったとき、残しておこうという気持ちを取り払おうとして、「サクッと早く消せよ」と、無駄な時間を費やしている自分に対して言う。

今使われなくなったコードが将来の要件にあっている可能性は低い。将来の自分がその時点で、この程度のプログラムはゼロから書ける、と信じよう。同じような要件であれば、2度めに新しく考え出したコードのほうが質が良いはずだし。要件が微妙に違う場合はアジャストしなくてはならないし。プログラムというのは要件が確定した時点から考え始めればよいのだ。

せっかくできた今のコードがスーパーだとか、将来同じような複雑なプログラミングがかけるのか疑問とか、捨てるのがもったいないからパラメータを調整してより汎用的な形にして残そうかとか、思うことはすべて無駄。

いつも自分に言い聞かせているのだが。。。

削除する手間もかかるので、気づいたその場で消せばいいのに。その手間を惜しんだ結果、残ってしまって産業廃棄物化しているコードもある。忘れてしまったあとで消そうとすると、またコードを追ってしまう羽目に陥る。時間が過ぎていく。

いつもやっていればプログラミング能力はアップしていく、はず。そうなったら今スーパーなコードは将来の自分には幼稚に見えるだろう。もしプログラミングをやらなくなったら、プログラミング能力は衰えていくだろう。そのときスーパーなコードは理解不可能なコードになる。産業廃棄物となって再利用などできるはずもない。

とはいえ、削除するタイミングは難しい。書いた時点ではしっかり理解しているため、産業廃棄物ではなく財産のように見える。明日以降に理解度が下がっている自分を想像できないのだ。

リファクタリング、ループの話

前回、リファクタリングのことを書いていたらいくつか書き留めておきたくなった。今回はループの話。

コードを組み立てていく時、最初からループがうまく回る保証はない。だからコーディング中はfor文に繰り返す回数を与えて、その数をデバッガーで見たり、アラートやログ出力して確認することになる。たとえば次のようなコードでは$sizeOfAryに何が入っているか、プログラマなら興味があるだろう。

//code A	xxxは配列
C_LONGINT($i;$sizeOfAry)
$sizeOfAry:=size of array(xxx)
for ($i;1;$sizeOfAry)
	...
end for

昔やっていたのが、上のように書いて動作検証した後で、次のようにリファクタリングすることだった。

//code B
C_LONGINT($i)
for ($i;1;size of array(xxx))
	...
end for

これでコードが一行減って、ローカル変数が１つ減って、読みやすくなった、と思ってた時期があった。散らかってたのを片付けました、、下書きを清書しました、という感覚。

．．．？　多分、そうじゃないよね。

何らかの不具合が原因でこのコードを「後で」見ることになった場合、実行環境が変わったり、データの仕様が変わったり、未配慮の状況に遭遇しているかもしれない。そのとき最初に見たいのはfor文が想定通りに回っているかではないだろうか。つまり元のコードの$sizeOfAryに何が入っているか、だ。それで値の中身を見るためにcode Bにコードを追加したりして、つまりはcode Aに近い形に修正し直す、ことになる。

あーあ、最初からcode Aの状態にしておいてくれればよかったのに。ってね。

回数をアラートに表示するとか、繰り返す内容をログ出力したり、$sizeOfAryに小さな値を代入して少ないループでテストするとか、ローカル変数に取得しておくとデバッグ時に都合が良い。だからデバッグしやすい「code Aのまま」にしておくことはそれほどコストはかからないし合理的と言えるのではないか。えっ、「コードが長くなって、あちこちでこのように書いてたら全体ではコード量が馬鹿にならない」って？

だから「やっていることの分だけコードはあるのだ」の原則を思い出そう。

ループの回数、と言う重要なファクターを我々は設計し、実装した経緯があるのに、リファクタリングによってその経緯がわからなくなる。短い方が可読性にプラスという思い込みのために、コードの品質を落としていないだろうか。「コードは道具」という側面があるので、清書して使いにくくするものではなく、使いやすい状態にしておくほうがいいと思う。

続きはまた後ほど。

やってることの分だけコードがある、のはフツーのこと。

「WEB+DB PRESS vol.127」（以下、wdp127）にリファクタリングの話があったので読んでみたら良かった。

https://gihyo.jp/magazine/wdpress/archive/2022/vol127

知らない単語が出てきたのでメモしておく。

□ 凝集度（cohesion）
□ 結合度（coupling）

調べてみると、語源は1979年あたりにヨードンが提唱していたらしい。

□ DRY（Don’t Repeat Yourself）

コードの最適化、なんでもDRYというルールがあるそうだ。

プログラミングしていると、同じようなコードを何度も書くとき、共通化できるのでは？と考える。あちこちに書いておくと、あとでそこに修正が生じた場合にあちこち直さなくてはならないため不便だし、処理が同じならモジュール化すべきだという考えだ。

wdp127では凝集度について、論理的凝集は避ける、ようなことが書いてある。要はフラグを使った関数内分岐を避けよ、という意味と理解した。ウチでは同じような意味で「多機能関数はダメ」というルールがある。

結合度については値は引数で渡す、ようなことが書いてある。要はグローバル変数は避けよ、という意味と理解した。ウチでは「関数の中はローカル変数だけを使う」と「グローバル的な変数にはゲッターセッターを用意して関数を介して取得する」というルールがある。ただし例外として、画面に一覧を表示する際のフォームオブジェクトはグローバル参照をしていいというルールもある。画面に表示する情報についてゲッターセッターをすべて用意するのはあまりにも面倒だ。フォームオブジェクトは名前付のルールでわかるようにしている。

ウチでは上記のほかに、

・モジュール内の構造は原則２つまで

forやifの構造が３つ以上出現する場合は、さらなるモジュール化を検討せよ、という意味だ。

・処理の分だけコードはある

仕様がケース分岐しているのであればコードも分岐している、のがフツーだ。入り口から分岐させて、中に共通処理を見つけたら共通モジュール化する、のが良い。

・デバッグしやすいコード

できるだけ１行で書く、というコードはダメ。if文の中に関数を記述したり、引数に関数を記述するのはわかりやすいNGだ。デバッグする時にたとえばforループが何回回るのかは重要な要素だ。上手くいかないときは0回の場合が多い。これをデバッグするには繰り返し回数を見れば良いのだが、大体はなんかの関数の戻り値である。これをfor($i;1;myFunc())のように書いてしまうとmyFunc()の戻り値を見たくなる。$count:=myFunc()とか記述して$countの値を見ることになる。それなら最初からそういうコードにしておけば良い。

・プログラマに必要な機能はおそらくユーザにも必要

上記はソース内部の記述だが、表面的な仕様でもデバッグに便利な機能を実装しよう。あるテーブルの中身が見たいような機能は言われなくても作ってしまう。デバッグでよく使うツールであればプログラマは便利になる。そのままリリースして、ユーザに「削除して」と言われてから「隠す」ようにすればよい。

まだ語り尽くせないので、また思いついたら続きを書く。。。

波乗りと仕事

20220224 波乗りと仕事

祝日、昼１ラウンド、夕方１ラウンド入水。上がってすぐにプログラミング始めたら入りが良くて、長持ちした。集中があってフロー状態。特に夕方のあとは冴えてた、風呂に入ったからかもしれない。

目の前のコードに目を向けると、単純に読み始めて理解しようとしてしまうようだ。かなりいい状態。

海から上がったら、すぐにコーディングに入るといいかも。

ゲーム時間が少なくて済んだように思う。

4D v18からはストラクチャーではなく「プロジェクト」

これまで4Dでのアプリ開発はストラクチャーファイル（.4db）を作ることだった。ストラクチャーファイルはバイナリファイルだ。4Dで開けば中身を見ることができるが、外部からは何が書いてあるのかわからない。このためgitのようなバージョン管理システムでソースの差分を管理することができなかった。

4D v18から「プロジェクトモード」という形で保存できるようになった。プロジェクトモードではフォームもメソッドも「Sources」というフォルダにテキストファイルで保存されている。これらのテキストファイルをテキストエディタで修正すると、変更内容が4Dのフォームエディタやメソッドエディタに表示される。外部からテキストファイルを修正すると「ストラクチャー」に変更内容が適用されるのだ。

従来からあるストラクチャーもサポートされていて、従来通りの開発方法を選んでソースをバイナリ形式で保存することもできる。こちらは「バイナリモード」と呼ぶ。新規プロジェクトを始めるとき、開発者はバイナリモードかプロジェクトモードのどちらかを選ぶことになる。バイナリモードには「プロジェクトに書き出し」を実行してプロジェクトモードに書き出すことができる。v17以前のプロジェクトはこの方法でプロジェクトモードに移行する。プロジェクトモードからバイナリモードに変換することはできない。

筆者がプロジェクトを推奨する理由はいくつかある。

１）メソッドを生成したい

２）フォームを生成したい

３）gitを使って修正箇所（差分）を知りたい

これまで１）はプロジェクトメソッドであればやっていた。JCL4D（当社ライブラリ）を使えばテーブル定義のテキストファイルからプロジェクトメソッドを生成できる。ただしオブジェクトメソッドやフォームメソッドを生成することはできなかった。熱望していた２）はほぼほぼ実現は無理、３）もあきらめていた。

2014年にパリで開催された4D Developer Summitでに参加した際に、「フォームジェネレータを作りたい、使えるコマンドはないか」と質問した時は、そのようなコマンドの実装計画はない、と回答された。2020年のv18でフォームは生成できるようになった。対応が早いことに驚く。

以下、バイナリモードを使ってみたところ、いくつか注意事項があったのでメモしておく。

□ 標準入出力フォームを生成する機能がない

ウィザードを使ったフォーム生成機能がない。ユーザモードを使ってデータを確認するときは不便だろう。もともとフォームを自動生成する仕組みを作るつもりだったので、まあいいかという感想。半年くらいかけてJCL4DにFormGeneratorを作成した。これを使えばフィールド定義ファイルからテーブルを生成、続けてメソッドとフォームを自動生成することができる。

□ スタイルシートが開発モードでは確認しづらい

実行モードでは適用される。設定がうまくできているか確認しづらいので注意。

□ 外部テキストファイルを修正した場合、アプリに反映するのに少し時間がかかる

Finder/Desktop上でファイルの入っているフォルダを表示すれば変更が適用されたりする。

□ リモートの4D Server上のソースやフォームを4D Clientで接続して編集することができない

ソースはテキストファイルなので、開発者が各自手元で修正してアップしてcommitすることになる。

これ以外にも注意点や制約がありそうだが、気付いた時点でまたブログを追加する。