LoginSignup
0
1

More than 5 years have passed since last update.

CodeReading/CodeWriting

Last updated at Posted at 2017-09-26

はじめに

JJUG CCC 2017 Springの登壇者が、こんな事を言ってました。
「コードは書く時間よりも読む時間の方が長いんだから、読みやすいコードを書きましょう」

また、WEB+DB Press vol.99にて、こんな記事がありました。
「コードを書くのは人で、コードを読むのも人である」

エンジニア歴4年目になる僕も、同じ事を思います。
各言語で、トレンドの書き方や最新バージョンの書き方があって、それを取り入れるのは賛成です。
自身の成長にも、プロジェクトの成長にも繋がると思いますし、コード自体もより良いものになっていくかと思うからです。

しかし、その一方で、最新技術を使う自分に自己陶酔して周りが見えなくなっている人もいるのが現実です。
また、自信過剰で自分のコードに絶対的な自信を持っている人もいるのも現実です。
言ってしまえば技術オナニー。

こういった人がプロジェクトに与える影響として主に考えられるのは「属人化」「開発効率の低下」といったところでしょうか。
一人で開発を進める分には良いかと思います。
しかし、会社は組織です。組織は他者とのコミュニケーションにより成り立ちます。そして、組織の人材は入れ替わります。
他者とのコミュニケーションが取れないコーディングをしたり、担当者がいなくなった途端に理解できる人がいなくなっては意味がありません。

読みやすいコード。
適切なコメント。
後任者に対してのドキュメント。

こういったものがあって初めて成り立ちます。

長くなりましたが、ここでは、コードの読み方や書き方を、簡単にまとめていきます。
(僕もまだペーペーなので、参考程度に...)

コードリーディング

基本的にはこんなところでしょうか。

  • 目的を持って読むこと
  • スコープを意識すること

新人の時に、「コードを読め」とよく言われますね。
部下ができた人も、こんな指示をした事があるのではないでしょうか。

「コードを読む」のは手段であって目的ではありません。
コードを読む目的で考えられるのは、「言語理解」「コード規約理解」「仕様理解」「先人のイケてる実装/イケてない実装の理解」などでしょうか。
指示する側も、「新人だから言語理解してね」「プロジェクト固有の書き方があるからコード規約を理解してね」「コードから仕様を理解してね」と一言添えてあげると、優しいですね。

また、「コードを読め」と言われても、蓋を開けてみると数万〜数十万行ものコードがあって、どこを見ればいいのか分からない...といった事は多々あるかと思います。
スコープが広過ぎるというのは雲を掴むようなもので、手当たり次第に読み込んでも意味がなく、無駄に時間がかかります。
なので、今見なければならない機能や箇所を理解した上で、数万〜数十万行から、数千〜数百行にスコープを狭めていく事が大切です。
読むコードを無駄撃ちしないようにして、時間コストをかけないように心がけましょう。

また、読み続けるとコードレビューも出来るようになるので、気持ち悪いコードやディレクトリ構成をしていたら、PM/PLに相談してみるのも有りです。
最初は煙たがられますが、プロジェクトの将来性を考えると大事な事なので、ガンガン行きましょう。
英語のことわざにもThe squeaky wheel gets the grease.とあります。ガンガン行きましょう。
正しい事を言って煙たがられるのもどうかしてますが。

コードライティング

基本的にはこんなとろでしょうか。

  • 適切なコメント
  • スコープの狭い変数
  • 分かりやすい命名
  • 再利用可能なコード

「そんなの当たり前じゃん」と思ってる人もいるかと思いますが、実践できてない人がいるのも現状です。

特に僕が言いたいのは適切なコメント
理由は二つあります。

1つ目は、コーダーの意図を伝えるためです。
コーダーは人間です。
人間は間違えますし、処理能力にも限界があります。
getXxx()というメソッド名なのに返却値がなかったり、setXxx()というメソッド名なのに何も設定していなかったり、あると思います。
処理が複雑になってくると、コーダー自身も理解が追いつかない...といった事もあるかと思います。
また、パフォーマンス向上が図れそうだけど、時間の都合上で止むを得ずクソコードを...といった事もあるかと思います。
そういった時に、コメントで// aaaをbbbしてcccする(複雑でゴメンなさい)とか// TODO パフォーマンス改善の余地あり(後は任せた)とか書かれていれば、後任者も修正しやすいです。
逆に、コメントが書かれていないと、後任者は「複雑な処理だけど崩していいのかな...」「パフォーマンス改善出来そうだけど理由があってわざと重い処理にしてるのかな...」と混乱を招きます。

2つ目は、コードは大概英語で書かれます。
これは完全に私事ですが、英語が苦手です。(ちゃんと英語を理解するようには努めてますよ!!!)
そもそも日本人の英語レベルはどのくらいなものなんでしょう。
と思ってざっくり調べたら、こんなのがありました。
https://www.rarejob.com/englishlab/column/20160729-2/
http://www.ivyleague-english.com/newpage5.html
http://bellthrough.com/diary/japanese-english
やはり日本人全体として英語力が低いようです。
それなのに英語に頼るなんて.....と、英語が苦手な僕は思ってしまいます。(ちゃんと英語を理解するようには努めてますよ!!!)
そして、コメント書かない主義の人はこう言います。
「綺麗な英語書いてればコメントなんて必要なくない?」
こんなこと言ってる人に限って、気色悪い英語を使ったり、ルー語みたいにカタカナ英語使っていて、正直反吐が出る。

英語ばかり並んでるコードより、母国語である日本語が要所要所に入ってる方が落ち着かない??僕だけ???(ちゃんと英語を理解するようには努めてますよ!!!)

スコープの狭い変数は、
 一時的なものなんだからあちこちで使い回さずにすぐに殺せ。
分かりやすい命名は、
 変数が何を保持しているのか、メソッドが何を処理するのか、端的に表現しろ。
再利用可能なコードは、
 同じコードは書くな。同じになるなら外出しして他でも使えるようにしろ。拡張性大事。
みたいな感じです。


最後に余談。
Qiita見てる人って、この記事の事くらい意識もしてるし、理解も実践もしてるよね。
実際に読んでほしいのはQiitaとか見ない人なんだけど、そういう人って以下略(

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1