最適解を求めるためには試行錯誤が必要だ。 試行錯誤を繰り返すには目標立てと方針立てと目的とそれに伴ういろんな結果を受け止めることが必要だ。 いろんな結果をそれぞれ受け止めるためには物事を分けて考える頭が必要だ。 物事を分けて考えるには事象の消…

プログラムを作るときの話。 仕様書がいるかいらないかの話。 そもそも。 決められた予算に加えて決められた期間で仕事こなすための話。 予算と期間が決まっていれば、 物事に対して取れるアプローチの種類が決まります。 また、物事を行う人達が持つ力量に…

実装を知るというのはツメがきっちり出来るかどうかにかかってくる。 ウォーターフォール的に言えば設計時に製造のコストを下げる共通化が効果的に行えるかどうかにかかってくる。 烏合の衆が集まってもダメね。 できやしねぇ。 効果がどのくらい見込めると…

もしもあの時この道を選んでいなかったらどうなっていたのだろうか。 っと、次回同じようなことに出会ったときにやってしまわないように考えてしまうくせがある。 巨大で複雑な画面を作成しようとすると巨大なコストがかかっている。 闇の中にあった要求を明…

今やっていることが難しいのなら簡単に出来るところはどこでしょ。 どうやったら出来るのか道をさがしましょ。 巨大な敵を相手にしてるとしんどいのなら 小さな敵を多数相手にするようにすればいいんです。 難しいことを出来ないというのは簡単で、 やりたく…

「開発」という楽しいプログラミング作業を効率化し、 「設定」という決まりきった手順のプログラミング作業としたものがある。 「開発」は考えるというプロセスが存在し、試行錯誤が繰り返され、 時に悩み、時に苦しみ、時に神憑り的な閃きを得、作業を終え…

