キレイなコードでも仕様書の代わりにはならない - 設計者の発言
４ＧＬ（第四世代言語。既に死語）を使っていた頃に「ソースコードが仕様書だ」と言い張っていたことがある。テーブル操作コマンドと統合されているそのプログラミング言語を使えば、じっさい英語の文章のように明解にコーディングできた。しかしそんな強力な言語を前提にしても、今から考えれば「コードが仕様書だ」と主張したのは間違いだった。 理由は単純。仕様書として通用するほどキレイにコーディングが可能と謳われている言語を使ったとしても、コーディングがキレイになることが「保証」されているわけではないからだ。まあ当然のことで、文章の読みやすさが書き手によってまるで違うのと同様、コードの読みやすさはプログラマによってまるで違う（その日の気分や体調によっても違うかもしれない）。いかに標準化を徹底しようが、同じ動きをするのにいっぽうは読みやすくいっぽうはわけがわからないなんて事態は日常的に起こる。そして、システム開発
詳しすぎる詳細設計書 - SiroKuro Page
「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力： 「性別と身長のペア」のリスト 出力： 男性の平均身長」と「女性の平均身長」の差 処理概要： 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を１つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を１増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を１増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい
詳細設計書が滅亡しない理由 - kagamihogeの日記
IT 業界というか SIer の枠組みの中で働いている人であれば、一度は詳細設計書ないし詳細仕様書というドキュメントを見たか書いたことがあるだろう。 Excel 方眼紙の悪夢 詳細設計書の話の前にちょっと触れておきたいのが「Excel 方眼紙」 これまでのプロジェクト経験とネットの情報を見る限り、詳細設計書はほぼ 100% コレで書かれている。Excel 方眼紙がどのようなものかは こんな感じ である。典型的な使われ方は 【図解!!コレが方眼紙Excelだ！】:島国大和のド畜生 がわかりやすい。 「Excel 方眼紙」でググるとわかのだが、コイツは猛烈に嫌われている。一発作り捨てならば、図や表を交えたドキュメントをそこそこ作りやすいという利点はある。プレゼンや紙印刷を考えないならば、個人差はあれど PowerPoint 並の使い勝手を覚える人はいる。 がしかし、Excel 方眼紙はそのメリ
オブジェクト指向の皮をかぶった関数型プログラミング言語 Haxe
2013/08/25のなごやまつりでの発表資料です。マクロと抽象型の説明は力尽きたのでやっつけです。Read less
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（後編） 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。お読みのページは後編です。 大規模なテストをどうやって実行しているか 続いて、大規模なテストについて。 1000万件のテストパターンを作っても、それぞれのテスト結果の正解を人手で作っていたら追いつきません。なので、別々に運賃計算ソフトウェアを作って、その答えを突き合わせてチェックしよう、という話です。 例
Cocoa関西勉強会#54でTDDについて話してきました #cocoa_kansai - yashiganiの英傑になるまで死ねない日記
最近TDDやってて意識高まりまくってるので，TDDについてCocoa勉強会関西#54でTDDについて発表してきました． 個人の感想レベルの発表なのでTDDモヒカンの方は斧をおさめてください． スライドはこちらです． スターお待ちしています． あと，サンプルに出した駅探索APIクライアントとテストコードですが，こちらに置いておきました． yashigani/HREClient · GitHub このAPIを叩くやつです．駅検索APIにしか対応してないから使えるかわからんけど一応podspecもつけておきました． XCTest/Kiwi/Spectaのテストがついてますので参考にどうぞ． KiwiとSpectaは同時にビルドできないので，試したいほうをpodfileで有効にして，いらないほうのテストはビルドから外してください． TDDをはじめた感想 参考までにTDDをはじめた筆者の様子を共有し
gitのdiff, status, logを極限までコンパクト化＋便利化する - Qiita
git diffを見やすくする git diff --color-words で差分を小さく表示する 通常のgit diffは行単位なので、例えば変数名を一括変更した場合見づらいです。 --color-wordsを指定すると記号やスペースで区切られた単語単位でのdiffを表示できます。gitの設定は不要です。 より細かな表示のカスタマイズも可能です。man git-diffで--word-diffを検索してみてください。 ※ただし、変更が複雑な場合は、通常のgit diffのほうが見やすいこともあります。 .gitattributesを設置してもっと小さく表示する .gitattributesファイルを設置することで、言語文法に基づいて変数名、関数名といった単位でdiffを表示できます ファイル設置後にgit diff --color-wordsとすると、下記のようにさらに小さく表示できま
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
DevLOVE 『誰が為のテスト』 ～ 千里の道も一歩から ～ 和田卓人さん (1/4)
DevLOVE 世界のすべてをテストせよ。 ～Make the world Green by Test ! ～
VB6からVB2008 への移行に関して
ＶＢ６（Visual Studio6.0)がWindows7や8で使えずいずれサポート打ち切り、最悪はそのＥＸＥも次期ＯＳでは動かなくなる恐れから止むをえずＶＢ２００８へ変換を試みていますが、余りにＶＢ２００８は利用者泣かせよくもこのような製品を世に出したなと言わざるを得ません。ＶＢ６で便利に使えていた機能をことごとく排除、オブジェクト指向と言う単に技術者の傲慢、自己顕示欲を示すだけの製品になっている。オブジェクト指向になってどこがどう便利になったのか複雑怪奇にしただけで便利さや機能の優れている点等どこにも見えない。ＶＢ６の便利な機能排除の主な物は以下の通り。 Inetコントロール、Winsockコントロールの排除、コントロールの配列機能排除、ポップアップメニュの左クリック排除、フォームのUnloadの排除等等 その他枚挙にいとまない。またこれを代わりの方法で実現する方法等本にも書いてない
git bisect で問題箇所を特定する - Qiita
以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか？」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします（例えばソースからのビルド処理もテストスクリプトに含めま
集中型バージョン管理システムと分散型バージョン管理システムって - 未来のいつか/hyoshiokの日記
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Private Site
ソフトウェアの基礎
20110409_DevLOVE「DDDについて」_和田卓人さん
ソフトウェア開発を勉強し始めて3年間でやったこと～After～ #devsumi
20110409_DevLOVE「Building Blocks」_都元ダイスケさん
GitHub - gitbucket/gitbucket: A Git platform powered by Scala with easy installation, high extensibility & GitHub API compatibility
