詳細設計書が滅亡しない理由 - kagamihogeの日記
IT 業界というか SIer の枠組みの中で働いている人であれば、一度は詳細設計書ないし詳細仕様書というドキュメントを見たか書いたことがあるだろう。 Excel 方眼紙の悪夢 詳細設計書の話の前にちょっと触れておきたいのが「Excel 方眼紙」 これまでのプロジェクト経験とネットの情報を見る限り、詳細設計書はほぼ 100% コレで書かれている。Excel 方眼紙がどのようなものかは こんな感じ である。典型的な使われ方は 【図解!!コレが方眼紙Excelだ！】:島国大和のド畜生 がわかりやすい。 「Excel 方眼紙」でググるとわかのだが、コイツは猛烈に嫌われている。一発作り捨てならば、図や表を交えたドキュメントをそこそこ作りやすいという利点はある。プレゼンや紙印刷を考えないならば、個人差はあれど PowerPoint 並の使い勝手を覚える人はいる。 がしかし、Excel 方眼紙はそのメリ
Javaプログラマであるかを見分ける10の質問に対する回答なのかネタなのかフィクションなのかもうよくわからないもの - kagamihogeの日記
Javaプログラマであるかを見分ける10の質問 - やさしいデスマーチ ==演算子とequalsメソッドの違いは何か？ ==は、なぜか文字列が一致しているのに時々思ったとおりに動かないことがあるが、equalsは動くため。 文字列の連結は原則として+演算子を使ってはならない理由を説明せよ。 コーディング規約でStringBufferを使用すること、と定められているため。 Listのようにジェネリクス型を使う主たる目的は何か？ 主にJavaのバージョンが1.5以上のときのソースコードレビューを通るため。 オブジェクトがガベージコレクション（GC）される主たる条件は何か？ 本番環境のメモリがきわめて少ないとき。 チェック例外と非チェック例外の違いを型と例外処理の観点で説明せよ。 catch文を書いてもいいときと、書かなくてもよいとき。 フィールドのアクセス修飾子をprivateにしgetter
レガシーコード改善ガイド - kagamihogeの日記
「テストがないコードはレガシーコードだ」のあおり文句が実に眩しい一冊。本書を一言で紹介するなら、リファクタリングの実践書であり、オブジェクト指向プログラミングの参考書であり、テスト駆動開発の教科書である。感想に個人差はあるだろうけど、かなり多面的な顔を持つことに異論を唱える人はいないであろう一冊です*1。タイトルだけに釣られて買うと、その内容の豊富さに戸惑うかもしれませんが読後の爽快感はかなりのものです。 数年プログラマをしていれば、誰にでも経験するであろう「すでに動いているコードの動作を崩すことなくその部分のコードを修正や機能を追加する」という作業。たいていの場合、これは中々に難易度の高い仕事になる。本書でもそのことについて触れていて「編集して祈る」という名前をつけている。 本書を読むまでは、俺は「編集して祈る」スキルはプログラマに必須なものだと考えていた。あるコードに手を入れる際、ただ
JJUG Cross Community Conference 2009 Fall - kagamihogeの日記
JJUG Cross Community Conference 2009 Fall に行ってきました。昼過ぎから。台風でどうせムリになるだろ……と高を括って目覚まし止めて昼に起きたら、そこにはぴーかん晴れの空模様が。 ので、午前と午後一部のセッションは聞き逃しました…… 関数型×オブジェクト指向 マルチパラダイム言語Scalaの魅力と可能性 Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala) がマジオススメ。らしい。入門書としてが半分、残り半分がscalaの設計思想についてになっている。ので、入門者にもじっくり勉強したい人にもおすすめのようだ。 scalaはなぜうれしいか？ 一つはJavaの悪い部分を改善し、ベターJavaとして使える。JVMの上で動くから、scalaからJavaのクラスを使える。いわゆるscalaとJavaの相互
ウォーターフォールと裏プロセスに関するメモ - kagamihogeの日記
ひとりにはなりきれない空を見あげる のエントリに、俺は下記のような半ばヤケクソ気味に脊髄反射なブクマコメを残してきた。 【建前】『外部設計』の工程ではプログラムを書いちゃだめ【現実】どっかの小人さんがホントに作りこめるのか検証・先行実装してる裏工程がだいたい存在している。スケジュール表には出てきませんがｗ はてなブックマーク - 極道的研修のあらまし「引数と戻り値が分かりません」 - 歩きつづける ゆり 咲きつづける 裏工程って単語を使ったのだけど、これは俺の言葉ではない。どっかで読んだ記事でそんなよーな言葉使ってたよな、と思い出してコメントに使用した。で、何処の記事だったか探し当てられたのでリンクを張っておく。 「ITエンジニアは職人気質を取り戻すべき」− ＠IT自分戦略研究所 この連載シリーズの第三回目。「現状のソフトウェア開発は間違っていないか？」（プロセス編） − ＠IT自分戦略研
privateメソッドは不要、出力パラメータに御用心 - kagamihogeの日記
privateメソッドは不要 - @katzchang.contexts 書いてあることに同意。Meyer センセを始めとして「値を返すだけの function と副作用を伴う procedure は分離しる！」とむかしから言われてるアレと同根かなぁと。 で、トラバ元のエントリとは直接関係無いのだけど、このエントリ読んでて思い出したことがあるのでそれについて。 共通関数（この言い回しは良くないかな？）として static なメソッドに切り分けてるつもりで、やばいことになってるコードについてです。 public class OutputParameter { private List<String> privateList; public OutputParameter() { super(); this.privateList = new ArrayList<String>(); } pu
コンピュータは身近になり、誰もがその恩恵を受ける時代になるのかな - kagamihogeの日記
ネタ元：ホワイトカラーはみんなプログラマーになる仮説 - Blog on Publickey その昔― 1980 年前後くらいかな？―いまやパーペキに死語と化してはいるんですが EUC(End User Computing) という概念が流行った時期がありまして。これは何かっていうと、コンピュータの専門職じゃない人でも直接コンピュータ使って仕事しちゃえばよくね？ というものです。なんでこうなったかっていうのは IT用語辞典 に時代背景が書いてあるんですが、計算機の能力向上・安くなって一人一台が現実的になってきた・アプリの充実、ってとこですかね。 この概念が流行るもうちょっと前の時代は、給与計算なんかにコンピュータが使われる程度だった、という時代背景があります。パンピーが使えるコンピュータは電卓が精々で「カンピュータ」なんていうオヤジギャグがブイブイと幅を利かせておったわけです。コンピュータ
197x特別企画「未知との遭遇 - 自重しない大人と学生」 - kagamihogeの日記
うわー自重しないにも程があるよ 197x ござ先輩こと id:gothedistance からちょっとだけ話は聞いてるけど、マジで public な場でやるならピー音無しでいけるとは到底思えない……ｗ ＿＿＿_ ／ ＼ ／＼ ｷﾘｯ . ／ （ー） （ー）＼＜「ソフトウェア開発には業務知識が重要です」 ／ ⌒（__人__）⌒ ＼ | |r┬-| | ＼ `ー'´ ／ ノ ＼ ／´ ヽ | ｌ ＼ ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､. ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒)) ＿＿＿_ ／_ノ ヽ､_＼ ﾐ ﾐ ﾐ oﾟ(（●）) (（●）)ﾟo ﾐ ﾐ ﾐ だっておｗｗｗｗｗｗｗｗ /⌒)⌒
フツウのプログラマがフツウに評価される社会を夢見る - kagamihogeの日記
俺は大学でコンピュータサイエンスを 4 年間学んだ。とはいっても大学自体の学歴・成績は平凡もいいとこ。真の意味でのプログラマのレベルは凡骨もいいところな自覚はある。まぁその大学は自分と似たよーなレベルの人間を毎年輩出してるわけです。 でまぁ、就職活動に真剣に取り組み始めにゃならん時期になんとなしに 2ch （つーかしたらばか）の出身大学の出身学科のスレ見たら驚いた。そこでの議論の趣旨は「コンピュータサイエンスを 4 年学んだ人間はソフトウェア業界以外の進路は何があるか？」だった。 「今更 IT ドカタやる以外ないだろ常考」「公務員ならなんとかなるかも？」「情報科目の教員免許はどうだろうか」「コンピュータに精通した事務員とか会計士とかアリじゃね」「起業とか？ 俺たちのスキルじゃ余りにもリスク高すぎるか……」etc,etc ずっとスレを追っていたわけではないが、前向きにソフトウェア業界行きたい
QA はプログラマと同じくらいすごい存在 - kagamihogeの日記
ここ数日、脳内お花畑全開の妄想混じりでプログラマから見た QA を書いてきたけど、実のところ言いたいことは「QA すげぇ」の一言に尽きる。 正直に告白させてもらうと QA の力をナメていた。テスト項目を一つずつ消化していく単なるテスターに過ぎないぐらいの勢いで。これって、プログラマは仕様を一行ずつ落とし込んでいくコーダーに過ぎない、と決め付けてるようなものだと気付いた。まぁ…もちろん QA エンジニアもプログラマと同じくピンキリなんだけどさ。 腕の良い QA はソフトウェアの品質を確実に一段階引き上げられる。俺のようなヘボいプログラマの書いたコードでも、お客さんにそれなりに満足して頂いているのは QA の存在が非常に大きい。今回のデスマで納品したソフトウェアは色々とボロボロではあったけど、ギリギリのラインで品質を保てたのは QA のおかげといっても過言ではない。 プログラマとマッタク異なる
反復型開発はプログラマだけでなく QA も幸せにするんじゃないかな - kagamihogeの日記
散々いろんなとこで語り尽くされている感はあるけど。デスマ中に QA との様々なやりとりからも、ウォーターファール的なやり方*1はもう限界だよなぁ、と感じている。 少し前のデスマで QA とこんなやり取りがあった。 「（渡されたアプリケーションを見て）事前の情報を遥かに超える規模のアプリケーションなので予定してテスト工数では足りない。話が違う、もっと機能少なかったんじゃないの？」 「完成度が低すぎる機能がある。QA の意味が無いので一時テスト作業を凍結する（もう要員割り当てちゃったよ。どうしてくれるんだ的な意味で）」 これらはテスト期間と要員の見直しが急激かつ大きく必要になるので QA からしたらたまったものではないだろう。QA は他プロジェクトの開発スケジュールと合わせてにらめっこしながら一つのプロジェクトのテスト期間と要員を割り振る。そのため、一つのプロジェクトにリソースをふりすぎると他
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
