スポンサーサイト

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

システム開発の入門者から中級者にステップアップするための10のティップス

CATEGORYプログラム
システム開発の入門者から中級者にステップアップするための10のティップス
彼は、開発者向けのブログや記事、雑誌の内容が2種類に分類できるということを述べていた。その2種類とは入門者向けのもの("Hello World"に代表されるもの)とエキスパート向けのもの(MSDN Magazineのようなもの)である。
    (省略)
開発者が入門レベルから中級レベルにステップアップするうえで役立てることのできる情報がほとんどないのだ。

#1:新たなプログラミング言語を学習する
#2:検索を行うための高度な技術や戦術、戦略を学ぶ
#3:他者を助ける
#4:根気よく学習し続ける
#5:人の言うことを鵜呑みにしない
#6:いくつかの先進的アイデアを徹底的に掘り下げて学習する
#7:あなたの分野を支える基本的な理論を学ぶ
#8:上級開発者のコードを読む
#9:良い習慣を身に付ける
#10:楽しむ

というようなことが書いてある。
確かにその通りなんだけど、Tips というには実行に移すにはハードだったり、精神論的なことだったり。
自分だったらどうだろう、と考えてみたりした。

  1. マニュアルを読む
  2. 理論を学ぶ (設計論とか計算機工学とか)
  3. ドメインの常識を知る
  4. 他人のコードをデバッグする
  5. 他人にコードを見てもらう
  6. 初心者のうちに、エキスパート向けの情報を読む
  7. 複数のOSを触る
  8. 寿命が長いプログラムを作る
  9.     うーん...


・マニュアルを読む

まず、マニュアルをてっぺんからケツまで、とにかく一通り読んでみる。
言語のでも、API でも、OS でも、何でも良い。
ググれば知りたいことはすぐ分かるようになっているのだけれど、そもそも何をキーワードにして探せば良いか分からないことには始まらない。
頭の中にインデックスを作っておくことが大事(内容まで覚える必要は無い)。

もうひとつの側面として、仕様を仕様としてきちんと理解する癖をつける。
API の二番目の引数の意味がよくわからないけど、0 を入れてみたらなんとなく動いたからOK、なんてやっているうちは、いつまでたっても入門者の域を超えられない。

そういえば、入社一年目についた先輩が「こういうコードで実験してみたら…」ってよく言ってたけど、基本的にありえないな。
API の使い方なら、まずはマニュアル。アルゴリズムなら、それなりの書籍(次項)をまず当たろうゼ。

後、マニュアルが英語だからって避けて通らないのも大事。
下手な機械語翻訳よりも、英語の原本の方が分かりやすいことも多い。


・理論を学ぶ (設計論とか計算機工学とか)

ただ動けば良い、ってものじゃない。
どう設計すべき、だとか、こういうアルゴリズムは、こんな局面でとても効率的だとか、いろいろな人がずいぶん前からいろいろやっている。
最初から全て理解しなければいけない、ということじゃない。

ちょっと前、職場で小耳に挟んだ話。

(A) 「ユースケース図を、どの単位で書いたら良いんだ?」
(B) 「機能単位に書いていけば良いんじゃない?」
(A) 「あの機能を使うアクターが多すぎてなあ…」
(C) 「でも、メディエーターをどこに書いたら良いかな」

って...
ユースケース図は、ユースケース単位に書くに決まってるじゃん。
ユースケース図を書く前に Mediator とか言ってんなよ。
UML をろくに読んでないうちに、GoF 本を読んだんだろうなあ、とか邪推したり。


・ドメインの常識を知る

プログラムは、あくまでも「道具」なんで、それが使われる問題領域で、どんなことが常識なのか、どういう業務で使われるのか、使う人はどんな人たちなのか、というようなことを知っていることは、とても大事。

受発注をするようなシステムを作るようなところに居るなら、簿記とかキャッシュフローの考え方とか、知っておいたほうが良い。

その方面の第一人者になる必要は無い(なれるに越したことは無い)。でも、客が言ってることがわかる程度にはなろう。


・他人のコードをデバッグする

「なんでこんなクズみたいなコードを、オレがなおさにゃあいけないんだ」みたいな気持ちになることもあるけど、結構、地力がつく。
ある程度、冷静にコードを読めるので、
  • こういう書き方をするから、こんなバグを埋め込んでしまうんだ
  • コピペするから、何箇所も直さなくちゃいけない
  • コーディング前の設計って大事だなあ

など、いろいろなことが実感として分かる。

仕事でそういう機会があまり無いなら、自分で使うツールは、なるべくソースが公開されているものにしたら良い。
デバッグとは言わないまでも、気に入らないところを直したりするのは、とても良いこと。


・他人にコードを見てもらう

前項の逆。
「デバッグしてね」とは言いづらいけど、機会があれば、コードのレビューをしてもらおう。

オープンなコミュニティに参加してパッチを出したり、質問サイトでコードを晒して回答したりするのでも良い。
質問サイトで、よく「(宿題なんかの)教えて君には困ったものだ」みたいなことがよく言われるけど、新しい言語を覚えたりするときの肩慣らしなんかにはちょうど良い。


・初心者のうちに、エキスパート向けの情報を読む

元ネタにあるように、確かに公開されている情報のレベルは連続していないのかもしれない。
であれば、自分にはちょっとレベルが高いかな、というような情報を積極的に読もう。

