今日LIGのブログを読んで、直近自分の中で課題に思っていることと近いことがそのまま書かれていたので、非常に参考になった。そこで自分の思考を整理するためにも、以下の記事を読んでそのあたりについて思うところを書いてみる。 プロジェクトでトラブルが発生したときにWebディレクターがとるべき3つの手順 | 株式会社LIG 自分自身の課題 最近の自分自身の課題としては、「問題が発生したときに、すぐに解決手法を考えてしまう」というものだった。それには全く自分自身では気づいてなかったのだけど、最近はあるところで 問題を見つけた時、いちどその原因はなにかを考えたほうが良い 問題 = 原因ではない、そこを意識した方がいい との指摘を受けて、確かに自分は問題だと思ったときに、それが本質的な問題か別の問題なのではないかと考えてはいたと思う一方、問題の原因とは何かについては深く考えてなかったということに気づいた。

チーム開発実践入門という本が最近出ていたので、読んだ。 チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus) 作者:池田 尚史,藤倉 和明,井上 史彰技術評論社Amazon この本は良くない開発フローの例をケーススタディとして2章で紹介し、その後の章でそれに対応する形でバージョン管理やチケット管理、テスト、構成管理などの紹介をしている。 なんとなくエンジニアリングの開発フローがうまく行っていないけど、どこから始めていいか分からないという人には非常に面白いと思う。2章のケーススタディの例を読んでみて、その中で確かに自分のチームでもあるあると思えたところを中心につまみ読みしてみると良いと思う。 個人的にはほとんど知っている内容ばかりだったので、どちらかというと事例を含めてもう少し内容があると良かったように思う。 この本を読んでいる中で一番良かったの

今回はドキュメントの場所をどうやって気づかせるかという話を書く。 ドキュメントがあるときの問題 以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;に書いたとおり、僕の意見としては 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う というものだった。 基本的には一番近いコメントにすると、見つけやすさ・更新しやすさともにある程度担保することが出来る。しかし、メインの部分が明確に決まらない*1いろんなパーツが関係しあう機能の場合は、ドキュメントを書かないと全体の概要が分からないということもある。このような時、ドキュメントを書いても結局そのドキュメントに気づかれないし、そのため更新されないとい

最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと

以前職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;や補足 - 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;で紹介したコードコンプリートを再読した。 Code Complete 第2版 上　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCode Complete 第2版 下　完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 一年前はどちらかというと、コードのスタイルの話とか、条件をどうやって綺麗に書くのかとか、コメントはどう書くのかということを学びたくて読んだけど、今回はクラス設計をどうしていくべきかとか、チームでのエンジニアリングをどうしたら良いかとかを中心に読んでいった。 やっぱり学びたいと思っている内容が違うとそ

レガシーコード改善ガイド (Object Oriented SELECTION) 作者:マイケル・C・フェザーズ翔泳社Amazon レガシーコード改善ガイドを読んだ。 この本では、レガシーコードの内部をリファクタリングする際に何を気にする必要があるかとか、非常に長いモンスターメソッドをリファクタリングしていく時にまずどこからやるかとか、そういうことが書いてある。とにかくレガシーコードに直面して何から始めたらいいかわからないという時にはおすすめ。 リファクタリングという本と近い内容だけど、僕の中ではこの本よりはリファクタリングの方がなんとなく肌にあった。また今度再読してみようと思う。 印象に残ったところを書いていく。 依存関係を排除する 「たいていの場合、テストの最大の障害となるのが依存関係です」と書いてあるのだけれど、これは確かにと思った。いつもは無意識にやっているけど、言語化されてよかっ