この年になって感じた。プログラミング哲学や開発思想が重要だと感じた話

あいかわらずエンジニアは俺一人。そしてWebシステム的な部分も、そんなにたいしたことをやっているわけでもなく、だいたい俺一人で済んでしまう現状。*1

 

需要あるかないか分からないけど、俺得として広く知られている、個人的にたどり着いたプログラミング哲学をそれぞれ2件、取り上げます。

 

まずは、広く知られているものを

 

DRY (Don't Repeat Yourself)原則(同じものを作らず共通化)

 

私は昔初めてRuby on Rails を触れたときに知り、今になってありがたさに気づきました。

 

同じ事を繰り返すな という主旨ですが、特にWebアプリケーションなどを作るときに、参照するモデル(DB、テーブル)などが異なるだけでやりたいことは同じ。みたいなケースも多々。

 

文字列の整形みたいな機能なんか特に。

 

KISS&YAGNIの原則(簡潔に単純に/必要になってから追加)

 

これらの考え方は、コードを書く前の段階。何を実装するか(もしくはしないか)で役立った。

 

今の仕事でよくあるのが、「顧客が本当にほしかったもの」のたとえ話に出てくる、木の枝にタイヤがぶら下がっている画像のような、

 

「本当に必要なものは、それほど複雑でもなく多くもない」ものがほとんど。

 

各部門の担当者などに相談しながら進めて、いらないものは省いて早く作るが、

あとから拡張できるように作るようにした。

 

ココから先は、個人的にたどりついたもの

 

ハードコーディングが許されるのは、練習までよねー(設定ファイルなどで読ませる)

 

 

開発規模が大きくなる、別のシステムでも同じ仕組みを使う、・・・などのときに重要。 

 

プログラミング言語、環境などの入門書(特に、10日で覚える何たら入門系)・・・だけでなく全般で、サンプルコード内に文字列や設定などが直接記述されていることはおおいです。

 

たとえばこんなの

 

<pre>File.read("lib/example.txt")</pre>

 

ただしこれらは「特定のメソッドや機能などを説明するために、単純に書いた」だけであるので、実際に納品、実運用する環境下ではやってはいけません。

 

前の会社で働いていたとき、とあるプロジェクトで定例処理を書いていたときに、還暦近いエンジニアの指示で徹底されていた。高々数十行のスクリプトでも納品、共有するものなら・・・大事。

 

逆にAPIの動作検証など、個人的な使用だけで終わるようなものなら「それではやく終わる」なら、使っても良い。というのが個人的見解。

 

設定はどうやって読ませるのか?もちろん引数や設定用ファイルに記載。

特に Rubyではyamlが使えた

 

仕事をはやく終えて、遊びに行こうー(うん。重要)

進捗管理ツールの講習会に参加したときに聞いた話。

特に、いわゆる「Web系エンジニア」にありがち。*2

 

そう。俺もみなし残業労働形態なんだ。

 

(加筆するかも)

 

 

 

 

*1:少ない労力で多くの業績を上げられるのであれば良いが、エンジニアとしては物足りなく感じる今日この頃

*2:使用している言語や環境が、更新が激しいこともあるかもしれないが、それ以上に労働感の変化もあると思う。