「サブルーチン」を含む日記 RSS

はてなキーワード: サブルーチンとは

2019-09-04

クラスメソッドサブルーチンの違いは?

C#勉強中。

クラスでつまづいてる。

メソッドは良く分からない。

サブルーチンは、もらった材料を加工するための場所だと思ってる。

料理で例えたりできるのかな?

少し考えてみようと思う。

出来たら書いてみるからNG判断よろしく

2019-06-04

anond:20190604143136

ああそういうことか

と思って手元の手ごろなソースを見てみたら判定用の関数なんて組まずに

その例でいうとグラボ名をgetしてそのままメインのロジックで判定してからそれぞれのサブルーチン呼んでたわ

1000ステップぐらいしかないバッチプログラムだし仕方ないね

2019-04-05

anond:20190404140637

全体的に「解説」というよりは「注意事項」を重視してるっぽいですね。

「この注意事項をみんなに伝えなければならない」という使命感を感じます

解説を重視するのなら説明する順番も考えるべきでしょう。

いきなり「関数」と言っても伝わらない可能性は十分あります

関数?なにそれ?数学嫌いなんだけど?」といった感じで。

関数さえ分からないような人間プログラミングには向いてない」

と切り捨ててもいいですが、先にGOSUBを説明しておけばより分かりやすいハズです。

まず一番最初は「GOTO」を説明しましょう。

GOTO指定した行(ラベル)にジャンプするだけのとてもシンプルな仕組みです。

GOTOが分からない人はさすがにほとんどいないでしょう。

次に「GOSUB」を説明します。

GOSUBはラベルジャンプして処理が終わったら元の場所に戻ってきます

GOSUBもほとんどの人が理解できるはずです。

GOSUB(サブルーチン)まで説明すれば「プログラムブロック毎に分ける」感覚が分かります

GOSUBまで説明した後に関数説明すれば

関数はGOSUBみたいなものか」

「でもGOSUBとはここが違うんだな(引数戻り値など)」

「だから関数には()がついているのか」

という風に理解できるはずです。

呪文」を使わず解説するなら現代でも最初BASIC無難かと思います

2019-04-04

anond:20190404165512

いやいや、アセンブラを学ぶのに半加算器の知識不要でしょw

というか、論理回路知識すら要らない。せいぜいBooleanくらいでじゅうぶん。

知っていると便利なのは、ALUとか、レジスタとか、メモリーとか、アドレスとか、バスとか、I/Oとか、ポインターとか、スタックとか、その程度かと。

サブルーチンを呼ぶとスタックにリターンアドレスを積んで云々、、、を知っているだけでイメージがわくし。

anond:20190404135821

GOSUBというと、何かの古代言語で使われていたような気が.....

Fortranだっけ? サブルーチンとか言ってるし.....。

anond:20190404034812

>>なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。

こういう煽り別に必要ないですよね?

これだけ長文なら関数のあたりでサブルーチン(GOSUB)のことも触れておきべきでは?

あと「RubyとかPython」でなぜRubyを選んだんですか?

2019-01-21

anond:20190121093829

入力と出力を持たないサブルーチンって処理分割以上の意味を持たないか

(どうやってテストしたんだよ)

分割されていようがされていまいがバグ潜在性は全く変わらんぞ。処理がつかみにくくなる関係修正難度は飛躍的に高くなるけどなw

anond:20190121093535

意味はあるよ。

行数が10行のコードより、1000行のコードのほうがバグが含まれてる可能性が高いとか、ifが1個しかまれてないサブルーチンより100個のサブルーチンのほうがバグを含んでる可能性が高いとか、その程度には。

2018-11-09

”今後必要になる〜”の著者がうちの派遣おっさんだった

かなり興奮しているし酔っているので要領を得ないかも。

今日急にうちに派遣で来てるおっさんに飲みに誘われて、会社の近くの安い居酒屋につれていかれた。

なんで誘われたかというとこれもうまく言えないのだが、チームや全体での飲み会で近くにいることが多く、不幸なことに自分が少し聞き上手だからかもしれない。

とにかく席についてビールが来ないうちに、人をばかにしたような半笑いで話を切り出された。

