きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
プログラムを「とりあえず」やってみることができる人の強さ - Feel Like A Fallinstar
今、自分の個人的な会社の開発でRuby On Railsを使っています。 真面目に、というか実質的には、初のRailsプログラミング。 やっぱり、最初は仕様が違って混乱したり、文法も今まで扱ってきたものと違ったり・・・ でも、友人のすすめで「とりあえず」Railsにしてしまったのは今から思えば大正解。 DBが大事な設計なので、rake db:migrateが超便利（sql処理が快適！） あらかじめ最低限のフォルダ構成が用意されてている快適さ などなど・・・ 「とりあえず」やってみることができる人、できない人 いまきはコンサルティング会社で働いています。 コンサルタントはみんな優秀。 方法論もすばらしい。 （いまき自身は新規事業を提案してそっちをやってるので、ちょっとアウトローですが） でも、だから毎回「頭」から入る。 これだけが本当にもったいない。 おかげで、ウェブのコンサルティング会社な
私の言語遅延学習法 - 三つのルール+1 : 404 Blog Not Found
2008年02月09日00:05 カテゴリLightweight Languages 私の言語遅延学習法 - 三つのルール+1 つっこみが遅くなりました。 新しくプログラミング言語を覚えたいときに行うべき10の練習問題 | IDEA*IDEA 404の人とかが突っ込んでくれそうな気がするので気軽にいってみます。 いい機会なので、私の言語学習法をこの際披露することにしましょう。 私の場合、一番の特徴は、「必要を感じるまで学ばない」「本当の問題に出会った時に、それを全力で解く」「学ぶ時には『原典』に当たる」ということでしょうか。私はこれを「遅延学習」と呼んでおります。実はこのことはコンピューター言語に限った事ではないのですが、コンピューター言語の場合、このことが特に顕著です。これらの特徴について一つずつ解説してみましょう。 必要を感じるまで学ばない 私の場合、長らく「プログラマー」としてより「
できる開発者になるための7つの習慣 - builder by ZDNet Japan
Sun Microsystems Asia-PacificのスタッフエンジニアであるLee Chuk Munn氏によると、アプリケーションを書くことは本を執筆することに似ているという。 「私はさまざまなプログラミング言語を学んできた。しかし、どんな言語を使ってプログラムを書いているかは問題ではない。書く物語がよいものでなければいけないのだ」Lee氏はZDNet Asiaの電話インタビューでこう答える。ソフトウェアのプログラミングでは27年の経験を持つベテランのLee氏はSunのソフトウェア部門で働いており、社内の開発者やJavaやSolarisを使用している個人ソフトウェア開発者のネットワークを指導している。 彼はこう続ける。「プログラミングは解決策の一つの表現にすぎない。プログラミングの多くを構成するのは、問題を理解して認識し、助けを得ることだ。この考え方はすべてのプログラミング言語にお
Geekなぺーじ : 良いプログラマの見分け方
「How to recognise a good programmer」という記事がありました。 良いプログラマを見分けて雇用するためのTIPSが書いてありました。 原文前半では、Paul Graham氏が書いている「The 18 mistakes that kill startups, 日本語版:スタートアップを殺す18の誤り」というエッセーに書かれている「90年代のE-コマースで多くのベンチャーを失敗させたのが質の悪いプログラマであるが、プログラマではない起業家には良いプログラマと悪いプログラマを見分ける術がない。」といった内容に対して反論すると書いています。 見分け方をまとめると、以下のようになるそうです。 流石に全ての項目を満たすような人は少ないそうですが、どれか一つでもあてはまる項目があれば、それは良いプログラマなのかも知れないそうです。 原文には、詳細な説明があるので興味のある
IT 戦士の作り方
操作方法 → キー: 次のページへ ← キー: 前のページへ ↑ キー: 目次ページへ ↓ キー: 目次ページから戻る 目次ページでは ← → キーで一覧を移動し、クリックで選択します
プログラミングの6大10項目リスト
Jeff Atwood / 青木靖 訳 2007年3月22日 以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。 [ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。] ジェラルド・ワインバーグの｢エゴレスプログラミングの十戒｣ 自分が誤りを犯すということを理解し、受け入れること 。 自分と自分のコードは別物である。 どんなに｢空手｣を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 相談せずにコードの書き直 しをしない。 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 世界で唯一変わらないのは変わるということだけ。 唯
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA