5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

Javaアーキテクトの鉄則

1 :仕様書無しさん:2007/02/21(水) 13:09:58
* 必ず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ソースのコメントだけに記述すること。


2 :仕様書無しさん:2007/02/21(水) 13:17:03
またつまんねえのたったな

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


4 :仕様書無しさん:2007/02/21(水) 13:30:50
* データ型として利用するクラスは必ず不変クラスにすること。
* データ型として利用するクラスには、必ず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)で一つにまとめること。

5 :仕様書無しさん:2007/02/21(水) 13:34:45
うわぁ
ストラッツのimport行数みたいだ

6 :仕様書無しさん:2007/02/21(水) 14:41:13
よし、上から順に理由を述べていってもらおう

7 :仕様書無しさん:2007/02/21(水) 18:48:22
Java飽きてきた

8 :仕様書無しさん:2007/02/21(水) 18:53:21
鉄則多いなあw

9 :仕様書無しさん:2007/02/21(水) 20:05:41
>* 『アジャイルソフトウェア開発の奥義』を読破し、実戦せよ。

この本買う価値あるの?

ちなみに
Effective Java
HP: 19200 攻撃力: 3000 防御力: 400

プログラミングVisual C# 2005
HP: 19200  攻撃力: 3000  防御力: 5500

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

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

10 :仕様書無しさん:2007/02/21(水) 21:17:04
勉強になるからもっと書いて

11 :仕様書無しさん:2007/02/21(水) 22:50:22
Javaえらいよ、やっぱすげぇよ、さすがに開発論が活発なだけあるな。
それよりも>>1がすげぇ、VB厨はおろか、C++厨にこんなん書けるか?
無理だろwww いやぁ、Java選んで良かったよ。俺ももっと勉強しよ。

12 :仕様書無しさん:2007/02/21(水) 22:56:34
ところが3000行のメソッドをコピペで作るのがJAVA厨である。

13 :仕様書無しさん:2007/02/21(水) 22:57:44
>>1を守ったらデスマが無くなるっていうのなら守る。
>>1を守ったら利益率50%超えるっていうんなら守る。
>>1を守ったらかわいいあの子とごにょごにょできるんなら守る。

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

14 :仕様書無しさん:2007/02/21(水) 23:16:40
>>13
findbugsとcheckstyle入れればいいだけ。
あとはEffective Javaでも読んどけ。

15 :仕様書無しさん:2007/02/22(木) 00:18:45
>>3
> importには*を使用してはならない。

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

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

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

16 :仕様書無しさん:2007/02/22(木) 00:55:13
>>9
> >* 『アジャイルソフトウェア開発の奥義』を読破し、実戦せよ。

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


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

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


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

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

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

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



17 :仕様書無しさん:2007/02/22(木) 00:57:17
>>13-14
確かに、守っただけではデスマが無くなって即座に利益に繋がるとは
限らない。

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

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


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

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

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

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

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


19 :仕様書無しさん:2007/02/22(木) 01:06:02
>>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


20 :仕様書無しさん:2007/02/22(木) 01:10:01
時代遅れな本は他にもまだある。

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

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

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

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

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




21 :仕様書無しさん:2007/02/22(木) 06:14:16
鉄則以外受け付けないIDE作ってくれ

22 :仕様書無しさん:2007/02/22(木) 17:24:47
自分は実装言語の名称と職種の名称を組み合わせた単語の
「Javaアーキテクト」が何を意味するかが理解できません

23 :仕様書無しさん:2007/02/22(木) 18:16:22
その言語を使うにはあまりに面倒なことが多いので
ドカタ以外にドカタ++が必要というところですか

24 :仕様書無しさん:2007/02/22(木) 18:34:56
ここまで環境が進化しツールが充実して鉄則まで明文化されているJavaで
デスマったらカスということか
Javaアーキテクトは大変だな

25 :仕様書無しさん:2007/02/22(木) 18:49:04
実装のための環境がいくら進化しても
仕様の変更管理をはじめとする各種リスクの管理には役に立たないね。

