◆はじめに

考えながらプログラミングしないとヤバぉなコードが産まれます。
考えながらプログラムを書いていると、だんだん体に染みついてきていい感じになってくる。
お前はまず初心者であるゆえ、何を考えればいいのかすら分からないだろう。だから、ヒントっぽい事を話します。
具体的な例にあまり触れていないから、読んでも理解できないかもしれない。
今理解できなくてもいいんです。頭の隅で覚えておいて欲しい。

◆考え：プログラムとは

プログラムとはつまり、入力をうけて、出力を返すものだ。出力は文字列であったり数値であったり画像であったり映像であったり、色々。
プログラムにある値を渡すと、結果としてある値をくれる。それがプログラムの全てです。
だから、正しい出力をするプログラムは正しいプログラムであると言える。

補足：しかし、正しくない出力をするプログラムを作ってしまった時に、コードが汚いと修正が難しくなる。また、出力する内容を変えたい時も困る。「動いたら正」という言葉があるが、あれはジョークだ。綺麗なコードを書かなければいけないのは常識だし、誠意だ。

綺麗なコードであろうと汚いコードであろうと、プログラムは「入力をうけて、出力を返すもの」だ。つまり、プログラムはメソッドであるということが分かるだろう。これは当たり前のことだ。この当たり前なことを、みんな意外と忘れる。
一番最初に抑えるべきは入力と出力である。

◆考え：目的

目的が無いとプログラミングはできない。
また、プログラミングをしている最中に目的を見失うと、求めていなかったプログラムが産まれる。
初めのうちは、全容を紙に書きだすのが良い。
書き出すことはまず、入力されるデータと出力したいデータ。次に処理の流れだ。書いているうちに色々気付くこともあると思う。書き方は割とどうでもいい。うまく書けなくてもいいから思うようにやれ。

次々発生する問題に、その場その場で対応してはいけない。最終的に解決すべき問題を常に頭に置いておかなければいけない。つまり、新しい処理を追加したいときは一連の処理を見直したほうが良い。どの位置に処理を追加するべきかを考えよう。

◆考え：分離

「今日の行動」というプログラムがあったとする。
内容はこうだ。

⇒家を出る
⇒市役所に行く
⇒銀行で金をおろす
⇒散髪に行く
⇒映画を見る
⇒スーパーで牛乳を買う
⇒家に帰る

これは正しい。正しいが、こういう考え方もできる。

⇒家を出る
⇒市役所に行く
⇒家に帰る
⇒家を出る
⇒銀行で金をおろす
⇒家に帰る
⇒家を出る
⇒散髪に行く
⇒家に帰る
⇒家を出る
⇒映画を見る
⇒家に帰る
⇒家を出る
⇒スーパーで牛乳を買う
⇒家に帰る

つまり、毎回家に帰るという方法でも、目的を達成できなくもない。
こういう行動は人間にとっては面倒でしかないが、コンピューターは文句も言わずやってくれる。
そして、プログラミングではその考え方ができたほうが良い。

課題を分離することで、それぞれの課題に集中することができる。複雑になりそうなときは、まず一つ一つの事を着実に解決するコードを書こう。一つの巨大な処理を分割するよりも、複数の処理を後で合体させるほうが簡単だ。力がついてくれば「いつでも分割できる巨大なコード」を書くこともできるようになる。
色々な課題を一度に消化しようとすると、記述されているコードが今何をしているのかということが、だんだんとわからなくなってくる。書いている人は分かるかもしれない。だが、そのコードを読んだ人には分からない。また、一か月後のお前にとってもコードを読むことは難しくなる。

プログラミングの先輩から「この処理とこの処理って同じループでできるじゃん」と言われることもあろう。処理の負荷は小さくなるだろうし、それは正しいといえる。だが、下手な書き方をすると容易に可読性を損なう。お前の先輩は概ね正しいから従っておくのが無難であるが、疑いも持っておいて損はない。
１つのループ内で複数の事をしたいときは、「いつでも分離できるように」記述しておかなければならない。互いの処理が影響し合うのは危険だ。

