レガシーコードのはなしをしてみた #DevKan - 日々常々
レガシーコードと対峙する方法を考える - DevLOVE関西 | Doorkeeper 2014/03/25にあったDevLOVE関西「レガシーコードと対峙する方法を考える」で、「"レガシーコード"再考」とか釣りっぽいタイトルで話してきました。DevLOVE関西は発表とダイアログって形式が多いので、その時のネタの一つにでもしてくれればいいかなーくらいを力点にしてます。だもんで、「レガシーコードってなんやねん」とか聞くだけ聞いて、結論付けたりとかはせずに終わったり。そんな毒にも薬にもならない話でした。 スライド "レガシーコード"再考 問い: 発表者の気持ちを答えよ（制限時間10分） 「レガシーコードの話をする」のは簡単なことだと思う。世の中にはレガシーコードが溢れてる事にはおおむね同意されるだろうし、見てきたものをそれなりに話すだけでも「あるある」とか「うへー」みたいな、参加者の多くである
ベタープログラマを読もう - 日々常々
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック 作者: Pete Goodliffe,柴田芳樹出版社/メーカー: オライリージャパン発売日: 2017/12/15メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る 読みながらブログを書いてみようと思いたちました。去年ポチって届いたまま積んでた。とりあえず今回は目次流しして、部ごとにブログ書いていこうかなーとか思ってます。思ってるだけかも。 どんな本かというと コードを気にかける人の姿勢みたいなものかしらね。著者はCodeCraftと同じPeteGoodliffeなので、読んだことがある人は想像できるのかもしれない。 Code Craft エクセレントなコードを書くための実践的技法 . (Mynavi Advanced Library) 作者: Pete Goodliffe出版社/メーカー: マ
技術から入ってもいいと言う話 - 日々常々
システム開発の分野は技術の移り変わりが早く（これも他の分野と比べたことないので「早い気がする」と言うだけなのだけど）、なんらかの成功を収めた企業などの採用しているものがバズワードとなって一気に広まったりします。この時、その技術だけを追ってしまう現象がよく観測されます。だからバズワードになるんだけど。 批判的な意見 バズワードに飛びつくのは往々にしてアンチパターンです。例えば「モノリスからマイクロサービスへ」でも、明確な理由もなくマイクロサービスに飛びつくのは避けるよう書かれています。 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド 作者:Sam NewmanオライリージャパンAmazon 書籍に限らず経験のある人は技術の螺旋を見通し、「この技術は結局のところ重要な課題を解決しない」と示唆する発言をしたりします。 強く辛辣な言葉もたまに見かけます。「そこに問題はないんだ
いい名前が思いつかないときは変な名前をつける - 日々常々
プログラミングは名付けの連続です。しかし、いつも「いい名前」が見つかるわけではありません。付けたときはいい名前と思っていても、時間が経って知識が増え、ブレイクスルーが起こると、それまでいいと思っていた名前も途端に微妙に感じたりします。 このように「いい名前は見つからない」とか「どうせ変わる」とか思うと、名前を考えるのが無駄に感じたりしなくもありません。でも名前は重要です。名前の重要さは割愛します。プログラマが知るべき97のこととかを読んでください。 プログラマが知るべき97のこと 発売日: 2010/12/18メディア: 単行本（ソフトカバー） 名前を付けるときは、誤魔化さずに付けるように意識しています。と言うと、「いい名前をスパッと決められている」ように捉えられるかもしれませんが、そうではないです。私は名付け能力の低さには自信があります。誤魔化さずに付けると言うのは、「理解できていないこ
開発時間の内訳を眺めてみよう - 日々常々
開発効率を上げたいとか、開発速度を上げたいと言うのはプログラマの自然な欲求だと思います。 「そう思いはするもののどうすればいいかわからない」のであれば、開発時間の内訳を眺めてみましょう。 この図はグルーピングが微妙だったり、重要なものが抜けていたりすると感じるかもしれませんが、雰囲気は伝わるかと思います。使用している技術要素や取り組んでいる内容によって項目レベルでなかったりもします。参考程度に。 さて、単に「開発効率」と言うと、「コードを書いている時間」に目が向きがちです。これはさらにタイピングの時間だとかに分けられるかと思いますが、実際のところ、ここに割かれる時間は全体で見れば誤差のようなものです。もちろん早いに越したことはありませんし、無意識に書けるようになれば思考を他にやりながら書けるようになります。実際ある程度慣れた方であれば、コードを書きながらコードを読み、抜け漏れに気づいたり、
私の技術書の選び方 - 日々常々
技術者たるもの、毎月積読タワーを成長させる義務があります。嘘です。成長させちゃいけません。とは言え毎月のように新しい技術書に触れる事は重要だと思います。私はそれほど読書速度も速くないし、勤勉でもありませんが、それでもそこそこの量は読んでると思います。 毎月の技術書代 「技術書に幾らかけているか？」はたまに話題になります。私の場合だいたい 1万円／月 です。値段がどうしたと思うかもしれませんが、だいたい冊数がわかります。3,000-4,000円 が多いので、だいたい3冊ってことですね。 費用自体は収入や読書速度、近くの図書館の蔵書などにも左右されるとは思いますが、勉強会でお会いする方々に聞いてみたところだいたい似たようなものでした。中には 2-3万円 かけてる方も居ましたが、大事なのは継続して読み続ける事だと思います。なので月当たりの費用を聞いてみました。本はそのまま身に付きますので、払えな
英語がアレな私と洋書の話 - 日々常々
元ネタ：僕だったらどうやって洋書が読めるように努力するか - give IT a try プログラマに英語は必要です。なぜなら日本語に切り替えるのが面倒だから。 面倒って言うとネタに見えるかもしれませんが、入力モード切り替えたり、いちいち変換したり、誤変換によるアレコレ、さらに文字コードの話とかが積み重なって、いったいどれだけの英語圏のプログラマに存在しないコストを支払っているかを考えてみればわかる話です。…すみません、冗談です。 さて、元ネタに 僕自身は昔から英語が好きだったし、英語は一番の得意科目だったので*1、英語が苦手な人の気持ちを完全に理解することはできません。 僕だったらどうやって洋書が読めるように努力するか - give IT a try とありましたので、昔から英語が苦手*1な私が書いてやろうと思いました。私の英語の成績は非常に残念でしたが、スラスラとではないにせよ洋書や英
文字列連結と+演算子について整理しておく - 日々常々
何度か書いているけど、整理的な意味で。今後は「このエントリ参照」にするつもりで書いてみる。 文字列連結から見るシステム内で扱う型について - 日々常々 Javaプログラマであるかを見分ける10の質問 に答えてみる - 日々常々 String の連結ネタの続き - 日々常々 前書き Stringなんてboxed primitive*1でもないただのクラスのくせに、中途半端に贔屓されて*2てムカつく*3し、その中途半端ぶり*4がなお腹立たしい……。そして +演算子 で連結して問題が起こるような状況、つまりそんな長々と文字列連結したいような場合は、きっと他の適した型がある。StringBuilderじゃなく、もっと別の何か。業務要件で文字列を組み立てる目的を考えれば、たぶんテンプレート的なものに落ち着くんじゃ無かろうか。ライブラリ的な所でなら逐次書き出し等になるような。どちらにせよ文字列の組み立
テストが間違ってたら？ - 日々常々
「テストが間違ってたらどうするんだ」 自動テストの話をするとよく言われます。テストが間違ってたらわからないじゃないか。手動テストであれば、注意深く目で確認していれば間違いに気づけると言う主張です。 「目で確認していれば気づける」のは間違いではありません。必ず気付けるわけではありませんが、十分な知識を持った人が、十分な集中力と責任感をもってエビデンスを確認すれば、誤りに気付ける可能性は高いと思います。 品質(主に機能性)を目的とした自動テストでも、それを行う必要があります。それがテストコードのレビューです。 手動テストの場合、テスト実施前に手順や確認項目のレビュー、実施中の確認、実施後のエビデンス確認と、人が確認するタイミング*1が三カ所あります。 これに対し自動テストの場合、テストが書かれた時のみ。実行中は勿論、実行結果の確認に注意はありません。ただ成功か失敗かだけなので。ならば、テストコ
思い通りに動くコードを書きたい #TddAdventJp - 日々常々
2012年のTDD Advent Calendar、4日目でございます。 TDD Advent Calendar jp: 2012 : ATND 3日目 @grimroseさん open build/reports/life/index.html: スタッフになってみませんか？ #TddAdventJp 5日目 @a_suenamiさん 受託開発でTDDを導入するということ #TddAdventJp - assertInstanceOf('Engineer', $a_suenami) 自分にとってのTDDを考える 「TDDとは？」なんて掲げたところで、万人に通じる明確な答えを私は持っていません。原典はありますが、相応に進化も派生もしておりますので、固執する必要はないと思います。その上であえて「私にとってのTDD」を挙げるなら、以下の二点になります。 思い通りに動くコードを書く コードの成長
テストと言うパートナー #TddAdventJp - 日々常々
TDD Advent Calendar jp: 2011の 12日目です。 前：あなたは写経しますか - pocketberserkerの爆走 次：TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP - うさぎ組 テストはパートナー 「何を言ってるんだ？」な感じかもしれませんが、私にとってテストはパートナーです。 私がTDDのコンテキストで言う「テスト」はDeveloperTestです。このテストは開発者の開発者による開発者のためのテストであり、つまり開発者たる私のためのものです。私だけのためにテストは働いてくれます。 テストに対する不安 TDDや自動テストと言う言葉に触れ、「いざテストを書こう」と思った時。もしくはよく知らないままテストコードを書かなければならなくなった時。テストに対して不安を感じると思います。TDDは「不安をテストにする」とか言いますが、そもそもテス
「プログラマが体験するべき50の危険なこと」と「きのこ本」 - 日々常々
「プログラマが体験するべき50の危険なこと」 - Togetterまとめ*1 プログラマが体験するべきではない50の危険なこと - Life like a clown はてなブックマーク - Togetter - 「「プログラマが体験するべき50の危険なこと」」 あるあるネタです。よくある危険な体験談なので、共感を得られるのも当然だと思います。ですが、単に並べるだけでは苦笑やネガディブなネタになってしまい、何も改善されません。 笑って済ませるのは悪です。そんなの皆わかってるでしょうけど、改めて「そんなもの」にしてしまわないように意識して欲しいと思うのです。どこが危険であり、どう改善するべきか。また、なぜそのような事が行われるか。そして実際体験する事になった場合の対処等に展開できたらいいなと思っています。最終目標はこれらの多くを無くす事です。こんな事、体験させるべきじゃないんです。 発端 子
凝ったコードは凝っているように見えない - 日々常々
新しい技術を使ったり凝ったコードを書くとメンテするのが大変。新しく入ってくる人でも分かるように書く必要がある。 この意見に対する上手い切り返しが出来るようになりたい。— Hidari。 (@Hidari0415) 2012年12月27日 "凝ったコード"……はどうだろう。 コードを書くことに凝るのはいい。でも、出来上がったコードが "凝っている" なんて言われるのはよくない。なぜなら "凝っている" と言われるコードは、おそらく "巧妙なコード" になっているから*1。そう言うのは得てして読みづらくて、凝りを解きほぐさないと理解しづらかったりする。そのようなコードは書くべきではない。コードの可読性から来る理解の容易さが全てじゃないが、他の条件がすべて同じ場合、読みやすいコードを書いた方が良いに決まっている*2。 コードのメンテナンスは書いた瞬間から始まっているし、その場しのぎは長生きするも
Java SE 8 で入る Lambda の構文は新しいメソッド用と言うわけでもなく - 日々常々
Java SE 8 でようやく Project Lambda が入ります。何が嬉しいかってーと内部イテレーターですね。内部イテレーターってそのオブジェクトの中でぐるんぐるんするんで、外からは「この処理をしてくださいな」と渡す必要があります。それを簡単に書けるようにしたのが Project Lambda の構文。よくfilterとか新しく追加されるメソッドと一緒に紹介されますが、それだけでもありません。 現行のJava*1でも、何らかの処理をするインスタンスを渡せば出来なくはないんですが、やっぱりなんだかんだで面倒くさくございます。たとえば Collections#sort に渡す Comparator とかがそれにあたります。こういうの。 メソッド引数に new Comparator とか出てきてインタフェースを無名クラス実装して渡す。コード自体はIDEが適当に埋めてくれるので書くのはそれ
第1回 関数型言語勉強会 大阪に行って話してきた感想とか #fpstudy - 日々常々
なごやがおとなしくてこわかったです。 第1回 関数型言語勉強会 大阪 : ATND 第一回関数型言語勉強会 大阪 まとめ #fpstudy - Togetterまとめ 関数型言語勉強会と銘打たれ、入門編として行われたイベントに参加、LTしてきました。 参加対象者：関数型言語に興味がある人。初学者〜中級レベル と言うことで、私はHaskellのインストールからhspec、HUnitを使ったテストを紹介してみました。スライドは適当にスペース借りて置いてみた。SphinxのS6です。Safariで大雑把に調整したせいかChromeでみると微妙に文字のサイズが残念、まーいいや。 関数型言語勉強会 大阪 LT 先に断っておきますが、私はHaskellに手を出たのは今月からです。文法をシャキョって*1、とりあえずxUnitだろーとHUnitに手を出したものの、なんか微妙だなーと思ったところにhspec
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
