Qiitaの記事が伸びてる

記事書くのが一年ぶりになってる。。。

最近、Qiitaの記事が異様に伸びていて驚いています。 まあ内容はawesomeなんで、自分の中から出たアウトプットではないんですが。 個人メモですね。

みなさん何処から記事にたどり着いてるんでしょうか。 Qiita公式Twiiterとかですか??

くさい開発環境 Java

5月中に書き上げるつもりが月をまたいでしまいました。


いま触っているシステムを一言で表すなら***でできたジェンガと言ったところですかね。

以前なにかのセミナーで、「エリック・エヴァンスドメイン駆動設計を実践してみた」というような内容の発表をしていた方がうまい例えをしていました。

良い設計は分子模型のように、土台がしっかりしていて外に拡張可能である。

そうでない設計は往々にして、穴だらけでグラグラ、上にただ機能を積み上げることしか出来ないジェンガである。

なるほどと思いました。(本に書いてあるんでしょうか?)
いま触っているシステムはまさにこれ。

クソの上に何を乗せてもクソとは良く言ったもので、 本当にどんなに改修や機能追加を試みてもそこは臭くなってしまいます。これは精神衛生上とても良くないです。 私自身、スキルに自信があるわけではありませんし、やはりコーディングルールやフレームワークといった枠組みがないと、 どうしても「とりあえず動けばいい」だけのクソコードが出来上がります。 もし土台がしっかりしていたなら、私ももう少し良いコードが書けていると思うんですよね。(いいわけくさいですが、事実の側面もあるはずです。)

ここまで散々ディスったわけですが、具体的にはいったい何が、どこが臭いのでしょうか。


さて、前置きが長くなりましたが、今回は私がブログなどを読んで知った「これはJava(EE)アンチパターンだ」と思っているものを紹介致します。
(こちらと被る部分が多々ありますが、ご容赦ください。)

まずはこちら、これが一番の問題だと考えています。

1. JSPメソッド定義やロジックが詰め込まれている

私が何よりクソだと考えているのがこれです。長いファイルだと1万行に届き、行数を見ただけでそっ閉じです。 デメリットは色々あるのですが、順に見ていきましょう。

クラス化されていないため、メソッドやロジックのユニットテストが出来ない。

実際、半分以上の画面がクラス化されていない気がするので、それだけユニットテストが実施出来ていないことの証明です。

(そもそもテストは全て手動+Excelに結果記述なのでJUnitなんて使う気もないようです。)

これにより回帰テストが全く出来ないのがとても困りもので、メソッドをクラスに移動したり、利用されているクラスのリファクタリングを行おうとすると、それが知らぬ間に別画面に(絶対に)影響するのですが、それを全く検知出来ず、運用から電話がかかってくるんですね。
この流れが本当にクソ。リファクタリングのやる気を削がれたらもうどうしようもない。 そもそもが2003年とかに書かれて以降ろくなメンテもされないままツギハギな機能拡張が行われているので、その複雑さはネスト以上に深淵です。

可読性が落ちる。

JSPにロジックを書くと、当然ですがJavaコードとHTMLが混在します。私が触っているファイルは、HTML中に表示する段階になって初めて、 そこでデータを処理してHTML中で出力する、というふうにしていることが多かったです。 これはスクリプトレットと言いますが、これをやってしまうとJavaコードとHTMLが入れ替わり立ち替わり出現するので、その度に頭を切り替える必要が出てきます。また、コードもHTMLもそれぞれのインデントがあるのに、コードとHTMLが変わるタイミングでインデントも変わるので、目線の移動が発生しますね。長くコードを読んでいたのに、突然HTMLが出てきたり、その逆になったりすると、本来のインデントがどこだったかわからなくなり、上に戻る、なんてことも普通にあり得ます。

IDEのサポート能力が落ちる。

これはIDEによるのかも知れませんが、現在使用しているEclipseでは、自動補完のスピードが著しく落ちました。Javaコード以外のものも混ざっているため、解析に時間がかかるのでしょうか。他にも、エラーが発生するようなコードでも反応が無かったり遅かったりと不安定になりやすいです。

いわゆるMVCに則っていない。

MVCにおけるView(JSP)部分に、ModelやControllerにあたるコードが混ざり込んでしまうことになります。MVCパターンは、各レイヤの役割をはっきりさせ、互いの依存性を抑えることでメリットが生まれます。しかし、JSPにロジックを書いてしまう方法は、この全く逆になり、1つのファイルに役割が集中し、コードの再利用性が落ちます。

2. 命名規則やコーディングスタイルが統一されていない

命名の重要性は共通見解だと思うのですが、このプロジェクトではそうではないみたいですね。 コーディングスタイルはあまりかっちり決めてしまうのもかえって良くないと耳にしますし、Javaの基本的な規則が守られていれば十分ではないでしょうか。(つまり守られていない。クラス名頭文字が小文字だったりした。)

プロジェクト内Wikiなどがなく、プロジェクトで使用されている言葉や意味が個人の経験に基づいていて共有されていない。

