ソースコードの写経は本当に無駄なのか❓

こんにちは、おおとろ（@digiangler）です。

SIer として小さなソフトウェアの会社に入って 2 年目ぐらいのお話です。

当時、本社のシステム開発を先輩 1 人と同期 3 人で担当していました。70％ ぐらいは完成していて、仕様の変更による機能の追加やバグ修正などに携わっていました。

プログラミング言語は Object Pascal で、統合開発環境（IDE）が Delphi だったと思います。

学校で C 言語を習っていたので、少しは理解できましたが、設計書の読み方やコードの規約など、覚えなければいけないことだらけでした。

先輩からは、「プログラミングコードを写経するのがスキルアップの効果的な方法だよ❗」とアドバイスを頂きました。

それから毎日定時後、コードを学ぶために、ただ書き写す行為をひたすら繰り返しました。

やったことがある方なら分かると思いますが、実際にコードを自ら一行一行手打ちしていくことによって、より理解を深め、記憶にも定着させることができるようになります。

見てなんとなく理解したつもりであっても、実際に書こうとするときちんと理解できていないことに気が付いたりします。

また、実際にコードを書いてみることで、エラー（バグ）を体験することができます。

エラーを体験をすることによって、「どの箇所でエラーを出しやすいのか❓」を自分で知ることに繋がります。

つまり、デバッグ能力を向上させることにも繋がります。

写経しながら意識するべきこと

写経が効果的だからといって、何も考えずにひたすら書き写すだけでは効果は半減するどころか、マイナス（時間の無駄）になってしまいます。

書き写しながらも、頭で意識すべきことがあります。

それは、文法です。

どの言語にも制御構文や変数宣言、算術演算とか、文法の共通概念というものがあります。

箇条書きにすると、

・データ型
・変数
・配列
・リスト
・連想配列（ディクショナリ）
・算術演算
・整数操作
・文字列操作
・制御構文（選択）
・制御構文（ループ）
・例外処理
・関数（メソッド）宣言
・クラス
・コメント
・コンソール出力
・コードブロック
・ライブラリ / モジュール関連

など

初めてプログラミング言語を目にしたとき、何かの暗号なのかと思うぐらい、天才は除いて、すぐ理解できるようになるにはかなりの時間と労力が必要だと思います•••

数学と英語が得意なら、何の処理をしているか何となくわかるかも知れません。

参考書を読んだり、写経をしながら、実際に自らコードを真似して書いてみて少しずつ理解する（スキルアップ）ことができます。

何事にもまずは、自分で手を動かしながら書いてみることです。

要は論理展開です❗

「書くことで文法がどのように、そのコードに関係しているのか❓」が見えてくるはずです。

私の場合、先輩社員が書いたコードを元に、反復してひたすらコピペしないで自らコードを書きながら覚えていきましたね。

でも今は、写経をすることは推奨していません。

なぜなら、こちらの記事に詳しく書いているので写経に興味がある方は読んでみて下さい。

会社にプログラミング言語の参考書もあったので、分からない箇所は自分で調べたり、どうしても分からなかった場合は先輩に聞いて教えて頂きました。

なかには、教えてくれない先輩もいましたね。答えをすぐに教えてしまうとスキルアップできないからという理由で、厳しい先輩もいましたね。

ヒントだけ教えてもらい、あとは自分で考えさせられました。

自分の頭で考える癖をつけろ❗

今になって分かりましたが、その先輩の行動が一番スキルアップに繋がるということです。

自分の頭で考える癖をつける（つけさせる）ことです。

上司が細かく指示してしまうと、指示待ち人間になってしまいます。そして、部下は自分で考えることを放棄してしまい、言われたことしか仕事をしなくなるのです。

私もこのときは、そうでした。指示待ち人間でした。恥ずかしい•••

「自分で考えさせるためにどうするか❓」

それは質問の仕方だと思っています。人間は聞かれると、考える生き物です。

例えば、部下の仕事のやり方に問題があるとします。そのとき「○○は間違ってるから○○しなさい❗」と指摘するのは簡単で、上司も楽です。

しかし、正解をすぐに教えてしまうと、その理由や考え方、あるべきプロセスやアプローチの方法が身に付かなくなり、なぜその答えになるのかは永久にわからなくなります。

また、わかろうとしなくなります。

プログラミングや設計の世界でも同じことです。

「なぜ、ここでこのロジックになっているのか❓」

仕様書や設計書を理解して、自分で考えたロジックは説得力もあり、大きな深い（致命傷な）バクにはなりません。

出戻りが多いプログラムほど、何も考えず成り行きでプログラミングしている場合が多いのです。

こんな感じで、先輩のサポートをもらいながら、約 2 週間ぐらいで何とか初めてのシステム開発を納期までに完成させることができました。

システム開発での学び

一番苦労したのが、ある箇所のバグを修正したら、そのバグで隠されていた別のバグが見つかったり、正しく動いていたはずの機能が動かなくなったりしてパニックになったことです。

プログラムやシステムは、ひとつひとつの機能が複雑に絡み合っています。開発者の意図しない動作や、想定外の動作が起きたときにバグは発生します。

バグ修正などの変更をプログラムに加えたら、修正した箇所以外に影響がないかを確認するテスト（リグレッションテスト）もしないといけません。

これ、すごい重要❗

関係性のない部分に思えても、想定外の不具合が発生することもあり、特に大規模なシステム開発のときには注意してコードの追加や修正、テストをしないといけません。

仕様を理解し、設計書に基づいてプログラミングしないといけないので、私の経験上、一番難しい行程のひとつだと思っています。

そのまま納品してしまうと、後になって重大なトラブルが起こったり、クライアントの信用を失うリスクがあります。

ここで役に立ったのが、以前の携帯電話の評価業務で身についたテストのスキルです。

仕様書を読んで仕様を把握し、ユーザーの気持ちになって携帯電話のあらゆるパターンを想定してテスト項目を作成し、動作テストを数百件実施してきた経験を活かすことができました。

ユーザーの気持ちになってシステムを動かすと、バグが出るわ出るわ。

先輩が書いたプログラムをテストするとき、念入りに（めっちゃ真剣に）バグを発見したのはナイショです。

なかには、バグとして表示されない発生しないバグというのもあります。

現実問題、大規模なシステム開発ではソースコードの分量の多さも手伝って、バグのないソフトウェアはありえないというのが現状です。

パソコンのツールやスマホのアプリも数ヶ月に一度、バージョンアップしたり、パッチを適用したりしますよね❓

そのへんの話はまた機会があったら、詳しく書きたいと思います。

最後まで、読んで頂きありがとうございました❗

読んだ証明として、1 日 1 回クリックをお願い致します m(_ _)m

👇

人気ブログランキング

それでは、また。

是非、感想をコメントや SNS でくださると嬉しいです。

Twitter: @digiangler
Instagram: @digi_angler

☝️フォローしてね❗️

また、スキボタンを ”こっそり” 押したり、サポートしてくださるのも、とても嬉しいです。

"こっそり" Twitter からのリツイートでの感想もくださると嬉しいです。