『スキルアップのためにラップを剥がしてみる』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 仕事で会計関連のバッチ処理を設計しているところなのだが、機能のほとんどが数値を操作するだけのいわゆる業務ロジック（ビジネスロジック）なので、ちっとも面白くない。そういえば、WEB+DB PRESS Vol.38 の特集に、「"業務ロジックしか書きたくない人" のための書かない技術」というタイトルを見て、違和感を感じた記憶がある。 もちろん、このタイトルの意味は理解している。「業務ロジック」というのは、ユーザーの業務に特化した処理である。そのため、それぞれのシステムによって処理内容が違い、その都度新しく処理を「書く」必要がある。一方、業務ロジック以外の部分は、どのシステムでも似
『本来の目的を思い出そう』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 「面倒くさいこと 」に書いたように、繰り返し行うような単純作業はコンピュータにやらせた方が効率的だ。プログラムを作る時間が掛かったとしても、長期的にみて利益が大きいならそうすべきである。 しかし、逆に、人間がやった方が効率的な仕事までコンピュータにやらせようとして、失敗することも少なくない。苦労してデータを入力しても、それに見合うだけの恩恵を与えてくれないようなシステムを見かけたことがないだろうか。 コンピュータに限らず、道具というものは、適した所に適した形で使わなければ効果がない。「システム化」といっても、何でもかんでも電子化してコンピュータで管理すればいいというものではな
『プログラミングの入門書は何が良いか？』
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 プログラミングの入門書として何が良いかと聞かれることがある。これが意外と困るのだ。自分が入門書の類を読まないので、具体的な書名を挙げることが出来ないのである。 もちろん、プログラマには、いつまでも新しいプログラミング言語を学ぶ機会がある。しかし、ある程度の経験者と、全くの初心者とでは、その学び方が異なるのである。ベテランのプログラマは、「入門書」を読むのではなく、文法書やリファレンス、既存のソースコードなどを読んで、その言語の「特徴」を押さえることで、新しい言語をマスターしようとするだろう。言語が違っても、プログラミングという仕事の基礎の部分は共通しているのである（※１）。
『YAGNI ～ 予想でモノを作るな』
人間には未来の出来事を知ることはできない。だから、せめてできる限りの予想をして未来に備えよう、ということになる。プログラマの仕事でもそうだ。 「次のバージョンアップでこんな機能が要求されてるんだけど」 「そんなこともあろうかと、その仕組みは既に作ってあります」 なんてことになれば、得意な気分になる。予想が当たれば嬉しいのは、ギャンブルもソフトウェア開発も同じだ。 しかし、予想に基づく行動にはリスクが伴う。それもギャンブルと同じである。 以前、私は、あるシステムの内部データを CSV ファイルとして出力するプログラムを作った。その際、将来のバージョンアップで出力するデータ項目が追加されるかもしれないと考えた。そこで、プログラムを直さなくても、「定義ファイル」に項目を追加するだけで、CSV に出力できるようにしておいた（顧客からそんな要望はなかったにも関わらずだ）。 しかしである。その後、実際
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
