主力とマイナス要因との差は何か？ パッと思いつく内容であるところの ・手が早い ・言語の慣れ は決定的な差とはなっていない。 プログラムを作る前に、作りながら、 あるべき姿をどれだけ明確に共有するかどうかにある。 「答え」をコードを構築する段階の…

俗に「神降臨」しているときの効率は素晴らしい。 しかして素晴らしいがゆえに悩みが生じる。 ・神降臨状態にいかにしてなるか ・神降臨状態でない状態でも推し進めるにはどうするのか 前者は「なってしまえばこっちのもの」だが、 そう簡単にはなれない。 …

言葉であれこれ可能性を語るより。 試せるなら試せ。 答えはより具体的な結果に近づくだろう。 っつか、うだうだあーでもないこーでもないとか言ってる暇があったら やったらいーじゃん。

最近の仕事ではこれでもかーーってくらいにレビューがある。 紙を作る基本〜詳細設計ってフェーズから ソースコード作る工程も。もーあれじゃね？ クラス図とシーケンス図まで作ってなお、ソースのウォークスルーとか無駄じゃね？ なんだか心配で心配で心配…

モデラーによるモデラーのためのモデリングを行うと 実装が大変になる。 ただし、慣れていないとって前提で。 実装側に寄っていそうなイメージのあるマイクロソフトの言語を使うと モデリングの結果による設計は、一言で言うと「もどかしい」。 そこにあるの…

去年まで学んだこと、実践してきたことの中の、 「やっちゃいけねぇ集」を今年は体験している感じだ。 モチベーションが低下すると作業効率がおちる。 これは何の疑いもない事実だが、 もう一歩先があった。 「○○のヤロゥのためになんざ働けるか！！」 作業…

ソースコードの構成、 ソースコードの作り方、 用意されてあるデザインパターン、テンプレートの管理、 アルゴリズムを採用した経緯、利点と欠点、その対処方法、 共通関数、クラスなどの有無、利用方法、 IDEの使い方ワンポイント、テキストエディタの使い…

人間保身に走るやつがいて、誰かが追随するとみんな止まらない。 ・自分の仕事外のこと関係ないって線引きする から始まって。 ・だれかがやらなきゃいけないこと ・だれもがやらないこと ・自分もやらないとまずいこと ・自分がやらないとまずいこと 段階を…

考えるポイント ・フィードバック方法は考える。 ・各人の失敗の経験も、組織的にはダメージのない方法で行えるよう考える。 ・各人は自分の作業を「どうすれば期間内に完成するか」を考える。 ・道筋が出来たら考えずに作業する。 ・道に迷ったら再考する。…

どんな作業であれやっていると気づくことってのがあって。 ましてやドキュメンターが作った設計もどきの検証は、 プログラムを作っている時にはバンバン行われてバンバン変更となり、 ドキュメンターゆえにいろんな変更に伴い発生する仕様的矛盾を統制しきれ…

時間をかけていいのは品質を作りこむ時のみだと思っている。 時間をかけた代償を補ってあまりある恩恵がその先にあるからだ。 ・修正時間が想定の範囲で収まる ・想定の範囲が度を越えない この2点の価値がわかるかわからないかが、品質の話が出来るか出来な…

そこそこよいマシンでメモリも豊富。 やったぜやっほぅって気持ちで使い始めてしばらく。 VISTAと.NET2008っておもてーな。 コンパイルに時間がかかる。 体感的にたえられへん。 ってあれだ。 忙しい最中に時間のかかる行為ってやだな。 今更再インストール…

むずかしい。とっても難しい。 正確には「みんなの平均値を高めること」がとっても難しい。 ソースコードとモジュールのみを相手にみんなでやいやいやるのは 技術力があればさほど難しくない。 そこにドキュメントが入り込んでくると、難易度がとたんに跳ね…

設計書と言う名の書類が多い。 しかしあれだな。 データの移送表的なものがあればプログラム作りに支障はないし、 要望は文章で箇条書きが望ましいことを踏まえるとシステム化できるよな。 あれ？ 登録データをExcelに出力する仕組みってなんぞなかったっけ…

意外に難しいことなのかなと思った今日この頃。 例えば。 「画面で使用したデータをデータベースに送る」 代入が１回で済むような作りをするようなプログラムのことは無視してよいと思うが、*1 通常は「画面→データオブジェクト→DB」のように行われると思う…