最初から全部わかる必要なんて全く無い。
「こういうことを問題にして考えている人も居るんだ」というようなレベルからでも、読んでいくうちに自分のレベルは確実に上がってゆく。


・複数のOSを触る

元ネタにあった「新たな言語」というのに近いかもしれないが、入門者のうちは、最初の言語ですらままならないのに、次の言語も「本当に身につける」というのはかなり敷居が高い。

Windows で VB しか触ったことが無いのであれば、unix 系のパイプでつなぐコマンドの使い方を知る、とか、逆に unix 系で画面は X という世界しか知らないなら、Windows で VBA をやってみるとか。

プログラムにどんな機能を持たせるかのアプローチにはいろいろあるのだ、ということを知ることは大事だし、環境が変わると、思わぬ制約があるのだ、と気づくことも。


・寿命が長いプログラムを作る

作り捨てのプログラムだけを書いていると、コーディングに至る前の設計の大事さ、というようなことが実感として分からないと思う。
長い期間付き合っていくプログラムは、「設計というのは(機能追加を含めた)保守を楽にしてくれるのだなあ」と気づかせてくれる。

仕事でそういうプログラムにめぐり合えることは、幸運に恵まれないと難しいかもしれない。
そういうときには、自分用のツールを作ろう。なるべく長く付き合えそうなやつを。


・    うーん...

なかなかきれいに10個というわけにはいかないな。
候補として、以下のようなことを考えては見たのだけれど
  • コストについて考えてみる
  • 統計学を学ぶ
  • デバッガに頼らない
  • 自分できちんと理解/検証する
  • 得意技を持つ
  • コーディングスタイルを確立する

どれも、最後の二個に当てはめるには、ちょっと違う気がするんだよな。

コストについて...

お金のことはマネージャーに任せてあるから関係ない?
でも、お金は、コストパフォーマンスの分母にくるものだし、また、アウトプットの具体的な評価基準のひとつでもある。
# いや、メンタルな話は Tips じゃないな

統計学を学ぶ

代表値とか、検定とか。
ちょっとしたボリュームのものを相手にする場合には、知っておかないと、パワーだけで立ち向かう羽目になっちまう。
少しでもかじっていたら、「バグを全部無くせ」というようなたわごとも出てこないはずだし、そんなたわごとを聞いたからといって、逆ギレすることもなかろう。
# とはいえ、中級者になるためのステップなのか、というと...

デバッガに頼らない

一昔前、今のように統合環境が当たり前じゃないときには、デバッグというと、いきなりプリントをちりばめるのが当たり前だった。
そんなんで、printf() を入れたら再現しない、とか、消しちゃいけない printf() なんてのも良く見たもので、「デバッガを使おうよ」なんて言ってたものだった。
時代は流れて、今やデバッガを扱えないやつのほうが珍しくなったが、逆に、手元に実行環境が無いとデバッグができないやつが増えた。
そんなやつは、ログの残し方も下手っぴで。

# この中では、10個入りに一番近いと思うのだけれど、Tips たるまで消化しきれない

自分できちんと理解/検証する

元ネタの「他人の言うことを鵜呑みにしない」。
ネットで探し当てたコードを組み合わせただけで製品に仕立て上げちゃうなんて...
せめて、自分が書いたコードは説明できるようにしようよ。

# これも、このままでは精神論に近い

得意技を持つ

元ネタの「掘り下げる」。

# んー、そうなのかなあ。
# 中級者になったといえるときには、得意技が幾つかできている、というように方法じゃなくて、結果のような気がするんだが

コーディングスタイルを確立する

元ネタの「良い習慣」。

# スタイルに対するこだわりは大事だと思うけど、具体性に欠けるんだよな。
# 「スタイル」としてどうかな、というコードを書く GURU も居るしなあ


ま、良いか。自分的には、なんとなく終了したかな。

結局、「動けば良いや」→「ただなんとなく動いてるだけじゃ駄目なんだ」と考えられるようになったときに、その間でやってきたことをを思い出して、優先順位をつけてるだけなんだ、と気づいた。


# というか、飽きた :-)




ちょっとだけ、元ネタに突っ込み。

#2:検索を行うための高度な技術や戦術、戦略を学ぶ
検索だけで済ませてるのが、入門レベルを超えられない原因だと思うけど。
いろんなことを覚える必要は無くて、どこに書いてあるか、とか、どうやれば調べられるのかだけを知っておけば良い、というところまでは同意する。

#5:人の言うことを鵜呑みにしない
っていうか、#2 のようなのを Tips にするからでしょうが。
基本的に、ネットで得られる情報の九割はノイズだと思って間違いない。

#4:根気よく学習し続ける
#10:楽しむ
当たり前じゃん。中級者にステップアップしたいと思ってるなら、楽しんでやってるに決まってる。
ってか、楽しいでしょ?
関連記事
スポンサーサイト

0 Comments

Leave a comment

1 Trackbacks

Click to send a trackback(FC2 User)
この記事へのトラックバック
  •  UMLがわかる本
  • UMLがわかる本 UMLの学習を必要とする人には、大きく分けて2つの立場が存在するのではないでしょうか。 ひとつは、UMLによって設...
  • 2009.06.16 (Tue) 15:53 | もぼなもな書房
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。