26 :仕様書無しさん:2007/02/22(木) 18:54:43
>>22
「Javaプログラマ」という言葉があるなら「Javaアーキテクト」
という言葉があってもいいはず。

27 :仕様書無しさん:2007/02/22(木) 18:55:22
>>24
カス? 下っ端がカスだったら
アーキテクトが優秀でもプロジェクトが巧く信仰しないこともあるよ

28 :仕様書無しさん:2007/02/22(木) 19:01:51
>>27
下っ端がカスでもここに書いてあることを全部守らせれば
いくらなんでもそれはないだろ?
これだけ守らせてダメならアーキテクトの問題だろ

29 :仕様書無しさん:2007/02/22(木) 19:10:35
>>28
「全部守らせる」という6文字を体現するのはどれだけ大変かw

30 :仕様書無しさん:2007/02/22(木) 19:11:11
>>28の論理によれば

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


31 :仕様書無しさん:2007/02/22(木) 19:11:53
日本の経済悪化を小泉や安倍のせいに
しようとするやつとかわらんな

32 :仕様書無しさん:2007/02/22(木) 20:26:07
XP, RUPなどを実戦
したいのですが、客も上司も理解がありません。仮に説得できそれで品質や
納期を短縮できたとしても、それに合わせて次の納期や要求が厳しくなるだけ
です。いたちごっこであります。

33 :仕様書無しさん:2007/02/22(木) 22:38:22
それでも強行しろ
一度品質が落ちたら取り戻せない

34 :仕様書無しさん:2007/02/22(木) 22:52:34
>>32
納期を短縮する必要はない、今までの納期でサービス残業を減らすなり忙しい
ふりをしておればいいのだ、XP、RUPも顧客や上司を喜ばす手段ではない、開発
者を幸せにするためのものなのだ。

35 :仕様書無しさん:2007/02/23(金) 02:21:57
>>32
> XP, RUPなどを実戦
> したいのですが、客も上司も理解がありません。仮に説得できそれで品質や


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

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

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



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


36 :仕様書無しさん:2007/02/23(金) 13:16:23
     ______
    /::::       \     / ̄ ̄ ̄ ̄ ̄ ̄
    |::: IニニニニI  |    /
    \__|___________|__/   < エンジニアの地位と給料を
   _,,,-‐≡≡≡≡≡‐-,,,_   ヽ   アゲテクダサイ
 / || ::          ||. \   \__________________
 |::  || :: ◎  ◎  ◎ .||  ::|
 |\__| :: (二二二二)  .|__/|
 |::   | ::          |   |
 |_____.| ::          |_____|
 |::   | ::          |   |
 |._____| ::          |_____|
 / / .| ::    .      | | | |
 |∧/| :: ◎  ◎  ◎ |∧|ノ
    |________________________|
     |         |
   . └―――――‐┘

37 :仕様書無しさん:2007/02/23(金) 19:03:09
それはロビタ

38 :仕様書無しさん:2007/02/23(金) 20:50:26
お前笑わせるなw


39 :仕様書無しさん:2007/02/25(日) 08:19:58
アーキテクトは特定の言語に依らずにシステム全体を見渡す人でしょ?
Javaだけに特化したアーキテクトなんて、ただのJavaスペシャリストじゃん。

40 :仕様書無しさん:2007/02/25(日) 13:21:46
Javaスペシャリスト

じつはジャワしかできん

ジャワ糞なだけ

Javaアーキテクト==ジャワ糞

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


41 :仕様書無しさん:2007/02/25(日) 16:00:38
http://www-06.ibm.com/jp/developerworks/java/030418/j_j-jtp02183.html
不変クラスの作り方って、このページにかいてあることでOK?

