変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod
脱ブランチファースト - 日々常々
あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト（造語） 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン（ master ブランチ）に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙
Gistで遊んでみる - 日々常々
GitHubにはコードの断片を管理したり人に見せたりブログに貼付けたりするのに便利なGistってのがあります。 通常の使い方では、ブラウザで貼付けたりとかすると思うのですが、GistもGitのリモートリポジトリなので、クライアントから使う事も出来ます。 ……ってのはGistにも普通に書いてるんですけどね。 Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository. とりあえずやってみます。 色々やってみる まず適当に作ります。 GitHubはお金払わないとプライベートなリポジトリは作れないのですが、Gistだ
「淡路島の電車の運行状況を聞いた話」をシステム開発に置き換えてみる - 日々常々
気象庁の地震情報|平成25年04月13日05時48分 気象庁発表 4/13のAM5:33にM6.0らしい地震がありました。各地で大きな被害が無いことを祈りつつ。 フジテレビのアナウンサーさんが淡路島の電車の状況を聞いたと言う話 【放送事故】フジテレビが淡路島民に「電車動いてますか?」と質問 「淡路島は電車ありません」 - NAVER まとめ だいたい見てると「電車無いのを知らずに聞いてしまった」のを叩く向きに思えます。実際のところ、聞いたこと自体はNGなのでしょうが、これをシステム開発の話に置き換えると見えるものがある気がしました。 以降はJavaの語彙で書きますが、これって NullPointerException っぽいなと。 コードっぽい何かで書いてみる こんな感じ。 運行状況 = 淡路島.get路線().get運行状況(); get路線() が何を返すのか知らないけど、これが nu
文字列連結と+演算子について整理しておく - 日々常々
何度か書いているけど、整理的な意味で。今後は「このエントリ参照」にするつもりで書いてみる。 文字列連結から見るシステム内で扱う型について - 日々常々 Javaプログラマであるかを見分ける10の質問 に答えてみる - 日々常々 String の連結ネタの続き - 日々常々 前書き Stringなんてboxed primitive*1でもないただのクラスのくせに、中途半端に贔屓されて*2てムカつく*3し、その中途半端ぶり*4がなお腹立たしい……。そして +演算子 で連結して問題が起こるような状況、つまりそんな長々と文字列連結したいような場合は、きっと他の適した型がある。StringBuilderじゃなく、もっと別の何か。業務要件で文字列を組み立てる目的を考えれば、たぶんテンプレート的なものに落ち着くんじゃ無かろうか。ライブラリ的な所でなら逐次書き出し等になるような。どちらにせよ文字列の組み立
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
見やすいコードのために出来るたった一つのこと - 日々常々
タイトルは釣りっぽいですけど、結構まじめ。 フォーマッターを使用すること。 これが全てです。「スペースがどうこう」とか「括弧の位置がどうこう」とかどうでもいいです。そんな美的感覚でかわるような枝葉の話に結論は出ません。 コードフォーマッターを使用してください。そのプロダクトを通して、統一された同じフォーマッターでフォーマットすること。コードはそれだけで格段に見やすくなります。個々人が好き勝手にやったり、気をつけたり、CheckStyleなどでの見た目の警告を処理したり……そんなのしてたら不統一で見難いコードにしかなりません。 個人個人での見やすさとかはあります。当然です。例えば変数代入のイコールの位置がそろってる方が見やすい人もいます。変数宣言は1行開いてた方がいいって人も、メソッド間は2行開いてた方がいいとか、賛同できませんけどそんな人も居ます。そう言うときは自分専用にフォーマットして、
私の技術書の選び方 - 日々常々
技術者たるもの、毎月積読タワーを成長させる義務があります。嘘です。成長させちゃいけません。とは言え毎月のように新しい技術書に触れる事は重要だと思います。私はそれほど読書速度も速くないし、勤勉でもありませんが、それでもそこそこの量は読んでると思います。 毎月の技術書代 「技術書に幾らかけているか？」はたまに話題になります。私の場合だいたい 1万円／月 です。値段がどうしたと思うかもしれませんが、だいたい冊数がわかります。3,000-4,000円 が多いので、だいたい3冊ってことですね。 費用自体は収入や読書速度、近くの図書館の蔵書などにも左右されるとは思いますが、勉強会でお会いする方々に聞いてみたところだいたい似たようなものでした。中には 2-3万円 かけてる方も居ましたが、大事なのは継続して読み続ける事だと思います。なので月当たりの費用を聞いてみました。本はそのまま身に付きますので、払えな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
