【独り言】どのようにして学生が書いた研究のソースコードは『殘念』になるのか
どうも、最近サーバ周りを触っているのですが中々面白いですね。
さてはて、今回は少し問題提起と言いますか、ちょっとした自分の意見を言いたいと思います。
あくまで確認できているのは自分の周りだけの話なのですが、やはり同じような状況になっている人も多いと思うので。今回のテーマは少し技術系の話とは離れて、「どうして学生の研究に使うソースが『殘念』になるのか」という問題についてです。
読む前に
筆者は別に名のある騎士でも、高名なプログラマーでも、ましてや神でもない、ただの一般理工系修士大学生であり、変な事を書いてても生暖かい目で見守って欲しい。
この記事を書くに至ったのも、自分が現在の研究で用いていたソースコードがとてつもなく『殘念』なコードになってしまい、リファクタリングを行っている最中である事。
研究室内のソースコードに対して、「テストコードをどうして書かないのか！？命名規則がバラバラ！？コメントォォォ！」などという話があった事（ちょっと大げさに書いてる）。
聞いてるこちらとしても当てはまる点があり、心にグサグサっと刺さったので、原因について冷静に考察し、記事を書こうと思った。
『殘念』になってしまう理由
まずは自分の中で考えられる要因について列挙していく。
- 研究に対するモチベーション
- 機能が確定していない事による手探りでの開発
- 新規研究ではライブラリが適用できない
- 自分の研究テーマを他人と絡めてやることが少ない
- 予想していなかった研究期間の延長
- 教授から評価されるのは実験結果のみ
- 学生のスキル
その他にも色々とあると思いますが、周囲の環境を見て自分の中で挙げられるのはこんな所だと思う。
それでは、それぞれの要因に対して少し掘り下げてみる。
研究に対するモチベーション
日本には多くの理工系大学生がいて、3～4年になる頃には研究室に入り、卒業前に研究の発表を行い、その単位を得てようやく卒業することができる。だが、いきなり「研究室に入れ」と言われても半分以上の学生は研究室に対する情報を全く持っていないため、先輩や研究室紹介でしか情報を得る機会がない。*3
そして、入ってみたら自分の考えていた研究内容と違ったり、そもそも研究室配属が「卒業するための一つの過程」と考えている場合も多いだろう。
そうなってしまえば、自分から研究をやることもなく、教授から言われたテーマを何と無くこなして卒論発表をして卒業…なんて事になってしまう。
そのモチベーションの結果生み出されるソースコードに力を入れることもおそらく無いだろう。
故に『殘念』になる。
機能が確定していない事による手探りでの開発
大体の研究は、経験や理論による仮説から手法を実装し検証して評価、することを繰り返すのが研究だと自分では思っている。
その為、教授や自分の考えた手法を実装しても上手く動かなかった(´・ω・`)という場合が普通にある。
その場合、その手法を修正するか、全く異なる手法で問題にアプローチするという二択で対応する。
前者は大小あるがソースコードの変更、後者ではソースコードを全て破棄。
変更・破棄する可能性がある為、ソースコードの書き方が「後からコメントとか機能分割すればいいや」と思い、雑になる。
つまり、強度や結合度を全く無視し、実装を行うことになる。
そして、テストコードを書くということは無い場合がほとんどだろう。*4
故に『殘念』になる。
新規研究ではライブラリが適用できない
研究開発は新規性が必要なので既存の手法でも多少の拡張を行う必要がある。
つまりは、研究開発用のライブラリが適応するのが難しい場合が多い。
自分の研究でも画像処理を扱っており、画像処理ライブラリの『OpenCV』を使っているが画像の入出力と画素値の抽出、画像への点・線の描画くらいしか行っていない。
研究用ライブラリは『枯れた技術の集合体』であり、新規の研究開発にはあまり寄与できない場合が多い。
これによって自分で機能を実装することでソースが膨れあがり、機能分割を怠れば徐々にコードがスパゲッティになっていく。
故に『殘念』になる。
自分の研究テーマを他人と絡めてやることが少ない
そもそも研究テーマは最初のうちは一個人で完結してしまう場合も多い。
その為、「自分さえわかればいいや、コメントも機能分割も面倒だし」などと雑なコーディングを行ってしまう。
この場合でよくあるパターンが、ある程度の研究進捗を見せると研究室内、同大学内や他大学、企業との共同研究になり、ソースコードの提出を求められて＼(^o^)／となる場合が多い。
また、一年後にその研究が復活することもあったりする。もちろん、その時の自分は「ソースコードを書いていた自分」とはまったくの別人であり、これも＼(^o^)／となる。
しかし、こんなリスクを認識していない、無視をする事でコーディングが雑になってしまうのはよくあることだ 。*5
故に『殘念』になる。
予想していなかった研究期間の延長
一、二ヶ月という短期間での研究では機能の細かいモジュール化は手間なので、「とりあえず動けばいいや！」などと思い実装する。
そして、研究の進捗発表をしてしばらくすると、「やっぱりあの研究面白ろそうだから続けてみない？」と死の宣告を教授から受けて、( ﾟдﾟ )となる場合がある。
そんな綺麗に書いていないコードを何とか拡張しようと、日々騙し騙し実装していくと徐々にソースがスパゲッティになっていく。
故に『殘念』になる。
教授から評価されるのは実験結果のみ
自分が個人的に最も感じているのがこれだ。
教授などに見せるのはほぼ全て研究結果であり、ソースコードを見たいという発言はあまり耳にしたことがないし、自分は一度もない。
全ては研究が上手くいったかどうか、ということを研究結果のみで判断される。
たしかにプログラミングは手段であり、最終的な結果が重要であることは重々承知してはいるが、ソースコードの可読性・保守性・拡張性を度外視したコーディングで最終的に迷惑が掛かるのは、研究を引き継ぐ人、もしくは共同研究者だ。
結果的に後継する人が苦労し、研究の発展が遅くなってしまう。
しかし、妙齢な教授であれば新しい言語のソースコードは読めない場合もあるし、そういった末端の部分は学生に任せている場合もあり、教授から一切評価されない、なんてことはざらにある。
また、ソースコードのリファクタリングに対して時間を取ることは「研究の為に時間を使っている訳ではない」と考えている人もいるのではないだろうか？
そのため、雑なコーディングを行ってしまうこともしばしば。
故に『殘念』になる。
学生のスキル
自分で言うのはブーメランになってしまうのですが、そもそも学生のコーディングスキルは一部の人を除いてそこまで高くない。
コーディングスキルを社会に出て身に付ける人も多いだろう。
もちろん理工系の学生は多少のコーディングスキルを授業で習うが、プログラミングの好き/嫌い、出来る/出来ない人は個人的な主観だが授業の開始直後に二極化される。
嫌いな学生からすれば、今の自分が手がけているソースコードが酷いのかどうか、という状況にそもそも気づけない。
出来る学生でも、上記のようなシチュエーションで雑なコーディングを行ってしまい、結果的に酷いソースコードがアウトプットされることもある。
そもそも関数化も出来ない学生もいるし、クラスを書けない人もいるし、そういった学生に綺麗なコードを書く、というのがそもそも無理な話だろう。
故に『殘念』になる。
まとめ
上記に学生のソースコードが『殘念』になる様々な要因やシチュエーションを上げた。
やはり学生ということもあり、自分のアウトプットしたソースコードが評価（もちろん酷評も含めて）されることが少ないからこそ、雑なコーディングを行ってしまうというのが一番の要因だと自分は思う。
といっても、ソースコードを評価するのは凄く難しい（コーディングスタイルや考え方の違い、知らない技術に対しての反応の問題）と自分では思うし、それも凄く手間だろう。
教授は研究結果の良し悪しも大事だが、ソースコードの良し悪しの重要性も頭の隅に置き、学生は雑なコーディングを行うことで、結果的に誰かの迷惑になる可能性があるということ、丁寧なコーディングを行う事でスキルアップになる、ということを頭の隅に置いて、研究に臨むことで少しは研究のソースコードが綺麗になるだろうと考えている。
最後に
まとめが雑になってしまって申し訳ございませんでした。
文章中ではやや攻撃的な口調になっていますが、そこが気に障ってしまった方はすみませんでした。
最後までこのような駄文を読んで頂き、ありがとうございました。
最後の最後に
実は「残念」となっている文章、もとは『糞』と書いていたのですが攻撃的過ぎたし、気分を害する人もいるので『殘念』という言葉に置き換えました。
