沼津カンファ2

高専カンファレンス in 沼津2で使った発表資料

2年弱前 にアップロード

(2013年03月02日)

「沼津カンファ2」の内容

  1. プログラミング破門 @_a__san アーさん || あーさん
  2. 自己紹介 @_a __san アーさん プログラミング歴 = パ ソコン歴 ゆる ふわガチ勢
  3. 提供 なんちゃっててへぺろ ゆるふわにわか プログラマー()
  4. 破門? 入門 = 言語などの使 いかたを紹介する 破門 = 言語を使えなく する?
  5. 破門? 入門 = 言語などの使 いかたを紹介する 破門 = 言語を使えなく する? 間違った使いかたをする → 破門に繋がる プログラミングの共通項 : コード
  6. こんな人が対象 オブジェクト指向言語 の機能は知ってる オブジェクト指向なコード を意識したこ とはない コード設計な話
  7. オブジェクト指向での コード設計
  8. コード設計の必要性って?
  9. 可読性の向上 読みやすいコードは他の人が編集しやすい チーム開発での開発効率が上がる
  10. 再利用性の向上 機能ごとにコンポーネント化する 他に使いまわせるようになる
  11. 保守・拡張性の向上 保守性が高いとシステムが安定する 拡張性が高いと新機能の追加が容易 柔軟なサービスを提供できる
  12. 設計することで得られる 恩恵は多い
  13. 世の中のコードの全てが 設計されてるのか? 商業・個人に関係なく N O !!
  14. オブジェクト指向に基いて 設計されていないコード オブジェクト指向を知らない 設計したかったコード オブジェクト指向は知ってる 設計を知らない 設計されてるコード オブジェクト指向も設計も 知ってる
  15. 二つのコードを見比べてみる ※注意 スペース上の問題で簡略化した記述をしています 文法が滅茶苦茶なのはご了承ください
  16. ここでは ・Twitterの簡易版botで考えてみる ・継承・抽象化などは使わない(話がややこしくなる) ・機能はツイート・リプライの2つのみ と仮定
  17. 設計されていないコード
  18. class Bot{ string screen_name; main.cpp Bot(string str){ screen_name = str; int main(){ } Bot bot = Bot("bot_munyo"); void Tweet(string str){ : } bot.Tweet("tweet!!"); void Reply(){ : return 0; } }}
  19. main関数と同じファイルにclass実装してる ・可読性 ・再利用性 全てにおいて悪い ・保守・拡張性
  20. 可読性 main.cppの行数が1000行以上あるとします もし閉じ中括弧"}"を書き忘れたら? 1000行のコードの中から探しだす → ダルい 機能ごとの依存関係チェックが必要になったら? 1000行ほぼ全て読むことになる → ダルい
  21. 再利用性 main.cppの行数が1000行以上あるとします Tweet機能だけ他で使いたい(Twitterクライアントとか) 依存関係を調べ,他のファイルにコピペして使う ベースシステムを別のプロジェクトに流用したい ベースシステムだけの抽出にコストがかかる
  22. 保守・拡張性 main.cppの行数が1000行以上あるとします 新しい機能を追加したいとする(DMの操作とか) 1000行のどこかに追加することになる → 肥大化 可読性・再利用性の更なる低下 バグが検出されたとする どの部分が悪さしているのかを特定しづらい
  23. オブジェクト指向が意味をなしていない
  24. 設計されてるコード
  25. class Tweet { #include "Tweet.h" int BotTweet(){ #include "Reply.h" : Tweet(){ } : class Bot{ } Bot(){ int BotReply(){ : : : } } } } Tweet.cpp Bot.cpp class Reply { #include "Bot.h" Reply(){ int main(){ : Bot bot = Bot("bot_munyo"); } : bot.BotTweet("bot tweet!!"); } return 0; Reply.cpp } main.cpp
  26. 機能ごとにファイル分けがされている ・可読性 ・再利用性 全てが向上している ・保守・拡張性
  27. 可読性 もし閉じ中括弧"}"を書き忘れたら? ファイル分けによって,最低限度のチェックで済む 機能ごとの依存関係チェックが必要になったら? 実装ファイルとインクルード先のチェックで済む
  28. 再利用性 Tweet機能だけ他で使いたい(Twitterクライアントとか) 必要な機能を実装してるファイルをそのまま使える ベースシステムを別のプロジェクトに流用したい ベース機能を実装しているファイル郡を使えば良い
  29. 保守・拡張性 新しい機能を追加したいとする(DMの操作とか) 機能を実装したファイルをインクルードするだけ バグが検出されたとする バグがある機能を実装したファイルを軸にチェック
  30. オブジェクト指向な設計によって よりクオリティの高いコードが書ける
  31. オブジェクト指向の恩恵 - 番外編 gitなどでバーション管理をしていた場合 + githubと連携など
  32. 1ファイルに全てを記述すると ・コンフリクト(衝突)が起きるリスクが高い ・コミットログとコードの対応付けに手間取る ・githubで公開しても,他の人が読めない(読まない)
  33. 機能ごとに分割して記述すると ・コンフリクト(衝突)が起きるリスクは通常コスト ・コミットログとコードの対応付けが容易になる ・githubで公開しても,他の人が手を加えやすい
  34. バージョン管理にも設計は影響してくる 最近ではバーション管理システムを使うのが デファクトスタンダード(例外もある) 高専の下級生のうちからgitなどを 使い出した方が良い かも githubなら無料リポジトリが簡単に手に入る
  35. 最低限度の設計は意識してコードを書いてみましょう さもなくば リファクタリングで死人が出る
  36. いろいろ書籍もある
  37. いろいろ書籍もある

このスライドを共有する

  • このエントリーをはてなブックマークに追加
↑