もとやんです。
最近はなんだかプログラム開発と、コンサルティングの業務が増えてきました。お仕事募集中です。
まぁそれはそれとして、ちょっとプログラムの話を脳みその整理がてら書いときたいと思います。
プログラミング能力は独学できるのか
もちろん独学できます。私もすべて独学です。
もちろん書籍やネットのリソース、あと雑誌とかの類には大変お世話になりましたし、現在進行形でなっております。
・・いまだに取ってあるC MAGAZINEのバックログとかたまに読み返すと面白いんだよな・・。
とか思ったら電子版発見した。
C MAGAZINEの電子版がkindle unlimitedにあるだと・・！？
— calcs (@calcs) 2017年7月21日
個人開発で身につきにくい力
まぁ自分で目的を持ってごにょごにょプログラム書いていれば腕は上がっていきますし、できることも増えていくんですが、一方なかなか身につきにくいこともあります。
たまに聞く独学だと大きな規模感のコードの書き方が身につきにくいとか、コードが汚い(綺麗さに頓着しない)とか言うのはあんまり無いんじゃないかなと思います。
独学で個人開発オンリーだと身につきにくいかなーと個人的に思うのは例えば下のようなもの。独学でも仕事するようになったら勝手に身につきますけどね。
- 自動化テスト
- （教科書通りの正規化以外の）DB設計
- ドキュメント作成のコツ
自動化テスト
自分の独断で仕様を作れるからあんまり仕様的な意味で手戻りすることが少なかったり、コードをガンガン書き捨てて行ってるからリファクタすることがないとかだと、自動化テストのニーズをあまり感じることはありません。
前者はゲーム開発とか、後者は短いコードで問題を解くことに快感を覚えるcode golfer的な素養を持っている人とかのイメージです。
ドキュメント作成のコツ
まぁ一人で完結してるとこれもあんまりやる機会無いから上達しないんですよね。
APIとかライブラリとか作って公開するなら、インタフェース仕様書を書く必要性には駆られるんですが。
開発前にゴリゴリと設計指針をメモ書きして置くだけでも結構後で役立つので、ちょっとずつやっておくことをお勧めします。
（教科書通りの正規化以外の）DB設計
本稿の本題はコレ。DBの利用があることが前提ですが・・。
まぁ自分だけで開発してると結構この辺はきれいに作りたくなるので(ていうかわざわざ汚く作る必要はない)、パフォーマンスに影響を与えない範囲でそれなりに正規化してシステムを作るのが普通です。
ただまぁ、実際にサービス稼働させると結構それだと困ることがあったりするんですね。
具体的には監査です。
監査と一言で言っても色々あるんですが、まぁここでは「操作(データの変更)の履歴の追跡ができること」としておきましょう。
これを実現するには、RDBMSでいえばUPDATE文を単純に使えなくなります。
システム内でお金を使ったからといって
UPDATE wallets SET amount = amount - 100 WHERE user_id = XXXX
とか書けません。
具体的には増減等の操作をひたすら追記していき、現在の値はその総和としてとるような仕組みにしなければいけなかったりします(それだと重いから上記のような処理をキャッシュ的に作ることはある)。
法律やらサポートの兼ね合いで、不正な操作やトラブルがあった際に追跡できるようにしておかなかったりするので、一部のデータにはこういった設計を取り入れる必要がある場合もあります。
追記型のデータベースを使うことでミドルウェアにその辺を任せる選択肢もあるんですが、まぁその辺含めて結局監査をどうするかを考えないといけないという点では一緒です。
もちろんこういうことを考慮しないといけないということさえ分かっていれば、設計に組み入れればいいだけではあるんですが、独学で個人開発オンリーだとあんまりぶつかることないから思考のエアポケットになりやすいよね、という話でした。
番外編
業務知識とかは完全に別枠だと思うので、ここには書かないよ？
コメント