命名規則については、業務システムでは特にしっかりと命名が必要だと実感しています。 業務ドメインの用語がとてもたくさんあって、しかも名前が著しく似ていたりするので、変数名が同じなのに別のJSPでは意味が違ったりします。 これが厳密に定義されていないため、触るファイルが変わるごとに頭を切り替える必要があります。また、修正する際などに、うっかり意味を思い込みで考えてしまい、あとで別の意味だったことに気づく、ということもざらです。

Javaの基本的なコーディング規約すら守られていないことがある。

これは頻度はそう多くないですが、見てしまったときは気が滅入ります。 特に上記のクラス名頭文字が小文字は絶句してしまいました。 他にもメソッド名に

isGet~

など動詞が重なっているものなど、いかにも適当につけてしまっています。

3. Gitによるソース管理やツールによる自動化が行われていない。

社内政治によって導入は難しいのですが、これらのツールは便利であると同時に必須スキルになりつつあるので、日常的に使える環境だと嬉しいですね。

SVNによって管理されているが、コンフリクトが起こることがある。

開発ブランチは特にバージョン管理されておらず、 また開発は複数チームにまたがっていて、しかも他のチームがどこを弄っているかはわからない(チーム間コミュニケーションはない)ため、 運悪く同一ファイルをいじっていると、コンフリクトが発生してしまいます。

SQLなどコード以外のバージョン管理がされていない。

SQL(DDL)などは、実行したらそのままで、変更が入る場合は

--2015/XX/XX Mod

のようなコメントを挿入することで管理しているようです。 これは本当にムダで、変更の都度「Gitでバージョン管理すべきだろ」と思いならがらコメントを書いています。

書いているうちに思いついたのはこれくらいですが、作業中はもっと色々な点について脳内で毒づいています。

「これは別にアンチパターンではないだろう」というところがあったら、教えて頂ければ幸いです。

あなたのハートをロックイン!

なーに言ってんだって感じですね。

ロックインという言葉ご存知ですか。
IT業界だと、よくベンダーロックインなんて言いますよね。

特定のベンダー(メーカー)の製品を利用するとき、周辺もそのベンダーの製品で固めることで、利便性は上がるが、そのベンダーに強く依存してしまうこと。

であってますか。

簡単に言うと、「囲い込まれ」てしまうこと、でしょうか。

私は前職もJavaプログラマで、そのときはあまりこのベンダーロックインについて強く意識していなかったのですが、 そのときは運用環境がCentOS + Tomcat5.5というオープンソースメインなものだったので、 操作について教えてもらいながら、Linuxなどのオープンソースソフトウェアの普及率なども知っていきました。
そこで気づいたのは、プログラマ

社内での専門スキル(業務スキル)だけでなく、普及率の高いオープンソースソフトウェアやデファクトスタンダードなソフトウェア(ミドルウェア、OS含む)に関するスキル

そういったものが必要だということでした。

とは言ったものの、それらを勉強してきたかというと全くしてこなかったのが私です。 現在でもヤバイことにJavaすらまともに書けません。

しかし最近になって、自分でも理由は良くわからないのですが、再び上記のことについてよく考えるようになりました。 きっと焦りのようなものなんだと思います。

前置きが非常に長くなりました。

ここでついに私はこのことをうまく表現できる言葉に気づきました。 それがロックインです。 ロックインは、それ単体でなく、様々な言葉と組み合わせることで、重要なことが見えてくるような気がします。

  • ベンダーロックイン
  • 会社ロックイン
  • コミュニティロックイン
  • 現場ロックイン(*1)
  • スキルロックイン
  • ロックインジャパン(*2)

誰しもが様々な枠組みに所属し、そこにロックインされていると言えるのではないでしょうか。 ある枠組みがあって、その中で特化していくことは尊敬すべきことだと思います。 しかし残念なことに、その枠組みは突然消えてしまうこともあります。

そんなとき、その特化したスキルが自身の中で一般化・抽象化され、他所でも活かすことができるかどうかが、 その後を大きく左右するかも知れません。

今いる環境や使用しているツールなどは、それを一般化したときに果たして自分は今までのように使いこなせるのか、一度問い直してみると良いと思います。


この記事は、ロックインについて考えているときに、以下のブログ記事を読んで、触発されて勢いだけで書いたものです。

blog.kentarok.org

  • (*1) 上記の記事からの引用
  • (*2) 私はアニソンしか聞きません

より良い開発環境とは

今日は、常駐先の開発環境に対する不満(ぶっちゃけ愚痴です)と、その改善案を提案してみます。

(提案は自分に対してであって常駐先に対してではありません。そんな政治力はありません。)
 
まずは問題点から。 (私のスキルの件は棚の上に置いておきます。)

最重要案件

貸与されているノートPCがクソ遅い。
Eclipse + アプリケーションサーバ + DB開発ソフトの同時起動が出来ないのがつらいです。
様々なツールがメモリ不足で途中で固まってしまいます。
IEも2,3タブ開いたら2,3分待たされる感じです。(システムがIE向けなのでIE使ってます)
これがかなりストレスです。
いまどきメモリ2GBて!
 

 重要案件1

