タグ

開発とprogrammingに関するkoudaiiiのブックマーク (7)

  • プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。

    この文章について OOP(オブジェクト指向プログラミング、オブジェクト指向パラダイム)について プログラミング勉強中の大学生さんに説明する機会が何度かあったので、 自分の中で整理するために書きました。 中には適切でない説明もあります。ばっさり省いているところもあります。 詳細より イメージを掴んでもらうことを優先しているためです。 「それにしてもあんまりだなー」という表現がありましたらご連絡いただけると嬉しいです。 大学生さん 大学生さんたちはいろんな背景を持っています。 プログラミングを始めたばかりの人 独学で Objective-C や JavaScript を書いた経験がある人 Web やコンピュータの仕組みについてもこれから勉強する予定の人 使用言語 大学生さんたちはプログラミングの第一歩として JavaScriptPHP を使っています。ここでは説明に PHP のコードを使

    プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。
  • 作業中断のコスト

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    作業中断のコスト
  • リファレンスマニュアルの記述方法 - 2011-05-05 - ククログ

    Rubyではライブラリのリファレンスマニュアル作成のドキュメントツールとしてRDocが標準となっています。これは、古くからあるという理由とRuby体に標準添付されているという理由からです。しかし、RDocはそれほど活発に開発されていないため、最近のドキュメントツールとして機能不足と言わざるをえません1。どのような機能が足りないのかについては別の機会にします。 数年前からYARD(Yey! A Ruby Documentation Tool)というドキュメントツールが開発されています。YARDはRDocとの互換性を残したまま機能を拡張しているため、RDocからの移行も容易です。実は、YARDは第2回フクオカRuby大賞(SSLの証明書の期限が切れているので警告がでます)に「Improving Documentation in the Ruby Community」というタイトルで応募してい

    リファレンスマニュアルの記述方法 - 2011-05-05 - ククログ
  • 適切なサイズのコミットにする方法の案 - 2012-04-17 - ククログ

    以前、読みやすいコミットにする方法としてコミットメッセージの書き方と小さくまとまったコミットの具体例を紹介しました。今回は、小さくまとまったコミットにするためのより一般的な方法の案を紹介します。案としているのは、広く使えそうな気がしますが、思いついたばかりでまだ実例がないためです。この方法が使えそうな気がしたらぜひ試してみてください。 どのくらいのコミットが読みやすい適切なサイズかというのはケースバイケースのことがほとんどです。以前紹介した具体例が使えることは日に何回かあるでしょうが、1日に二桁くらいはコミットするはず1なので、コミットの大半はケースバイケースで判断していることになります。では、ケースバイケースで判断しているときはどのように判断しているのでしょうか。感覚的にはケースバイケースで判断しているときも何かしら一般的な判断基準を使っていそうです。 そこで思いついた(気付いた)のが今

    適切なサイズのコミットにする方法の案 - 2012-04-17 - ククログ
  • 名前のつけ方 - 2012-06-28 - ククログ

    はじめに わかりやすいコードを書くことはソフトウェア開発において大切なことです。では、具体的にわかりやすいコードとはどんなものでしょうか?その観点はいろいろなものがあります。その中で今回は名前のつけ方に着目します。 コードに名前をつけるということ ソフトウェア開発において、名前をつける作業というのは絶えず発生します。メソッド名、変数名、クラス名、ファイル名などなど。名前をつける機会を挙げたらキリがありません。では、そもそもなぜ名前は必要なのでしょうか? それはソフトウェアに限らず言えることですが、複数のモノを区別したいためです。例えば、まったく違う処理をする別々のメソッドに同じ名前をつけたらソフトウェアは正しく動きません。それを防ぐためにそれぞれのメソッドにちゃんと名前をつける必要があります。それぞれのモノにそれぞれ違う名前をつけて区別できなければソフトウェアはそもそも動きません。 名前を

    名前のつけ方 - 2012-06-28 - ククログ
  • クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ

    最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので

    クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ
  • コミットメッセージの書き方 - 2012-02-21 - ククログ

    はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常

    コミットメッセージの書き方 - 2012-02-21 - ククログ
  • 1