おっさんが持っている10年も前にあったようなガラケーメモ帳画面を見せられ、君になら理解できるだろうとかクィータとかいサイトにはろくな人材がいないとかブツブツ言っていて、俺はメモの中身を読み進めているうちに顔が引きつっていくのがわかってなぜか記事自体よりもそのことで笑いが止まらなくなりそうなった。

しばらく自分はどうすればいいのか知らないふりをするべきか、なだめたほうがいいのかまじでわからなかったのだが、結局記事の本意を聞きたい好奇心には打ち勝てなかった。

ちなみに自分仕事場ではWinXPが現役で動いている。派遣おっさんも含め会社がそういうカラーだと言えば伝わるだろうか。

自分趣味でReact(ないしReactNative) とかで家計簿アプリを作っているし、Androidも(それこそJavaでだが)やっていてちょっと新しい技術は知っているというレベルである

・「マスター言語」について

端的に言うと「必修」という意味で使ったらしい。ルー大柴かおまえは。いや意味が通ってないしルーに失礼か。

JavaJavascriptが同列になっている点について

どうやらプロトタイプベースオブジェクト志向という意味をはきちがえている。

まりJavascriptはオブジェクト指向言語プロトタイプとして生まれ言語であり、完全オブジェクト指向言語(これも意味がわからなかった)のJavaとは切っても切り離せない関係であると思っているらしい。もう自分はここらへんから笑いが変な声で漏れる笑いを堪えられなくなっていて、喘息気味なんですとかアホな言い訳必死ごまかそうとしていたんだけれど、この派遣おっさんに対してそこまで気を使っている自分にも笑いが止まらなくなってまあなんというか、おもしろかった。

RubyJavaサブルーチンとは

Rubyが(というかRORが?)動作が遅いという話をどこかで読んだか聞いたかしたらしく、そして動作が遅いかわりに処理がしっかりしている(現文ママ)という位置付けの言語だと思っているらしい。正確性が必要な処理はサブルーチンにしたRubyに投げるべきだとかなんとか。

パッセンジャーよりもエンジンクスにひもづけるべき(現文ママ)とか言っててもうビールがまずくて仕方ない。

MSDN