命名規則やコーディングスタイルが統一されていない。決める様子もない。
 わりと大きな会社の基幹システムらしいので、DBの規模とかもそれなりなんだと思いますが、カラム名が日本語なので、コード上でどう表現するか迷います。
英語に訳す?ローマ字表記?決まっていないので毎回迷っています。
先輩は「getKingaku( )」みたいな感じで英語ローマ字混在なのですが、
ローマ字表記って、書き方が数通りあったりするじゃないですか。
(「ん」が「n」か「nn」か、「ちょ」が「cho」か「tyo」かなど)
しかもそこでまた揺れてるんですね。
私はそれが嫌でいちいちGoogle翻訳で英語に訳しています。
絶対に正しい意味になっているとは言えませんけれどね。
実は、そもそも業務ドメイン上の用語が理解出来ていません。問題ですね。
 
また、クラス名が動詞であったり、状態持ちクラス名がUtilだったり、JSP名がID連番だったりしました。
 

 重要案件2

テストがしづらい。 
ソースコードのどれくらいかはわかりませんが、かなりの画面数でJSPにロジックを全て詰め込んであります。2003年とかに書かれたようです。(長いと1万行を超える)
そして全く同じコードがいろいろなJSPで散見されます。(うごごごご)
クラス化されてないということは、JUnitとか使う気は全く無いようです。
また、テスト環境のDBは、本番環境からコピーしたものが2つのみで、完全コピーなのでめったくそデータ量があります。ちょろっとクエリを走らせたいときにも大量にデータが来てしまうので、いちいち絞り込む必要があります。
もちろんテスト時にはモックもテストデータも使わず全てそのDB内のデータで行います。
手動で行ったテストの結果はExcelにぺたり。
 

重要案件3

ソース管理が上手く機能していない。 
SVNを使っているのですが、開発ブランチはSVNで管理されていないため、後になって実はコンフリクトしていた、ということがままあります。
また、DBのストアドプロシージャなどもバージョン管理されていないようです。
開発サーバのソースを更新する際はその都度マージツールを起動して、コンフリクトが無いか事前に調べています。
 

ひとまずこんなところでしょうか。
ここからは改善編です。よく最適解的に耳にするツールや手法を使ってみます。
 

最重要案件

これについてはかなりの政治力が必要になるのでちょっと難しいですので、残念ですが飛ばします。
 

重要案件1

やはり、社内(プロジェクト内)Wikiが有効なのでは無いでしょうか。
コーディングスタイル、基本的な命名規則、業務ドメイン上の用語をどう表すかの対応表やスペリング、意味集などがあるとかなりソースコード上の混乱を抑えられる気がします。
 

重要案件2

まずロジック部のクラス化、データソースなどは外部注入できるようにすべきだと思います。テストデータは、本番DBのクローンに加え、テキスト形式で作成したものを新規に流しこめるような、データが常に空のDB(テストが終わったら全てTRUNCATEされる)ようなDBもあると良いのではないでしょうか。
 

重要案件3

やはりGitを使いたいですね。デファクトスタンダードになりつつありますし。
可能なら社内サーバ上にGithubクローンを置いてバージョン管理できると良いと思います。コードレビューもできるようになりますしね。
問題は学習コストでしょうか。
 
 
いかがでしょうか。これが全て実現できたなら、かなり改善されたと言える気がします。
環境改善に悩んでいて、政治力がある方々の参考になったりしたら嬉しいですね。
 
私はこれから社内政治について考えてみます。
おやすみなさい。
 

いまなにをしてるか

私は現在、とある会社に常駐というかたちで、そこの社内システムの開発保守をしています。

 
システムは、JavaEEウェブアプリケーションですが、その内部は例えるなら、「クライマックスのジェンガ」という感じです。
 
私はJavaですらあまり書けるわけではありませんが、それでもかなりグラグラしているのがわかります。機能追加とバグフィックスが絶対にセットなので間違いないと思います。(いまや私も原因の一端を担っている)
 
そしてそのジェンガの上にさらにジェンガのブロックを積み上げている、というのがいまの実情です・・・。
 
最近はソースコード(命名規則などが当然のようにバラバラだったり、JSPにロジックが1万行だったりと割と聞くヤツ)を見るのがつらくなってきてます。
 
常駐先を変えてもらえないかなと密かに思っていますが、スキルも実績も政治力もないので言えずにいます。
 
環境を改善するのが最善なんだと思いますが、プログラマに貸与されるPCのメモリが2Gだとわかったときに、「それも難しそうだな」と思いました。
 
スキルも政治力もないプログラマが、いまいる環境を自身がスキルアップできる環境へ改善していく。そんなことが出来たらいいですね。

はてブ始めてみよう

はじめまして。

 

最近いろいろと思うところがあったのですが、

発信するところを持っていなかったため、

今まで読むだけだったはてブを開設してみました。

 

プログラミング関連のことを書くだけならQiitaでもいいのでしょうが、

クオリティの低いエッセイ(ポエム)をQiitaに流すのは少し気が引けたので、

そういうのをこちらに書いていこうと思っています。