何に対しても名前は重要だ。プログラマが知るべき97のこと書評このエントリを読んで昔よりはまともなソースコードが書けるようになったかな、と振り返った。昔は良いプログラムを書こうとしても書けなかった。経験も努力も足りなかった。プログラマが知るべき97のこと書評このエントリはタイトルが秀逸すぎる。誰のためにテストを書くのか?それはコードを見る人のためだ。コードを見る人は未来の自分かもしれない。そのためには良いテストを書かなければならない。プログラマが知るべき97のこと書評プログラミングにおける「再利用」を重視する人は多いですが、いつ、何を、どのように再利用すべきかがわからなければ、良い結果にはなりません。プログラマが知るべき97のこと書評もし無人島にIDEかツールのどちらかしか持っていけないとしたら、私は迷うこと無くUNIXツールを選びます。僕もUNIXツールを選択する。ここで言うUNIXツールとはコマンド群の事。プログラマが知るべき97のこと書評Webに限って言うなればプログラマやデザイナどちらも対象とすることができるエントリ。私は「ペアプログラミング」の信奉者です。ペアプログラミングは、協力の究極のかたちと言ってもいいでしょう。ペアプログラミングの利点は、プログラマとしてのスキルが確実に向上するということです。橋の構造解析に時間がかかるように、テストにもやはり時間がかかります。どちらも最終的な成果物の質を一定以上に保つためにすることです。今のプロジェクトでは毎日AM1:00ごろにDailyBatchと称してユニットテストを作動させている。ユニットテストは大体5分ほどで完了している。夜間に稼働させたほうが節電できるしね。前々からやりたいと思っているのだがなかなか手が出せていない。静的なコード解析ツールを用いることでリポジトリにコミットされているコードをチェックすることができると思うが時間が作れていない。やろうと思うのでエントリには残しておく。自動化するためのステップがやや面倒でも自動化はしたほうがいい。手で行なっているのであればそれはスクリプトを書いてcronに登録したほうがいい。「やり直し、だな...」、Deleteキーを押しながら上司が言いました。私は、毎度のことながらとても沈んだ気持ちで、コンピュータの画面を見つめていました。私の書いたコードが1行、1行きれいに消されていくのを見ていたのです。プログラマが知るべき97のこと書評シングルトンパターンが安易に使われてしまうとユニットテストがしにくくなりそう。このエントリーに書かれていたのでそう思った。シングルトンパターンの使い所は見極めよう。プログラマが知るべき97のこと書評ソフトウェア開発のプロジェクトでは、よほど小規模なプロジェクトは別にして、必ず人と人が共に仕事をすることになります。人は、人とともに、そして人のためにソフトウェアを書くというわけです。私たちプログラマは妙な生き物です。コードを読むとなると嫌がってしまうという性質があります。読むのは辛いと感じるのです。辛いのが、他人が書いたコードを読むことです。いうのがこのエントリーの肝。ある問題について十分に考えたら、あとは音楽を聴くなり、散歩をするなどして脳の創造を司る部分をはたらかせてみてください。プログラマが知るべき97のこと書評バージョン管理システムを使い始めてしばらくしたら思ったことだがまさにこの通り。プロジェクトを構成する要素は、とにかく何でもバージョン管理の対象のすべきでしょう。プログラマが知るべき97のこと書評プロのプログラマとは、どういう人のことでしょうか。いう態度、責任感です。難しい問題をそのままに受け止めて難しいコードを書く必要はない。いうか、難しく書いてはいけない。読むプログラマはその難しさに苦悩してしまうだろう。プログラマが知るべき97のこと書評そのとおりだと思った。結局実行されるのはソースコードのみ。ドキュメントが実行されるわけじゃない。人の言葉がそのまま実行されるわけでもない。プログラマが知るべき97のこと書評プロジェクトの中で「暫定ソリューション(その場しのぎ)」を作ったことがある人は多いのではないかと思います。間違いなく作ったことがあると思う。「プロジェクトを見える化」しようという発想。Integration:継続的結合)サーバ用意してそのなかで静的コード解析ツールを走らせたり、テストカバレッジを設定して通知したり。プログラマが知るべき97のこと書評このエントリーはこのような表現でも意味が理解できる。いろいろな人と目線を合わせる。コミュニケーションをとっていれば良いというわけではない。言い古された格言ですが、確かに真実です。ミース・ファン・デル・ローエという方の言葉らしい。余分なコードは決して書かない。