DBの定義書をExcelで作りながら思うのですよ。 (´-`).｡oO(そういやExcelで方眼紙のようなシート作って定義してた会社って結構あったな) 個人的に方眼紙では効率化の限界はすぐくるので好みではありません。 記述データを利用しようとコピーしたあと、テキス…

専門家には知識と経験と基礎力と応用力が要る。 素人はそれが基準値に達していない者、また総合力がまだ足りない者を指す。 さて。知識や経験といったものがどんな場面で活用できるかというと、 ・日常の会話や原因調査時の仮説立て ・解法の発見のためのい…

データの結びつけを考える。 検索の効率を考える。 プログラミングの精度と効率とメンテナンスを考える。 正規化の話はよく出るが、し過ぎず、しなさ過ぎずが一番。 「しなきゃいけない」「やらなきゃならない」ってな強迫観念にかられた理由から とられた形…

よく「if」の括弧のつけ方でモメる。 ゆとり派かガチガチ派か。勝手にカテゴリを2つにしてみた。 if( isError ) と if(isError) また同様に strbTmp.append( strNewItem01 ); strbTmp.append( strNewItem02 ); と strbTmp.append(strNewItem01); strbTmp.app…

ソースの形態が保守性に優れている形式になっている。 からといって、すんなりメンテナンスされるわけじゃない。 メンテナンスをすんなり行うためには何か要る。 先日こんなよな会話があった。 相手：(,,・Д・)＜そういやいつぞやのプロジェクト、大変なこと…

ひょんなことからRAIDが壊れたサーバ機が手に入り。 HDDを換装したら復活したので使う事になった。 事務所内ファイルサーバ。 それだけじゃーもったいないので、自分の席に持ってきて管理するという名目でゲット。 画面が4つになったよ ﾍ(･∀･)ﾉ PCも4台。 sy…

先日ペアプログラミング中に感じたことがある。 同じソースを見、同じソースをデバッグしながらも、 把握力が違うなと。 自分が作った自分のソース。 目指すものは「作りやすいよりメンテナンスしやすいソースコード構成」 それは誰かがメンテナンスする際に…

「変数名は意味のあるものをつけること」 コーディング規約のネーミングルールは時折遵守がめんどくさいと思う自分があります。 こんなソースな時とか。 string employeeName = employeeMaster.getEmployeeName(); int workingDay = employeeMaster.getWorki…

美しいコードが嫌いな人がいるのかしら。 それが汚されて朽ちていくことは悲しいことではなくて？ あなたは何も感じなかったの？ っとララァといつでも会話できそうな世界で話してみる。 今。 全てのプログラムコードは文字の、テキストの羅列としか我が目に…

構想を練るのには時間を必要とする。 どんな構成がいいか、どんな方法がいいか、どんな形式で実現できるか。 仮定と検証の繰り返しが脳内やコード上で繰り返される。 熟練者の開発作業が早いのは、この構想にかける時間が短くかつ効果的なカタチを用意できる…

最近もっぱらVB.NET改めVBScriptを書くのを手伝ってみてる。 ( ´∀｀)＜あれだね。どんな言語も所詮テキストの集合体だね。 ってかつての自分の実感を改めて感じている。 書くべきことは同じ。 様式と制約の中で構築する形が決まると。 .NETならクラスをバン…

旧体然としたところに今いてる。 いわゆる「SE」がハバを効かせている世の中に多く見られる体制である。 個人的には「プログラマ無くしてシステム開発の成功などない」と思っているので、 営業と要求定義とドキュメント作成以外は口を出すな挟むな管理の真似…

システムの設計段階でプログラマがいない。 構想を模索する段階ではなく、 実案として固める段階でプロフェッショナルがいない。 子供たちががんばって出し合った意見はかわいいもんだが、 実用的であるかどうかはまた別の話が実社会というものである。 だい…

わが事 最近おいらがメソッドとかクラスのコメントを全く書かない事はない。 正確には記述がない形で放置される事がない。 なぜか？ コピペツールバンザイだからである。 メソッドのスケルトンをコピペで定義する。 1から書かなくていいから最低限は存在する…

システム開発の方法。 傾向と対策に1つの結論を持ってからというもの、 世間とのズレを日々感じるようになったことに気が付いた。 無知からでる行動の選択肢は、知識を得たときに終わるはず。 しかして現実はなかなかそうはいかない。 知識を得てなお、それ…

プログラムを組むとき、ソフトウェア開発時に経てきた取捨選択。 ・何はともあれ作り始める事。 作るものの形すら見えずに何ができよう。 仕様書という名の書類にある画面は完成形ではない。 機能を作りながら考えても、作り直す事ができなければ バグが消え…

上流工程という名の開発フェーズから流れてくる作業内容を引き継ぎ、 ﾌﾟﾛｸﾞﾗﾑを組む際に、必ず不一致は出る。 しばしば「こんなんつくられへんやんけっ」ってことも起こる。 無いデータ項目は創造のしようが無いのだ。 必然として質問事項となる。 必然が確…

プログラマの美意識と開発効率はしばしば相乗効果をもたらさない。 「変数やオブジェクト名をわかりやすく」 この御題において、それが顕著に表れる。 美意識はどこにコーディング規約という形で定義される。 これをもって共通認識とするのである。 ゆえに「…

OJTといえど効率化は出来る。 何が足りないか、何を伸ばせばよいか、何を必要としているかなどを的確に把握した上で次の指示をだせるなら･･･である。 的確でなくともそれに近しいことであればよい。 世の中のOJTが非効率的であるとおいらが断言するのは丸投…

この手の未熟な技量しかもっていないのに大言壮語を吐く輩を客観的に判断するための材料が必要だと思います。 まだまだ未熟なIT-SSを「あんなんつかえねーよ！」という意見はよく耳にするけれども、 今の世の中「それ以外の共通の判断基準があるのか？」とい…

ここ最近はもっぱらVB6に戻っている。 画面を好き放題制御できるの楽しい( ´∀｀)ｗ ブラウザとは違うな〜とおもいつつも不便な点がないでもない。 .Netで作り上げたDBアクセスクラスの速攻作成のための道具がつかえない。 Javaで作り上げた同様のクラス構成…

友人がちょうどバイトさがしてたので、 ちょいと手伝ってもらうことにした。 プログラムではなく、アシスタント。 個人的にはモチベーション維持のための触媒的役割がどう作用するかを 想像したことはあれども実際に試したことは無い。 なんかあれね。 いい…

現実の作業を顧みたときに、おいら自身の作業は１回目は他とほぼ変わらない。 しかして2回目3回目と数をこなせばこなすほど圧倒的に短く正確になる。 同じようなプロジェクトしかり、同じ言語しかり。 客観的に見たときに、言語知識、プロジェクトの知識で、…

とりあえずﾌﾟﾛｸﾞﾗﾏﾚﾍﾞﾙを見極める際のｵﾚ的注視ポイント。 (1) コメント付け (2) メソッドの中身 (3) クラス構成 見極めはソースが全て。 ソースを見たらどんなレベルかは大体判断つく。 何を考え。何を思い、何を解して生み出したソースであるか。 概要を把…