初級者と中級者の狭間で
ちょっとリアクションが遅かったけど、静的オブジェクト指向は設計者が苦労を背負込むシステムを読んで。
自分の経験に照らし合わせると、業界に入って6年、Javaをやり始めて3年、たどたどしいながらもプログラミングが出きるようになり、
プログラミングにやや自信がついた頃には共通チームに所属したり技術リーダーとかになったりし、
そして今、フレームワークの開発をしてる。
フレームワーク開発をちゃんと行えるというラインを中級者とすれば、
自分は丁度初級者と中級者の狭間にいるんでしょう。
初級者と中級者の間の差ってのは本当に深くて、今その差を越えようとしている者としては実感もひとしおです。
制限の中でプログラミングをするのと、その制限を考えると言うのは、頭の回転数が雲泥の差に感じられます。
Javaの特にWebアプリケーションは覚えることも多いし、
そもそもServletやたいがい利用されるWebフレームワークって奴が事の本質を隠蔽しちゃっている部分もある。
覚えることの多さと、「本質の隠蔽」がさらにいろんな壁を作っちゃってるんだろうな。
自分は今までそんなに感じなかったけど、JavaとJavaを使ったWebアプリケーションが、
成長曲線がなだらかでない言語(システム)であるってことは、言われてみると納得できる。
技術の二極分化って言うのかな。
なんか格差社会みたいだけど、技術レベルの二極分化というものを、
経営者は意識しないといけないんだろうと思う。
意識しないといけない事の一つが技術者の評価であったりするんだろうけど、
技術力のある人が作ったクラスがどれだけの生産性を向上させたかを示す指標ってのは、測るの難しいなぁ。
コードレビューの文化が根づいてたら、そこでの発言をきっちりフォローしていけば評価していけるかもしれないけど、
この方法だと評価者にも技術力がいるし、技術的趣向の問題もある。
ただ、初級者と中級者、上級者の差別化は出きるだろうな。
まとまらん文章を書いたけど、なんにしろ評価は難しい。
技術力の高い人が評価される世の中になって欲しいもんです。
自分の経験に照らし合わせると、業界に入って6年、Javaをやり始めて3年、たどたどしいながらもプログラミングが出きるようになり、
プログラミングにやや自信がついた頃には共通チームに所属したり技術リーダーとかになったりし、
そして今、フレームワークの開発をしてる。
フレームワーク開発をちゃんと行えるというラインを中級者とすれば、
自分は丁度初級者と中級者の狭間にいるんでしょう。
初級者と中級者の間の差ってのは本当に深くて、今その差を越えようとしている者としては実感もひとしおです。
制限の中でプログラミングをするのと、その制限を考えると言うのは、頭の回転数が雲泥の差に感じられます。
Javaの特にWebアプリケーションは覚えることも多いし、
そもそもServletやたいがい利用されるWebフレームワークって奴が事の本質を隠蔽しちゃっている部分もある。
覚えることの多さと、「本質の隠蔽」がさらにいろんな壁を作っちゃってるんだろうな。
自分は今までそんなに感じなかったけど、JavaとJavaを使ったWebアプリケーションが、
成長曲線がなだらかでない言語(システム)であるってことは、言われてみると納得できる。
技術の二極分化って言うのかな。
なんか格差社会みたいだけど、技術レベルの二極分化というものを、
経営者は意識しないといけないんだろうと思う。
意識しないといけない事の一つが技術者の評価であったりするんだろうけど、
技術力のある人が作ったクラスがどれだけの生産性を向上させたかを示す指標ってのは、測るの難しいなぁ。
コードレビューの文化が根づいてたら、そこでの発言をきっちりフォローしていけば評価していけるかもしれないけど、
この方法だと評価者にも技術力がいるし、技術的趣向の問題もある。
ただ、初級者と中級者、上級者の差別化は出きるだろうな。
まとまらん文章を書いたけど、なんにしろ評価は難しい。
技術力の高い人が評価される世の中になって欲しいもんです。
Comment
カテゴリ一覧
最近のエントリー
最近のコメント
2008-05-28 Wed 19:42
>自分は丁度初級者と中級者の狭間にいるんでしょう。
フレームワークを作ろうとしている。
それらの中で制限、制約などを考えようとしている。
これらはすでに中級～上級へのアプローチのように思えます。
で、初級～中級、中級～上級となっていくにつれて、プログラム言語と言う敷居が無くなってきて、徐々にインフラや人の思考を思考するなどと言った別の技術が必要になってくるように思っています。
>生産性を向上させたかを示す指標ってのは、測るの難しいなぁ。
よく思考されたクラスを利用する場合には、生産性の向上ももちろんですが、その後の維持運用時に大きな差が出てくるのではないでしょうか。少なくとも私はそのように考えています。
理由としては、思惑と異なった使い方をされやすいことと、より多くの人の手を渡っていくためです。
そのため、クラスを設計する時点でより多くの時間をかけて思考する時間が大切だと思います。
（現実には、そこに時間をなかなかかけさせてもらえず、様々な妥協が後に発生する場合が多いのですが・・・）
>この方法だと評価者にも技術力がいるし、技術的趣向の問題もある。
そうですね・・・。コードレビューと言う観点では非常に評価が難しいように思えます。
趣向の問題については、評価者と言う立場にいるのであれば対象者の思考を紐解いて様々な概念を許容する必要があるかと思います。
>技術力の高い人が評価される世の中になって欲しいもんです。
同感です・・。
また、立場的なものについても考えてほしいものですね。
別に誰それが偉いとかではなく、PMもSEもPGも同等の立場で作業できる環境があればいいと言う意味で・・・。
2008-05-28 Wed 20:36
>これらはすでに中級～上級へのアプローチのように思えます。
まだまだ初級者の域を脱していない自分なので、いきなりのレベルアップということかぁ。。。
精進しなければ！
>その後の維持運用時に大きな差が出てくるのではないでしょうか。
もちろん維持運用ってのも含みます。
クラス設計を形にする上でのメソッドのスコープなんかは結構気をつかいますよね。
リファクタリングのし易さってのも良く考えます。基本的な所だとメソッドの構成とか。
>別に誰それが偉いとかではなく
いろんな所で言われていることですが、どうしてもPGが下っていう風潮はよーく肌身に感じます。