なんで誰も用意しないんだろう。 開発時に。 って思う現場は多い。 最近の現場でも「綺麗なデータを用意してください」といったら(ﾟДﾟ)ﾊｧ?っていわれたし。*1 開発時に「こうあるべき」って姿を用意できないデータ。 作るの難しいから後回しにされるデータ。…

コンピュータが出来ることは全てコンピュータに任せたらいい。 この怠け心からスタートする。 プログラム作成を自動化するには制約がある。 制約とはある一定の手順が作成されてあることである。 手順とはこれをこうしてこうすればああなるってこった。 手順…

ちなみに。 ・プログラム(機能)の予定工数を決定する ・プログラム(機能)作成工程を10段階ほどに分ける ・各工程に案分の重み付けを行う ・各工程が完了したら案分の分だけ作業が進んだと管理する ってなことをそのときのメンバーの実績値から工程や案分量を…

・ウォーターフォールモデルでの開発は至難だ。 ・開発において技術力は必要不可欠な要素だ。 以上2点を考慮してプロジェクトを成功に導くにはどのようなアプローチがよいか？ 答え ・技術力のある開発者を集めて、アジャイル。 現実問題で考慮すべきこと ・…

同じ160時間をすごすなら。 (1)良い現状維持に費やす (2)悪い現状維持に費やす (3)良い循環の継続に費やす (4)悪い循環の継続に費やす どれがうれしさ満杯で、どれが絶望と永久の縁を結ぶことになるのだろうかとふっと思った。 よくないプロジェクトにあたる…

世の中の多くの人々が共有している知識がある。 世の中の多くの人々が共有している感覚がある。 それでもそれが実行できるかどうかはコトによる。 だってほれ。 30cm物差ししかない状況で2mの直線が引ける人間がどれほどいるというのだ？ 物差しがあれば直線…

自分の守備範囲を頑なに固持するってのはよくないな。 機能毎のインタフェースがあっても、 機能間の連携箇所が無考慮なため、 なにか作れば何か出てくるってことが起きている。 っつかね。 ナンボ急ぐプロジェクトだからって言っても、 ＣＶＳだのＳＶＮだ…

システム開発時、状況判断の場面において常に頭においておく必要があることが3つある。 仕様を変更を無くす事 期間を確保する事 開発者の能力を活かす事 仕事を達成するのは開発者の能力以外に推進力は存在しえず、 期間は達成という目標地点まで到達するの…

プログラムは誰のために作るか。 そんなもんは決まっている。 使う人のためだ。 ただその性質上、使う人＝作る人になったりするだけで、 お金を払う人＝使う人ってだけでもない。 業務じゃもちろんユーザ本意になるのは言わずもがな。 その上で。 今回は業務…

そういえば。 例えばこんな条件下でプログラムを開発するとしたら見積もりってどのくらい違うのだろう。 ・マスタのメンテナンス画面 ・項目数20〜30 ・一覧検索機能と登録更新削除機能付 細かいこと抜きでこんな規模の〜プログラム作成にかかる費用見積もり…

情報の整理の得手不得手は仕事の出来る出来ないに直結してそうだ。 先日のんだくれながら語ってたこと Aさん：(,,ﾟДﾟ)＜教えていても覚えるやつなら教え甲斐もある。 けど2回3回同じこと言わなあかんのは耐えたくないな。当然メモもとらん。 Bさん：(..・Д・…

たとえば固定フォーマットの定型ファイルを出力するプログラムを作るとする。 レイアウトがあって、桁数があって、データの取得元があった上で プログラミングがはじまるのだが、どう形作られるもんなんだろ。 ってのを今目の前のソースを眺めながら思い返し…

やっちゃいけない手ってのがある。 事実を踏まえず型通りにウォーターフォールモデルの開発を行うとか。 今まで積み上げてきたことを、時間も無いのに忘れて別の道に進もうとするとか。 構造化プログラミングも知らないビギナーにプログラム組ませるとか。 …

確認のために聞く事があるのだが、 すんなり答えが返ってきたためしが少ない。 (,,ﾟДﾟ)＜ここの設定ってどこからとってくるの〜？（テーブル的な意味合いで） ここで想定される簡潔かつ仕事として許容したい回答は以下のようなことだ。 (1)○○テーブルですよ …

ある目的を達成するための手段を考えるのがお題だとしよう。 達成できる手段がいく通りかあり、それら手段のメリットデメリットを考慮し、最終決定を導く。 これがやりたいことであり、大事なことだ。 目的を達成出来ない方法は選択肢に入ってちゃおかしいだ…