自分MSDN学生時代にVisualC++とかで使ったことがあって、デスクトップアプリ用のライブラリだとずっと思ってたんだけど、違うんですかね。(無知

MSDM(何度聞いてもエムにしか聞こえない)の逆アセンブリ言語C++だとか、ここの話は輪をかけて本当に何言ってるのかわからなかった。

ねこのことを考えて耐えた。

SQL

あんま深く考えてなかったらしい。言語名前がついているか言語のくくりに入れた、くらいのスタンス

ちなみになぜか、使ったこともないらしいSQLiteで配列型を使えないことは知っていた。

と、ひと通り聞きたかたことを聞いた後、もうなんか疲れ果てたのでビールを半分残して帰った。

よほど調子が悪く見えたらしく、おっさんはひどく自分のことを心配してくれた。ごめんおっさん

2018-10-21

普通プログラマ関数型プログラミング絶対理解できない

実を言うと、普通プログラマオブジェクト指向以前のプログラミング理解できないんだけど、あれらはまだ手続き的な要素を内在してるから、そっちだけを受け取ることはできる。

それまで手続き的な要素+宣言的な要素だったプログラミングが、関数型プログラミングへと移行する時に手続き的な要素を切り捨てたのね。より純粋手法進化するために。

から、それまで手続き部分だけを受け取って喜んでた普通プログラマは急にわからなくなりヒステリーを起こした。

だけど、プログラミング上級者はオブジェクト指向以前にも宣言的な部分しか見てないか普通プログラマが何を騒いでるのかわからない。

普通プログラマって、部品化の凄いやつが関数型プログラミングになるとか勘違いしがちだけど(staticおじさんもその変奏)、全く質の違うもの

部品化って、重複コードをひすたらサブルーチンに括り出すようなもの副作用がある。

日本SIer(日立NEC富士通とか)って教養がない極東田舎者から副作用理解できない。すぐに「部品化」を持ち上げる。怖いんだろう。自分理解できないプログラミングが。モナドですら大多数は理解できないんだものあん教科書的なものですら。

とにかくアジアってIT後進国なのね。トップ日本ですらこうなのだから。"NTT"データHaskellレガシーシステム脈絡なく解析してホルホルしてるレベルもの

まず日本に生まれた時点で、関数型プログラミング理解するには圧倒的に不利。こんなこと言うと、「普通プログラマにもわかやす説明できるのが一流ダー」みたいな恥ずかしい駄々っ子が沸いてくるけど、プログラミングって歴史上一度も大衆相手にしてないので。

昔は研究機関IBMで、今はMSGAFA

OSS恩恵で、普通プログラマコンパイラ無料で使えるようにになっただけで泣いて喜ぶべき。

そしてあれは、将来のスポンサーコミッタ入り口としてやってるの。1000人に1人、将来コミュニティに貢献する人材いるかもしれないと信じて。

シリコンバレー住人にもOSSコミッタにもなれない普通プログラマはまあ、おこぼれで"文化的"コスプレしてQiitaでもやればいいんだと思うよ。

anond:20181021093430

2018-10-12

プログラミング本質カプセル化ブラックボックス

コンピュータマシン語命令文もデータも数値で表す。これは今も昔も同じ。

数値だけでは人間管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ

(わかりづらい数字人間理解やす英単語に置き換えた)

アセンブラも規模が大きくなると人間には管理しずらくなる。

そのため人間言語により近い高水言語が生まれた。

if や for などで制御をわかりやすくした。

複数の処理をひとまとめで扱うサブルーチン関数プロシージャ・ファンクション

いったものができた。

(処理の流れをわかりやすくした、構造化、カプセル化

複数データをひとまとめで扱うレコード型や構造体生まれた。

カプセル化

コードデータをまとめて扱うクラスができた。

カプセル化抽象化

アプリケーションからOS機能を呼ぶシステムコールAPIが生まれ

ブラックボックス化)

複数クラスコードデータをひとまとめにするにモジュールができた。

カプセル化

プログラムを外部から操作するRPC、CORBA、SOAPRMIができた。

リモートから操作ブラックボック化)

WebAPIアーキテクチャーを超えての疎結合が進む

さらなるブラックボックス化)

IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。

ブラックボックス化)

CIツールサーバ数台〜数百台を1人で扱えるようになった

操作の簡略化)

DockerWEB/DB/KVSなどをまとめてコマンド1つで扱えるようになった。

カプセル化抽象化

プログラミングとはわかりづらいマシン語人間にわかやすくするのが本質

カプセル化ブラックボックス化・操作の簡略化は正義

2018-06-24

サブルーチン20行以下で書けって言ってる人をたまに見るけど、本人は実践してるのか疑問だわ。

初心者に変なことを教えるのはやめてほしい。

2018-04-27

バグレポート

ソフトウエア開発のバグ報告で、現象再現方法だけよこせばいいのに、原因を推測して報告してるやつがイラっとするわ。

そんなもん98%はずれてるし。

バグ原因の報告ならまだしも、コードの書き方とかアドバイスしてくるやつ、滅んでほしい。

「同じ処理はサブルーチンにして共通化したほうがいいよ」とか、プログラムを初めて一週間目のやつにするようなアドバイスやつとか、人をなめすぎだろ。

2018-04-10

anond:20180410165141

引数禁止。全部グローバル変数で渡せ」

えー、グローバル変数変わるタイミング分かりづれー

サブルーチンを使うとあちこちに飛んでわかりにくい。同じ処理をするときコピペでそれぞれの場所に同じコードを書きなさい」

むかーし、「ふんどしプログラム」って呼ばれてたやつか。

サブルーチン無しのメインだらだら書くやつ。

プロジェクトで開発した事無い奴らなのか?

それともそのプロジェクトで失敗して変に原点回帰しようとしてるのか?

何れにしても悲惨現場だな。

anond:20180409181511

サブルーチンに値を引数で渡してたら「引数禁止。全部グローバル変数で渡せ」とか、「サブルーチンを使うとあちこちに飛んでわかりにくい。同じ処理をするときコピペでそれぞれの場所に同じコードを書きなさい」とか言われたことがあるわ。

