javadocとは2017-07-19■anond:20170719142651なんと具体的な回答が!なるほどね。食ってかかるようで申し訳ないが、それで7割減は大げさでないの?自分もずいぶん前にドキュメントの作成方法についてはいろいろやってみた。javadocのようにコンテンツの記述のみ行えばよくてデザイン・レイアウトは決め事という方法をとっても7割減はむりだろ。要件定義書やインフラの設計書なんかは書式的に面倒なことは少ないと思われるので、(詳細設計書は自動生成として)おそらく面倒なのは基本設計書、テスト仕様書と結果報告書だと思うが、それらにはjavadoc方式(内容と書式の分離)では表現が不足して実用にならないだろう。いうわけで元増田がドキュメント生成ツールを開発して無償でつかえるようにしてくれ。14:452016-11-05■なぜソースじゃなく詳細設計を欲しがるのかJavaを始めとするオブジェクト指向言語による開発になると、設計の手法も従来とは大きく変わる。その結果、不要になるドキュメントが出てくる。ここでいう詳細設計とは、本来コードで記述する処理を、逐一日本語で書き下したものを指す。そんな物を読むくらいなら、現物のソース読めよって話だ。だいたい、ソースに書くレベルの粒度の記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。何よりソースに修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEやPGという人種が、実質同じ内容を何度も書きたがるわけがない。それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テスト・システムテスト以降で、そんなことをしている余裕など現場にはない。結果、実装と合ってないドキュメントだけが放置されてしまう。なることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。負担ばっかり増えて、尚且つ無意味な作業をやらせるなって感じ。なんでそんなに「日本語訳」が欲しいの?ぶっちゃけソースコードレビューでいいじゃん。客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。元請はITのプロなんだから、ソースなんてスラスラ読めて当然なわけで。英語読めない英語の専門家が存在しないのと同じ理屈ね。それこそ読み取り専用でリポジトリのアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。いえ、別に何も「真実はソースただ一つ!」なんて言うつもりはない。ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。ドキュメントがあるお陰で、システムがトラブった時もいきなりソースの問題箇所を探し回る苦労から解放されるのだ。ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソースを確認すればいいと。Javaだったら、ユースケース図、アクティビティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドのソースを読めばいい。逆に言えば、記述の粒度が同じ成果物は2種類以上も要らない。整合性を保つための手間が増えるだけなので。詳細設計書は不要というのはそういうことだ。「ソースが読めないから日本語訳を渡せ」とか甘えんな。15:532016-06-17■1.0から学ぶJavaタイトルを見て釣られクマーな皆さんこんにちは。ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。今調べたらホッテントリメーカー2008年だそうで。古臭いなーと思いましたよー。「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。面倒くさいんですけどね。1.0から学んでみましょうか。1996年1月23日Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。そんな感じだったかなあ。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。Applet標準でGUI(グラフィカル・ユーザ・インタフェース)を扱えるオブジェクト指向1996年の時点にこんな言語が登場したのですから革新的でした。いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが......。プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。分散オブジェクト技術といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。GUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。JDBCはJavaとデータベースをつなぐインターフェースです。VMにオブジェクトを送って実行する、といったことができます。Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。Archiveからダウンロードすることができ、今でも入手することができます。Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。当時のjavadocは今とはデザインが大きく異なります。java.appletjava.awtjava.awt.datatransferjava.awt.eventjava.awt.imagejava.beansjava.iojava.langjava.lang.reflectjava.mathjava.netjava.rmijava.rmi.dgcjava.rmi.registryjava.rmi.serverjava.securityjava.security.acljava.security.interfacesjava.sqljava.textjava.utiljava.util.zipこの時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。現代にJavaを学ぶ場合、どのバージョンでは何があって......というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。クラス名や、クラスに定義されている操作であるメソッド名を動的に指定して呼び出す。グラフィカルユーザインタフェースツールキットが標準ライブラリに統合された。サンのJava仮想マシンにジャストインタイムコンパイラが備わる。さまざまなウェブブラウザにJava実行環境を組み込むことができるようになり、Javaアプレットを実行できるようになった。IDL(インタフェース記述言語)の実装が導入され、CORBA分散オブジェクト環境との相互運用ができるようになったコレクションフレームワークの導入strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。今時のCPUだと大丈夫だとは思うんですが。リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する......みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。今ならJavaFXを使うのが良いと思います。初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。コンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。いった方向に舵を取ります。JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。した産業利用は一般的なユーザーの目にはあまり入らないわけです。Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。企業で用いられる社内システムにもServletは多く採用されました。理由はいろいろ挙げれると思うのですが企業で用いる個々のマシンにアプリをインストールして回らなくても、中央サーバーだけでバージョン管理できるシステムを作るにあたって、本格的なオブジェクト指向プログラミングを要求されるGUIの開発よりも、HTMLでのUIデザイン、ページ遷移という仕組みは開発しやすかったというのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。HTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。いうか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。EZアプリ2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。docomoはiアプリ含めiモードによって一世を風靡します。した土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。話を2001年に戻しましょう。Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。Startではブラウザから起動しつつも独立したアプリとして起動するのです。Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。した事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。Applications)というわけです。Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。AIRSilverlightあたりです。JavaScriptでした。JavaScriptで実現させました。やめて欲しいですよね。脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。anywhere"を破壊したのはスマートフォンだったというわけです。Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。機能追加はあっても言語構文が大きく変わることはありませんでした。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。アノテーションswitch文でString/列挙を扱えるようになった言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。出るまでJavaは停滞してしまいます。Microsystemsという会社がなくなってしまったためです。経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。VM上で動く非Java言語も台頭してきました。Scalaなどですね。戻って2007年にAndroidが発表されます。VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。(2014年3月18日)です。APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。僕たちはいつだって宗教戦争だ。vimのキーバインドで。teratermの背景色で。ログファイルの名称で。変数名で、タブの桁数で。spfileの設定で。jbossの設定のおまじないで。stratsの継承方法で。