いろいろ
i d e a * i d e a – 人生をシンプルにする方法(2005年度版)
フリーマインド
Going My Way: Going My Way RADIO 2005-05-30
http://kengo.preston-net.com/archives/001978.shtml#001978
オブジェクト指向は分類学なのか?
「これは分類学なんだな」ということでした。
手続き型のプログラムをたくさん書いていると、よく似た処理をまとめたくなってきます(特にそうはならない勤勉なプログラマを除いて)。
例えば、ユーザーのデータをデータベースから引っ張り出して、その人が本登録済みかどうかを判定する、という処理を毎回書いているうちに、どこか1箇所に書いて、全ての場所からその処理を使いまわしたいと思うのは自然な流れです。
この「処理を1箇所にまとめる」という時にどうまとめるのか?
例えばユーザー本登録チェックモジュールみたいなのを作って毎回呼び出すとか、色々方法がありますが、その色々な中で生き残って色々な可能性に耐えているのが、「物=オブジェクトを元に分類する」ということなんだなあ、と感じたのが僕の理解でした。
つまり、「ユーザー」というオブジェクトを作って、そのユーザーに「あなたは本登録済みですか?」と聞くのが分かりやすく、現実世界の概念に似ているために、分類が行いやすく、また、多くの開発者の中で共有しやすいんだろうなあと思います。
実際に開発をやっていると、何がオブジェクトになれるのか、とか、どのオブジェクトが処理を行うのが自然なのか、みたいな疑問がしょっちゅう出てくるわけですが、こういう問題をあれこれ考えるのは「この世の中は何でできているのか?」というパズルを解いているみたいで、個人的に楽しく感じています。
以下の方法で解決!!
Windows XPでExplorer.exeがCPUリソースを100%使用するバグが発覚 (MYCOM PC WEB)
○「フォルダに共通の作業を表示する」をオフにする
(1)[スタート]→[コントロールパネル]を選択する。
(2)[デスクトップの表示とテーマ]→[フォルダオプション]をクリックする(もしくは[フォルダオプション]アイコンをダブルクリックする)。
(3)「フォルダオプション」が表示されるので、[全般]タブにある[従来のWindowsフォルダを使う]を選択して[OK]をクリックする。
無駄なドキュメントは書くな。時間の無駄である。実装は日々変化する。それに追従する形でドキュメントが更新されるということはない。断言する。実装に関するドキュメントと最新の実装は常に食い違っている。いまだかつて同期したことがない。無駄なドキュメントを書く時間があるならコードを洗練しろ。無駄なドキュメントを書く時間があるならコードをドキュメントにしろ。
個人のミッションステートメントを書こうと思う
自分が何をしたいのかはぜんぜんわかんないけど、とりあえず地道にやっていく。考えたことをすこしずつ実践して自分のものにする。自分にできることはどんどんやる。タスクはどんどんためる。たまったら片っ端から片付けていく。
いろいろSE系文書
失敗しない情報システム調達 – 顧客の視点で、アジャイルを説明
情報システムを調達するときに、情報システム開発会社(以下、「やつら」と略記)から不当に搾取されないように!!!
保守の21箇条
一.保守者はシステム開発のすべての工程を短期間で行う技量が必要と心得よ。.. 1
二.ソフトウェア開発の教育のみを行っても保守者育成には不十分と心得よ。.. 2
三.保守担当者が将来に不安を持たないようなキャリアパスを確立し,提示すべし。.. 2
四.保守はシステムの現在と未来の課題に対するソリューションサービスであると心得よ。 2
五.開発と呼ばれているソフトウェアの作業も保守であることが多い.. 3
六.システムライフサイクル中で保守プロセスの期間が最も長いことを再認識せよ.. 3
七.保守作業は規模の大小・期間の長短に関わらず,担当者任せにするべからず.. 3
八.保守対応費用の請求先はその発生原因によって異なることに注意せよ.. 4
九.保守作業にコンカレントエンジニアリングが必須と心得よ。.. 4
十.保守履歴を丹念に分析すれば,今後の保守案件の発生予測が可能。.. 4
十一.経済情勢の変化が激しい今は,保守案件が増加すると予測せよ.. 4
十二.システムの状況は個々に相違あり。保守部門自らが現状認識し保守戦略を立てよ.. 5
十三.開発担当者が片手間に保守作業しているような状態を作るべからず。.. 5
十四.開発部門とは独立した部門が保守すれば,開発部門の品質は上がる。.. 5
十五.保守部門は職務分掌を明確にして,組織として行動すべし.. 5
十六.保守コストを下げるためには最もコストのかかる作業(事前調査とテスト)の効率化を第一優先にすべし。 6
十七.保守案件単位に最適な共同レビューを実施すべし.. 6
十八.保守案件の多いシステムは低品質ではなく,ユーザが積極的に利用していると考えよ 6
十九.開発者が保守しなければならないのは,開発品質が悪いからである。.. 6
二十.保守の戦略や計画の立案及び保守作業の環境整備に力を入れよ.. 7
二一.開発者から保守を引き継ぐ際,開発者から保守性の設計思想を出させるべし