プログラミングについて

ちょっと思ったこと。
仕事でやるプログラムと、趣味(ってわけじゃないけど)でやるプログラミングって全然書き方違うんです。
仕事のばやい、みんなで作業するんで、あんまり自分勝手には作らない（作れない）んですね。
自分がプロジェクト抜けた時に、スムーズに引き継ぎとかできるようにね。
「おいおい、あいつのとこだけ書き方違うから読みにくいぜ！」とか「こいつ、勝手に部品作ってやがる！」とかありがちですから。

だから、コーディング規約みたいなものを使ってプログラムの書き方のルールを決めます。
僕の場合、導入前のプロトとか作ることが多い（ルールを作る側）ので、自分勝手にやりがちだけど（汗）

単純に書き方のルールから、各種ネーミングルール、共通部品をどうまとめるかのルール、そのたもろもろ。
要するに、だれが見ても瞬間で違和感なくコーディングできるように（メンテナンス性を上げる）っていうこと。
メンバの入れ替わり激しい現場多いから。

メンテナンス性を上げるために、フレームワークを作る。
重要な処理とか処理フローの枠を牛耳っておかないと、何かあった時に全改修あああぁぁぁぁぁぁとかっていうことになっちゃう。

また、メンテナンス性を重視していくと、時にはパフォーマンスを犠牲にすることもあります。
パフォーマンスを無視してるわけではなくて、妥協できる部分でメンテナンス性を優先させるってこと。

ちょっとくらいパフォーマンス悪くなっても、可読性を上げておく。
→言っても、そんな悪くならないですけどね。

ちょっとくらいパフォーマンス悪くなっても、共通部品にまとめておく。
→仕様変更時の修正箇所を集約したいし。

ちょっとくらいパフォーマンス悪くな・・・・・・・・


というように、お仕事の場合メンテ重視にコーディングをすることが多いです。

だから、Androidアプリ作り始めのころ、僕のアプリ共通のフレームワークみたいなもの作ったり、メンテ重視でいろいろ手探ってたんですけど、これは全部ボツになりました。
なんでかというと、「ちょっとくらいパフォーマンス悪くなっても」が致命的だった。
「ちょっとくらい」はAndroid（いろんな端末あるから）にしたらちょっとじゃなかった。

結局のところ、メンテナンス性とか、可読性とかよりも省メモリ・省電力・高速化・アプリサイズを小さくとかいう事に重点を置くようになりました。
プログラムも僕しか見ないから、可読性なんか悪くても良い（ってことはないけど）し、メンテナンスも機能の切り分けだけできていれば大したことないし。

同じものを作るのにも、いろいろなアプローチがあって面白いなぁ。
良し悪しはないので、臨機応変にやるしかないんでしょうけど。


で、何をこんなこと書いているのかというと、仕事で「ソース読みにくくなったよね」って言われたから。。
ごっちゃになっちゃってんさ。

ごめんなさい関係者さま。
このブログのことは知る由もないんでしょうけど。ｸｯｸｯｸｯ。