そこまでひどくなくてもレヴューを受けると「うわ、こいつレベル低っ」「この人Excelばっかりでコードいたことないんだろうな」みたいな人ばっかり。

レビュー機能してる現場に遭遇したことない。

2017-12-04

anond:20171204164348

サブルーチンの先頭で引数をチェックして異常ならすぐそこでリターンするって書き方は、ガード節って名前がついてるくらいだし、OKだと思う。

swiftだとガード節が文法に組み込まれてる。

2017-11-10

おっさんメソッド引数なしで長くなる理由

どうやら「メソッド細かくして~戻り値変数作って~引数渡しして~」という行為が面倒くさいというか短期記憶で処理しきれなくなるようだ

引数なし戻り値もほぼなしのメソッドが5行くらい並んでる(使うデータや出力されるデータは外部のどっかの広域変数に置いてある)、というのはその間に何か挟まれるとカタマリとしてわけがからなくなるから

過去おっさんメソッド/サブルーチンが長いのは現代プログラミングに触れてない世代だったからという解釈があったのだが、ぶっちゃけ加齢が主原因であった


40歳になったからわかったわ

2017-08-08

やっぱ俺の書いたコードは最高だな

システムの改修をやっていて、ちょっとした改修なんだけどコードが汚いから大変。

処理単位サブルーチンにしないで、上から下までベタッと書いて超巨大なサブルーチンになってるし、そのでかいスコープのなかで変数の使い回しとかやってるし、変数初期化とかしないでいきなり参照してたりしてたりするスタイルから、使い回しとの合わせ技で(その行での)変数の値が有効かどうか判断するのに大変だし。

作業やってるうちに何年か前に自分の書いたきれいなコードがでてきて、今まで誰も手を入れてないで汚されてなかったから、そこの改修は一瞬で終わったわ。

やっぱ俺の書いたコードは最高だな。

2016-09-06

手続き型で代入ができる言語では、参照透過性があり副作用がないサブルーチンって存在しないんだろうか。

int sum (int n) {
  int i = 0;
  int result = 0;
  while (i <= n) {
    result += i;
    i += 1;
  }
  return result;
}

例えばこんなサブルーチンなら、ローカル変数のiとresultに再代入はするけど、同じ引数で毎回同じ結果になるし、ローカル変数以外には影響を与えない。

条件はおそらくこのくらいでいいはず。

こういうのがコンパイラIDEで検知できれば便利そうなんだけど。

2016-07-18

IT業界認定試験もっと重要視すべき

IPAのやってるやつだけじゃなくて、ベンダーのやってる言語とかDBとかああいうのも。

PHPプロジェクトPHP認定試験に受かってる奴しか使わないとか、MySQL資格もってないとテーブル設計やらせないしSQLも書かせないみたいな。

認定試験なんて実力とは関係ないって言う人いるけど、SIerではびこってる「経験年数=技術力」って基準より数段マシになると思うわ。

Java入門書も読んだこと無いレベルの人が、コードを書くどころかレビュワーをやっていて、しかも「経験年数=技術力」って世界観から自分は実力あるとナチュラルに信じこんでるし。

VBから来たベテランが「エラーハンドラを全サブルーチンで書くべし」みたいなルールJavaに持ち込んで「全メソッドcatch(Exception e)するべきだろ」とか自信たっぷりに言ってる世界

ダメ技術者が、年をとってるってだけで評価されて上にたってダメ技術者を育成するって負のループに入り込んでるから一定客観的基準評価する仕組みをもちこんで負のループを断ち切るべき。

2015-11-07

http://anond.hatelabo.jp/20151107014318

サブルーチンの行数は一画面に収まるようにすべしというのは、PC20行とか25行しか表示できなかった時代から言われてるけど、当時それを言ってた人たちは本当に実践してたのかね。

2015-09-20

オブジェクト指向はなぜダメなのか?

人類には難しすぎたから。

日本PG/SEの60万人のうち、オブジェクト指向らしいコードを書けるのは1割以下だと思うわ。

