Javaアーキテクトの鉄則

* 必ずCheckStyle, FundBugs, JUnit. Apache Ant, Apache Mavenを使用すること。
* IDEは必要に応じて任意に使用。使える環境であるならば使うことが望ましい。
* 英語を極めよ。海外サイトでいち早く最新技術動向を調査し、プロジェクトに採り入れよ。
* クラス名、オブジェクト名はなるべく名詞形に、メソッド名はなるべき動詞形に。
* 『アジャイルソフトウェア開発の奥義』を読破し、実戦せよ。
* 最低でもGoFデザインパターンは極めよ。
* 不変クラスの作り方くらいは極めよ。
* Jakarta Projectの製品くらいは使いこなせるようにすること。
* 必ずXP, RUPなどを実戦すること。
* 設定ファイルは死すべし！ Seasar2, Spring FrameworkなどのDIコンテナを使うこと。
* 文字コードはすべてUTF-8で統一すること。Shift_JIS, EUC-JPなど論外！
* 必ずUML、データベース設計、ネットワーク技術、セキュリティ技術を極めること。
* データベースの扱いにはHibernateなどのO-Rマッピングツールを使うこと。
* ソースコードには必ずJavadocコメントを加えること。
* 分割し、統治せよ。モジュール間の依存度はできるかぎり疎になるようにすること。
* 一つのメソッドは100行を超えてはならない。一つのクラスファイルは1000行を超えてはならない。
* 常にリファクタリングせよ。とにかく自動化して開発効率を高めよ。
* 必ずアノテーション、Genericsを使うこと。
* Tomcatの設定web.xml等は手書きせず、XDoclet等を使用してServletソースのコメントだけに記述すること。

またつまんねえのたったな

* ソースコードはEclipseなどのフォーマッタを用いて常に綺麗にしておくこと。
* いつでもプログラムを拡張できるようにしておくこと。
* パッケージ名の接頭辞には必ずドメイン名を使用すること。
* 環境変数CLASSPATHは絶対に使用するな。コンパイラ/実行オプションを使ってクラスパスを追加すること。
* importには*を使用してはならない。
* インスタンスフィールドは、パッケージプライベートでない限り、できる限りprivateにすること。
* メソッドの引数はできる限りfinalにせよ。
* プロファイラを使用してパフォーマンスチューニングすること。
* Hashtable, Stack, Vector, Propertiesは使用禁止。替わりに、HashMap, ArrayList, ResourceBundleを使用すること。
* 例外はきっちりと補足すること。catch(Exception e)だけで済ませることは絶対に許されない。
* try-catchステートメントでは絶対にreturnを使用しないこと。
* Statementは使うな。替わりにPreparedStatementを使用すること。ストアドプロシージャやO-Rマッピングも考慮に入れよ。

* データ型として利用するクラスは必ず不変クラスにすること。
* データ型として利用するクラスには、必ずequals(), hashCode(), toString()メソッドをオーバーライドすること。
** 必要であれば Comparebleインタフェースを実装してcompareTo()もオーバーライドすること。
* オーバーライドされたメソッドには必ず@Overrideアノテーションを付加すること。
* @SupressWariningアノテーションはテストコード以外では絶対に使用しないこと。
* メソッドの引数はだいたい3つまでにしておくこと。可変引数以外で引数が6つ7つなどのメソッドは作ってはならない。
* 配列はできる限り使用せず、Collectionを使うこと。
* どうしても配列を使ってパフォーマンスをあげたければBufferを使うこと。
* 定数宣言にインタフェースを使用しないこと。替わりにprivateコンストラクタを持つfinalクラスを使うか、enumを使うこと。
* クラス内で同じクラスのインスタンスメソッドやインスタンスフィールドを参照するときは接頭辞に必ずthis.を追加すること。
* クラス内で同じクラスのstaticスメソッドやstatic変数を参照するときは接頭辞に必ずクラス名.を追加すること。
* DB接続にはClass.forName()を使用せず、DataSourceを使用すること。
** データソースの設定情報はserver.xmlには記述せずXDocletなどで読みとれるようにJavaソースのコメント欄に記述すること。
* 複数のJARファイルに依存したプログラムを配布するときはFatJarを用いてすべて一つのJARファイルにまとめること。
* Tomcatなどで動くウェブアプリケーションは必ずWAR(Web Archive)で一つにまとめること。

うわぁ
ストラッツのimport行数みたいだ

よし、上から順に理由を述べていってもらおう

Java飽きてきた

鉄則多いなあｗ

