https://ameblo.jp/argv/ とある職業プログラマの悪態を綴る。入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 ja-jp https://ameblo.jp/argv/entry-10727289798.html ビジネスによくあるシーン。　1. ドキュメントを作る　2. 誰かに見せる　3. 質問される　4. 質問に答える　5. 納得してもらう例えば、報告書の類とか、我々の仕事なら設計書のレビューなどもそうだ。また、ソースコードのレビューも同じである（以下、「ドキュメント」にはソースコードも含むものとする）。さて、上記の流れの後でそのまま終わってしまう人も多いのだが、それはよくない。単純に考えると、質問された内容というのは、「作成したドキュメントから読み取れなかったこと」である。しかも、少なくとも聞き手が 2010-12-05T02:52:08+09:00 https://ameblo.jp/argv/entry-10506289858.html 誰かに仕事をお願いするときに、「頑張ります」という返事をされるのは好きではない。頑張らないとできないのかと思うと、不安だからだ。できれば、頑張らずに涼しい顔で遂行してくれる人を探したい。頑張るための余力は何かトラブルがあったときなど、いざという時にとっておいて欲しいのである。もし、依頼した「100 の仕事」に対して、110、120 の結果を出すために頑張ってくれるというのなら嬉しいが、それなら黙って頑張って欲しい。「頑張ります」という言葉を使うとしたら、「100 の仕事は無理ですが、なるべく 2010-04-12T01:42:11+09:00 https://ameblo.jp/argv/entry-10254777348.html 「低レベルなプログラミング」と聞いて、どういうものをイメージするだろうか。プログラマとそうでない人では、答えが違ってくるのではないだろうか。一般の人には、「誰でもできそうな簡単なプログラミング」、あるいは「質の悪いプログラミング」といった意味にとられるかもしれない。しかし、プログラミングについての文脈で「低レベル」といわれる場合は、通常は「ハードウェアに近い」という意味である。つまり、「低レベルなプログラミング」とは、「ハードウェアが理解する言葉」に近い（たとえばアセンブラのような）言語を使った 2009-05-05T01:13:51+09:00 https://ameblo.jp/argv/entry-10228407175.html 「データがダーティである」という言い方は一般的だと思うが、私の周囲では伝わらないことも多い。何らかのデータを変更するプログラムにおいて、保存されているデータを直接書き換えるのではなく、データをコピーしてからそのコピーを変更し、最終的に元のデータに書き戻す、という方法をとることがある。このとき、「コピーの方は変更されているが、元データには反映されていない」という状態を「ダーティである」という。たとえば、ユーザーが画面でデータを編集するようなソフトでは、既存のデータを編集してそのまま終了しようとする 2009-03-22T00:44:49+09:00 https://ameblo.jp/argv/entry-10169317824.html プログラミング入門者のための教材として、「カレンダーを表示するプログラムを作れ」という課題がある。この課題に対して「カレンダーなんて OS に付属しているのに、なんでそんなもの作るんですか？」という人がいる。なんという的外れな意見だろう。言うまでもなく、勉強のために作るのであって、使いたいから作るわけではない。これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「本来の意図が伝わっていないな」と思うことは日常茶飯事である。★CodeZine の「コーディングスタイル 2008-11-25T01:44:57+09:00 https://ameblo.jp/argv/entry-10156651130.html 「こういうことができるか？」といった質問を受けることがある。質問する方は簡単なのだが、答えるのは難しい。何かが「できる」ためには、いろんな要因があるからだ。・理論的にできる／できない・技術的にできる／できない・時間的にできる／できない・費用的にできる／できない・感情的にできる／できないなど。ソフトウェア開発者の中には、理論的・技術的な可能性にしか注目しない人がいる。例えば、「既存のシステムにこんな機能を追加したいが、可能か？」という質問があったとする。それが、システムの仕様として矛盾がなく、実装 2008-10-26T23:36:07+09:00 https://ameblo.jp/argv/entry-10144604985.html 以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済 2008-09-27T23:27:43+09:00 https://ameblo.jp/argv/entry-10128582482.html 受託開発プロジェクトの終盤、ユーザーテスト（受け入れテスト）などと呼ばれる検証が始まると、当初の要件を覆すような「仕様変更」が発生するものだ。システムの要件定義（要求分析）は依頼者（顧客）と開発者が共同で行うものであり、漏れがあったとしても、どちらが悪いとも言い難い場合も多い。例えば、開発者の考慮不足とも言えるが、顧客側の情報提供が不足とも言えるというようなことだ。しかし、顧客は「金を払って依頼している」という意識が強いためか、開発会社の責任で修正させようすることも多い。開発会社もある程度は折り 2008-08-18T01:47:19+09:00 https://ameblo.jp/argv/entry-10113627094.html 中学生の頃だったろうか、「サボる」という言葉を漢字で書こうとして辞書を引き、はじめて「サボタージュする」の略だということに気がついた。ずっと純粋な日本語だと思っていたので驚いた記憶がある。日常的に使っている言葉は、昔からあったかのように思ってしまうものだが、意外に新しいということがある。★この業界では「ひもつく」という言葉がよく使われる。個人的には「ひもづく」と言う方が多いのだが、同じものだろう。データ構造に関する文脈などで、「繋がっている」、「関連している」といった意味でよく使う。たとえば、「 2008-07-07T00:20:28+09:00 https://ameblo.jp/argv/entry-10104530514.html ちょっとした仕事（タスク）を忘れてしまう人が意外に多い。ToDo リストのようなものを作って、管理すればいいだけのことなのだが。上司から ToDoリストを作るように言われ、数日の間、「今日のタスクは ToDo リストを作ることであります」などと言っていたが、結局できなかったという人もいた。やるべきことが発生したら追加するというだけのもののはずなのに、このように気合いを入れて作ろうとするのもおかしな話である（最初に作る時は、抱えているタスクを列挙するのに時間が必要かもしれないが、それでも何日もかか 2008-06-09T01:22:25+09:00