新卒向けカリキュラムを考え中の記事を書いたのが去年の8月末です。あれから半年以上、時間が経つのは早いものです。
先月、講義がひととおり終わりました。時々、講義資料のメモをここで公開しましたが、公開していなかった初回の講義メモを公開します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
新卒向け講義 Part0 ================================================== 最初に謎かけ - なぜプログラマは0から数えるのか? 今後の進め方 - カリキュラム全体像 - 4本柱(プログラミング、システム、Web、開発プロセス) http://dev.ariel-networks.com/wp/archives/821 - プログラミングから開始 途中、システムと開発プロセスを並行して進めながら、Web修了でカリキュラム終了 - 週一回の講義 - 毎回、宿題(課題)を出します http://dev.ariel-networks.com/wp/archives/883 - プログラマとして何を目指すべきか 最も価値ある問いは「何を作るか?」 => しかし、これは教えられない(答えがわかったら他人に教えず自分で作ればいい) => 自分自身の中で問い続けるべきだが、本講義のスコープからは外す 次に価値ある問いは「どう作るか?」 => コスト(お金と時間)をかければ、たいていのソフトウェアは作れる => (当然ながら)低いコストで作れたほうが競争力が高い => 多くのソフトでコストがかかるのは、(改善も含む)保守 => 保守コストを下げるには? コードの可読性 => 人間が読んで理解できるコードであればなんとかなる => 可読性はあまり自明ではない(単なる慣れかもしれない) => ロジックの明瞭さ、境界の意識、依存性の意識、名前、イディオム、etc... => まずは意識することから始める => 他人の目を意識してコードを書けるようになれば、本講義は(一応)卒業 - 実践的アドバイス 慣れたツール(環境)を作る コードを書いてすぐに試せる環境を構築する 書いた検証コードを書きためておく 本を読む(とりあえず目を通すだけでもいい) 手を動かす 勉強会に参加する ソーシャルメディアを使う - 心構え 技術的な足場を作る(狭く深く) 色々と手を出す(広く浅く) 無理をしない(技術の習得は長距離走だと認識すること) 熱狂できるか見極める(プログラマが向いていない可能性もある) 他部署の人と交流する 英語の勉強をする |
なぜプログラマは0から数え始めるか、という簡単な謎かけで講義を始めました。ある知識(メモリのアドレス。2進数。ビット数を省略する文化など)を知っていればわかりますが、たぶん知らないだろうと思って質問しました。予想どおり知識はなかったのですが、簡単に正答したので驚きました。今時のなぜなぜ思考はあなどれないと思いました。
さて講義ですが、教えられるほうも初めてですが、教える側も(本格的な講義としては)初めてなので苦労もありました。パーフェクトJavaを書いたので、教えるのは簡単だろうと思っていましたが、そうでもなかったです。本に書いてあることそのままを口頭で話しても仕方ないと思いながら、言いたいことはだいたい本に書いてあるというジレンマがありました。
プログラミングでもっとも大事なのは分割統治だと繰り返し伝えました。プログラミングでは複雑さをいかにてなづけるかが重要で、そのためのもっとも効果的な手段が分割統治だからです。
最近、ある生徒のコードレビューをしていますが…分割しすぎです…。デザインパターンの弊害を見る思いです。
しかし、コードレビューにより、意味のある分割とそうでない分割を考えるきっかけになりました。この問いは意外に深いものです。意味のない分割のアンチパターンを分析しています。次回、人に教える時には役立ちそうです。それから、コードを読んでもっとも違和感があるのが命名です。命名に比べればロジックの巧拙は誤差です。命名は分割にも関連します。そのクラスの役割(責務)は何なのか、という問いかけに通じるからです。これも長年業界にいすぎて改めて考える機会が減っていた名前づけについて考えるきっかけになります。
最近のコメント