もっと少ないかも。

オブジェクト指向言語オブジェクト指向フレームワークを使っていても、クラスにどんどんメソッドやメンバ変数を追加していって、クラスの中で手続き型言語風にコーディングしてるだけだし。

まだ手続き型で、ちゃんと構造プログラミングしてればいいけど、一個のクラスにやたらとメンバ変数を作って、各メソッドから適当アクセスしてるから手続き型言語グローバル変数を多用したようなコードが量産されてるし。

普通人間には手続き型で「サブルーチンを使いなさい」「グローバル変数は多様しないように」と教育するくらいが限界だと思われ。それでも対応できるのは何割かしらんけど。

2015-08-19

僕のいつまで経っても初心者プログラミング

タイトル通り、ちょっとでも詳しい人なら情けなくなるレベルでさえそこに達するのに何年も掛かった。

何せ、本業どころか趣味ですらないし、たぶん一般的プログラマとは全然違う。

ともかく、レベル的にはがっかりするような話であることは最初にどうしても断っておきたい。

 

事の始まりは前職の会社就職した時のことである

非常に特殊仕事で、ある環境計測データ現場で測定し、それを持ち帰って取りまとめて分析して報告書を提出するのが主たる業務の会社であった。

世の中にはほんと色んな仕事があるもので、そんな業種があるなんて務めるまで聞いた事もなかっただけど、パソコンという文明機器に触れたのも僕はその会社が初めてだった。とても古い話でお前いったい何歳だ?みたいな。

 

なので、その最初に触れたPC-9801シリーズの型番は言わないが、勤め始めた時にその会社にあったHDDは外付けでSCSI接続されたものがたった一台あっただけ、とは言っておこう。

環境計測データを取り扱うのが主たる仕事からパソコンデータ処理出来なければ仕事にならない。

その計測機器基本的に、当時は計るだけであり、記録データと言えば、記録紙にペンで波形記録してくれるレコーダーや、分析値を印字出力してくれる分析器、あるいはまた磁気記録によるデータレコーダくらいしかなく、今みたいにパソコンどころかメモリーカードや、スマホデータ記録といった直接AD変換記録してくれるものなんてなかった。

・・・いや、あるにはあったけど、そのAD変換機器パソコンをつないで自家製プログラムで処理したりしていた。

とにかく、アナログ値をどうにかしてデジタル値に変換するのは、手入力やらプログラムやらで処理するほかはなかったから、それなりにプログラム技術をどうしても身につける必要があった。

 

一番最初に書いた、ちょっとはまともに動くプログラムとして憶えているのは、サインとかコサインみたいな計算をやってパソコン上で波形を構成し、その値を使ってXYペンプロッターで作図する、というものであった。

ペンプロッターなんて今でも生きているのをたまに見る事があるけど、今は普通にプリンタだよね。

でも当時は、プリンタで作図したものを打ち出すとかありえない世界だった。ドットインパクトプリンタ?くらいしかなかった。

感動したよ、実際には今とは比較にならないほど極超低速だけども、滅茶苦茶にウィンウィン素早く動くペンに感動したもんだ。

僕が書いたとおりに動く、と言う感動。

言語はN88-Basic

ペンプロッタをRS-232Cパソコンと繋いで、描画命令を送るとその通りに動く。

但し、プログラムバグがあると紙とペンのインクを無駄にする。

僕はそこからプログラムを書くという魅力に取り憑かれるようになり、その会社では在職期間中、多分数で言えば一番プログラムを多く書いたのではないかと思う。と言ったって小さなさなプログラムばかりだが。

なお、それから何年か経ち、レーザープリンタが導入されたけども、作図のやり方自体は変わらず、プリンタに直接描画命令を送って、みたいなやりかたをしてたよ。だって当時、レーザープリンタを買うと漏れなくコマンドマニュアルが付いてきた時代だったしね。

 