全てを分離してしまうのも問題だ。なぜならループを沢山回すとそれだけ処理が遅くなってしまうから。だが、すべてまとめてしまうことの方が問題だ。
気を付けよう。

◆考え：ロジック

「ロジック」は、つまり処理の手順だ。プログラム自体をロジックともいう。
「ロジックを書く」は「動く処理を書く」と言うことだ。つまり、ロジックを書くだけではいけない。
ロジックは煮詰めることが可能だ。より読みやすく、修正のしやすいコードに変換しなければいけいない。シャレたロジックなんて誰も求めてはいない。お前の賢さなんて誰も興味は無い。アルゴリズムをやりたいのならアルゴリズムの開発をしろ。デザインパターンというものを教わることもあるだろうが、あれは考え方こそが重要だ。哲学が理解できたのなら使う必要はない。使い時を良く見定めなければならない。遠回りをしてはいけない。
多少の処理負荷のロスがあったとしても、人間性ゼロの「およそ動かしようのないコード」が一番いい。コーディングを自己表現の場だと履き違えてはいけない。システムの品質で自己表現をしろ。

考えたことをコードにしてはいけない。なぜなら、俺たちはバカだ。「処理する方法」を思いついたとしても、それを実装したらまずい。脳が読むことを拒むようなコードになる。SAN値が削れ、すべてを放棄して帰宅したくなる。だから、常にするべきことを意識し、自分の考えを疑い続けなければいけない。「この変数何？」とか、読み手に思わせてはいけない。

良いコードは、読める。続きが読みたくなる。プログラムを詰めると、それは結果的に文章のようなものになるはずだ。何も考えずに書いたらそれは「読ませる気のないコード」になる。読ませる気で書け。読んでもらえなくなるぞ。

◆考え：確認

プログラム書いて金貰ってんなら、おまえはプロだ。
プロなんだから自分の創ったモノの品質を担保しろ。処理やコメントを読み直し、動作確認をしろ。テストコードを書け。仕様書を修正しろ。人に投げるな。自分の手でやれ。

書きっぱなしは無責任かつタチが悪い。自分で自分の作ったものの面倒を見られないんなら、そもそも作るな。仕様だけまとめて別の人間にコードを書かせろ。

◆考え：仕様

仕様の実装を漏らしてはいけない。仕様は管理されなければいけない。
だけど、仕様は完全でも絶対でもない。漏れもあるし、変更もされる。

仕様をそのままコードに起こすのは間違いだ。お前のミッションは「仕様を満たすコード」を書くことだ。
「動作が完全に仕様通り」のコードを書こうとすると、仕様漏れがそのまま埋まることになる。可読性も低くなる。直しづらくもなる。

仕様をコードに落とす段階で、その仕様がおかしいことに気づけるくらいが望ましい。そもそもの設計段階で気づけって話ではあるが。

◆考え：嗅覚

読みづらいコードに対する嗅覚が必要。
俺はクソコードを追っているときに「何の話をしてんの？」とよく思う。
「何の話をしてんの？」と思ったら、そのコードを綺麗に出来ないか考えよう。

お前の技能が低いのかコードの品質が悪いのか。判断は難しいけど、とにかく綺麗に出来ないか考える癖をつけよう。

嗅覚が無いと辛い。「処理的には動くんだけど論理的に正しくない」コードを許容できるようになってしまう。
「これがこうなってこうだから大丈夫だよ。動くよ。」って言われても困る。特に上司に言われると困る。「あっ…この人ってそっちの人なんだ…」と思う日がきっといつか来るだろう。動くから大丈夫って言ってしまえる人は嗅覚、肌感覚が無い人だ。例えば、その”動くコード”に処理が追加される時に、そのコードを改修する人が前提条件を知っているとも限らない。地雷をスルー出来る能力を高めてはいけない。「マズい書き方」「マズい設計」に対する嗅覚を磨かなければいけない。

「コードがどうあるべきか」について知見を深めるのには時間がかかる。
まずは
・要らない変数を作っていないか
・新しい変数を作ったほうが読みやすくならないか
・自分がつけた変数名やメソッド名は正しいのか
あたりから考えるといいと思う。

