こんにちは、Ikoba(<a href="http://twitter.com/ikoba0911">@ikoba0911</a>)です。
今回はちょうど1年半を迎えたときの自分が良いコードについてどのように書いていたかの備忘録です。
現在も同じ命題については考え続けているので、過去の感想を残して行こうかなと思います。
※ この記事は2020年2月ごろ、自分が過去に良いコードについて考えてアウトプットした際のリライト記事になります。 
※ 現在の状況や感想とは異なりますが、備忘録的に当時の感情や状況を残すためそのまま移動しています。
2020年も2月に突入し、皆さん今年のペースは掴めましたか？ 
私は絶賛体調崩してます笑
久しぶりにがっつり風邪ひいて、雑念が逆に消えたので治るにつれて自分の思考がクリアになっていく感じがしますね。
さて、掲題の通り今回は
良いコードを書くこととは、自分と向き合うこと
こちらのテーマについて書いて行こうかなと思います。 
そもそも今回の記事を書くことになったきっかけは下記の記事を読んだからですね。
<a href="https://qiita.com/alt_yamamoto/items/25eda376e6b947208996">『良いコードの書き方』</a>
<a href="https://qiita.com/AKB428/items/20e81ccc8d9998b5535d">『リーダブルコード要約とリーダブルコード要約の活用方法』</a>
今年の4月で開発職のエンジニアとして働き始めて1年半、そしてそのタイミングでちょうど私事ですが30歳までの残余時間が半年を切ります。
そうなったときにキャリアとは別のベクトルで「どんなコードが書きたいのか」、「どんなスキルが欲しいのか」このあたりにフォーカスを当てて記事を書いて行こうかなと思った次第です。
私の簡単な自己紹介をしておくと、
<ul>
<li>2018年10月から自社開発モバイルアプリ業務に関わる(IT業界とエンジニアキャリアの始まり)</li>
<li>2019年4月から某大手飲食顧客管理iOSアプリの開発職としてアサイン</li>
<li>細々とアウトプットしながら現在に至る</li>
</ul>
といった感じです。 
昨年は別の目標があったので、クリエイティビティを向上させるために動画編集やラジオ、このブログ、イラストなど何でもかんでもかたっぱしから作ってたりもしてましたが、それは別の話笑
今年は現場のメンバーが入れ替わったり、その他自分の節目の年でもあるので、改めて整理をする意味でもこの記事に落とし込んでいこうかなと思っています。
<h2 id="人に優しくコンピューターに優しく">人に優しく？コンピューターに優しく？</h2>
最近自分がコーディングをしていてつきまとう命題のひとつはこれ。 
プログラミング言語には特性として、上級言語（コンピューターに優しい言語）と庭球言語(人間に優しい言語)があります。 
単純に分類できるわけではないですが、基本的には上級言語ほど人間には読み辛くコンピューターにはより詳しい指示が出せます。 
これはすなわちそのプロダクトのパフォーマンスやバグの発生率に影響するのですが、この観点で自分がどうしたいのか。
似たような話でオブジェクト指向型プログラミング、手続き型プログラミング、関数型プログラミングなんて言葉もありますが、つまるところ『人に優しくするの？それともコンピューターに優しくするの？』ということだと個人的には思ってます。
そして、この観点だと私の目指すべきは『人に優しく』かなと思っています。 
コードの美しさや原初的な目的はやはり上級言語にあり、そしてコンピューターに優しくだとは思っていますが、私は全身全霊をこの観点にかけることには興味がやはり持てないです。
なのでできる範囲でカバーはしますが、基本的に『人に優しく』の考え方で出来上がったツールを利用しながらこれからも開発をしていきたいと思っていますし、そうなるといまの分野から転換するとしたらフロントに近い分野で力を発揮するセクションに転換するのが個人としては目指すべき方向性なのかと思っています。
複雑なロジックを実装するよりは他の天才が作り出したツールに肖って、多くの作品制作に関わりたいといった感情が強いです。
専門領域やそれぞれの開発者の方の考え方は異なっているので正解はないと思うので間違っている部分もあるかと思いますが、私の現在の経験上はこんな感じで考えて、これからの未来を描いていこうかなと思っています。
<h2 id="ぶつかる壁が人によって違うから辛いし結局プログラムを書いて解決するしかない">ぶつかる壁が人によって違うから辛いし、結局プログラムを書いて解決するしかない</h2>
本記事の最初で紹介した記事を読んでいろんな感想を持つ人がいるかと思いますが、著者の私が感じた最も強い感情は悲しみでした。
1年前多くのスキルのあるエンジニアの方に助けがあったから、ここまで辞めずに開発職として続いた自分があると思います（本当に関わってくれたエンジニアの皆さんに感謝したい）
同時にある程度コードが書けるようになって、理解して、実装ができるようになったからこそわかることがありました。
**『どれだけのスキルのある人と仕事をしても体系的に初心者のぶつかる壁を明確にして、その全てをカバーできるような方法はない』**ということです。
私は特に前職はとても古風な業界からこの業界に移ってきました。 
だからこそ、きっと多くの才能あるエンジニアの方に触れ合うことで、失敗経験や成功経験を分析することで自分がぶつかりそうな壁を事前に予見できるのではとタカを括っていました（もっと言えばその答えも持ち合わせているのではと思っていた、本当に甘い）
具体的な例示をいくら示されてもいざ問題にぶつからないと(というか必要なシチュエーションにならないと)紹介した記事に置ける“良いコードの書き方“を体系的に実践はできない。
これが非常に厄介かつ、この仕事を継続する上でのもっとも難所であると言えます。 
概念じゃなくて、ケースで説明してくれと言われても、ケースバイケースなんだよと1年働いてきた私は苦笑いして言ってしまう。
これはとても辛いことだし、営業の手法を後輩に伝える時にも感じた虚しさだ。 
きっと、多くの心優しいエンジニアが苦しんでいるに違いない。
明日書くコードの答えを全知全能のシステムで魔法みたいに解決してあげたい。 
でもそれはやっぱりできないんだ。。。(主人公風)
<h2 id="これからできること私の持ち味とは">これからできること、私の持ち味とは</h2>
これからできることは明白。
1行でも多くのコードを書いて、知識を蓄えること
ただただ書いていても閃きや良い書き方には至らない。 
レビューや書籍、インターネットを駆使して自分の書けるコードのベストを尽くしたい。
そして私が目指すこと、これは不明瞭だが自分みたいな苦労を感じる人を減らしたいとは思う。 
美しいコードやアーキテクチャはそれこそ感覚的なものに近いと私は感じている。
私は人間で、プログラミング言語を通して、伝えるのはコンピューターだ。
だからこそ、私よりも多くの時間を共にコンピューターと過ごした人からその感覚を継承する必要が私自身にある。
そして私がその内容をよりわかりやすく次の世代に継承できたら、持ち味を活かすことになるのかもと少し思ったりもする。
私は具体的にテクニカルな部分ではまだまだ至らない点が多いが、こういったパイプ役としてその時の感情や感覚を言葉で説明できることが多い。
<h2 id="一度自転車に乗れるようになった人間がその乗れるようになれるまでのプロセスを説明するのは非常に難しい">一度自転車に乗れるようになった人間がその乗れるようになれるまでのプロセスを説明するのは非常に難しい</h2>
同様にプログミングもできるようになるにつれて説明や感情が不可逆になる部分があると思う。
だからこそこの不可逆の部分を少しでも自分の言葉で埋めて、発信できるようにするのが私の目指すべきことのひとつかなと思っている。
また専門性が高すぎる故に他のセクションの全貌が見えなくなることも多い。
いまの業務で言えば他のセクションの人が当然意識している部分をネイティブのエンジニアは意識しないケースがあるし、その逆もまたある。 
だからこそ、WEBとNativeがサービス的に共存するときは足並みを合わせながらよりお互いに丁寧な説明をする必要性があるように感じる。
<h2 id="おわりに">おわりに</h2>
完全に独白みたくなってしまったが、私が成長曲線の最下層から抜け出せずにいまもがいているからこんな記事を書いたのかなと思っている。
実際に言葉にした方が伝わると思うし、現場の人にも伝えているがやはり多くの人が通る道らしい(それがわかるだけでも心理的な安心感はあるよね！)
1年を超えてまだまだな自分とできるようになってきた自分。 
どちらも自分だし、過去も未来も自分だ。
だからこそ、私を含めた多くのエンジニアの方が「懐かしい」と思えるような、そしてこれから壁にぶつかるエンジニアの方々が「こんな感じなんだ」と思えるような。 
そんな記事にエンジニア人生の途中下車の記事になったら幸いです（うまく言えなかった笑）

転職から1年半経ったiOSエンジニアの良いコードを書くことについての記事です。

中堅エンジニアが良いコードを書くことについて考えてみた