しかし、言うまでもないけど、DOS上で、いちいちエディタを使ってBasicソースコードを書き、保存してrunさせるという一連の手続きはとても面倒で、N88-Basicは行番号を行ラベル、GOSUB~RETURNという感じでのサブルーチン処理が出来たくらいで、例えば変数初期化を忘れて気付かずに同じ変数名でサブルーチンを使ってしまうと、最悪ハングアップしてどうしようもなくなり、リセットする羽目になること屡だった。

から自家製ブレークポイントと言うか、STOP命令ソースのあちこちに書いて、うまく行けばSTOPを削除するとかコメントアウトするとかは必須な当時だった。

 

そんなこんなで勤めてから半年くらいで確か社長マイクロソフトのQuickBasicを買ってきた時にはほんとに感激した。

構造Basicであることもさることながら、統合開発環境ほとんど全てやってしまえるってのが如何にすごい効率化を生むかを知った。

汎用サブモジュールを作ってしまえば、あとはそのソースファイルを読み込んで、引数与えてサブルーチンを読めば同じ記述を何度もこぴぺする必要から開放される。

あるいはもう、バイナリライブラリファイルにまとめて、クイックベーシック起動時にスイッチで読み込むバッチファイルとしてしまえば考える必要もない。

さらに、exe形式の実行ファイルも作れてしまい、特定の処理のためにいくつもそれ用に実行ファイルを作っておけば、プロンプトから一発で様々な処理が出来る様になった。

 

QuickBasic時代が一番多くのプログラムを書いたと思う。もちろん、数だけの話で行数や文字数ではないけれど。

しかしそれは、僕にとってのプログラミング世界を狭小なものにしてしまった。

ちっとも勉強しなかったと言えばそれまでだけども、僕はいまだにBasic言語しか使えない。

Cやらその他の言語を書けなくはないのだけど、Basic言語で先ず考えて、みたいな頭に出来上がってしまったみたいである。

 

いや実のところ、早いことBasic以外の言語も覚えたかったのだけど、その会社社長がそれを許さなかった。

一度、Pascalを使ったプログラムを書いた事があったのだけども、社内で僕以外の他の誰も触ることができないと言う理由で禁止されてしまった。

社長は元々FORTRANから始めた人で、BASICと非常に良く似ていると言う理由で、会社を立ち上げた時からBASIC一本やりだった。

彼はそもそもプログラムは書いたとしてもプログラミング技術にはあまり興味がない人で、とにかく仕事のために問題なく動きさえすればよく、言語などどうでも良かったのである

からプログラムスピードアップのためにC言語の導入を僕が進言した時には「それを覚える時間無駄」と取り合ってもらえなかった。

Windows時代になってVisualBasicが導入されてもそれは変わらなかった。

VisualBasic6.0にもなると、純粋オブジェクト指向ではないが、それなりにオブジェクト指向っぽいことは出来る様になっていたし、オブジェクトを扱う方が、サブルーチンコールだけに頼るやり方よりもずっと能率的だって事くらいは分かっていたので、僕はオブジェクト指向っぽくプログラムを書きたくて仕方がなかったのだけども、社長ユーザー定義変数を使うことすら許さない。

VisualBasicから最低限、フォームやらコマンドボタンを使う必要があるから、それらのプロパティメソッドなどを使わざるを得なくなっていたし、社長も使っていたのに、いざクラスを書こうとすると滅茶苦茶怒られた。

「一つ一つのプログラム会社資産であり君のものではない。別の人間保守できなければ、君がいなくなったらただのゴミだ」

というのが彼の口癖だった。

 

なので、構造プログラミングレベルで工夫するしかなく、それから数年後に辞めるまで、僕は構造プログラミング技術を磨き続けただけで進化は停止してしまったのである

Windows環境になり、VB5以降にもなると、プログラムはどんどん肥大化して行った。

DOS時代のようにメモリを気にする必要があまりなくなって行き、1つのプログラムで様々な事が出来る様になると、困った問題が1つ重くのしかかるようになって来た。

社長フローチャートを書かないと絶対に許さない。

どんな小さなプログラムでも業務上で使うものである限り、自分しか使わないユティリティーレベルのもの以外については、絶対フローチャートを提出し確認を貰う必要があった。

