フロントエンドエンジニアという単語を知る
フロントエンドエンジニアという単語を知る。
システムの画面をつくる専門家のことらしい。
こういう専門での住み分けは良い傾向だよね。
現代のWebシステムはやたらとややこしくて、覚えなきゃならん技術が多い。
例えばJavaで場合、こんな感じ。
・画面(HTML、JavaScript、css)
・ロジック(Java、MVC、ORMapping、DI、EJB)
・DB(SQL、PLSQL)
それにツールを使いこなすテクニックも覚えなきゃならない。
・ソース管理(Git、Subversion)
・バッチ(コマンドプロンプト、シェル・・・)
覚えることが多すぎてパンクしちゃうね。つーかしてるもん俺。
画面だけでも専門家に任せられるんなら、楽ちんでいいね。
ただ、そう上手くはいかないんだろうね。
※以下JavaのMVCフレームワークをつかった業務システムを想定してます
①連携はどうすんの?
ロジックから画面に受けわたすパラメータを設計する必要があるんだろうね。
型、桁数、変数名、Jsonの構造・・・
今までプログラマがノリで決めていたことを設計書に起こさないといけない。
大変だなあ。近い設計は今でもやってるけど、そんなに細かくきめてないもんなあ。
Jsonの構造なんてまったくノータッチですわ。
②JavaでもJavaScrpitでも出来る機能はどっちでやるのさ?
この問題は今でもあって、結局、解決してねーんだよな。
個人的には「サーバで出来ることはサーバでやる」のが好きなんだよね。
理由はイロイロあるけど「Javaのほうがデバッグしやすい」のが一番の理由だね。
これからは多分「画面で出来ることは画面でやる」方針になるんだろうけど。
さらにHTML5でクライアントがストレージを持つことになったんで、
JavaでもPLSQLでも出来ることを、画面でも出来るようになりました。
画面とロジックの役割分担が、どんどんグダグダになってる気がする。
③保守は?
たとえば「一覧表に項目をひとつ追加したい」ってハナシになったとして、
誰がプログラムを保守するのかねぇ。
「Javaだからキミが保守して」って安易な発想で俺にお鉢が回ってくるんだろうね。
ヤダねぇ。専門家の書いたコードなんて難しくて読めないよ。
それこそ保守もフロントエンドエンジニアに任せられればハナシは別だけど、
間違いなく、保守フェーズではフロンドエンド開発チームは解散しているよ。
もし残っていたとしても、管理者は嫌がるだろうねぇ。
フロントエンド1人、バックヤード1人で、合計2人の人足が必要だ。
「なんでこんな簡単な改修に、忙しい○○クンを出さなきゃならんのか!」ってね。
結局、2人でやれば1日で終わることを、1人で5日かけてやる羽目になる。
あと、コードの寿命を決めるのは俺たちPGじゃないけど、一度つくったシステムって10年は使うんだぜ。
「当時の流行」に流されやすい人種がマニアックな技術を尽くしたコードを、
専門家でもないPGが苦しみながら保守する姿が、ありありと見える。
つーか今の俺がその状態だ。コードはシンプルに書け!
ちょっとマイナスになりすぎたかも。個人の感想です。
まあ、上記のことは裏返しで。
①設計を綿密にやろう
②実装方針を決めよう
③保守体制もしっかり決めよう
ってことなんだけど。
特に言いたいのは③だね。
フロントエンドエンジニアの存在がもっと浸透すれば
当然、保守体制も変わっていくと思うけど、時間はかかるかもね。