＞* 『アジャイルソフトウェア開発の奥義』を読破し、実戦せよ。

この本買う価値あるの？

ちなみに
Effective Java
ＨＰ： 19200　攻撃力： 3000　防御力： 400

プログラミングVisual C# 2005
ＨＰ： 19200 　攻撃力： 3000 　防御力： 5500

Java言語で学ぶデザインパターン入門
ＨＰ： 19200 　攻撃力： 00 　防御力： 5500

内容良くてもバーコードバトラー2で勝てないと意味ないよね

勉強になるからもっと書いて

Javaえらいよ、やっぱすげぇよ、さすがに開発論が活発なだけあるな。
それよりも>>1がすげぇ、VB厨はおろか、C++厨にこんなん書けるか？
無理だろｗｗｗ　いやぁ、Java選んで良かったよ。俺ももっと勉強しよ。

ところが3000行のメソッドをコピペで作るのがJAVA厨である。

>>1を守ったらデスマが無くなるっていうのなら守る。
>>1を守ったら利益率５０％超えるっていうんなら守る。
>>1を守ったらかわいいあの子とごにょごにょできるんなら守る。

でも無理だろう。
まあ>>1をもう少し解りやすく書いてプロジェクトを成功に導くのがアーキテクトじゃない？

>>13
findbugsとcheckstyle入れればいいだけ。
あとはEffective Javaでも読んどけ。

>>3
> importには*を使用してはならない。

「Javaパフォーマンス戦略」とかいったJavaテク本には、それと逆の事が書いてあったけど。
「importの正確さなんか、こだわるだけ無駄。保守が大変。」とかね。

>>14
「Effective Java」はJava嫌いの俺でさえ「良書」だと思ったし、ちゃんと読破したよ。

それにしてもJava開発って本当ウンザリだなあ…。
数年前に足洗ってC++に戻ったけど、本当に良かったと思うよ。

>>9
> ＞* 『アジャイルソフトウェア開発の奥義』を読破し、実戦せよ。

> Effective Java
> Java言語で学ぶデザインパターン入門


うむ、この本も追加しておこう。

『アジャイルソフトウェア開発の奥義』は内容が濃く、かなりのもの。
Open/Closed Princlpleなどのテクニックが乗っている。


型推論を使っている言語やプロトタイプベースオブジェクト指向と呼ばれる
JavaScriptなどのようなスクリプト系動的片付け言語には
真似できないものだが。

これを実戦できないのはオブジェクト指向ではないと、この本では説いている。

そのため、JavaScript, PHP, Perl, Ruby, は、この本の定義によれば
厳密には「オブジェクト指向言語ではない」ということなんだそうだ。

なぜならば、これらの言語では先ほどあげたOpen/Closed Principleなどの法則を実現できない
(完全に実現することが難しい)からだ。

>>13-14
確かに、守っただけではデスマが無くなって即座に利益に繋がるとは
限らない。

だが、刀は磨けば磨くほど強くなる。ソースコードはリファクタリングすれば
するほど強くなる。それも長期的にやってこそ実現できる。
新人や初心者がたった数ヶ月でJavaをマスターしたといっても
実際にはうまくはいかないものだ。やはり、経験が必要なのだ。

そのためCode Readingという本もお薦めできるかもな。

>>15
> >>3
> > importには*を使用してはならない。
> 「Javaパフォーマンス戦略」とかいったJavaテク本には、それと逆の事が書いてあったけど。
> 「importの正確さなんか、こだわるだけ無駄。保守が大変。」とかね。

恐らく時代遅れな人間が書いたのだろう。
importは最初は*で記述しておき、あとからEclipseなどのツールをつかて
コマンド一発で、ソースコードに使用されているクラスから自動判別して
自動的に展開してくれる。

よって、コードを他人に読んで貰いたいなら、展開することがお勧めされる。

それに、Javaには後からクラスが次々と追加される。
そこでimport宣言に*を使ったimport文複数を古いJavaバージョンで記述し、
後からJavaがバージョンアップしたときに、importした異なる二つのパッケージに同じ名前のクラスが
登場するようになったとき、コンパイルエラーが起きる。

よって、Sunもimportに*を使うことは推奨していない。

>>15
それに、

概要やレビューをみると、パフォーマンスに拘っていることがわかる。
拘ることは大事だが、この本は2000年に登場した本。あれからJavaは随分と進化している。
「このイディオムを使えば速くなる、遅くなる」というものも、Javaコンパイラ、JVMの最適化技術
によって無駄になっているものがいくつもでている。たとえば、クラスをfinalにすれば速くなる
という話が時代遅れだということは有名な話だ。「都市伝説」と言われている。

