タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

programmingとmanagementに関するsyanbiのブックマーク (5)

  • 初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)

    出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない

    初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)
  • 人月 - ギークに憧れて

    2013-07-23 人月 入社する前からずっと人月について考えてる。 10年くらいずっと人月disられてるのに何でなくならないのか疑問だったけど、詰まるところは発注側(顧客)がソフトウェアを定量化して評価できないから労働対価という形で契約を結ばざるを得ないんだと思う。受託開発は顧客がコミットしてくれないと絶対良いものにはならないし、現状そういう姿勢を持ってるのはネット系のスタートアップが多いからソニックガーデンとか永和の価値想像契約とかが成立するんだろう。 でも大企業とかは悲惨で、特に金融とかはディフェンシブかつ丸投げでヤバいと思う。でもそういうリスクの保険屋みたいな感じで大手SIerえてるのも確かだと思う。そういう意味ではNTTデータとANAが成果報酬契約を結んだニュースは面白いなーと。 でも上記の様なモデルは昔は良かったんだけど昨今は通用しなくて、人月単価はどんどん下がって

  • プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記

    プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基的には誰にも話さないが、 (家族や友人などプログラムを知っていない人間に話しても分からない、という事もある) プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか? 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」 などといった、その先がまたあいまいになっている場合もある。 このような場合、来であれば決裁権のある人間に

    プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
  • 多人数プロジェクトで学んだこと - <s>gnarl,</s>技術メモ”’<marquee><textarea>¥

    この書き方はまずいからあとで直そう→直さない あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる コミュニケーションしなくても正しい判断ができるようにする 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。 どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい? 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。 軌道を修正するコストは早ければ早いほど小さい。 仕組みを変えることにはコストが伴う。心理的コストも。 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変え

    多人数プロジェクトで学んだこと - <s>gnarl,</s>技術メモ”’<marquee><textarea>¥
  • プログラムは手段だけど、せっかく作るなら儲かって綺麗にこしたことはない。 - お前の血は何色だ!! 4

    コードは綺麗だけど儲からないプロジェクトと、 コードは糞汚いけど儲かるプロジェクトのどっちがいいですか? もちろん、コードは綺麗で儲かるプロジェクトがいいのは理想ですが、今回は、この2つです。 コードは糞汚いけど儲かるプロジェクトの場合、次期バージョンとかの予算を確保することができます。 そこで、汚い部分を捨てて書きなおすことだって出来ます。 コードは綺麗だけど儲からないプロジェクトは、次のバージョンの改修費用もでずにゴミ箱に送られる運命です。 プロジェクト解散、メンバーは散り散りです。 フリーソフトの場合は、儲かるをユーザに使ってもらえるソフトとか支持されるソフト、 ゲームの場合は、儲かるを面白いゲーム、支持されるゲームとかと適当に読み替えてください。 コードは綺麗に越したことはないです。 だけど、プロジェクトとして成立しないことには意味がありません。 コードは綺麗だけど、誰も遊んでくれ

    プログラムは手段だけど、せっかく作るなら儲かって綺麗にこしたことはない。 - お前の血は何色だ!! 4
    syanbi
    syanbi 2013/05/14
    汚いコードというのは試行錯誤の段階だから、メモ書きか清書かの違いな感じで扱ってる。メモ書きで出版もアリかもしれんが、増版するときに結局清書しなければいけないから死ぬ感覚。
  • 1