細かな変数やら関数やらのドキュメント仕様書は、ソースコード内に所定の様式コメントを書けばそれでオッケーだったが、小さなサブルーチンでさえもそれが存在する限り、細かくフローにしないとダメなのだった。

入社当時こそ、それが非常に勉強になったし、他人の書いたプログラム理解するのに役立ったのだけれども、慣れてくると煩わしくて仕方なかった。

だいいち、うちの会社プログラムを外部に売っているわけではない。

データ処理や分析など、業務に必要から作っているに過ぎない。

流石に、稀にある、ソフト設計自体重要意味を成す業務では、詳しい仕様書をまとめて、その仕様書を通して取引先とやり取りしたりしていたけども、そんなのは滅多にない話だったし、汎用プログラムでさえも、一回完成させたら、その中身を見ることなんか滅多になかった。

実際、不具合があったらフローチャートなんか見ずに、誰もが直接コードを叩いて直したりしていただけだし。

 

DOS時代の時は、そんなに大きなプログラムは書けなかったので、フローチャートもそんなに面倒ではなかったが(そもそも僕はめんどくさくなると業務自体を早く終わらせたいのでソースを完成させたあとにフローチャートを起こしていた)、VB時代になるとフローチャートがあまりにも複雑怪奇になって行き、そんなフローチャートを例え完璧に作っても、誰も読んで理解しようとは思わないくらいにさえなっていった。

僕以外の社員も実際困ってて、そのせいでみんな夜遅くまで残業するようになっていった。

社長はどうかというと、社長業が忙しくなり、自分プログラムする事は滅多になくなったし、あっても少しサブルーチン的なところを書いたりとか、大雑把なフロー書いて、実装社員に任せっきりだった。

但し、社員の作ったプログラムフローには絶対に目を通す人で、ソースコード自体はあまり見ないが、フローがしっかりしてないと何度でもダメ出しをし、社員社長のオッケーが出るまで何度も書き直さないといけない。

 

で、ある業務で、いつものようにプログラムを先に完成させてフローに起こし直していた時のことだった。

どーせソースコードなんか見ないだろう、と辻褄の合うようにだけフローを書き、実際のソースとはかなり違うフローチャートを提出し社長にオッケーを貰った。

ところが、その業務で追加の仕事が発生し、時間的に僕では無理で、社長が僕のプログラムを触るしかない状況になった。

フローとあまりに違うソースコード社長激怒し、しかしそれまでめんどくさいフロー起こしに鬱憤を貯めていた僕もその鬱憤を晴らすかのごとく、かなり暑くなって反論し返してしまい、もう少しで暴力沙汰になる手前まで口論して、それから数日後、僕は辞表を提出したのであった。

 

その会社を辞めてから、次の仕事は全く関連のない無関係な全く違う職種になり、パソコンこそ触るものプログラムなんか書くことはなくなってしまった。

DOS時代パソコン通信フリーソフトを二つほど作った事がある程度で、必要に迫られない限り、プログラミングをする人間ではない。

ただ、当時どうしても許されなかったオブジェクト指向だけはいつの日かチャレンジしてみたいなぁとは思っていた。

それで、あるとき思い立って、何度か仕事で生かせないかなぁと思い、エクセルVBAを使って、昔取った杵柄じゃないけども、こそこそプログラムを書くようになり、もしかしてオブジェクト指向的に書けばちっとは勉強になるかなぁとやってみたのではある。

しかし、大雑把な初歩的・概念的なことは知っていたけども、実際、オブジェクト指向プログラムしようとしても、構造プログラミングをあまりにもやりすぎたせいか、どーしてもオブジェクト指向的にならない。

歳を食ったせいもある。頭が新しいことを憶えたがらない。

クラス設計書であり、インスタンス実体である、とか言われても理屈こそ分かっても頭が理解を許さない。

フローチャートロジックばかりが頭に浮かんでしまい、インターフェース的な理解をしようとしない。

 

最近になってようやく、少しはまともなオブジェクト指向が身に付き始めたんだけどね。

ほんと、こんな歳になって、いったい何年掛かったのやらw

 

長々と、単に自分記憶を掘り出しただけの文章披露してみただけで、ごめんなさいです。では失礼。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん