私のソースコードの書き方 - @kyanny's blog
note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける（当たりのつけかたにもいろいろあるのだが後述） 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う（エディタの undo でせっかく書いたコードを失わないため） 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ
コードを書く経営者ドワンゴ川上会長「プログラミングこそが基礎教養」 | Biz/Zine
Developers Summit2015 (略称デブサミ)は翔泳社が主催するエンジニアイベント。ビズジンでは、ビジネス層向けのセッションレポートをお届けする。初日(2月19日)の朝一のセッションではドワンゴの川上量生代表取締役会長。「このままでは、二流のWebエンジニアが大量に生まれる」と警鐘を鳴らした。 象徴CTOって何？ IT業界のエンジニアイベントにはあまり呼ばれないという川上氏。数年前、とある有名なテクノロジーメディアのイベントに出て、「主催者、事務局、媒体そのものと来場者をdisり、講演自体は高評価だったのですが、その後呼んでもらえませんでした(笑)」と語り、のっけから超満員の聴衆に問いかける。 なんでエンジニアの人って、勉強会好きなんですかね。前から疑問に思ってたんですけど。こういうところに来るより、ネットで調べたりした方が良いんじゃない? 今日のデブサミはいろんな会社のCT
データ構造と メソッドのネーミング - codic ブログ
データ構造など技術的な背景をちゃんと知っていれば、データ操作に関する正しい英語を使えるねーて話です。用語のイメージもつかめるようにしていますので、shift / unshift とかイメージできない方もどうぞ。 1. push / pop = スタック push pop は、スタックの用語で、それぞれ pop はスタックから取り出す、push は挿入する事を意味します。JavaScript や Ruby の Array には、スタックとしてのコンセプトもあるので、push / popという用語が使われます。 対して、Javaの ArrayList (インターフェースは Collection） は、単なる集合を表すインターフェースなので、抽象化のために add / remove というネーミングが使われます。そういえば、Javaには、Stackというクラスも別途用意されていますね。Stack
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
毎日コードを書くこと - snowlongの日記
ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。（そして、うまく行かなかったら失敗したような気分だった。） 週末にいつも予定が空いている
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
例え話だけで解決に向かうのか? - 技術的負債論 - MassKaneko.Out
はじめに 以下のエントリがHOTになっています。公開4日後の現在で949はてブです。 技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog 私は企業で Software Engineer in Test としてソフトウェアの保守性に責任を持つポジションに就いている身ですのでこのテーマに関心があるのはよいことだとは思います。技術的負債そのものについてのエントリは過去にも沢山あるようですが、mizchi さんのエントリは誤解を恐れないシンプルで断定的な書き方ですので多くの人に刺さったのでしょう。 ただ、技術的負債(technical debt)というメタファーが万人に誤解無く伝わるのかは疑問です。時間を借りているのかはピンと来ませんし、財務的負債と異なり返済の義務はありません。また、エンドユーザーに提供する価値よりも負債にフォーカスし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
