  |
はてなキーワード: サブルーチンとは
一文一文を訳す精度は上がった。
つまり日本人特有の婉曲的な話の進め方を逐語訳してしまったり、説明が先で結論が最後でもそれをそのまま翻訳してしまったりしている。
なので簡単なやりとりならもはや機械翻訳に頼ってもネイティブも相手の英語に違和感を持たないレベルまで来ているかもしれないが、
この増田で行われるようなそれなりにまとまった文章による主張のやり取りではいまだ「ああ、日本人のカタコト英語だな」と思われるような翻訳精度だと思う。
文章全体の意味を理解したうえで、それを英語圏の人ならどういうか、文章を再構成(文章→意味→文章への変換)する機能を翻訳ソフトのサブルーチンとして進歩させる必要があると思う。
1. プログラムの夢 - Wataru's Dream of Code
2. ループの迷宮 - Labyrinth of Loops
3. 変数の秘密 - Secrets of the Variables
4. 条件分岐の試練 - Trials of the If-Else
5. デバッグの夜明け - Dawn of Debugging
6. サブルーチンの冒険 - Adventures in Subroutines
7. レガシーコードの呪い - Curse of the Legacy Code
8. リファクタリングの旅 - Journey of Refactoring
9. アルゴリズムの競演 - Symphony of Algorithms
10. クラウドの彼方に - Beyond the Clouds
複数の機能で成り立っている長いコードを分割して実装することののメリット/デメリットを教えてほしいです。
「コードの分割」が指してることを大まかに言うと、「メインの関数は各機能を呼び出すだけで、実際の機能の部分はサブルーチンとしての関数(って表現が正確かも謎)に持たせ、サブルーチンを順次呼び出すことで総体としての機能を成す」ような方式にするってことです。
より具体的に言うと、1.データの取り込み2.取り込んだデータの突合3.帳票の出力の3手順を別々の関数とし、メインの関数から1,2,3の手順の関数を順次呼び出すという具合です。
上記の方法と、全ての機能を詰め込んだ一つの長い関数にする方法と、どちらが結局よかったのかなと思っているんですね。
今のところ私は自分のわかりやすさのためにコードを分割する書き方をしています。理由は、1機能1関数で分けておいた方がステップインじゃないですけど「ここまでは完走できた」の切り分けがしやすいのかなーと思うのが一つ。もう一つは単純に上下に長くなっていくとどの変数がどれでと特定していくのが辛いってのがあるためです。
ただこの方法にも問題があると思っていて、一番はメイン/サブ関数間で右往左往するので今やってる工程が何なのかがよくわからん、他人が読むならなおのこと、ってことです。一応の対処として、メインの関数は目次的に「総体としてこのような機能を持っている、また分割した関数の機能はそれぞれこうである」とコメントアウトし、サブの関数にも「この関数はここからここまでの作業をします」とコメントアウトすることにしています。
あとは関数ごとに変数をいちいち定義し直すのがだるいみたいなのもありますね。グローバル変数は後々の修正とかのために使わないようにしています。
自分では思いつけてない部分でコード分割することのやばみってあるのかなーと思ったので質問させていただきました。近々退職する予定なので、他人への引継ぎって観点からどうなのかなと思っています。
以下自分語りです。語彙とか概念のインストールが足りないと適切な調べ方ができなくて困るんですねー。あと問題があることを認識できなかったり効率悪かったり車輪を再発明したりとか。
私は無学のバイトなんですが、あるとき上長から「暇なら適当にエクセルでも勉強しといて」と漠然と言われて、このVBAっちゅうもんを学べばええんか？と勘違いしたのが始まりでした。本当はセルの結合とか別のセルを参照するとか、エクセル方眼紙的なものをある程度作れるようになってほしかったらしいです。折角なのでなんとか役に立つものをと思って、ある集計作業を自動化させたところ、今後も暇なときはよろしくということになりました。
いろんなものを作りましたが何をどのように作るかから、その後の運用保守までほぼ一任してもらって大変面白かったです。しかしなにぶん仕様や実装方法について相談できる方がおらず全ては私の泥縄式学習術によって成り立っているという恐ろしい状態でした。体系的な知識や組織の経験知みたいなものが一切ないので自分がどこにいるのか、努力の方向性が合ってるのかも結果が出るまでわからない。先達のあらまほしきことなり。
この議論には相互性がない。あなたと同じように、相手のほうも相手でメインルーチンを走らせており、時にあなたを含む他者をサブルーチン的に利用しているのだから。
つまり、あなた側の視点だけで関わり合いのある他者を機能的に命名してしまうと、あなたというドメイン内での局所的な命名のような命名が、同時に動作しているメインルーチン数だけ存在することになり、命名管理のコストが爆発する（というか、事実上、できない）。他者（あなたにとってのサブルーチン）が、あなたが定めた局所的な命名規則によって呼び出されることを保証できないのなら、それはプログラム的な意味での「呼び出し名」として成立していない。
よって、一意性がある命名を用いて、どのようなドメインからでもおおむね目的のサブルーチンの呼び出しを可能にしていることには、合理性がある。増田のような視点で言えば、会社の役職である「総務課長」や「営業主任」などは、相手が司る機能性に着目した命名とも言えるが、そうした役職は同時に複数存在しうるので、個別のインスタンスを指定して呼び出すには、やはり一意性がある命名を利用することが合理的だ。
また、他者の「機能」は自分との関係で変化する。機能が変わるごとにサブルーチンとしての他者の呼び方を変更することは、両者がドメイン（たとえば家庭）を共有している場合は低コストで可能だが（たとえば子供ができたあとに互いを「パパ・ママ」呼びするなど）、そうでない場合は、機能が変わるたびに命名を変えるのは、メインルーチン側から見ても合理的でない。
人間が他者との相互通信のコストを最小化するには、「他者を機能で命名して、変更があった場合は頭の中でテーブルを書き換える」より、「お互いにユニークに定められたマシン名を直接叩く」ほうがよいのだ。
他人のことを「経理の人」「困ったときに頼る人」みたいに認識してしまうため、他人の名前が覚えられなくて困っている。
（職場では、相手の首にかかる職員証を視線動かさずに見ることで、何とか対応してる。）
というか、そもそも論だが、なんで他人には、私が把握する概念（or機能）に即した名称が付いていないのだろう。
例えば、あの「○○さん」は、本当の名前が「経理の人」だったら、私が個体を認識するのに、なんて便利なことだろう。
まあ、そんなことが無いのは当たり前だとわかってはいるんだが。
しかし、そんな（私にとって）機能的でない名前なんて辞めればいいのに、改名すればいいのに、
と、毎日親切にしてもらったりしながらも、心の中ではこっそり腹立だしく思ってたりする。
だって、自分の中のプロトコルとして、他人だってプログラムのように、概念や機能が認識できるような名称であった方がいい。
他人なんて、私自身というメインルーチンに対するサブルーチンであって、概念や機能を把握しやすい名称が付いていた方が私にはわかりやすい。
私にとって異質な名称（＝その人本来の名前）だと、いちいちその他人というサブルーチンの機能を確認しないと、
このサブルーチンって何だっけ？どれを使えばいいんだっけ？となって時間がかかる。
つまりは、私にとっては「経理の人」という機能のサブルーチンなのに、
なんで、「○○さん」とかいう意味不明なルーチン名になってるの？みたいな感じの謎を毎日感じてしまっている。
そう、他人の名前というのはまさにプログラム内の名称と同じなのだ。
他人の名前も、サブルーチンとしての機能的に適切な名前であるべきなのだ。
サブルーチンのメリットは、そのルーチン内の雑多で長いコードをマスクすることに意義があるのに、
その機能をいちいち確認しないと使えないなんて、まさに本末転倒。
それは、私というメインルーチンを走らせながらも改修する日常の大きな妨げにもなる。
まあ、普通の人は頻出のサブルーチン（＝他人）なら、自然と名前を覚えていくんだろうけどね。
あーあ。私はそれもできないんだよ。
（追記）
うお。なんかトラバ超増えてる。
『からかい上手の高木さん』方式で覚えるしかない
二つ名をつけるといいんじゃない
「稟議のヤマダ」
なるほど。これいいね。やってみる。（本当に口に出してしまいそうだけど。）
つまり、あなた側の視点だけで関わり合いのある他者を機能的に命名してしまうと、あなたというドメイン内での局所的な命名のような命名が、同時に動作しているメインルーチン数だけ存在することになり、命名管理のコストが爆発する（というか、事実上、できない）。
それはたしかに。
それなら、メインルーチン（個人）ごとに、局所的命名と本当の人名とのリストを持っておき、
個人的命名を呼べば本当の人名に自動翻訳される機能があればいいのに、とか思った。
（プログラムに直接通信先を書くのを避けて疎結合にする時みたいなイメージ）
あと、機能が変化するごとに名称が変更されるのも、個人的には（呼びたいように呼ぶ感じで）別に構わないんだけど、相手はまあ、普通に戸惑うんだろな。
あとは、トラバにあるカースト制の話とか、ブコメの「ベイカーベイカーパラドックス」っていう言葉とか、知見が増えて嬉しいです。
この世界のあらゆる事象が一つのプログラムで表せたとしたら、そのコードの長さは相当なものになるだろう。
「慣用句」は、人々がそれを理解するために生み出したコード上の工夫のひとつだと思う。
その世界というコードの中で頻出する部分、すなわち、生活で多用される言語を「慣用句」としてネーミングする。
その処理内容はサブルーチンとして別扱いとすることで、メインプログラムは圧縮できる。
サブルーチンを呼び出す際には、その関数名には処理内容を想起させるような象徴的な用語を用いることにした。
まさにそれが、世界というプログラムにおける「慣用句」という象徴的な用語の在り方なんだと思う。
よって、関数名である「慣用句」を、文脈という名の変数とともに呼び出すだけで、
その処理内容を明示しなくても意味のあるアウトプットになるわけだ。
私たちが「慣用句」の処理内容をよく知らなくてもちゃんと使えるのは、慣用句集が一種のルーチン集だからだろう。
知らんけどプログラミングスクールとか専門学校とかプラクティス的な教育が中心なんでしょ？
新卒で現場に放り込まれて、現場に転がってるコードをお手本にして育って、リーダブルコードに書かれてるようなお作法に触れてないプログラマってコードがひどいよね。
まあ「コメントはしっかり書きましょう」程度のことは知ってるけど、方向性がおかしくて、装飾がやたらと多い凝った書式のコメントを書くのに命をかけてたり、情報量ゼロのコメントを大量に書いて満足してるとか、そんなのになりがちだし。
クラスとかも、同じような目的で使うサブルーチンをとにかく全部つっこんで「これ、クラスじゃなくてネームスペースつかうところじゃね？」みたいになってたりするし。
全部のメソッドを catch (Exception e) で括って「絶対に落ちないプロのコード」とか誇らしげだったりするし。
開発言語は基本的にPHPとJavascriptの職場。
別に複雑なコードでもないし、PHPやJSでも、まがりなりにもコードを書いてる人なら見ればわかるでしょって感じなんだけど。
スマホアプリ作るときも、JSならだれでもメンテナンスできるからってmonacaとかいうJSでアプリが開発できるやつを採用したけど、Webとはアーキテクチャが違いすぎるから結局一部の人間にしか触れなくて、そんなマイナーなプラットフォーム採用した意味なかったし。
ちょっとしたツールを作るときも、Windowsアプリとして作ったほうが使い勝手いいから、VB.NETかC#で作ろうって話になってもベテラン勢が猛反対して、無理やりPHPでWebアプリとして作ることになったし。
サーバーで使うシェルスクリプト(.sh)も未経験の俺が、ネットでチョコチョコとググって改修して、すごいびっくりされたことがあるけど、こっちからすればなんであんたらは触れないかっていう感じだし。(黒魔術的な書き方もあるらしいけどもちろんそんな書き方ではない)
Windowsサーバーで使う .BAT ファイルを書くときに、.BATファイルの仕様では黒魔術的なテクニックを使わないと実現できない仕様だったからほかの言語にしませんかって提案したけど、.BATでないとほかの人が保守できないからと却下。
無理に.BATで書いて、逆に変なテクニックを駆使した保守性皆無のコードになってたし。
どの言語を使うかって話題になると、自分の使ってる言語以外を使うとアイデンティティが崩壊するかのような勢いで反対する。
Haskellみたいにまったく思想の違う言語ならともかく、似たような言語で、かつifとループと配列とサブルーチンの概念を把握していたら理解できるような書き方しかしてないコードでも、普段使ってない言語って時点で理解不能に陥るんだよな。
全体的に「解説」というよりは「注意事項」を重視してるっぽいですね。
「この注意事項をみんなに伝えなければならない」という使命感を感じます。
「関数さえ分からないような人間はプログラミングには向いてない」
と切り捨ててもいいですが、先にGOSUBを説明しておけばより分かりやすいハズです。
GOTOは指定した行(ラベル)にジャンプするだけのとてもシンプルな仕組みです。
GOSUBはラベルにジャンプして処理が終わったら元の場所に戻ってきます。
GOSUB(サブルーチン)まで説明すれば「プログラムをブロック毎に分ける」感覚が分かります。
という風に理解できるはずです。
かなり興奮しているし酔っているので要領を得ないかも。
今日急にうちに派遣で来てるおっさんに飲みに誘われて、会社の近くの安い居酒屋につれていかれた。
なんで誘われたかというとこれもうまく言えないのだが、チームや全体での飲み会で近くにいることが多く、不幸なことに自分が少し聞き上手だからかもしれない。
とにかく席についてビールが来ないうちに、人をばかにしたような半笑いで話を切り出された。
おっさんが持っている10年も前にあったようなガラケーのメモ帳画面を見せられ、君になら理解できるだろうとかクィータとかいうサイトにはろくな人材がいないとかブツブツ言っていて、俺はメモの中身を読み進めているうちに顔が引きつっていくのがわかってなぜか記事自体よりもそのことで笑いが止まらなくなりそうなった。
しばらく自分はどうすればいいのか知らないふりをするべきか、なだめたほうがいいのかまじでわからなかったのだが、結局記事の本意を聞きたい好奇心には打ち勝てなかった。
ちなみに自分の仕事場ではWinXPが現役で動いている。派遣おっさんも含め会社がそういうカラーだと言えば伝わるだろうか。
自分は趣味でReact(ないしReactNative) とかで家計簿アプリを作っているし、Androidも（それこそJavaでだが）やっていてちょっと新しい技術は知っているというレベルである。
端的に言うと「必修」という意味で使ったらしい。ルー大柴かおまえは。いや意味が通ってないしルーに失礼か。
・JavaとJavascriptが同列になっている点について
どうやらプロトタイプベースのオブジェクト志向という意味をはきちがえている。
つまりJavascriptはオブジェクト指向言語のプロトタイプとして生まれた言語であり、完全オブジェクト指向言語（これも意味がわからなかった）のJavaとは切っても切り離せない関係であると思っているらしい。もう自分はここらへんから笑いが変な声で漏れる笑いを堪えられなくなっていて、喘息気味なんですとかアホな言い訳で必死にごまかそうとしていたんだけれど、この派遣のおっさんに対してそこまで気を使っている自分にも笑いが止まらなくなってまあなんというか、おもしろかった。
Rubyが（というかRORが？）動作が遅いという話をどこかで読んだか聞いたかしたらしく、そして動作が遅いかわりに処理がしっかりしている（現文ママ）という位置付けの言語だと思っているらしい。正確性が必要な処理はサブルーチンにしたRubyに投げるべきだとかなんとか。
パッセンジャーよりもエンジンクスにひもづけるべき（現文ママ）とか言っててもうビールがまずくて仕方ない。
・MSDN
自分はMSDNは学生時代にVisualC++とかで使ったことがあって、デスクトップアプリ用のライブラリだとずっと思ってたんだけど、違うんですかね。（無知）
MSDM（何度聞いてもエムにしか聞こえない）の逆アセンブリ言語がC++だとか、ここの話は輪をかけて本当に何言ってるのかわからなかった。
ねこのことを考えて耐えた。
・SQL
あんま深く考えてなかったらしい。言語と名前がついているから言語のくくりに入れた、くらいのスタンス。
ちなみになぜか、使ったこともないらしいSQLiteで配列型を使えないことは知っていた。
と、ひと通り聞きたかったことを聞いた後、もうなんか疲れ果てたのでビールを半分残して帰った。
実を言うと、普通のプログラマはオブジェクト指向以前のプログラミングも理解できないんだけど、あれらはまだ手続き的な要素を内在してるから、そっちだけを受け取ることはできる。
それまで手続き的な要素＋宣言的な要素だったプログラミングが、関数型プログラミングへと移行する時に手続き的な要素を切り捨てたのね。より純粋な手法に進化するために。
だから、それまで手続き部分だけを受け取って喜んでた普通のプログラマは急にわからなくなりヒステリーを起こした。
だけど、プログラミング上級者はオブジェクト指向以前にも宣言的な部分しか見てないから普通のプログラマが何を騒いでるのかわからない。
普通のプログラマって、部品化の凄いやつが関数型プログラミングになるとか勘違いしがちだけど(staticおじさんもその変奏)、全く質の違うもの。
部品化って、重複コードをひすたらサブルーチンに括り出すようなもの。副作用がある。
日本のSIer(日立NEC富士通とか)って教養がない極東の田舎者だから、副作用を理解できない。すぐに「部品化」を持ち上げる。怖いんだろう。自分に理解できないプログラミングが。モナドですら大多数は理解できないんだもの。あんな教科書的なものですら。
とにかくアジアってIT後進国なのね。トップの日本ですらこうなのだから。"NTT"データがHaskellでレガシーシステムを脈絡なく解析してホルホルしてるレベルだもの。
まず日本に生まれた時点で、関数型プログラミングを理解するには圧倒的に不利。こんなこと言うと、「普通のプログラマにもわかやすく説明できるのが一流ダー」みたいな恥ずかしい駄々っ子が沸いてくるけど、プログラミングって歴史上一度も大衆を相手にしてないので。
OSSの恩恵で、普通のプログラマもコンパイラを無料で使えるようにになっただけで泣いて喜ぶべき。
そしてあれは、将来のスポンサーとコミッタの入り口としてやってるの。1000人に1人、将来コミュニティに貢献する人材がいるかもしれないと信じて。
シリコンバレー住人にもOSSコミッタにもなれない普通のプログラマはまあ、おこぼれで"文化的"コスプレしてQiitaでもやればいいんだと思うよ。