Javaの理論と実践: パフォーマンスの都市伝説
ガーベッジ・コレクターなどのプログラミングに棲みついているワニについて
http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する
アロケーションは思ったよりも速く、しかも、さらに速くなりつつあります
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml

時代遅れな本は他にもまだある。

「Javaの格言」「Javaの落とし穴」「Javaの鉄則」「Java謎+落とし穴徹底解明」

中にはもちろん、為になることもかいてある。
だが、時代遅れで鵜呑みにするわけにはいかない内容もあるから要注意すること。

とくに「Java謎+落とし穴徹底解明」には要注意。Javaの悪口が目立つが、
どれもこれも今の進化したJavaでは問題にならないことばかり。

Genericsとアノテーション、enum型が登場したことでどうでもよくなったことも増えているのだ。

それに、EclipseやFindBugsや
CheckStyle, JUnitなどのツールを使えば問題なく解決できることばかり。

鉄則以外受け付けないIDE作ってくれ

自分は実装言語の名称と職種の名称を組み合わせた単語の
「Javaアーキテクト」が何を意味するかが理解できません

その言語を使うにはあまりに面倒なことが多いので
ドカタ以外にドカタ++が必要というところですか

ここまで環境が進化しツールが充実して鉄則まで明文化されているJavaで
デスマったらカスということか
Javaアーキテクトは大変だな

実装のための環境がいくら進化しても
仕様の変更管理をはじめとする各種リスクの管理には役に立たないね。

>>22
「Javaプログラマ」という言葉があるなら「Javaアーキテクト」
という言葉があってもいいはず。

>>24
カス？　下っ端がカスだったら
アーキテクトが優秀でもプロジェクトが巧く信仰しないこともあるよ

>>27
下っ端がカスでもここに書いてあることを全部守らせれば
いくらなんでもそれはないだろ？
これだけ守らせてダメならアーキテクトの問題だろ

>>28
「全部守らせる」という6文字を体現するのはどれだけ大変かｗ

>>28の論理によれば

会社の業績の伸びが悪くなった理由も
すべて上司のせいにするわけだな

日本の経済悪化を小泉や安倍のせいに
しようとするやつとかわらんな

XP, RUPなどを実戦
したいのですが、客も上司も理解がありません。仮に説得できそれで品質や
納期を短縮できたとしても、それに合わせて次の納期や要求が厳しくなるだけ
です。いたちごっこであります。

それでも強行しろ
一度品質が落ちたら取り戻せない

>>32
納期を短縮する必要はない、今までの納期でサービス残業を減らすなり忙しい
ふりをしておればいいのだ、XP、RUPも顧客や上司を喜ばす手段ではない、開発
者を幸せにするためのものなのだ。

>>32
> XP, RUPなどを実戦
> したいのですが、客も上司も理解がありません。仮に説得できそれで品質や


理解して貰えぬなら、上司を殴って殺してでもりかいさせようぞホトトギス
客なんぞに理解して貰う必要はない。

> 納期を短縮できたとしても、それに合わせて次の納期や要求が厳しくなるだけ
> です。いたちごっこであります。

車があれば目的地まで簡単に到着するだろうという話であるが、
その車を使うためには莫大なエネルギー(燃料、メンテナンス費)が
必要だと言うことを、顧客や上司に説くべきだ。



エンジニアの地位と給料を高めるために、ロビー活動を展開すべき。

　　　　　＿＿＿＿__
　　　　／::::　　　　　　 ＼　　　　　／￣￣￣￣￣￣
　　　　|:::　IニニニニI　　|　　　　/
　　　　＼__|___________|__／　　　＜　エンジニアの地位と給料を
　　　_,,,-‐≡≡≡≡≡‐-,,,_　　　ヽ 　　アゲテクダサイ
　／　|| ::　　　　　　　　 　||. ＼　　 ＼__________________
　|:: 　|| :: ◎　　◎　　◎ .||　 ::|
　|＼__| ::　(二二二二)　 .|__／|
　|:: 　 | ::　　　　　　　　　 |　　 |
　|_____.| ::　　　　　　　　　 |_____|
　|:: 　 | ::　　　　　　　　　 |　　 |
　|._____| ::　　　　　　　　　 |_____|
　/ / .| :: 　　　.　　　　　　| | | |
　|∧/| :: ◎　　◎　　◎　|∧|ﾉ
　　　 |________________________|
　　　 　|　　　　　　　　　|
　　　. └―――――‐┘

