プログラム学習カリキュラム
本日ちょうど大学の助教*1さんと学習カリキュラムについて話す機会がありました。
正直なところ、授業というスタイルでは全員に正しいことをたたき込むのは難しいので、気づくための欠片を埋め込むのはどうかという話になりました。
よいソースと悪いソースの比較
何が良くて、何が悪いのかを明確に定義しておく。
２つを比較出来る様にする。
悪いソースから、どこが悪いのか、どこが良いのかを発見するといった、厳密な採点では測れない、自分の意見とその理由を確立するためのカリキュラムを提供する。
(例)
変数を使い回す。
hoge1, hoge2, ... や a,b,c,...など、命名規則が悪い。
マジックナンバーを多用する。
共通処理が何ヶ所にも現われる。
不要なコメントを残す。
ツールをツールとして扱う
フローチャートやUMLは考えをまとめるツール。
決してこれが必要だという馬鹿な考えを押しつけない。
仕様書の矛盾*3を感じて貰う。
この様なことを授業中に述べたり、配った資料に明記したりといった方法で、頭の片隅には(運が良ければ)残るようにする。
そのとき理解できなくても、必要になったときの指針となり得るため、十分有用だと自分では思う。向上心のある人は、それについて自分で聞いたり、調べたり*4すると思うし。
また、私見ですが、会社に入って教育を受けても、ソフトウェアについてはプロになれる保証がないんですよね。しかも高確率で。
なぜなら、教える事が間違えている*5から。
それを考えると、情報系学生は時間のあるうちに勉強して、自分の意見を固めておくことをおすすめしたいです。
