気になる技術的なことについて少しずつ書いていけたらと思っております。2014-03-28【独り言】どのようにして学生が書いた研究のソースコードは『殘念』になるのかどうも、最近サーバ周りを触っているのですが中々面白いですね。はて、今回は少し問題提起と言いますか、ちょっとした自分の意見を言いたいと思います。確認できているのは自分の周りだけの話なのですが、やはり同じような状況になっている人も多いと思うので。今回のテーマは少し技術系の話とは離れて、「どうして学生の研究に使うソースが『殘念』になるのか」という問題についてです。あり、変な事を書いてても生暖かい目で見守って欲しい。この記事を書くに至ったのも、自分が現在の研究で用いていたソースコードがとてつもなく『殘念』なコードになってしまい、リファクタリングを行っている最中である事。研究室内のソースコードに対して、「テストコードをどうして書かないのか!?命名規則がバラバラ!?コメントォォォ!」などという話があった事(ちょっと大げさに書いてる)。聞いてるこちらとしても当てはまる点があり、心にグサグサっと刺さったので、原因について冷静に考察し、記事を書こうと思った。そもそも『殘念』の定義とは一概には言えないが、ここでは思いつく限りのことを書いていく。モジュール結合度が高く、モジュール強度が低い*1分かりづらいバグを埋め込んでいる変数名が分かりづらい、命名規則もバラバラコメントがないソースコードを見ているとため息をする頭が痛くなるイライラする手が震える気分が落ち込むYoutube/ニコニコ動画を見たい衝動に駆られる悲鳴/奇声を上げる家に帰りたくなる深夜テンションになるこのような症状が起きる場合は上記の定義を持ったソースコードである可能性が高い*2『殘念』になってしまう理由まずは自分の中で考えられる要因について列挙していく。教授から評価されるのは実験結果のみ学生のスキルその他にも色々とあると思いますが、周囲の環境を見て自分の中で挙げられるのはこんな所だと思う。それでは、それぞれの要因に対して少し掘り下げてみる。研究に対するモチベーション日本には多くの理工系大学生がいて、3~4年になる頃には研究室に入り、卒業前に研究の発表を行い、その単位を得てようやく卒業することができる。「研究室に入れ」と言われても半分以上の学生は研究室に対する情報を全く持っていないため、先輩や研究室紹介でしか情報を得る機会がない。*3そして、入ってみたら自分の考えていた研究内容と違ったり、そもそも研究室配属が「卒業するための一つの過程」と考えている場合も多いだろう。なってしまえば、自分から研究をやることもなく、教授から言われたテーマを何と無くこなして卒論発表をして卒業...なんて事になってしまう。そのモチベーションの結果生み出されるソースコードに力を入れることもおそらく無いだろう。大体の研究は、経験や理論による仮説から手法を実装し検証して評価、することを繰り返すのが研究だと自分では思っている。́・ω・`)という場合が普通にある。その場合、その手法を修正するか、全く異なる手法で問題にアプローチするという二択で対応する。前者は大小あるがソースコードの変更、後者ではソースコードを全て破棄。変更・破棄する可能性がある為、ソースコードの書き方が「後からコメントとか機能分割すればいいや」と思い、雑になる。強度や結合度を全く無視し、実装を行うことになる。テストコードを書くということは無い場合がほとんどだろう。*4故に『殘念』になる。新規研究ではライブラリが適用できない研究開発は新規性が必要なので既存の手法でも多少の拡張を行う必要がある。研究開発用のライブラリが適応するのが難しい場合が多い。自分の研究でも画像処理を扱っており、画像処理ライブラリの『OpenCV』を使っているが画像の入出力と画素値の抽出、画像への点・線の描画くらいしか行っていない。研究用ライブラリは『枯れた技術の集合体』であり、新規の研究開発にはあまり寄与できない場合が多い。これによって自分で機能を実装することでソースが膨れあがり、機能分割を怠れば徐々にコードがスパゲッティになっていく。自分の研究テーマを他人と絡めてやることが少ないそもそも研究テーマは最初のうちは一個人で完結してしまう場合も多い。その為、「自分さえわかればいいや、コメントも機能分割も面倒だし」などと雑なコーディングを行ってしまう。他大学、企業との共同研究になり、ソースコードの提出を求められて\(^o^)/となる場合が多い。一年後にその研究が復活することもあったりする。その時の自分は「ソースコードを書いていた自分」とはまったくの別人であり、これも\(^o^)/となる。こんなリスクを認識していない、無視をする事でコーディングが雑になってしまうのはよくあることだ。*5故に『殘念』になる。一、二ヶ月という短期間での研究では機能の細かいモジュール化は手間なので、「とりあえず動けばいいや!」などと思い実装する。そんな綺麗に書いていないコードを何とか拡張しようと、日々騙し騙し実装していくと徐々にソースがスパゲッティになっていく。教授から評価されるのは実験結果のみ自分が個人的に最も感じているのがこれだ。教授などに見せるのはほぼ全て研究結果であり、ソースコードを見たいという発言はあまり耳にしたことがないし、自分は一度もない。全ては研究が上手くいったかどうか、ということを研究結果のみで判断される。度外視したコーディングで最終的に迷惑が掛かるのは、研究を引き継ぐ人、もしくは共同研究者だ。結果的に後継する人が苦労し、研究の発展が遅くなってしまう。妙齢な教授であれば新しい言語のソースコードは読めない場合もあるし、そういった末端の部分は学生に任せている場合もあり、教授から一切評価されない、なんてことはざらにある。ソースコードのリファクタリングに対して時間を取ることは「研究の為に時間を使っている訳ではない」と考えている人もいるのではないだろうか?そのため、雑なコーディングを行ってしまうこともしばしば。学生のスキル自分で言うのはブーメランになってしまうのですが、そもそも学生のコーディングスキルは一部の人を除いてそこまで高くない。コーディングスキルを社会に出て身に付ける人も多いだろう。理工系の学生は多少のコーディングスキルを授業で習うが、プログラミングの好き/嫌い、出来る/出来ない人は個人的な主観だが授業の開始直後に二極化される。嫌いな学生からすれば、今の自分が手がけているソースコードが酷いのかどうか、という状況にそもそも気づけない。出来る学生でも、上記のようなシチュエーションで雑なコーディングを行ってしまい、結果的に酷いソースコードがアウトプットされることもある。そもそも関数化も出来ない学生もいるし、クラスを書けない人もいるし、そういった学生に綺麗なコードを書く、というのがそもそも無理な話だろう。まとめ上記に学生のソースコードが『殘念』になる様々な要因やシチュエーションを上げた。学生ということもあり、自分のアウトプットしたソースコードが評価(もちろん酷評も含めて)されることが少ないからこそ、雑なコーディングを行ってしまうというのが一番の要因だと自分は思う。いっても、ソースコードを評価するのは凄く難しい(コーディングスタイルや考え方の違い、知らない技術に対しての反応の問題)と自分では思うし、それも凄く手間だろう。教授は研究結果の良し悪しも大事だが、ソースコードの良し悪しの重要性も頭の隅に置き、学生は雑なコーディングを行うことで、結果的に誰かの迷惑になる可能性があるということ、丁寧なコーディングを行う事でスキルアップになる、ということを頭の隅に置いて、研究に臨むことで少しは研究のソースコードが綺麗になるだろうと考えている。最後にまとめが雑になってしまって申し訳ございませんでした。文章中ではやや攻撃的な口調になっていますが、そこが気に障ってしまった方はすみませんでした。最後までこのような駄文を読んで頂き、ありがとうございました。最後の最後に実は「残念」となっている文章、もとは『糞』と書いていたのですが攻撃的過ぎたし、気分を害する人もいるので『殘念』という言葉に置き換えました。23:35【独り言】どのようにして学生が書いた研究のソースコードは『殘念』になるのかTweet広告を非表示にする関連記事2017-06-05頑張って作っていたものがミドルウェアのオプションひとつで実現できた話どうも、お久しぶりです。デザインパターン...2014-10-11【デザインパターン】コンパウンドパターン【事前学習編1】どうも、昨日見事にブログを書き忘れていました。2014-09-13インターン生をTAという視点から見て感じたことここ数週間はインターンにTAとして参加していました。一年...2014-08-02【デザインパターン】コンポジットパターン普通に書くの忘れてました。React・Reduxの導入からサーバーサイドレンダリングによるUXの向上まで【書評】現場で役立つシステム設計の原則~変更を楽で安全にするオブジェクト指向の実践技法isucon9予選で赤い彗星になれず予選落ちしました月別アーカイブ参加グループ焼き肉ブログはてなブログをはじめよう!dorivenさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。