それはロビタ

お前笑わせるなw

アーキテクトは特定の言語に依らずにシステム全体を見渡す人でしょ？
Javaだけに特化したアーキテクトなんて、ただのJavaスペシャリストじゃん。

Javaスペシャリスト
↓
じつはジャワしかできん
↓
ジャワ糞なだけ
↓
Javaアーキテクト==ジャワ糞

上記公式からタイトルを入れ替えると
「ジャワ糞の鉄則」にも読み取れるという事だ

http://www-06.ibm.com/jp/developerworks/java/030418/j_j-jtp02183.html
不変クラスの作り方って、このページにかいてあることでOK?

読んでみました。不変クラスってそういうことだったんですねぇ。φ（．．）メモメモ．．．
IntegerやLongも不変クラスだったとは、そういえばset〜ってメソッド持ってないですもんね。
以外な発見(￣ー+￣)ｷﾗｰﾝ　いやぁ勉強になった、昼下がりの日曜日。ヽ(´ー｀)ノ　

ところで、C++みたいに、変数弄られたくないメソッドや引数にconstみたいなのつけるのが、
Javaにないのはなんか理由があるのかしらん?、とフト疑問におもた。(　ﾟдﾟ)?

>>42
final

>>43
いやいや、Javaのfinalは、C++でメソッドや引数に使うconstとは意味が違うでしょ。

>>44
C++ってインスタンスの引数にconst付けるとメンバ更新出来ないんだっけ？

>>45
ポインタも中身も、どっちも指定できる

>>45
「インスタンスの引数」って何？
引数ってメソッドとか関数に渡すパラメータのことじゃないの？
コンストラクタの引数ってこと？
C++でメソッドの引数にconstつけた場合の意味は、ググれ。

どっちみちcastされたら意味ないじゃん

ん？ castできたっけ？　エラーになったような。
普通はポインターじゃなくて参照渡しするでしょ。つぅかスレ違いだな。

偉大なJava使い殿、
JavaでWindows用デバイスドライバを作るにはどうしたらよいのですか？

なんでJavaでデバドラ作らなきゃなんねんだよw
VMをロードすんのか？頭悪いんじゃねぇの？

文面をそのまま受け取っても面白くない
50はハードを直接いじるようなプログラムはJavaでは書けないでそ
という揶揄に過ぎないかと

>>52
アセンブラでOOPでWebサイトとSOAやってくれ、みたいなもんか。

SOA　ﾌﾟ
ジャワでは重くて動かないけどね

JavaをC++に変換するソフトでC++に変換してから実行ファイルをつくればいい。

>>55
それって変換ソフトが凄いだけでは・・・

>>1
こんなくだらないことを決めるのがアーキテキトの仕事だと思ってんの？

決めるんじゃなくて実践させるのっ。もぉわからんちん、めっ(｀･ω･´)

>>1は責任持って1000まで鉄則を書きなよ

>>57 が立派なの書くんじゃね？

HibernateのかわりにSeaserプロジェクトのORマッピング使っていいですか？

>>40
その程度の煽りしかできんとは、アンチもレベルが低いものよ

>>44
finalは一回しか代入できないと言う点が決定的に違うことだな

>>50
Java Communication APIでUSBドライバなら作れないこともないぞ

>>55
んなもんすでにある。
だが、最適化技術が進歩しているお陰で
そういう技術は、ときとして無意味になることがある。

アンチ云々は他スレでいいから早く鉄則を書いてくれよ

すでにかいてあるだろ。かなりの数の鉄則を

Javaはかっこつけるの好きだな

かっこつけるのが好きなのはLispのほうが上

>>66
>>1 >>3-4

いや、>>1 >>3-4 だけじゃないからスレ立てたんだろ？

まず、>>1 >>3-4の内容について、
無理なく実戦できるかどうか確かめないと。

ちょっと無理があるものも含まれている。

すべて守りきる二は相当熟練する必要があるじゃないか。

　* 決まりを作るな

は「床屋のパラドックス」みたいなもんかねえ。

　* 守れない決まりは作るな

はパラドックスになる？

>>1
> * 必ずCheckStyle, FundBugs, JUnit. Apache Ant, Apache Mavenを使用すること。

まずこれについて。FindBugsの間違いだな。CheckStyle, FindBugs, JUnitについては
難なく使えるが、Ant, Mavenは慣れるのに時間がかかるだろう。
他人のソースコードぱくる所から始めないとなかなか覚えられないだろう。
ちょっと勉強時間を下さいな。

