コードリーディングのコツは極力コードを読まないこと｜牛尾 剛
私はクラウドのプロダクトチームで働いているが、何を隠そう一番苦手で克服できていないことが、コードリーディングだ。ものすごーく時間かかるし、時間かかったうえに読み間違えたりするし、しかもめっちゃ頭使うのに他の人はずっと速いので敗北感しか残らない。先日もマネージャの Pragna に相談したら、最初は２時間かかるけど、３か月もしたら５分で終わるわよ。って言われたけど、いや、そもそも俺４時間は最低かかるねんけどな、、、って感じ。 技術イケメンの皆さんのアドバイス よくよく私のキャリアを考えると、OSSにコントリビュートとかしていることはあったが、めっちゃくちゃ巨大でややこしいコードベースを読んで理解する必要が無いことが多かった。１からコードを書くのは得意だが、他の人のを読んでがっつり理解してとか、どうやったら出来るのかわからない。 当然自分の周りの技術イケメンの皆さんにコツを聞いていたのだが、ど
やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
「美しい」にモヤったら「認知負荷が小さい」と言いかえよう - Qiita
プログラミング業界では定期的に「美しいコード」が話題になり、そのたびに炎上が発生します: コードの美しさは実務には関係ない 美しくても動かなければ意味がない 「美しさ」は主観的で、プログラマーの自己満足に過ぎない 汚くたって俺は読める。読めないお前が悪い などなど・・・ 私もコードは美しくあれかしとは思いつつも、 「確かに『美しい』って曖昧だよな」とか、 「どうして = の位置がそろっているのを『美しい』というのだろう？『整然としている』なら分かるけど」とか、 「『可読性が高い』でもいいけど、今一つ『美しい』との違いが判らん」 「そもそも、どうして美しいコードの方が読みやすいと言えるんだ？」 と、割り切れなく思っていました。 ところで、最近の心理学・脳科学ではこんな説があるようです（本当かどうかは知らないよ）： 中野：（中略）美人の顔って対称性が高いって言われますよね。あれは別に体が健康だ
コメントのいらないプログラムの書き方｜NZ MoyaSystem
パラメータを決める 次に関数に渡すパラメータを決めます。 関数の名前で表現されている処理を実現するには、どれだけのパラメータがあればよいか？ と考えてみましょう。 今回の例でいえば「お客さんの年齢」と「日付」があれば、すべてのチケット価格が計算できます。 ということで、age と date の2つのパラメータを渡すことにします。 function calculateTicketPrice (age, date) { } パラメータの名前も、なにを表しているかわかるようにしてくださいね。 くれぐれも「hensu」とか適当な名前をつけたり、同じ変数にぜんぜん違う値を繰り返し代入したりすることのないようにしましょう。 テストを書く 次にユニットテストを書きましょう。 テストは常に更新される仕様書です。 業務ロジックをテストに説明させておけば、関数の仕様をコメントにいちいち書く必要などありません。
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ Mob Programmingって初めて聞いたけど、とてもいい方法に思える。 コードを書く時に、今現在の仕様はわかっていたとしても、今後どうなるか、どういう方向に発展するのか気になって、ビジネス的にその分野に詳しい人の所に聞きに行ってから書きはじめることがあるし、性能的に大丈夫かDBに詳しい人の意見を聞いたり、何か迷った時に過去のプロジェクトで似たようなケースをどっちの方法で解決したか調べたりすることもある。 書き出すとすぐ終わる短いコードでも、書き出す前に、聞きにいったり議論したりする時間が随分かかっていることもある。この時間をかけないと、結局、後で変更になるので、先に聞きにいくのがベターなんだが、チーム全員集まってひとつのコードを書けば、そういう時間を省略できるような気はする。 だから、これが生産性が高いということは感覚的に
新卒エンジニアでもできる！コメントアウトで同期に差をつける裏技 - Qiita
6月がやってきた 新卒の皆さんは、入社して2カ月が経ちました。 そろそろ会社に慣れてきた頃でしょうか。 会社によっては、研修期間が終了して、現場でバリバリ開発をしている人もいるかと思います。 JavaScriptでコメントアウト 基本的な文法は以下の通りです。 本には載ってないコメントアウトの裏技 それでは、裏技についての説明です。 これは、私が1年目の駆け出しだった頃、SONY系のゲーム会社から転職してきた「T先輩」に教わった裏技です。 当時の私は、仕事のやり方を覚えている最中で、「先輩から学べることは何でも学んでやろう！」と意気込んでいた頃でした。 さっそく、裏技のやり方を説明したいのですが、「基本編」と「応用編」で2つの技があります。 まずは、「基本編」から解説させていただきます。 基本編 以下のコードは、複数行コメントである「/* */」を使って、3行の処理をまとめてコメントアウト
スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
単体テスト盲信してる皆様へ
そもそも意味あるのかちゃんと考えてる？ 「単体テストを書けばバグが減ります！」 「単体テストのお陰で精神的安定を保てます！」 馬鹿じゃねーのかｗ？ テストコードのメンテなんてデバッグの手順書メンテしてるのと大して変わらねーよｗ その単体テストが本番と同一の動作をテストできてる保証はねーって気づけボケが 本番と同じ動作をテストしたかったらデバッグしろよ なんで別のコード書き始めちゃうの？無駄じゃん馬鹿じゃん それと「テストコードがあるから安全です」なんて寝言まだ言ってるの？ プロジェクトが進むにつれソースも依存ライブラリも変化する以上 いつも同じ結果になるわけじゃねーだろが、（保守しないって選択はあるけど金入ってこないだろ） 本番でもテストコード動かしますってやつら以外無理して単体テスト書く必要ないんじゃねーか？ お前らが欲しいのは軽いデバッグモードであって単体テストじゃねーだろ？ 工数削っ
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
既存コードの甘い匂い (悪意なきチグハグコードの誕生) - jfluteの日記
まえがき 前提として、しっかりとコーディング規約やコーディング手順などが整備されている現場ではあまり関係ないかもしれません。 そういうのを整備して実践していことが難しい現場、スタートアップからインクリメンタル開発を経て、成長していくサービスを長期間作り上げていく事業会社が主なターゲットの話かもしれません。 既存コードに if 文がありました さて、あなたが開発現場に途中から参画しました。すでに A と B という別の人が作った画面があります。 あなたは C を作ります。C は A と B と似ています。 「さあ、作ってください」 と言われました。どうしますか？ ... まあ、普通に考えたら、A と B を参考に作りますよね。ここに甘い匂いがします。 A と B には、とある定型の if 文による制御がありました。C では一見、要らなそうに見えますが複雑でよくわからない。 C でも if 文
研究職の人って失敗にめげず頑張っててホント凄いと思う
1週間前、あっ……これ良いかもっていうアイデアを思いついた ベクトルデータのクラスタリングに関することだったんだけど、ググったり関連文献あさっても同じような事してる人は全然いない なので今までそういう経験はほぼなかったんだけど、自分で1から実装してみることにした 結果、大失敗、意味なかった、というか無理だった 3日目くらいまでは、凄い順調で、おお、これ凄いぞ！やばいやばい！って一人でテンション上がってたんだけど 5日目の終わりに、あれこれもしかしたら、この概念を拡張したらアウトじゃない？拡張できなくない！？っていう疑問が湧いてきて ただ、自分の数学力ではそれを数式で証明なり検証するのは不可能だったので確認できるところまで実装を進めることにした で今日、というかさっき、自分が1週間前からやってたことは全部無駄だったというのが確定した もう気分の落ち込みが半端じゃない、本当に最悪、何もする気お
Androidソースコードレビューで指摘する事が多い項目まとめ2 - こやまカニ大好き
去年Androidソースコードレビューで指摘する事が多い項目まとめという記事を書いた時はアプリ全体を一度に見るような機会が多かったため、内容も大きめのものばかり書いていましたが、最近はプルリクエスト単位でレビューする機会が増えたので細かい項目についてまとめてみようと思います。 ミリ秒で時間を指定する時に自前で計算している 1000L * 60L * 60L * 24Lのようなコード。 TimeUnitを使いましょう。 24時間の場合は以下のように書けます。 TimeUnit.DAYS.toMillis(1L) ある文字列がhttp/httpsで始まるかチェック URLUtil.isNetworkUrl()を使いましょう。 ただしequalsIgnoreCaseで判定してます。 ベースURLにパラメータを付与していってURLを生成したい StringBuilder#append("&key=
Goだからこそ許される3つの作法 - Qiita
この記事はGo その3 Advent Calendar 2015の18日目です。 仕事の関係でGoを使い始めて気付けば9ヶ月。今ではすっかり慣れましたが、始めた当初はそれまでC言語・Java中心で仕事をしてきた自分にとってGoの文化はかなり異質に映ったのを覚えています。 せっかくなので、他言語経験者でこれからGoを始めますよという方向けに、「Goではこんなことしても許されるよ」みたいなポイントを挙げてみたいと思います。 1文字の変数名 昔のプログラミングの入門書のコード例なんかだと、 というように1文字の変数名が多用されてたりして、それを引きずったまま職業プログラマになってコードレビューで可読性警察に逮捕される、なんてことは良くあったのではないでしょうか。 最近は「リーダブルコード」などの良い書籍が普及したのもあり、変数名は多少長くとも意味が判るものが良い、という文化が一般的なのではないか
PHP初心者が仕事で躓いた4つの罠 - pixiv inside [archive]
こちらはピクシブ株式会社 Advent Calendar 2015の2日目の記事です。 こんにちは。Vimエンジニアの kana です。 さて、皆さんもご存知の通り、WebサービスのpixivにはPHPが使用されています: PHPについては様々な噂を聞き及んでいた為、 これまでPHPとは関わらないように注意して過ごしてきましたが、 pixiv.netの開発ではPHPを避けて通ることは出来ません。 仕方なくPHPを使うことになる訳ですが、 実際に使ってみると……これが予想していた以上に様々な方向から毎日新鮮な驚きを届けてくれます。 今回は実際に遭遇したPHP初心者が躓くポイントを幾つか紹介しようと思います。 switch の中で continue したら switch の直後に飛ぶ 大量のデータをループでぶん回して処理するのはよくある話です。 その中で特定の種類のデータについては処理をスキッ
![PHP初心者が仕事で躓いた4つの罠 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/6d2307a635e19c1c1fe2e28b504dc3b580db0c7e/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fk%2Fka-nacht%2F20151202%2F20151202201442.png)
Linus Torvals、クソコードにブチギレ
Linux-Kernel Archive: Re: [GIT] Networking Linus TorvalsがGCCの独自拡張を使った整数演算のオーバーフロー検知コードがあまりにクソすぎるためにブチギレしている。 On Wed, Oct 28, 2015 at 3:32 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: リリースサイクルのこの後半に入れるのはちょっと怖いと思われるかもしれないが、小規模なドライバーの修正をあちこちに施しただけだよ。 マジかよテメーら、こりゃクソだ。 コンフリクトはGCCの新しいクソヘッダーファイルのせいなんだが、俺がブチギレてるのはそこじゃなくてこいつがクソなせいだ。 net/ipv6/ip6_output.cの以前のコードはこれだ。 mtu -= hlen + sizeof(struct frag_hdr);
コードを直訳したコメントは必要なのか？「要る派」と「要らない派のまとめ」【 社畜ちゃん台詞メーカー 】
コードを直訳したコメントは必要なのか？ というお題を 社畜ちゃん台詞メーカーで画像を作って投下してみたところ、たくさんのご意見をいただいたのでまとめてみました。
ニトリのコードを見てニヨニヨする会（そして最後にニヨニヨできなくなった話） - Minecraftとタートルと僕
2015-06-24 ニトリのコードを見てニヨニヨする会 雑記 情報リンク集 ニヨニヨ はじめに ニトリのECサイトであるニトリネットがリニューアルに失敗して6日も経ってから復旧したということで、 （一部の）プログラマクラスタで騒ぎになっています。 僕の率直な感想は次のようなもの。 閉鎖状態の「ニトリネット」が6/23にサイト運営を再開、不具合の主因はCPU不足 | ネットショップ担当者フォーラム ともあれ関係者の皆さまお疲れ様でした。個人の責任問題などと短絡化することなく、粛々と原因解明と、できればぜひ知見の共有公開をお願いしたい。2015/06/23 13:40 プレスリリースでは、原因としてCPU不足を挙げています。 珍しい原因ですよね。あまり聞いたこと無いのでぜひその知見を知りたいものです。 しかし雲行き怪しく 早速、ニトリのトップページ見ている。すごい8000行の中にデバックコー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クソコードの測り方
良いコードとは