名前付けを極めていればコーディング能力では困らない。というのも、設計が壊れていると正しい名前を付けることができないからだ。他にも色々あるんだけど、とにかく違和感のある名前を付けてしまっているうちは三流と確信していい。

◆行動：姿勢

静かにコーディングしよう。
貧乏ゆすりしたりクソデカため息したり鼻をすすりまくったり独り言しゃべったり舌打ちしたりエンターキーぶっ叩いたりマウスを机に叩きつけたり居眠りしたりするのはやめよう。困るよ。
したくなっちゃったら一度トイレタイムを入れるなり筋肉をのびのびさせるなり飲み物のむなりすればいいよ。
居眠り民は睡眠時無呼吸症候群とかADHDとかだから病院いけ。

俺は鼻歌が癖だった。ゴキゲン野郎だった。でもそれは直した。部屋で一人の時に歌いまくろう。

あとは…酷な話ではあるんだが、ワキガも周囲の情報処理能力を下げがちだ。石を塗ろう。

◆行動：ググる

「メモリって何？」「クラスって何？」「オブジェクト指向って何？」と思ったら、ググればいい。
ググったときにわからなくても、無理して読もう。絶対にいつか理解できるタイミングが来る。逆にググらないと永遠に分からないままだ。

また、プログラム言語の歴史について知るのもいいね。

◆考え：謙虚に

プログラミング能力の壁にぶつかったとき、おそらくお前は「駄目だ」と思わずに「俺コーディングできるじゃん！」と思うはずだ。壁にぶつかったとき、なぜかそこが終着点だと勘違いする。しかしながら、本当は全くもってのクソだ。その「壁に見えるもの」は階段の１ステップに過ぎない。ある程度かけるようになると、プログラマーはマジに調子に乗る。
でも、ほんと結構やらないとプログラミング能力は上がらない。
「俺コーディングできるじゃん！」で停止すると、お前も辛いし、周りの人間も辛い。辛いんだけど、お前はその辛さの理由をよくわかっていない。辛さの原因が分かるほどの技術力を持っていないからだ。

調子に乗った挙句、先輩後輩同期に対して「もうテメーはコード書くんじゃねぇよバグ埋め機が」とか思ってはいけない。思ってはいけない。

思ってはいけない（自省）。

その人もまだ成長途中なんですよ。俺たちと一緒だ。
ただし、俺たちは「バグ埋め機」とか「仕様漏れ発生装置」とか「クソコードディスペンサー」とか「妖怪尻ぬぐわせ」とか「残業召喚士」とか「工数膨張剤」とか呼ばれてはいけない。気を付けようね。

◆行動：タッチタイピング

キーボードを見ずに仕事しよう。
特に練習ツールは必要ない。お金もかからない。キーボードを見ないってだけ。全部のキーだ。「@」とか「;」とか「”」とかから逃げてはいけない。

はじめは割とキツイけど、ムキになれ。どれだけ間違えても、指がピキピキいってもキーボードを見ずにタイピングしろ。
キーボードをチラ見しながらコードを書いてると脳のリソースがそっちに食われる。また、タイプミスとか全角半角モード違いに気づきづらい。そして何よりダサい。

タッチタイピングは選ばれし者の特殊技能ではない。勘違いすんな。やったら出来る。お前はやってないだけだ。取り組むコツとしては、イラっとしそうになった時に心の中で「…オラァ！…ウラァ！殺すぞ！」みたいにオラつきながらタイピングすれば楽しいと思うよ。

留意すべき点として、タッチタイピングが難しいキーボードもある。そういうのはアンプラグして壁に立てかけてからヘシ折れ。

◆行動：英語の勉強

最低限の英語感（造語）がないといけない。英語が全くわからんままコードを書こうとすると、読めないコードが出来てしまう。

「isOnModalEdit」っていう感じの変数名を見てな。日本の英語教育はどうなってるんだと、そう思った次第だ。これじゃあ「くぁｗせｄｒｆｔｇｙふじこｌｐ」っていう変数名を付けるのと変わらない。

◆結論

地味なところを攻めてみた。ためになる話はあっただろうか。
ピンと来なくてもいい。ただ、どこかに引っ掛けておいてくれ。