デバッグが早い人と遅い人の違い
会社にデバッグの早い人と遅い人がいる。 二人を観察していると、色々な違いが見れて勉強になる。 いくつかまとめてみる。 ・デバッグが早い人はコードに着手する前に状況を整理する 期待動作はどのようなものか、現状の動作（バグ）はどんなものか、どんな条件でバグが生じるか、生じないかを整理する 他人からアサインされたタスクの場合、手早くこれらを質問して状況を確認する。 デバッグが遅い人は何も考えずにコードを触り始める。 「何をデバッグしているの？」と聞くと言語化出来ない。 場当たり的、五月雨式に質問する。 ・デバッグが早い人は仮説を持っている。 ざっくりと全体像を把握し、当たりをつけてから作業する。 全ての作業が仮説の検証作業。結果が出た時に次に何をすべきかも把握している。 デバッグが遅い人は自分でも何をやっているか分かっていない。 「よくわからないけど一応2回試してみた」とか言う。 「それは今何を
ソースコードって実際のところどういうふうに書いていますか？｜Rui Ueyama
私はプログラミングは結構自信があるんですが、他の人の作業をつぶさに観察したことがあるわけでもないので、自分で当たり前だと思っているコーディングの方法が他の人にとってはそうではないこともあると思ってます。上手い人がどういうふうにしてプログラムを書いているのか知りたいんですよね。 逆に私はどういうふうに書いているかちょっとまとめてみました。自分はこうしている、というのがあったらぜひ教えてください。 まず私の場合、ゼロからコードを書くよりも現在のプロジェクトのためのコードを書くことのほうが多いので、コードを書くというのは既存のコードに変更を加えることがほとんどです。既存のコードに手を加えるときは、新機能追加か、リファクタリング（動作は変えずにコードをきれいにすること）のどちらかになるわけですが、まず前者をどうしているかどうかをできるだけ説明してみます。 まず必要なのは考えることです。よく知ってい
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
第三者のための『リーダブルコード』 - 詩と創作・思索のひろば
新人エンジニアにオススメの本のひとつだよねー、などと言いつつ自身は読んだことがなかったので慌てて買って読んだ。 お題「リーダブルコード」 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典出版社/メーカー: オライリージャパン発売日: 2012/06/23メディア: 単行本（ソフトカバー）購入: 68人 クリック: 1,802回この商品を含むブログ (131件) を見る なるほど当たり前のようなことでありながら短期的に意識して身につけるのは難しかったことばかりで、これがこのようにまとまった形の書籍になっていることはとてもありがたいことだと思う。規約を押しつけてるわけじゃなくて指針の集合なので、気楽さもある。 プログラム中で使用する英語動詞
大規模ソースコードの読み方
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
夏のインターン講義「1営業日で書くJavaScriptコンパイラ」の設計と実装 - クックパッド開発者ブログ
今年、クックパッドでは夏のインターンと題して20名弱のインターンを受け入れました。 このインターンは前半と後半に大きく分かれており、 後半が社員に混じって業務をするいわゆる普通のインターンで、 前半は7日間にわたってプログラミング関連の講義を受けるという仕組みです。 わたし（青木）はその前半の過程において、「プログラミングパラダイム」という 1 日の講義を担当し、 JavaScriptの処理系を書くという、ツッコミどころの多い課題を実施しました。 本稿では、その講義を開発する際に考慮したこと、特に難易度調整についてお話しします。 また講義のために開発したJavaScript処理系「JetSpider」についても軽くふれます。 ▼講義資料 Cookpad Summer Intern 2015 - Programming Paradigm from Minero Aoki JetSpiderコ
公式ドキュメントを読もう — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 最近、若手のエンジニアと話をする機会が多くあります。そういった場で、ここが重要ですよと伝えたい話のうちのひとつがこの話になります。別のところに書いていたものですが、すこし手を入れた上で再掲します。 ハッカーの世界には昔から「RTFM」という言葉があります（参照）。ようするに「マニュアルを読め」という言葉なのですが、これはとても重要な言葉です。 色々な人によってブログにメモやノウハウが記載され、簡単に検索でみつかる世の中ではあります。また、そのためのサービスや技術的な質疑的な質問をすることのできるサービスも沢山あります。 しかし、検索サービスは、その内容が正しいことまで保証してくれません。見つかった記事の著者が誤解している場合もあれば、理解していない場合もあります。そして、ほとんどの場合は最新の情報ではありません。 マニュアルや公式ドキュメントであれば、それ
1443641775
よく「どうやって情報手に入れてるの？」みたいに聞かれますが、そんなの、ひたすら時間かけてgithubみたりメーリングリスト読んだり最近ではgitterの会話読んでるに決まってます。 どうやって(How)ではなく、なぜ(Why)、自分がそんなことをするようになったのかを、あらためて書いてみる気になったので書いてみたいと思います。 書こうと思ったのは、Howだけ書いても、Why書かないとあまり意味ないと思うことが多くなったからですかね。(この件に関しては) 無責任に大雑把にいうと、(どんな理由であれ)情熱みたいなものがあれば、Howは自然に身につきます、たぶん。 なお、少し長くなるし、自分語りっぽくなるし、いつも書いてるようなものとは少し方向性が違い、具体的なすぐ役に立つ技術的な内容*1は基本出てこないので、期待してるものが違うと思う人は、ここで読むのやめたほうがいいと思います。 どれほどコー
プログラミング上達するためにだいじだなぁとおもったこと一覧
コードを書くことコードを読むことコマンドラインをほぼ常に使うこと（「使わないわけないだろう」と思う人が多いと思うが、それができない人はそれよりも多い）ライブラリも可能な限り読むこともっとコードを読むことコピペしてもいいけど、コピペするコードの意味は絶対に把握すること自分の勤め先がクソなら、会社は辞めること（ある程度技術力があればどこでもやっていける）英語が読めること数学的・論理的思考をみにつけることオープンソースのコードを読むことなるべく根本的な概念を知ることひとつの言語に拘らず、何個も触ること（ひとつのパラダイムに固執する可能性がある）UNIX/Linuxをメインでつかうこと流行を追いかけ過ぎないこと（結局ソフトの上で踊らされているだけ）自分の知らない分野はいくらでもあると心得ること井の中の蛙にならないように心がけることマネジメント視点も取り入れること「他人のため」を考えること（独りよが
学生時代に知っておきたかったWeb技術の学び方の学び方 | リブセンス
「プログラミングを学ぼうと瞬間最大風速的に意識は高くなるものの、一人でいると気がついたら一日ソシャゲして夕方頃に『また今日も勉強できなかった』と自己嫌悪。」モチベーションが続かない時の対策をはじめ、学び方、学べる環境の作り方をまとめています。
情報科学における18のメタテクニック
情報科学でよく使われるメタテクニックについての紹介です。取り上げたのはキャッシング、[ノン]ブロッキング、プロファイリング、パイプライニング、投機的実行、条件の緩和、Eager/Lazy、フィルタリング、再利用、並列化、結合/分離、多階層/クラスター化、先読み/先取り、動的適応、複製、仮想化、チェックポイント、トランザクションの計18個です。
コード リーディングについて
コード リーディング(code reading)とはプログラムのソースコードを読み解くことです。他人のプログラムをはじめ、自分が昨日書いたプログラムを読むのです。 コード リーディングの目的 コード リーディングは一般的に「わからないことを調べる」ときに行われますが、その詳細は様々です。 いくつか例を挙げてみます。 実装を学ぶ アルゴリズムやデータ構造など、プログラミングそのものを学習します。 テクニックを知る 動作が高速で安定したソフトウェアに仕上げるためにエレガントなプログラミング手法を学びます。 自分のコードに自信を与える 文字どおり自分のプログラミングに不安を覚えた時、先人の仕事を確認します。 さらに、あなたは優れたソフトウェア開発者になりたいですか？もしそうなら次のことを想像してください。 ピアニストを目指す者はお気に入りのピアニストの曲をあきれるほど弾きます。ときにはテクニック
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
ダメなコードを改造しなくてはいけなくなったときは、ダメさを片っ端から潰していくしかない
仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか
プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ
僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか？」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ
メソッド名をシンプルにするために、 知っておくと便利な英語のprefixとsuffix - codic ブログ
メソッド名などをネーミングする際に、知っておくと便利な、接頭辞と接尾辞をリストアップしてみました。どのように元の単語の意味が変わるかのルールを知っておくと、よく使う単語をベースにボキャブラリーを増やすことができるので、覚えておいて損はないと思います。 使う場合は、当たりを付けて実際の使用がないか、Googleなどで調べてみてください。 1. pre-, post- / 事前〜、事後〜 per-は、元の意味に “事前に、前に”、post-は “事後に”という意味が付け加わえます。汎用性が高いのでとても便利です。afterやbeforeの代替になるかもしれません。 // 事前テストする function testBefore(); ↓ function pretest(); // 事後処理する function executeAfter(); ↓ function postexecute();
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised
Write Code Every Day
オブジェクト指向できていますか？
関数名によく使われる英単語（動詞）の意味とニュアンス | PHP Archive