デジタル(ソフト)

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

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

実際にホームページや簡単な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. バックエンド

    【Laravel第4弾】Vue.js3(CompositionAPI+Scrip…
  2. オンライン教材

    ChatGPTをビジネス活用する講座をリリースしました【Udemy】
  3. オンライン教材

    【ChatGPT】エンジニア編をリリースしました
  4. オンライン教材

    【AWS】【初心者向け】インフラの基礎からわかる講座をリリースしました【Udem…
  5. オンライン教材

    【React】初心者向け講座をリリースしました【MUI】【Udemy】
PAGE TOP
Ads Blocker Image Powered by Code Help Pro

広告ブロックを摘出しました!!

ブラウザ拡張を使用して広告をブロックしていることが摘出されました。

ブラウザの広告ブロッカーの機能を無効にするか、
当サイトのドメインをホワイトリストに追加し、「更新」をクリックして下さい。

あなたが広告をブロックする権利があるように、
当方も広告をブロックしている人にコンテンツを提供しない権利と自由があります。

Powered By
100% Free SEO Tools - Tool Kits PRO