> * IDEは必要に応じて任意に使用。使える環境であるならば使うことが望ましい。
なれればすぐにつかえる。ただし、Eclipseはアップデートに悩まされることがある。
JASTミラーサイトが糞なのなんとかしてくれ。それに、それぞれのマシンにメモリ1GB以上は必要だ。

> * 英語を極めよ。海外サイトでいち早く最新技術動向を調査し、プロジェクトに採り入れよ。

これも、慣れだな。英語を勉強する時間を下さいな。手元に電子辞書がないとつらいものだともいえる。
スペースアルク(英辞郎)を翻訳に使うにしてもディスプレイがあるていどでかくて解像度がたかくて、
膨大な複数のウィンドウを開いていられるほどのマシンスペックが必要。今なら、どうってことないかもしれないが・・・.


> * クラス名、オブジェクト名はなるべく名詞形に、メソッド名はなるべき動詞形に。
御意。

> * 『アジャイルソフトウェア開発の奥義』を読破し、実戦せよ。

御意。だが、読破するのに時間がかかる。うむ、フォトリーディングで高速読込だ！


> * 最低でもGoFデザインパターンは極めよ。

どうにか極められる。だが、初心者を教育するにはちょっと時間がかかるな。時間をくれ。

> * 不変クラスの作り方くらいは極めよ。

デザインパターンを知っているなら余裕だな。深いクローニングにさえ気を付ければどうにかなろう。

> * Jakarta Projectの製品くらいは使いこなせるようにすること。

OROやCommons LangやCollectionsならつかいこなせるだろう。すべて覚えるのは時間がかかるが、
必要に応じて使い分けよう。Apache Mavenを使えば扱いも楽だ。


> * 必ずXP, RUPなどを実戦すること。

徹底的に実戦するのは難しい。XPとRUPと同時に実戦するのは難しい。できればXPがいい。


> * 設定ファイルは死すべし！ Seasar2, Spring FrameworkなどのDIコンテナを使うこと。

これも勉強しなければなるまい。慣れれば簡単だが。


> * 文字コードはすべてUTF-8で統一すること。Shift_JIS, EUC-JPなど論外！

新規開発はそれでよし。だが、古いシガラミコードは？　徐々に捨てるか！


> * 必ずUML、データベース設計、ネットワーク技術、セキュリティ技術を極めること。

これも勉強時間がいる。極めるのは難しい。とくにデータベース、ネットワーク、セキュリティは
かなりの難易度だ。

> * データベースの扱いにはHibernateなどのO-Rマッピングツールを使うこと。

これも慣れだ。だが初心者に教え込むにはまずはJDBCからだろう・・・

> * ソースコードには必ずJavadocコメントを加えること。

これも慣れか。Eclipseで自動生成すれば楽だな。ついでに、正規表現も使ってな。


> * 分割し、統治せよ。モジュール間の依存度はできるかぎり疎になるようにすること。

これも多大なる修行が必要だ。道は険しい。

> * 一つのメソッドは100行を超えてはならない。一つのクラスファイルは1000行を超えてはならない。

これも修行が必要なり。ときに、Eclipseのリファクタリングが必要になりそうだ。

> * 常にリファクタリングせよ。とにかく自動化して開発効率を高めよ。

これには同意する。自動化については、自動化ツールの使い方を覚えなくては。
AntやMavenを使いこなせるようになってな。

> * 必ずアノテーション、Genericsを使うこと。

これも、新規開発のときのみにやるのがいいな。
既存の自作クラスをパラメタライズするのは困難を極めるケースがある。
とくに、HashMapのようなクラスをパラメタライズするのは非常に難易度が高い。
ただ、Genericsで型指定するだけならいいが、Genericsに対応したクラスを作るのは
難しい。これも修行が必要なり。

> * Tomcatの設定web.xml等は手書きせず、XDoclet等を使用してServletソースのコメントだけに記述すること。

これも慣れなり。今は、Springなどもあるしのう。設定ファイルが乱立せぬよう・・・

ここまで書いて疲れた。

>>3-4についてはのちほど

たまに自分に帰ってきたレスに対して全レスするやつを見かけるが
何でそんな疲れることをするのかまったく理解できない。


きっと>>78なら理解できるんだろうな、と思った。

プログラミングしたことないけど、勉強になるな〜

Javaカーペンターの俺にとって今必要なのは、よい棟梁につくことだな。

Java Persistence APIは使いますか？

>>81
カーペンタースを思い出したw