ソースコードの写経は効果的か❓無駄か❓
こんにちは、おおとろ（@digiangler）です。
SIerとして小さなソフトウェアの会社に入って2年目の頃のお話です。
無事に携帯電話の評価業務も完遂し、次の現場が決まるまで一旦弊社勤務となりました。
私は支社（営業所）に所属していて、本社は東京にあります。
次の現場が決まるまで、本社のシステム開発業務のヘルプ（受託開発）をしました。
70％ぐらいは完成していて、仕様の変更による機能の追加やバグ修正など、初めてのシステム開発の経験にはもってこいの案件でした。
プログラミング言語は”Object Pascal”で、統合開発環境（IDE）が”Delphi”だったと思います。
懐かしい。
学校で”C言語”を習っていたので、少しは理解できましたが、設計書の読み方やコードの規約など、覚えなければいけないことだらけでした（汗）
先輩からは、「プログラミングコードを写経するのがスキルアップの効果的な方法だよ❗」とアドバイスを頂きました。
それから毎日定時後、コードを学ぶために、ただ書き写す行為をひたすら繰り返しました。
やったことがある方なら分かると思いますが、実際にコードを自ら一行一行手打ちしていくことによって、より理解を深め、記憶にも定着させていくことができるようになります。
見てなんとなく理解したつもりであっても、実際に書こうとするときちんと理解できていないことに気が付いたりします。
また、実際にコードを書いてみることで、エラー（バグ）を体験することができます。
エラーを体験をすることによって、「どの箇所でエラーを出しやすいのか❓」を自分で知ることに繋がります。
つまり、デバッグ能力を向上させることにも繋がります。
写経しながら意識するべきこと
写経が効果的だからといって、何も考えずにひたすら書き写すだけでは効果は半減するどころか、マイナス（時間の無駄）になってしまいます（汗）
書き写しながらも、”頭で意識すべきこと”があります。
それは、”文法”です。
どの言語にも”制御構文”や”変数宣言”、”算術演算”とか、文法の共通概念というものがあります。
箇条書きにすると、
・データ型
・変数
・配列
・リスト
・連想配列（ディクショナリ）
・算術演算
・整数操作
・文字列操作
・制御構文（選択）
・制御構文（ループ）
・例外処理
・関数（メソッド）宣言
・クラス
・コメント
・コンソール出力
・コードブロック
・ライブラリ / モジュール関連
など
初めてプログラミング言語を目にしたとき、何かの暗号なのかと思うぐらい、すぐ理解できるようになるにはかなりの時間と労力が必要だと思います･･･天才は除いて（汗）
数学と英語が得意なら、何の処理をしているか何となくわかるかも知れません。
参考書を読んだり、写経をしながら、実際に自らコードを真似して書いてみて少しずつ理解する（スキルアップ）ことができます。
何事にもまずは、自分で手を動かしながら書いてみることです。
要は”論理展開”です❗
「書くことで文法がどのように、そのコードに関係しているのか❓」が見えてくるはずです。
私の場合、先輩社員が書いたコードを元に、反復してひたすらコピペしないで自らコードを書きながら覚えていきましたね。
でも今は、”写経”をすることは推奨していません。
なぜなら、こちらの記事に詳しく書いているので”写経”に興味がある方は読んでみて下さい。
会社にプログラミング言語の参考書もあったので、分からない箇所は自分で調べたり、どうしても分からなかった場合は先輩に聞いて教えて頂きました。
なかには、教えてくれない先輩もいましたね（汗）
答えをすぐに教えてしまうとスキルアップできないからという理由で、厳しい先輩もいましたね（汗）
ヒントだけ教えてもらい、あとは自分で考えさせられました（汗）
自分の頭で考える癖をつけろ❗
今になって分かりましたが、その先輩の行動が一番スキルアップに繋がるということです。
”自分の頭で考える”癖をつける（つけさせる）ことです。
上司が細かく指示してしまうと、”指示待ち人間”になってしまいます。
そして、部下は自分で考えることを放棄してしまい、言われたことしか仕事をしなくなるのです。
私もこのときは、そうでした（汗）
指示待ち人間でした･･･恥ずかしい･･･
「自分で考えさせるためにどうするか❓」
それは”質問の仕方”だと思っています。
人間は聞かれると、考える生き物です。
例えば、部下の仕事のやり方に問題があるとします。
そのとき「○○は間違ってるから○○しなさい❗」と指摘するのは簡単で、上司も楽です。
しかし、正解をすぐに教えてしまうと、その理由や考え方、あるべきプロセスやアプローチの方法が身に付かなくなり、なぜその答えになるのかは永久にわからなくなります。
また、わかろうとしなくなります。
プログラミングや設計の世界でも同じことです。
「なぜ、ここでこのロジックになっているのか❓」
仕様書や設計書を理解して、自分で考えたロジックは説得力もあり、大きな深い（致命傷な）バクにはなりません。
出戻りが多いプログラムほど、何も考えず成り行きでプログラミングしている場合が多いのです。
こんな感じで、先輩のサポートをもらいながら、約2週間ぐらいで何とか初めてのシステム開発を納期までに完成させることができました。
システム開発での学び
一番苦労したのが、ある箇所のバグを修正したら、そのバグで隠されていた別のバグが見つかったり、正しく動いていたはずの機能が動かなくなったりしてパニックになったことです（汗）
プログラムやシステムは、一つ一つの機能が複雑に絡み合っています。
開発者の意図しない動作や、想定外の動作が起きたときにバグは発生します。
バグ修正などの変更をプログラムに加えたら、修正した箇所以外に影響がないかを確認するテスト（リグレッションテスト）もしないといけません。
これ、すごい重要❗
関係性のない部分に思えても、想定外の不具合が発生することもあり、特に大規模なシステム開発のときには注意してコードの追加や修正、テストをしないといけません。
仕様を理解し、設計書に基づいてプログラミングしないといけないので、私の経験上、一番難しい行程のひとつだと思っています。
そのまま納品してしまうと、後になって重大なトラブルが起こったり、クライアントの信用を失うリスクがあります。
ここで役に立ったのが、以前の携帯電話の評価業務で身についたテストのスキルです。
仕様書を読んで仕様を把握し、ユーザーの気持ちになって携帯電話のあらゆるパターンを想定してテスト項目を作成し、動作テストを数百件実施してきた経験を活かすことができました。
ユーザーの気持ちになってシステムを動かすと、バグが出るわ出るわ（苦笑）
先輩が書いたプログラムをテストするとき、念入りに（めっちゃ真剣に）バグを発見したのはナイショです（爆笑）
なかには、バグとして表示されない”発生しないバグ”というのもあります。
現実問題、大規模なシステム開発ではソースコードの分量の多さも手伝って、バグのないソフトウェアはありえないというのが現状です。
パソコンのツールやスマホのアプリも数ヶ月に一度、バージョンアップしたり、パッチを適用したりしますよね❓
そのへんの話はまた機会があったら、詳しく書きたいと思います。
最後まで、読んで頂きありがとうございました❗
それでは、また。
是非、感想をコメントやSNSでくださると嬉しいです。
Twitter: @digiangler
Instagram: @digi_angler
また、スキボタンを”こっそり”押したり、サポートしてくださるのも、とても嬉しいです。
"こっそり"Twitterからのリツイートでの感想もくださると嬉しいです。
よろしければサポートよろしくお願い致します。頂いたサポートはライターとしての活動費に使わせて頂きます❗m(_ _)mまた、感想のツイートやリクエスト、ぜひぜひお寄せください(*⌒▽⌒*)