42 :仕様書無しさん:2007/02/25(日) 16:43:37
読んでみました。不変クラスってそういうことだったんですねぇ。φ(..)メモメモ...
IntegerやLongも不変クラスだったとは、そういえばset〜ってメソッド持ってないですもんね。
以外な発見( ̄ー+ ̄)キラーン いやぁ勉強になった、昼下がりの日曜日。ヽ(´ー`)ノ 

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

43 :仕様書無しさん:2007/02/25(日) 19:41:05
>>42
final

44 :仕様書無しさん:2007/02/25(日) 19:51:43
>>43
いやいや、Javaのfinalは、C++でメソッドや引数に使うconstとは意味が違うでしょ。

45 :仕様書無しさん:2007/02/25(日) 20:48:25
>>44
C++ってインスタンスの引数にconst付けるとメンバ更新出来ないんだっけ?

46 :仕様書無しさん:2007/02/25(日) 21:00:11
>>45
ポインタも中身も、どっちも指定できる

47 :仕様書無しさん:2007/02/25(日) 21:08:16
>>45
「インスタンスの引数」って何?
引数ってメソッドとか関数に渡すパラメータのことじゃないの?
コンストラクタの引数ってこと?
C++でメソッドの引数にconstつけた場合の意味は、ググれ。

48 :仕様書無しさん:2007/02/25(日) 21:08:44
どっちみちcastされたら意味ないじゃん

49 :仕様書無しさん:2007/02/25(日) 21:26:27
ん? castできたっけ? エラーになったような。
普通はポインターじゃなくて参照渡しするでしょ。つぅかスレ違いだな。

50 :仕様書無しさん:2007/02/26(月) 02:03:14
偉大なJava使い殿、
JavaでWindows用デバイスドライバを作るにはどうしたらよいのですか?

51 :仕様書無しさん:2007/02/26(月) 07:52:04
なんでJavaでデバドラ作らなきゃなんねんだよw
VMをロードすんのか?頭悪いんじゃねぇの?

52 :仕様書無しさん:2007/02/26(月) 14:08:02
文面をそのまま受け取っても面白くない
50はハードを直接いじるようなプログラムはJavaでは書けないでそ
という揶揄に過ぎないかと

53 :仕様書無しさん:2007/02/26(月) 15:42:01
>>52
アセンブラでOOPでWebサイトとSOAやってくれ、みたいなもんか。

54 :仕様書無しさん:2007/02/26(月) 15:46:26
SOA プ
ジャワでは重くて動かないけどね

55 :仕様書無しさん:2007/02/26(月) 16:44:34
JavaをC++に変換するソフトでC++に変換してから実行ファイルをつくればいい。

56 :仕様書無しさん:2007/02/26(月) 17:04:33
>>55
それって変換ソフトが凄いだけでは・・・

57 :仕様書無しさん:2007/02/26(月) 18:22:01
>>1
こんなくだらないことを決めるのがアーキテキトの仕事だと思ってんの?


58 :仕様書無しさん:2007/02/26(月) 19:47:54
決めるんじゃなくて実践させるのっ。もぉわからんちん、めっ(`・ω・´)

59 :仕様書無しさん:2007/02/26(月) 19:57:06
>>1は責任持って1000まで鉄則を書きなよ

60 :仕様書無しさん:2007/02/26(月) 20:00:09
>>57 が立派なの書くんじゃね?

61 :アーサー@×A:2007/02/26(月) 22:08:05
HibernateのかわりにSeaserプロジェクトのORマッピング使っていいですか?

62 :仕様書無しさん:2007/02/27(火) 14:23:55
>>40
その程度の煽りしかできんとは、アンチもレベルが低いものよ

63 :仕様書無しさん:2007/02/27(火) 18:43:52
>>44
finalは一回しか代入できないと言う点が決定的に違うことだな


64 :仕様書無しさん:2007/02/27(火) 18:44:36
>>50
Java Communication APIでUSBドライバなら作れないこともないぞ

65 :仕様書無しさん:2007/02/27(火) 18:45:38
>>55
んなもんすでにある。
だが、最適化技術が進歩しているお陰で
そういう技術は、ときとして無意味になることがある。

66 :仕様書無しさん:2007/02/27(火) 20:57:13
アンチ云々は他スレでいいから早く鉄則を書いてくれよ

67 :仕様書無しさん:2007/02/28(水) 09:46:45
すでにかいてあるだろ。かなりの数の鉄則を

21 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)