プログラミング言語は技術です！
Progateなどいくつかのサイトでプログラミング言語を覚えて卒業認定もらっているんですけど、勉強したことを職場で全然生かせていない感じで、困ってます。
どうしたら良いですか？
生かせていないというのはどういうことでしょう・・・？
具体的なエピソードを教えてもらえますか？
ついこの前あったのは、
メインルーチンの最後に exit 0 を書いていたのですが、
その 0 が 0 で良い理由を問われてちゃんと答えることができませんでした。
自分としては、慣例的なもので「exit 0 を記載しておくもの」だと覚えていたので、これ以外の書き方は無いとまで思っていました。
なるほど。
問うてきたのはレビューしてくれた人ですかね？
あ、そうですね、レビューアです。
キャリアチェンジでアプリ開発の現場に配属されて、
最初のレビューでした。
慣例的なものの認識だってことを説明したら、「どこでそう覚えてきたのか」ってさらに指摘されちゃって・・・
さらに指摘されたことに対してはどのように回答したのですか？
どこで覚えたかなんて忘れてしまっていたので、正直に忘れたって答えました。
そうしたら、「忘れてしまったのならしかたないから不問にするけど、exit文について調べて、本当に0で良いのか検討してみて」と言われました。
そのせいで工程が1日遅延しちゃって・・・
その指摘者の指摘は良い筋ですね。
僕でもそう指摘すると思います。
え・・・だって、どうでも良いことなのに1日遅延発生させてまで再検討させるんですよ？
おかしくないですか？
全然おかしくないですね。
なぜなら、そこを 0 でなくて 1 とか別の値にした方が便利になるかもしれませんし、もっというと 0 以外にしないといけなかったかもしれません。
僕は当時の状況をよくわかっていませんが、例えばエラーのルートだったんじゃないですか？
あ、そうです。
ファイルオープン時にオープンできなかった時のルートです。
よくわかりましたね。
簡単なことです。
exit文はプログラム終了処理なので、終了ルートが正常以外ありえないならわざわざ exit 0 に対して指摘する必要がないからです。
つまり、指摘者は「エラーのルートなのに正常ルートと同じ exit 0 だとエラーなのか正常なのかわからなくなる」と考えたんだと思います。
まったく同じことを指摘者から説明されました。
私が再検討した結果では「exit 0 で終了できて後続の処理を不当に実行しないから 0 のままで良い」でしたが、「安全性の検討結果としてはそれで十分だけどエラー発生時のメンテナンス性の検討がされていないからもう一度検討してみて」と言われました。
そうですね。
表面上の達成したい機能にだけ目を向けていると、メンテナンス性がおろそかになりやすいです。
メンテナンス性がおろそかになると、いざ障害が発生した時に対応が遅くなってしまってユーザが不信感を抱きやすくなります。
exit文の仕様をちゃんと掌握することは大事ですね。
掌握した上で 0 で良いのかの決断を下す必要があります。
そうしないと、プログラム終了時の終了コードが 0 だけになってしまい、エラーが起きて終了したのか問題なく動いて終了したのかがわかりません。
はい。
監視アプリで監視しているシステムでしたので、本来は正常終了とエラー終了を分ける必要がありました。
分けないと、一律正常として扱うか、一律エラー通知するかのどちらかになってしまって、とても使い勝手が悪くなるところでした。
アプリ開発というのはその仕様を掌握していないと自分のアプリが実行環境に対してどのような影響を与えるのか想像できませんよね。
プログラミング言語の仕様も一緒です。
今回の例でいえば exit文 の仕様を掌握していなかったためにメンテナンス性の悪いプログラムを作ってしまうところでしたね。
そうですね・・・
書き方は完璧に覚えていたのですが、書いたものの意味までは考えていませんでした。
今思えば、レビューアの指摘は的確で、バグが発生しても調査工数が最小限で済むように仕向けてくれたことにも感謝しないといけないですね。
ちなみに、同じバージョンで同時リリースした他部署の機能が私と同じようにエラーのルートで exit 0 を使っていて原因がわからず徹夜していました・・・
ああはなりなくないと思いました。
プログラミングは技術ですので、書き方を覚えるだけでは仕事で使いこなすことができないのです。
良い経験になったみたいですので、これを教訓にして今後も活躍していってください。
励ましの言葉、ありがとうございます！
レビューで受けた指摘については他の人の意見を聞くということがあまりないので、ここで相談して良かったです。
コメント