タグ

コードに関するmather314のブックマーク (7)

  • 【書籍発売のお知らせ】レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

    著者/訳者:David Scott Bernstein、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士出版社:オライリージャパン発売日:2019-09-18単行(ソフトカバー):300ページISBN-13:9784873118864ASIN:4873118867 書は、David Scott Bernstein氏の『Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software』の全訳です。 著者のDavidはMicrosoftやIBMを含むさまざまな企業での開発経験をバックグラウンドに持つ、特にアジャイル開発における開発者向けの教育に情熱を注いでいる独立のトレーナー/コンサルタントです。 日にも、2019年のDevOpsDays Tokyoでの基調講演やScrum Allianc

    【書籍発売のお知らせ】レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • クソコードはエンジニアを貧乏にする|ミノ駆動

    何が書かれているのか理解が難しく、イレギュラーな方法で裏技的に実装され、ちょっと触ればバグと化す、クソコード。 プログラマ諸氏なら誰しもが見たことのあるクソ忌々しいアイツだ。 クソコードはエンジニアを貧乏にしてしまう。 なぜ貧乏になってしまうのか、その理由について、怒りをぶつけながら以下に書き連ねる。 記事の構成■理由①:プロダクトが利益を出せなくなる ■理由②:エンジニアが資産蓄積できなくなる (←ココ重要) ■クソコードを滅ぼし豊かになろう ■ソフトウェア開発に携わる方々へ 理由①:プロダクトが利益を出せなくなるまずこちらの理由は簡単だ。3項目に分けて説明する。 【クソコードは読みにくい】 どんなロジックなのか理解が容易ではない。ロジックそのものは簡単であっても、tmpと名付けられた正体不明な変数、非推奨なAPIによる意図不明な実装などにより、読み解くのを難しくさせてしまう。 「クソ

    クソコードはエンジニアを貧乏にする|ミノ駆動
    mather314
    mather314 2019/08/16
    同意。 / "もし経営者であるあなたがソフトウェア開発に投資し、利益を最大化したいと願うならば、設計品質の知識に明るいエンジニアを高給で雇うべきだ。"
  • プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列

    ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます! と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ

    プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
  • フリーエンジニアのIT案件ならレバテックフリーランス

    2016年11月3日(祝)、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 <この記事の要約> 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい

    フリーエンジニアのIT案件ならレバテックフリーランス
  • ミニマムリリースを意識していたらコードが肥大化していた話 - 弥生開発者ブログ

    Misoca開発チームの黒曜です。 仙台へ温泉旅行に行ったついでに、アースキャンディが一時期話題になっていた仙台市天文台に足を伸ばしてみました。 常設展示やプラネタリウムも良かったのですが、なにより口径1.3mのひとみ反射望遠鏡が大迫力で素晴らしかったです。 夜は温泉宿へ行ったので観望会には参加できなかったのが残念でした。 Misocaならリモートワークができるので、いっそ仙台に長期滞在してみようか… 受発注機能とミニマムリリース さて、Misocaでは最近、受発注に関する機能を強化しています。 このブログを書いている時点で見積書をメールで送信すると、サイト上で見積に関するやりとりや発注を行えるようになっています。 しかし、受発注に関する一番最初のリリースは「通常の見積書受信画面に発注ボタンが出て、発注通知を送れる」というだけの大変シンプルなものでした。 受発注に関する機能はなるべくミニマ

    ミニマムリリースを意識していたらコードが肥大化していた話 - 弥生開発者ブログ
    mather314
    mather314 2016/03/23
    “小さな機能追加では実装が楽な場所に追加してしまいがちですが、ある程度の規模に育ったタイミングで適切な場所に移すよう心がけていきたい”
  • きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません

    「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか?」という質問を受けたので、「はて?どうしているだろうか?」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス

    きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
  • よいコード、わるいコード

    論文紹介:MeMViT: Memory-Augmented Multiscale Vision Transformer for Efficient Lon...Toru Tamaki

    よいコード、わるいコード
  • 1