タグ

読み物と*programmingに関するround_teaのブックマーク (5)

  • 2010-03-20

    なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して

    2010-03-20
  • Shibu's Diary: 「ソースコードをきれいに書く唯一の方法」は4つある

    渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 taken by Manuel_Marin なんとなく書いたら、アクセス数が10000件超えたソースコードをきれいに書くための方法の記事。r-westさんの「きれいなソースコードを書くために必要な、たったひとつの単純な事」と、uwiさんの「誰がためのきれいさ?」と、フォローのトラックバックまで頂きました。僕のも含めてそれぞれスタンスが違いますが、どれが正しいとか、どれが一番いいかというのはないと思っています。人によってどっちがいいかは別れるはずです。人によっていちばん苦労がなくて、モチベーションがあがる方法がそれぞれの人にとっての正解である、というのが僕の考えです。 モチベーションマネージメントというのがよく言われるけど、「モチベーションを上げろ」と言われて上がる人なんていませ

  • まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary

    まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」に行ってきました〜。今年初めて行ったイベントなのですが、とてもいいお話を聞くことができました。美しいコードとはどのようなものか、またそのようなコードを書けるようになるためにはどうすればいいのかというお話でした。 以下、まとめになります。僕のメモを元にしたので、まつもとさんが話された内容と多少ズレがあるかもしれません。 そもそもコードとは何か 「コードの美しさとは」という前に、そもそも「コード」とは何か。 ソフトウェアの作成はものづくりではない コードは工業製品ではない。コードは、車とかと同じ工業製品だと思われることが多く、例えば次のような勘違いがある。 日は「ものづくり」が得意だ。だからソフトウェアも「ものづくり」として取り組めばいい 車のように、ソフトウェアも部品をどんどんコピーして組み合わせばできる 違うよ!全

    まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary
    round_tea
    round_tea 2009/02/10
    あとでもう一度読む
  • プログラムが遅い人の10の特徴: それほど間違ってないプログラマ用語辞典

    反面教師も良い教師ということで、これまで仕事してきて、これやったら仕事遅くなるよなぁと思うような行動を取ってしまった実体験とか、あと見ていてこれはイカンよなぁと思ったことを10個ほど。 1. フリーズする 難題が持ち上がった時に、特に何かを調べるでもなく、首を捻りながら長時間沈思黙考するタイプ。頭だけで考えていてもたいてい前には進まないので、長考する仕草を取るのは「眠いのを誤魔化したい時」だけに限定した方が良いかなぁと思ってます。 2. 質問をためらう 技術的な内容なら自分で調べた方が為になることはあるけど、仕様などの聞かないと分からないことについてまで、なぜかためらってなかなか質問に行かないタイプ。相手が多忙だと質問しづらいけど、行かないと作業が止まるような時は遠慮なく相手に犠牲になってもらうが吉です。 3. Googleから答えにたどり着けない 同じことを調べているのに2倍以上時間がか

  • 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント - 分裂勘違い君劇場

    「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ

    中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント - 分裂勘違い君劇場
  • 1