社内のメンバーに紹介しようと思ってためてきた各種Web記事へのリンクが大量に溜まっちゃいました。
ついでにここでも紹介しておきます。
一部の記事は会員登録が必要かもしれません。あしからず。。。
プログラミング/プログラム設計
プログラミングについてあまり知られていない７つのこと
http://www.tommyjp.com/2010/08/blog-post_1710.html
=> どれも超重要。知らなかった人はこれを機に覚えておきましょう。
ソースコードの質
http://el.jibun.atmarkit.co.jp/genmaicha/2010/11/post-5c3e.html
=> 保守性、可読性、拡張性の重要性について。
技術的負債
http://d.hatena.ne.jp/asakichy/20101210/1291936604
=> 技術的負債の原因や解決策について(その1)
技術的負債、マネージャの視点
http://www.infoq.com/jp/articles/technical-debt-levison
=> 技術的負債の原因や解決策について(その2)
「気合いでやり抜く努力型」
http://d.hatena.ne.jp/JavaBlack/20101201/p1
=> 「試行錯誤だけに頼ってプログラムを組んでいると、無茶苦茶なプログラムになる」。太字の部分にも要注目。
Write Less Code!
http://goodliffe.blogspot.com/2010/10/write-less-code.html
=> コードを短くすることの重要性について。(英語)
The Three "R"s of Clean Code
http://agile.dzone.com/news/three-rs-clean-code
=> クリーンなコードの基準は「読みやいこと」「信頼できること」「責任を負っていること」。そしてLess is More！(英語)
プログラマが知るべき97のこと
http://bit.ly/gTqrjk
=> オライリーから出ている本ですが、一部ネットで読めます。
プログラマが知るべきではない97のこと
http://d.hatena.ne.jp/tt_clown/20101213/1292232085
=> ネタです。社内開発ではそれほどじゃないかもしれないけど、世間のソフトウェア開発会社はたぶん該当項目が多いはず。。。
スーパーエンジニア達の習慣/成長しないエンジニアの悪習慣
http://hiroki.jp/2011/01/16/1472/
http://hiroki.jp/2011/01/18/1492
=> 自分に照らし合わせてみるとどうでしょうか？？
マイクロソフト アプリケーションアーキテクチャガイド2.0
http://www.microsoft.com/japan/msdn/vstudio/2010/solutions/architecture/
=> プログラムが書ける人(プログラムしかできない人)から新規システムをゼロから構築できる人にステップアップしたいなら、この手の知識は不可欠です。
設計と実装の両輪
http://d.hatena.ne.jp/j5ik2o/20091214/1260814225
=> 「上級のプログラマを目指すなら設計能力こそ磨くべき。」まさにその通り。
データベース
リレーショナル・データベースの世界
http://www.geocities.jp/mickindex/database/idx_database.html
=> 地味なデザインのページですが、データベースやSQLに関する情報は充実しています。
Queries, Damned Queries and Statistics
http://www.simple-talk.com/sql/performance/queries,-damned-queries-and-statistics/
=> SQL Serverの実行計画等を解析する手法。(英語)
Listing common SQL Code Smells.
http://www.simple-talk.com/community/blogs/philfactor/archive/2010/11/22/95781.aspx
=> 不吉な臭いのSQLについて。思い当たる項目はありませんか？(英語)
SQL Server Unit Testing with tSQLt
http://www.simple-talk.com/sql/t-sql-programming/sql-server-unit-testing-with-tsqlt/
=> T-SQL向けのユニットテストツール。たぶんマイナーだと思うけど。。。(英語)
開発手法・開発プロセス等
30分でだいたいわかるアジャイル開発
http://www.slideshare.net/kakutani/agile-in-30mins
=> だいたい分かるかも。
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ
http://blog.madoro.org/mn/84
=> 開発手法や組織のありかたについて。
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与
http://www.atmarkit.co.jp/news/201011/08/nar.html
http://se.naist.jp/events/srw2010/report1.html
=> 保守開発の工数見積もりの精度が向上できるかも。
プログラミングと設計は本来切り離せないものなのでは
http://d.hatena.ne.jp/ryoasai/20101030/1288432422
=> たしかに設計チームと実装チームは分けない方がいいと思う。
プログラマーの成長を考えないSIerの仮説は間違っている
http://d.hatena.ne.jp/ryoasai/20101206/1291640678
=> 「アーキテクトのスキルをプログラマーにトランスファー」するというのは経験上有効だと思う。
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
http://www.publickey1.jp/blog/10/post_139.html
=> むやみに人を投入してはいけないというのは昔から有名な話なわけでして。
人類初のソフトウェア・メトリクスをめぐる熱い論争
http://monoist.atmarkit.co.jp/fembedded/articles/kumikomi/24/kumikomi24.html
=> 細かい問題点はあるかもしれないけど、循環的複雑度(サイクロマチック複雑度)は大まかな指標にはなると思うよ。
文書
カーリル：【論文】カーリル開発の核心 コンセプト、組織、技術
http://calil.s3.amazonaws.com/pdf/introduction_of_calil_rakusai.pdf
=> システムの概要がこんな感じにまとめられていたら完璧だと思う。
詳細設計書が滅亡しない理由/技術の空洞化
http://d.hatena.ne.jp/kagamihoge/20100220/1266624446
http://dvamp.blog62.fc2.com/blog-entry-22.html
=> ソースコードと一対一で対応するようなドキュメントはさすがにいらないと思う。
その他
社内を幸せにするEUC
http://www.atmarkit.co.jp/im/cbp/serial/euc/index.html
=> エンドユーザーコンピューティングをコントロールするのは難しいよね。
業務破壊の地雷原、野放しのExcelシートをなくそう
http://www.atmarkit.co.jp/im/cits/serial/erpforsmb/07/01.html
=> 「未管理のExcelシートは、業務ノウハウの属人化の象徴 」。ありがちありがち。。。
なぜIT部門は提案できない／しないのか？
http://www.atmarkit.co.jp/im/cits/serial/murphy/32/01.html
=> 我々からの提案はもしかして嫌がられている！？
HTML5で進化したフォーム機能 ここが違う！サンプルで見るHTML5（5）
http://codezine.jp/article/detail/5652
=> 業務系のWebアプリを作るならこのあたりは要チェックかも。
Googleブックスで読めるソフトウェア開発に関する本たち
http://d.hatena.ne.jp/dearna/20101216/1292472757
=> ゲーム開発関連の本が多いですが、ネットで読める本がたくさん並んでます。
基調講演 "Librahack"事件を総括する
http://www.libra-sc.jp/project/2011011511581447.html
http://www.libra-sc.jp/project/doc/2011011511581447_1.pdf
=> 技術屋としては「どんな欠陥があったのか」「システムの動きを図説する」で挙がっているような問題の原因と対策を答えられるようにしたい。
