--/-- (--) --:--:--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
02/02 (Fri) 01:52:45
ソフトウェア開発においてフレームワーク(以下FW)というのがありまして、
と言ってもFWの定義は幅広く、開発方法論から実際の開発手法・手順まであるのだけれども、
今回は開発手法・手順といった下流工程を意図して書く。




開発手法・手順といっても、実際なんなんだよ? ということで簡単に説明。

<製造>
例えば、特定の動作をするクラスを作る場合は、必ず「クラス名_A」・「クラス名_B」・「クラス名_C」という3つのクラスで構成すると"決めて"、各_A _B _Cには共通の役割を持たせると"決める"。
そうすると、「_Aにはこの機能、_Bにはこの機能、_Cにはこの機能を割り振ればいいんだな」 となって、作る方も読む方も管理する方も楽になる。

具体例を出すと、動物クラスを作る場合のメソッドを考えると、「呼吸をする」から、「手を動かす」、「走る」、「食べる」、etcetcと、たっくさんのメソッドがあるけど、それを1クラスにするには無茶な話。だから五感の動き(見る、嗅ぐ)は_A、生きる動き(息吸う、心臓動かす)は_B、能動的な動き(食べる、遊ぶ)は_Cというように分ける。

他にも、あるテンプレートに沿った形式で制約事項(上の例なら、脈拍はいくつ、走る時速はいくつ)を書くと、自動的にソースまでジェネレートしてくれるようなものを組み込んだスンバらしいFWもある。

<テスト>
その制約事項を元に勝手にテスト仕様書作成してくれる。

<リリース>
リリース(開発環境から本番環境に上げる)の際は、この共有サーバのここにリソースを置いて、このドキュメントに記述してetc というのを"決める"。


長くなっちまった('A`;)





で、本題。

このFW、たくさんの決まりがあって制約が多い反面、誰が作ってもある程度は似た結果になる、つまり一定の品質が保証される。そしてある程度の自動化によって、開発も早くなる。新規の人でも、その決まりに沿ってやればよいので、すぐ慣れる。また、構成が決まってるのでソースも読みやすい等々、いいことだらけ。ヒャッハー。


と一見そう思う。俺もそう思ってた。



これはPJ全体から見た話。個人から見たら話は別。

○誰が作っても似た結果になる=誰でも自分の代わりが勤まる=使い捨てられる

○当然、新規の人が入ってきたら、すぐ追いつかれる

○FWが変わったら開発経験なんて無いと同義

○自分で考える箇所が少なくて、スキルが必要にならない=スキルが見に付かない&ルーチンワークになる



かなり極端に書いてるけど、スキルの上昇度が低いのは間違いない。

技術者にとって、自分じゃなきゃ出来ない技術を持っていないと死活問題。


開発が楽になることは、必ずしも全体のプラス、全員がハッピーになるとは限らないんだなぁ 
と思った次第であります。

異論反論大歓迎。
日記CM1. │ TOP▲
  
コメント

確かに効率が良く、見通しの効くコーディングは必要だよね
そのためのFWか・・・
でも自分のスキル向上に影響がでるのも問題だねえ

あすが│URL│02/03 14:21│編集
コメントする












 管理者にだけ表示を許可する?

     
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。