プログラミング

プログラムを上達する方法〜とにかく小さくする〜【脱初心者を目指して】

プロゲートやドットインストールをざっと把握して、

実際にホームページや簡単なWebシステムなどをつくって、

PHPフレームワーク『Laravel』などを使ってWebシステム構築したりして、

WebスクレイピングでAmazonの商品リストなどを取得できるようになって、

オブジェクト指向の仕組みがぼんやりとわかり、(カプセル化、継承、ポリモーフィズム(多様性))

なんとなしに、プログラミングができるようになった感があるにはあるんですが、

長年活動されている現役プログラマー、フリーランスの方々などの話を聞くうちに、

もっともっと高いところへ登りたいという欲が強くなってきて。

アオキ
彼らのような高い頂へ登るためには何が足りないのだろう・・

と考えるうちに、

いくつかの答えというか、超えるべき壁がなんとなく見えてきた感があります。

Sponsored link
  • システム設計
  • データベース構造
  • デザインパターン
  • 保守性・再利用性の高いコード
  • SOLIDの法則
  • UIUX

などなど。

それぞれがどっぷりと深い内容だし、

知識として知っているのと、実際に使えるようになるのとでは大きな差があると考えて、

ではなにからやっていこうかとググるうちに、ちょうどいいプレゼン資料を発見しました。

プログラミングを上達する方法 とにかく小さくする

オブジェクト指向の設計と実装の学び方のコツ

『現場で役立つシステム設計の原則』

という本を書かれた、増田さんの2012年のプレゼン資料です。

アオキ
この本めっさおすすめです!

プレゼン資料の中で、

オブジェクトの設計と実装の基本は、

とにかく小さくすることだと書かれています。

具体的には、

  • クラスは50行以内
  • メソッドは3行以内

というルールをつくって、

できるだけ一つのコードが長くならないようにすべきだと。

小さくする分役割分担をはっきりとわけて、

できるだけ同じような場所は共通化させて。

それが脱初心者、中級者への一歩だということです。

長ったらしいコードが何故にダメかというと、

単純に、上から全部読まないと中身がわからないからなんですね。

アオキ
そういえば、とある依頼で1ファイルに3,000行書かれてて萎えた事がありましたね・・

自分が書いたコードならまだしも、

他の誰かが書いたコードを上から3,000行読むのはとにかくしんどい。

みんながみんな長ったらしいコードを書いていたら、読むだけで日が暮れちゃう。

  • 3000行のコードを上から読むか
  • 50行くらいのコードを、必要な箇所だけ読むか

を比べれば、

アオキ
そりゃあ50行の方が楽でしょ〜

と。

ではどうやって小さく書いていくかということで、

プレゼン資料の中で、小さくするための9つのコツが書かれています。

Sponsored link

プログラミングを上達する方法 とにかく小さくする9つのコツ

小さくするための9つのコツ
 
1. ひとつのメソッドのインデントは1段階まで
2. else句を使わない
3. すべてのプリミティブ、文字型をラッピング
4. ファーストクラスコレクションを使う
5. 1行につき、ドットはひとつ
6. 名前は省略しない
7. クラス50行、パッケージ10ファイルまで
8. インスタンス変数は2つまで
9. getter/setterを使わない

いきなり全部は難易度が高いので、

まずは、

2. else句を使わない

というお題から取り組んでみました。

もうね、初心者向けの本なら必ずと言っていいほど紹介されている if 〜 else 文。

ですが実際には、

書けば書くほどややこしくなるので、できるだけ else は使わない方がいいようです。

確かに else を書かないようにしてみると、

プログラム自体がすっきりスリムに感じてきます。

アオキ
さようなら else くん、またどこかで・・

次に、

6. 名前は省略しない

メソッド名などできるだけ、名詞動詞+名詞 で書くようにして。

この辺りまでは身についてきたので、次は

8. インスタンス変数は2つまで
7. クラス50行、パッケージ10ファイルまで

というルールを身体に徹底させようかと。

プログラミングを上達する方法 小さくする事を意識してコード書きまくる

とにかく小さく、という事を意識してコードを書くうちに、

関数、クラス、継承、インターフェースあたりの知識が身についてくるだろうと。

パーツごとに役割をしっかり分けて、

同じような書き方があればメソッドとして分離させて。

会社もプログラミングも同じで、

営業がいれば総務がいれば、マーケティング部に人事部などなど、役割が別れているのと同じように、

プログラミングを役割を分けた方が後々効率がよく、整理もしやすくなると。

それが『ドメイン駆動設計』の意図だと思われます。

とはいえいきなり設計するのはなかなかハードル高く、何度もやりなおし!ってなりそうなので、

とにかく小さく作ることを意識してコードを書きまくるしかないかなと思っています。

アオキ
とにかく数稽古ですな、もりもり書くべし書くべし。

アオキ
ツイッターでも記事ネタ含めちょろちょろ書いていくので、よろしければぜひフォローお願いしますm(_ _ )m

アオキのツイッターアカウント


関連記事一覧 (一部広告あり)

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

CAPTCHA


最近の記事

  1. CG関連

    【3Dプログラム】初心者にオススメな方法はこれ(9)【P5.js】
  2. CG関連

    【P5.js】遊ぶようにプログラムできるクリエイティブコーディング〜はじめのいっ…
  3. 学び・教育

    『プログラミング教育』より大事な事を考えてみる~AI時代を見据えて~
  4. CG関連

    【WebGL】入門 わかりやすく【図解】してみた
  5. 学び・教育

    『ニュータイプの時代』〜リベラルアーツとテクノロジーの融合〜
PAGE TOP