保守性の高いコードを書くためにはどうしたらよいか
https://qiita.com/syguer/items/f5d9d02d8405d63d30a4
自分で書いていても当たり前のことだなぁと思うものの、当たり前のことを続けることは意外と難しいものです。
なぜ、当たり前のことが難しいかを、いくつかの事例を頭に思い浮かべながら整理してみる。
テストコードを書く
自分の知る範囲で、９割くらいの学校で、設計と試験を同時に書くことを習慣づけていない。
数少ない試験を書くことを教えている学校では、OS、言語、通信規約の設計を教えていない。
どういう設計の時は、いつ、何のためにテストコードを書くかを教えていない。
テストコードを書く場合でも、最終納品試験のテストコードは書けても、二つの設計の候補を評価するためのコードは書けないとか。
テストコードを書くのが難しいのは、設計と試験と仕様が三位一体で同時に考えないとよい設計、よい仕様になることが確かめられないことを経験していないからかも。
静的解析ツールを使う
無料のツールでは痒いところに手がとどかない場合があるかもしれない。
しかし、有料のツールを買ってもらえない場合があるかもしれない。
無料のツールであっても、かければ価値があるかもしれない。
dockerで用意しておくといいかも。
ライブラリのコードを使う。
どれだけライブラリがあるか知らない。
知らないコードは使えない。
コードを読む
ライブラリに限らず、オープンソースのコードを読んでいると、世の中のコード品質の動向がわかる。
自分のコードが時代遅れかどうかなど。
出荷するコード以外のコードを読む時間がないのかもしれない。
デンソークリエイトという会社には、仕事時間の１割を、次のプロジェクトでつかうかもしれない技術の勉強にあてていいという制度がある。
技術的なことは仕事のなかで十分学んでいけますし、当社には月に16時間を自己啓発や新技術の勉強のために自由に使える「3C（Change・Challenge・Charge）活動」や、さまざまな年代の技術者が集まって自主的にテーマを掲げ活動する「アトリエ」もあります。
ソフトウェアの会社に、こういうあたりまえのことができるようにする制度がないと無理かも。
よい制度があっても、仕事が忙しくて有効活用できていなかったり、現状で満足していたり、社内一なら安心してしまう風土があると、うまく機能しないかもしれない。
まとめ
架空の話では、あたりまえのようなことでも、実際に、特定の組織の特定の個人にあてはめると、
無理なことばかりのことがある。
どこを突破口にするとよいかは、本人次第かも。
p.s.
最後の１行は逃げ口上です。
それでは無責任そうに見える。あたりまえのことを、当たり前にやるにあたり、ツールの導入、内部の勉強会の企画など、提案、協力などは随時しています。組織上の制約で、半分以上の仕事時間を名古屋市内の企業または個人のために費やす必要があります。名古屋市内以外の方には、お待ちいただくことがあります。ごめんなさい。
文書履歴(document history)
ver. 0.01 初稿 20190528 午後
ver. 0.02 p.s.追記 20190528 夜
ver. 0.03 URL、引用追記 20190529
ver. 0.04 標題追記 20190530
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.