Download to read offline
Editor's Notes
- #3 今年からフリーランス。お仕事ください
- #4 新人向け。この内容がベースだけど読んでなくても問題なし。興味あればご購入を。
- #5 今日の主題
- #6 きれいなコードを書こうというからには何らかの理由があるはず。それはなにか。
- #7 言語って言われてるぐらいだから言語。
- #9 「コミニュケーション」
- #10 コミニュケーションと言うからには１人では出来ない。対話する相手が必ず存在する。
- #11 そのうち１人は言語処理系。プログラマは自分が実現したいことをプログラミング言語によって言語処理系(コンピューター)に伝える。
- #12 言語処理系はとても真面目なので読みやすかろうか、読みにくかろうか文句言わずに実行してくれる。
- #13 もう1つは人。仕事のメンバーだったり、オープンソースだったら世界中のプログラマだったり。更に言うと、数日以降の自分も含む。
- #19 正しいというよりは間違いではない
- #20 「綺麗な顔してるだろ。死んでるんだぜ・・・こいつ。」どんなにきれいでも死んでては意味がない。
- #21 プログラマが疲れると、いいものは出来ない。結局のところ、ソフトウェアを作りあげるのは誰でもない、プログラマである。
- #25 読みやすさとは別の軸での「きれい」なコード。
- #27 あくまで経験則だが、大抵この法則はあてはまるように思う。読みやすいコードも変更しやすいコードも、書いたプログラマがそれなりに時間をかけて丁寧に書いてある可能性が高いため。
- #28 是とも非とも。芸術は一種の自己表現だと思ってる。コード・ソフトウェアで自分を表現することは可能。しかし仕事のコードは自己表現の場ではない。
- #29 じゃあ、その様なコードを書くためにはどうしたらいいのか。
- #30 あとは、最初に紹介したWEB+DBも読んでもらえれば有り難い。
- #31 基本はやはりこれ。先程紹介した本もたくさんのサンプルが載っているが、それを自分で書いてみたり、修正してみたりするのが大事。
- #32 最近は書きよりこちらの方を重視している。ただ、どちら一方が大事というわけではなく、それぞれ補完する関係にあるので、読めばいい、書けばいいというものではない。
- #33 基本的には興味あるものを読むのが一番いい。仕事に直結しているものだと、成果がわかりやすくモチベ保てるかも。汚いコードも多いが、それはそれで「自分ではこう書くのに」という視点で読める。
- #34 そのうち自然とわかると思う。「自分の理解が足りない」=「わからない」=「悪いコード」という考えには注意。自分もまだまだ自信を持って「これは良いコード」と言い切れない。
- #35 何故こういうコードを書いたのか。別の解ではいけない理由はなにか? ただの手抜きなのか、時間的な理由か。
- #36 個人的にコードを読むことと本を読むことは共通していることが多いように思う。ここで言う本は文学とかの「娯楽本」ではなく、知識・理論を得て実践できるような本。オススメ。
- #37 基本的には好きなことを書けばいいと思う。
- #38 とは言え、あるコードを継続的に改良していくのも重要。リファクタリングなどの感覚はこの辺で掴みやすい。
- #39 大規模は言いすぎだけど、規模が大きい方が得るものは多いとは思う。ただ、普段のコードでそんなに大きいコードを書くかどうかは微妙。「継続的・規模」共になにかサービス・アプリを作るのが一番いいのかもしれない。
- #40 読みにも繋がるが、コードを読んだらそれを写経するのも良い。特に技術書系のサンプルコードは自分で書いて、検討して、初めて理解できることも多い。また、書いてこそその著者が正しいかわかる。あまり読み書きをわける必要はないんじゃないか。
- #41 「何が良いかは時期によっても違うし、人によっても違う」(ex.コメント) 結局のところ、何が良いか判断するのは自分なので、「何故、自分がこれが良いと思っているか」「何故これが良いとされているのか」という意識が大事。
- #42 昨日よりきれいなコードが書けた。明日はもっときれいなコードを書きたい。陸上とかスポーツをしていた人はこの楽しみはわかりやすいかもしれない。こういうモチベを持つのがコード上達の一番の秘訣なのかなとも思う。別に承認欲でもいい。(人に褒められるとか)。