コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2014年12月29日 >>> 2014年12月20日
link もっと後

2014年12月28日

継承と委譲

今日、初めて 〜Java 7の単一継承でつまづきました。

Javaなら継承じゃなくて、委譲だろ?という天の声が聞こえますが、委譲先と同じ名前の関数が増えてうっとおしいです。継承の方がスマートだと思うんだけどなあ…。

このまま委譲で作るか、思い切ってJava 8のMix-in機能に変えるか、悩ましい。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2015/11/29 05:33)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2014年12月27日

残念なコメント

コードのコメントは有った方が嬉しいですが、有ればいいってもんでもないです。

たとえば…、下記のような「見たら分かるわ!このおバカ!」というレベルのコメントは、いくら有っても嬉しくありません

残念なコメントの例

//hogeの合計を出す
for (i = 0; i < hoge_length; i++) {
    sum += hoge[i];
}

こんなコメントより、合計を何に使うのか?どうして今計算するのか?のコメントの方が嬉しいですよね。

しかし会社のコードでは、ひどいレベルのコメントを良く見かけるので、残念極まりないです。仮にもソフト開発部門なのに、こんな体たらくで良いのか……?

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2015/11/29 05:36)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2014年12月26日

おー人事、おー人事

最近、職場から人が去っていくことが多く寂しい限りです。

人が去るとき、残った人にコードを引き継ぎますが、大抵の場合、さほど詳しくない人がコードを引き継ぐことになります。

詳しくない人が、引き継いだコードを使おう、変えよう、とするのは非常に大変です。自身の経験でも、周りの人を見ていても、そう思います。

さほど詳しくないコードを引き継ぐときに、この情報があれば良かった…と思うことが2つあったので、自分が何か作るときの戒めとして書いておきます。

あったら良かった2つのこと

  • 1つ目は初心者のための「使い方」
  • 2つ目は熟練者のための「なぜその方法を取ったか」

「使い方」は、初めての人でも数分〜1時間で使い方がわかると嬉しいですね。

引き継いだのに初心者ってことは無いだろう?と思われるかもしれませんが、残念ながら、実際のところ初心者のことが多いです。断片的な設計資料があればマシな方ですが、初心者には全く役に立たない場合が多いです。

「なぜその方法を取ったか」は、コードを読んでも見えてこない設計の「Why」が書いてあると嬉しいですね。

文章の5W1Hと同じように、コードにも「When」「Where」「Who」「What」「How」が書かれています。余程クソみたいなコードじゃない限り、仮に設計資料が全く無かったとしても、コードを読んだり、動かしながら解析すれば5W1Hまでは何とかなりますが、「Why」は絶対にわかりません。

例えば、問題Qがあって、方式Aと方式Bという解決方法があったとします。コードを読んだり解析すれば、Qを解決しようとしていること、Aを採用していること、まではわかります。しかし、なぜAを採用したか?は、いくらコードを見てもわからないのです。

設計の「Why」にこだわる理由は、設計を変更する(例えば方式Aを方式Bに変える)時に、非常に重要な情報となるからです。

単に方式Aしか知らなかっただけなら、方式Bへの置き換えは検討に値するでしょう。でもBは地雷で別の問題を誘発するなら、Bは地雷だと書いておけば後継者が無駄な検討をせずに済むはずです。

情報を残す場所

自身の経験から言って、コードのなるべく近くに「使い方」と「なぜその方法を取ったか」があると嬉しいです。情報を残す手段として良く見かけるのは4つです。

1つ目、WikiやTracなどのWebシステムです。

  • まとめて書ける、読みやすいのが利点
  • コードとの対応が取りづらいのが欠点

特に「使い方」を書くとき、多人数に公開する情報を書くときに向いていると思います。コードと一緒にはできないので、コードとの対応を書いておくと良いと思います。

2つ目、PowerPointのスライドです。会社では一番多く見かけます。

  • 図が書きやすいのが利点
  • 差分が追いづらい、コードとの対応が取りづらいのが欠点

コードとバラバラに管理すると散逸しやすいのでPowerPointで情報を残したいなら、コードと一緒にコミットすると良いと思います。

3つ目、READMEのようなテキストです。

  • 差分が追いやすく、まとめて書けるのが利点
  • 長くなると読みづらく、コードとの対応が取りづらいのが欠点

コードのトップディレクトリに置いておくと目立つので「使い方」を書くときに向いていると思います。コードと一緒にコミットするのが普通でしょう。

4つ目、コードのコメントです。

  • 差分が追いやすく、コードとの対応が取りやすいのが利点
  • まとまりがなくなるのが欠点

必ずコードの近くに書けるので「なぜその方法を取ったか」を書くときに向いていると思います。コードと一緒にコミットされる(そうせざるを得ない)のも良いですね。

編集者:すずき(2014/12/27 15:59)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2014年12月29日 >>> 2014年12月20日
link もっと後

管理用メニュー

link 記事を新規作成

<2014>
<<<12>>>
-123456
78910111213
14151617181920
21222324252627
28293031---

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事3件

  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www2.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/20 02:52