雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
テストコードにまつわる5つのエトセトラ - give IT a try
はじめに ひとつ前のエントリでRSpecの話を書いたので、それにちなんで最近僕の身の回りで起きたテストコードに関する雑多なエピソードをいくつか書いてみます。 その１：テストコードを書いてない処理で見事にバグを出してしまった・・・！！ 僕はソニックガーデンの中では「テスト番長」の異名を持っていて、基本的にテストコードはしっかり書くタイプです。 ですが、どうしてもリリースを優先しなければいけないときは、やむを得ずテストコードを後回しにして先にリリースすることもあります。 先日リリースした「テストを後回しにしたコード」は、リリース直後は問題なく動いていました。 その数週間後、別の仕様変更が入り、変更したコードをリリースしました。 「テストは全部パスしているので大丈夫なはず～！」と思ったら、リリースの翌日に変なシステムエラーが発生。 エラーが起きている場所を見て、ガーン。 例の「テストを後回しにし
ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
プログラマ向け：自分の強みや得意分野を見つける方法 - give IT a try
質問：あなたの強みや得意分野は何ですか？ プログラマのみなさんに質問です。 あなたの強みは何ですか？ 胸を張って「任せとけ！」と言える得意分野はありますか？ これはソニックガーデンの採用面談でよく聞かれる質問です。 僕もときどき採用希望の人と面談（という名の雑談）をすることがあるのですが、この質問に対して「はい、私はxxが得意です！」と即答できる人はかなり少ないです。 まあ、入社を希望する段階でいきなり「これが得意です！任せてください！」と言うのはかなり勇気がいりますよね。 下手に偉そうなことを言って、あとから「なんだ、大したことねーな」と思われたくない、という不安もきっとあるでしょう。 僕もかつては即答できなかった 何にせよ、即答できない気持ちはよくわかります。 実際、ソニックガーデンに入社した当時の僕もそうでした。 しかし、入社してから3年ほど経ってみると、いつの間にか僕にも得意分野（
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
「Coupe Baguette」のWebサイトができあがるまで - give IT a try
はじめに 明けましておめでとうございます。 新年第一弾のブログは前々から温めていたプライベートプロジェクトのご報告から始めたいと思います。 妻がパン屋を始めました 実は去年の年末から妻がCoupe Baguette(クープバゲット)という小さな手作りパン工房を開店しました。 まあ、平たくいうとパン屋さんです。 別にこれで大儲けしまくろうとか、そんな大きな野望はなくて、あくまで趣味の延長でやっているお店です。 まだ子どもも小さいし、家事と育児を兼業しながらやらなきゃいけないので、営業日も金曜日と土曜日だけです。 とはいえ、妻のパン作りに対する熱意と研究熱心さは僕も舌を巻くほどなので、パンの味は抜群にうまいと思います。 職人です。完全に独学だけど。 「国産小麦や天然酵母を使ってるけど、前面には押し出したくない。あくまで味で勝負したい。」 「どんなに体にいい食材を使っていても、おいしくなかったら
これまでに読んできた技術書を振り返る - give IT a try
このエントリを書こうと思ったきっかけ irofさんのこちらのエントリが面白かったので、僕も技術書についてあれこれ書いてみたくなりました。 私の技術書の選び方 - 日々常々 僕の場合は技術書の選び方、というテーマではなくて、自分が技術書とどのように付き合ってきたのかということを振り返ってみたいと思います。 序盤 僕もこの業界に入った時は、技術書らしい技術書よりも「xxxポケットリファレンス」とか「逆引きxxxの技」みたいな、「書いてある内容をそのまま書き写せば終わる」タイプのリファレンス本をよく買っていた気がします。 代表的な一冊はやはりコレですね。 【改訂第3版】 SQLポケットリファレンス (POCKET REFERENCE) 作者: 朝井淳出版社/メーカー: 技術評論社発売日: 2009/04/29メディア: 単行本（ソフトカバー）購入: 6人 クリック: 117回この商品を含むブログ
Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編) - give IT a try
2011.12.31 追記 後編を書きました。こちらもあわせてどうぞ。 Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(後編) - give IT a try はじめに 先日、FizzBuzz問題を使って社内プログラミングコンテストを開きました。 このブログでも書いた通り、なかなか興味深い結果になりましたが、一方で反省点もいくつか見つかりました。 特に問題が解けなかった人が出てしまったのは痛い誤算だったので、今回はできるだけ最後まで解けるような配慮をしてみました。 ただし、問題自体はFizzBuzz問題よりもずっと難しくしてあります。 今回もちょっと長いエントリになっていますが、よろしければ最後までお付き合いくださいませ。 前回の反省点 詳しくはこちらのエントリに書きましたが、簡単にまとめると 言語の得意・不得意が結果に大きく影響した 抜き打ちで実施したことがその
ダメエンジニアの使い道 - give IT a try
ダックタイピングは間違い？ - give IT a try ↑のエントリで書いたダックタインピングとダメエンジニアの関係や考え方について、Matz先生の非常に興味深いコメントを読ませてもらいました。 以下にちょっと引用してみます。(またまた無断転載ですみません・・・) ダメエンジニアしか手に入らないという悲観的な考えと、ダメエンジニアでも鎖で縛れば使い物になるという極度に楽天的な考えが同居できるもんなんだな。— Yukihiro Matsumoto (@yukihiro_matz) September 15, 2010 「うちのエンジニアはダメダメだ」と「こいつらを矯正してなんとかまともな仕事をさせてやる」ってのは、一番ダメな組み合わせじゃないか。ダメなのはエンジニアじゃなさそう。— Yukihiro Matsumoto (@yukihiro_matz) September 15, 201
FizzBuzz問題が解けなかった理由を聞いてみた - give IT a try
はじめに かなり大きな反響があった第１回社内プログラミングコンテストの後日談です。 FizzBuzz問題が解けなかったメンバーに、なぜ解けなかったのか、どうすれば解けていたのかを質問してみました。 また、第１回コンテストの良かった点、悪かった点をふりかえり、次回以降の改善ポイントを考えてみます。 何の話かよくわからない方は先にこちらをどうぞ↓ FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try なぜ解けなかったのか、どうすれば解けていたのか？ メンバーの回答から、解けなかった理由をピックアップすると以下のようになります。 Perlに慣れていなかった 起動時引数の取得やあまりの求め方を調べるのに大半の時間を使ってしまった Perlの業務経験は改造案件が中心で、この種のプログラムをゼロから作ったことがなかった ルールを勘違いして、もっと得意な
FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに！？ ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第１
SQLとの付き合い方 - give IT a try
はじめに 先日、会社のメンバーから「SQLのJOIN文を視覚的に理解する」というサイトを紹介されました。 SQLのJOIN文を視覚的に理解する | IDEA*IDEA おいらも見てみたのですが、「自分がSQLを書いたり読んだりする時はこんなベン図を思い浮かべることはまずないなあ」というのが正直な感想でした。 そこで、おいらがSQLを書いたり読んだりする時の思考過程をアウトプットするとどうなるだろうかと考えてみました。 SQLを書く場合 おいらの場合、以下のような手順でSQLを組み立てています。 1. ルートとなるテーブル(出力のメインデータ)を決める。 まずはベースとなるSQLを書き始めます。 テーブルによっては大量のデータを抱え込んでいる可能性がありますので、とりあえず件数だけを確認するようにします。 SELECT count(*) -- 今回は書籍注文情報をメインデータとする FROM
自動化テストで気をつけること - give IT a try
先日、会社のメンバーからテストの自動化に苦労しているという話を聞きました。 そういえば、一言で「テストの自動化」といっても結構奥が深いので、自動化テスト初心者が注意すべき点や重要なポイントをちょっと考えてみました。 自動化テストの注意点 どのような処理でもプログラムとして自動化できるプログラミングスキルを実装者が持っていること。 結局、手作業でやっていることのほとんどをプログラムとして実装する必要があるからです。 いつでも、どこでも、誰が実行しても同じテスト結果が返ってくるようにテストを作成すること。 たとえば、テストの成功・失敗がシステム日時や外部ファイルやデータベース等に格納された不安定なデータに依存しているとテストがすぐに壊れます。 壊れたテストを放置しないこと。 少なくともソース管理システムにコミットしたファイルはすべてパスするようにしましょう。 壊れたテストを放置すると、誰も自動
C#のコード品質を上げるフリーツール8本 - give IT a try
はじめに 読みにくいコードや複雑なコードをメンテナンスするのってイヤですよね。 コードの品質を上げる方法の一つにコードレビューがありますが、すべてのソースコードを人力でチェックしていくのは大変ですし、レビュアーのスキルや好みにも大きく依存してしまいます。 そういう場合はツールを使って自動化するのが有効です。 ツールを使えばあっという間に完了しますし、実施者のスキルや好みに左右されることもありません。 しかし、あまりお金がかかるツールだと、ちょっと気軽に導入しにくいです。 そこで今回はC#のコード品質向上に有効なフリーツールを紹介します。 実際のプロジェクトで使用したことがあるものばかりなので、どれも「使えるツール」だと思いますよ。 ところで、ツールを紹介する前にTipsと注意点を簡単に挙げておきましょう。 ツールを利用する際のTips 自分の書いたコードのみを対象とし、ツールが作成したコー
犬小屋と高層ビルの違い - give IT a try
ちょっと興味深いエントリを見つけました。 IDE教育に不安を覚えること - みねこあ なるほど、Smart UIと呼ばれる作り方が、システムの品質を下げるという点は同意です。 ただ、その原因がIDEにあるのかというと、必ずしもそれだけではない気がします。 おいらが思う一番の原因は、犬小屋と高層ビルの作り方の違いに気づいていないプログラマが多いせいではないかと思っています。 つまり、「はじめてのXXX」とか「一週間でわかるXXX」みたいな本やWeb記事には、ごく基本的な文法の説明や簡単なサンプルプログラムの作り方しか載っていません。 こうした説明のほとんどはSmart UIパターンになっていると思います。 もちろん初心者向けの内容なので、簡単な内容に終始してしまうのは仕方ありません。 しかし、ここで説明されているのは、いわば犬小屋の作り方です。 実際に業務でシステムを構築する場合は犬小屋レベ
社内SEの憂鬱? - give IT a try
先日紹介した「残念なコラム」にあったコメントからの抜粋です。 あなたが生き残っていられるのは、 「企業の情シ」というクローズドな環境にいるからです。 （「企業の情シ」が楽だとかレベルが低いという意味ではありませんので、情シの皆さんは誤解しないでください） あなたは自分の技術にかなりのプライドを持って居られるようですが、 オープンな人材市場ではあなたには、業務知識にしか値段が付かないでしょう。 （ここは多くの方に同意していただけるはずだと思います） そこを自覚された方がよろしいかと思います。 う〜ん、確かにそうかもしれません。 下請け中心のSIerから外資系製造業の社内SEに転職して約3年。 お給料がかなりアップしました(今はちょっと良すぎる気も・・・)。 残業が減りました(今は月30時間以下にしろと言われる)。 土日出勤がなくなりました(未だに一日もありません)。 納期やコストのプレッシャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
