アラン・ケイが考えるオブジェクト指向プログラミング - @katzchang.contexts
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Dr. Alan Kay on the Meaning of "Object-Oriented Programming" 私が考えるOOPはメッセージング、状態処理のローカルでの保有・保護・隠蔽、そして全ての物に対する強力な遅延束縛、これだけだ。これはSmalltalkとLISP
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
ソースコード改造の発注時に気をつけること - @katzchang.contexts
メモメモ。他にあれば、ぜひおしえてください。 ソースコード中の改変コメント（"// add 2011.02.03 katzchang start"等）は不要です。 元のソースコードのコメントアウトは不要です。必要ないコードはそのまま削除してください。 ifなどのブロック（"{ ... }"）の追加や削除の場合、ブロック中のソースコードに改変がないとしても、インデントを適切に増減させてください。 Javadoc コメントを記述する場合、定義と矛盾がないようにしてください。メソッドコメントの @param が特に矛盾しやすいようです。setter/getterのように自明であれば、省略しても結構です。 Javadoc以外で、ブロックコメント("/* ... */")は使わないでください。 SCMで適切に管理されていることが前提です。 追記 あぁ、大事なことを忘れていた。 VSSで管理しないでく
下限に合わせたプログラム設計はシステム開発を停滞させる - @katzchang.contexts
FxUG@北陸の懇親会で出た話題。 中規模以上のプロジェクトになれば、悲しいかな、テンプレにそったプログラムしか書けない人や、そもそもプログラムを書いたことすらない人が結構いたりします。10人もかき集めれば2〜3人、いや半分はそういう人だったり。リーダーさんは仕様検討とかで忙しいから、そういう初級者さんにプログラムの作成を頼らざるを得ないってのが現実です。 で、初心者さんにもわかりやすい設計のプログラムを量産していきましょう、となる現場はよくあります。なに、うちのところもそんなもんですよ。 でもそれで良いの？と、個人的には疑問を持っています。 初心者でも書けるように、テンプレートをコピーして使う。 コピペ駆動開発の副作用は周知の通り。 テンプレートが役立つのは限定的な場合。仕様が想定の範囲を超えればテンプレートを捨てなきゃならないけど、その判断を誰が下す？ 後々の保守しやすいよう、初心者で
プログラマが作ったスケジュールはいつも壊される - @katzchang.contexts
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログより。内容については同意します…というか、ほんとうにその通りだと思うけど、現状そんなに上手くいかない理由について列挙してみる。 いつも急かされる。 2週間かかりそうなものを、マネージャから「1週間で仕上げてほしい」と言われる。2週間かかる根拠を求められ、FP等の数字を算出しても「1週間で仕上げてほしい」と繰り返される。 単純に説得に時間がかかる。場合によっては1週間以上使ったり！ 時間をかけて説得できたらまだマシ。メンバーが"ハイ"と言えば万事おｋ、と思ってるPMはたまにいる。 顧客もまた然り。 こんな調子で「1週間あれば大丈夫でしょ」と言われ続けると、その内「1週間あれば大丈夫かも」と何となくそう思ってしまうパターンはマジでよくある話。 「あの機能が1週間の見積もりなら、この機能も同程度だろう」で、ズレが拡大
新人が一人で客先常駐って時点で、完全に終わってることを自覚しなさい。 - @katzchang.contexts
http://anond.hatelabo.jp/20080823023553という記事について。 すぐに客先常駐を中止して、社内勤務に変更しろ。これ以外の対処はない。残念ながら。 医師や専門家のカウンセリングも悪くはないけど、彼の状態の原因は勤務環境にある。その勤務環境を変えてあげない限り、長い薬物療法に入るか、退職するしかない。ただし、彼は自己評価が出来ない状態だから、彼自身は退職なんて手も打ちづらい。 とにかく個人的なことで会社に不満を持っていると感じた。 まったく勉強してなくて、理解出来てないことでも、"自分は出来る"と自信だけは異常なくらい持っていたり、不思議な感じもした。 （話だけを聞くとデキル人間のように感じるけど、ちょっと突っ込むとすぐにボロが出る。） http://anond.hatelabo.jp/20080823023553 個人的なことって(笑) 想像してみなよ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
