未踏作業日誌――余計なもの作るよ!

未踏の作業日誌的なものを書きましょうということで書くことにしました.余計なことばっかりしています.

プログラミングの思考プロセス

はじめに

プログラミングって,できる人はジャラジャラ書くんでしょ? という誤解がある.いや,本当にできる人は設計とかアルゴリズムとか考えずにジャラジャラコードが吐き出されるんだけれども,あいにく常時パチンコの大当たり状態ではない.コードを書き始めるのに,どうしても準備が必要になる.

自分は書き始める前にどんな条件が揃わないと書けないのかな,と考えてみたので記録してみる.

おおまかにプログラムを書く前の思考は以下の通りになると思う.

設計

どのようなクラス設計にするか考えてないと書けない.どのようなパターンで組み立てるか,どこに処理を委譲させるか,疎結合になっているか,そんなことを考えながら作る物を設計に置き換えていく.

自販機なら,ジュース管理モジュール,金額管理モジュールがあって,それぞれなになにがあるよね,などなど.

いきなり書き始めることもできるけれども,神クラスが出来上がっていて困ることがたまにある.良い神クラスは後で抽象化することもできるけれども,悪い神クラスは手のつけようのないほど酷い.

命名

クラスの名前や変数の名前は大事.クラスや関数,変数などなどが何のために存在しているのか,説明するために必要.説明がちゃんとしていれば,読んだ時に何をしているのか理解できる.

この名前を思いつくための頭のプロセスが起動していないと,名前を考えるだけで時間を食べてしまう.

かと言って,a,b,c,hogehoge,puyopuyoとか,一時変数を多用するのはよろしくない.難しい処理をしている時ほど,意味不明なコードになりやすいので困る.

名前とかどうでもいいし!って思ってる人もいるかもしれない.だがしかし,Func01232(int arg0, float arg1, float arg2)という関数があったらどうだろう? 人類史上最も頭の悪い命名規則だと思うけれども,こんなのが至るところに存在してたらだいたいの人が発狂するんじゃないかなって思う.コードの名前をかんがえるって本当に大切.

 プログラマは黙ってこれを手元において繰り返し読もう.

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 

 

アルゴリズム

アルゴリズムというよりも,実装する内容なんだろうか.処理の流れもそうだし,計算もそうだし,データ構造の持ち方からどのような結果を出力するかということもそうだし.

これが思いついていないと書けない.書くものがないのに書くことはできない.誰かからコレ作って,って言われて仕様が渡されれば作れるかもしれない.処理の流れを整理して,何かしら作るものを決まっていないと,書き始めることができない.

そもそも作るものが決まってないのに作れるんか? と言うと,作れることもある.動的計画法で目的の結果を得るまでちょろちょろと繰り返すこともある.ただ,これもやっぱり集中してやっていないと,いつまで経っても同じことを繰り返したりする.

体調やタイミングなど

体調が悪いと品質の低いコードがじゃんじゃん生成される.なにか考えてるんだろうけど,平常時と比べて思考力が落ちているので,意味のわからないコードを作ってしまいがち.こればかりはどうしようもない.

イライラしている時は書けない.感情的になっていると思考が邪魔されて何も思いつかない.横で怒鳴られながら品質落とさずにコード書ける人がいたら天才だと思う.心理的に落ち着いた状況でないと,for文1行記述するのにも苦労する.

タイミングももちろん重要だったりする.集中できるタイミングとできないタイミングがある.1秒間で集中状態になれる人はそんなにいないと思う.陸上選手だったらトラックに入らないと集中できないだろうし,トラックに入ってよ~いする手前で上司からメールが来ました! 稟議書の助詞の使い方が間違っているから今すぐワードで修正して送ってドン! で平均的な記録を出せる陸上選手がいたらすごいと思う.

メールなどで集中は簡単に途切れる.ご飯のタイミングでも集中は途切れる.

メールが届くとメールを書くために集中しなければならない.別の集中が必要になるから疲れる.メール書いてるだけで1日が終わったりすることもある.

結局のところどうなんだろう

どれか少し欠けていてもできるかもしれないけど,品質は落ちるよなぁ.集中してないのにコード書いたって,なんか変なのしか出来ない時もあるし,めっちゃ集中できても設計できてない段階だと神クラスができるし.体調✕設計✕命名✕アルゴリズム✕タイミング=集中力なんだろうか.とにかく集中できないといいコードを生み出せない.集中してなくても簡単にすごいプロダクトを生み出せるならそんなに苦労しないんだろうけど,そのレベルに到達すると人間性を何段階も捨てている気がする.ガルパン見ながらLinuxのハードディスクアクセスのカーネルコードの最適化しますとか,そんな人がいたらめっちゃヤバイし,頭おかしいと思う.授業の前日に教材のノベルゲームエンジン作りましたって先生もいた.新卒の研修で,スマホで3~4体同時に3Dキャラをレンダリングできるようにしましたとか.集中力が尋常じゃないだろうし,そこへ至るまでの経験も尋常じゃない.集中力はやっぱり大事なんだろうけれども,安定して集中力を維持することが難しい.楽器とか,ゲームとか,漫画とか,映画とか,好きなことがたくさんあるので,俗世から魂を解放しないと,集中できないんだろうか.かと言って,集中し過ぎると健康によくない.

ここ最近の進捗

あとは実験をまとめれば,博論を書けるベースにはなると思う.問題は論文だ.適当な論文を書いてacceptされるなら,それが今までどおりのやり方だから一番楽なんだろうけれども,査読者に誤解を与えるとそのままノリと勢いでrejectされるのでつらい.

せっかく頑張って書いても,文章のミスなり図が変だとか,書いてある内容がよくわからないって理由で,3ヶ月ぐらい水の泡になったりするのが研究.でも,品質を担保するにはそれぐらい厳重にやらないといけないのは確かで,そのセオリーに則ってそれなりの論文を書く必要がある.

なので,特集号などにたくさん出すよりも,質の高い研究をアピールすることで,推薦論文を貰って確実にacceptされる方針に切り替えることにした.

自分の研究に自信があるといえども,くだらない理由でrejectされる可能性は残る.「理解できないなら頭からちゃんと読み直せ」とかacceptの権限を持っている査読者に言えないわけである.「だったら理解できるような論文を書け」とか返されるのがオチだろう.

それなら,よほどのことがない限りrejectされないように,推薦論文を貰って条件付採録の可能性を上げて,acceptを貰ったあとに査読者視点のミスを減らしていったほうが確実性が高い.

もちろん,研究会で質の高い論文を書かなきゃならないけれども,rejectされるよりかは何倍もいいと思う.rejectされるのは時間の無駄なので,採択率100%になるように工夫しなきゃならない.

そういうわけで,しばらく論文を書きっぱなしの時期が続きそうな感じがする.なんか,修士の1~2年の時の再来のような感じもするけど,卒業できるように頑張るしかない.良い研究は自分でやるので良い論文を書いてくれる秘書がいたら雇いたい.