【絶対にこうなるな！】プログラミング初心者あるあるのミスを紹介
プログラミング初心者の方、またはプログラミング初心者を教育する方：
プログラミングの初心者にありがちなミスはなんだろう？予めそれを知ることで、ミス防止にしたいな。
今回はこのような悩みに対して解説していきます。
この記事の目次
【絶対にこうなるな！】プログラミング初心者あるあるのミスを紹介
細かいこと言い出すとキリがないので、今回は大きく3つについて、自分の実体験ベースで紹介します。
- 相談なしでどんどん進め、見当違いなモノを作ってしまった
- 古いファイルで上書き、または削除して成果を台無しにしてしまった
- 変化点しかチェックせず、不具合を出してしまった
相談なしでどんどん進め、見当違いなモノを作ってしまった
作業指示を受けた際、「よし！やるぞ！」という気持ちになるのは素晴らしいのですが、そこから実際に作業に入ったら、都度先輩や上司に、成果物を確認してもらうようにしましょう。
なぜなら、仮に見当違いなもの作っていたら、その時点で気づくことができるからです。
これがもし、最終成果物まで作り上げたら、それまでの時間と、やり直しコースが増大してしまいます。
実体験：ベースソフトが古くてやり直しになった
ベースソフトをもとに、新たな機能を追加する作業をしました。その際、新しい機能自体はきちんと実装できたのですが、肝心なベース元のファイルが間違っていることに気づきました。
しかも、全部コード実践し終わってからです。
当然、コード実装を1からやり直しになりました。
もちろん、すべてのコードを捨てることにはなりませんでしたが、途中で先輩に内容確認してもらっていれば、このようなことにはなりませんでした。
なので、以降は、一気に最後まで突っ走るのではなく、ちょこちょこと、先輩に確認をしてもらうようにしました。
特に決まりは無いのですが、
- とっかかりで間違ってたら嫌なので20%で見てもらう
- 半分できたところで、以降もそのままでいいのか知りたいので見てもらう
こんな感じで考えているからです。
なので、20%,50%時点を目安に確認してもらうようにするとよいでしょう。
とは言え、指示の仕方が悪い場合もある
ここまで解説したのは、
「指示された内容を勘違いしたまま作業しないようにするために、ちょこちょこと内容を確認してもらいましょう」
と、言う事でしたが、自分が作業を勘違いしたのでなく、そもそも指示の内容自体が間違ってる可能性もありますよね。
上司や先輩も忙しいので、説明を簡単にしすぎてしまったり、そもそも説明の仕方がへたくそだったりすると、このようなことになります。
なので、そのような意味でも、やはり作業は指示されたら最後まで一気に突っ走るのではなく、ちょこちょこと内容を確認してもらうと良いでしょう。
古いファイルで上書き、または削除して成果を台無しにしてしまった
せっかく作った成果物を、古いもので上書きしてしまったり、間違えて削除してしまう、なんてこともあるでしょう。
なぜなら、ソースファイルや設計書、テスト結果など、いろんな種類のいろんなファイルを触ることになるので、どこにどんな状態でファイルが残っているか分からなくなってしまうためです。
実体験：苦労して作った単体テスト仕様を消してしまった
1週間かけて作った単体テストの仕様書(Excelファイル)を、会社の共通サーバーに置いて作業していたのですが、誤ってこれを消してしまいました。
もちろん、会社のサーバーはバックアップを取っているので、その気になれば復元させるのは可能だったのですが、自分の1個人のファイルのために、バックアップを依頼するわけにもいかず、泣く泣く諦めました。
そして、再度1から作り直すことに。
新人の頃の苦い経験です。
そうすれば、簡単に言うと、
- 上書き保存すると勝手にファイルの履歴をとってくれる
- 昔の履歴に戻ることも可能
となるからです。
これでしたら、間違って消してしまっても、バージョン管理ツールに過去のファイルが残っているので、1から作り直す必要がありません。
その場合は、オールドフォルダを用意しましょう。
どういうことかと言うと、
- 1日おきに、現在の最新ファイルをコピーし、オールドフォルダに置く
- コピー元のファイルを更新していく
こうすれば、最新のファイルを誤って消してしまっても、オールドファイルには、前の日のデータが残っているので、最悪でも前日の状態に戻すことができます。
変化点しかチェックせず、不具合を出してしまった
ベースソフトを元に、がんばって今回の顧客要求を実現するためのコードを実装するのはよいですが、きちんと既存コードに問題がないかも確認しましょう。
なぜなら、今回の変更により、既存コードの思わぬところに影響がでている場合があるからです。
実体験：既存処理が動かなくなった
あるシチュエーションの際に、LEDを点滅させる処理が既存コードであったのですが、そこに新たなシチュエーションと点滅パターンを追加しました。
動作確認すると、新しく追加したところは問題なく動いたのですが、既存のシチュエーションが発生しても、今回追加した点滅パターンで動いてしまいました。
ソースファイルを確認してみると、たとえ既存のシチュエーションが発生しても、追加したシチュエーションの点滅パターンを意味する変数が、常に追加コードの内容で上書きされるようになってしまっていました。
つまりは、今回の変更により、もともと動作していた箇所がうまく動かなくなってしまいました。
例えばこんな感じです。
- 処理速度が遅くなることによる影響
- ある部分を今回の要求を満たすために変更したことにより、その機能は満たせても、もともとできてた機能が動かなくなった
このように、もともとうまく動いていた部分が、変更により動かなくなる、と言うネタは、プログラミングをしているとしょっちゅう発生します。
なので、プログラミングをする際は、自分の変更がどこにどう影響するかをきちんと解析した上でコーディングするようにしましょう。
影響範囲がわかっているなら確認は変更点のみで良い
ここまで書くと、
「いかなるコード変更でも、既存の処理に影響がないかをこと細かく確認しないといけない」
と、思うかもしれません。
もちろん、それに越した事は無いのですが、皆さんおそらく忙しいですよね?
よくあるのは、
「こんな上変更で規定演技に従った営業会社休してる暇なんてない」
と、いったものです。
いくら過去に影響分析不足による不具合が発生したからといって、すべての変更に対して詳細な影響解析を課してしまったら、それこそ開発をやっていられません。
なので、影響分析はケースバイケースでいきましょう。
例えば、単に変数名の変更のみでしたら、影響分析もへったくれもありませんよね。
こんな感じで、影響分析は、あくまでその変更内容に応じてさじ加減を決めるようにしましょう。
ここまで書いて思ったのは、今回紹介した内容は、新人にかかわらず、経験者でもやってしまいがちなことなので、新人であるかないかににかかわらず、これを読んだ方は解説してきた事を気をつけると良いのではないでしょうか。
今回は以上です。