技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに本番リリースしました。 「それってテストいるんですか？」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi
4年の開発が積み重なったアプリへのリファクタリング手法
複雑なビジネスルールに挑む：正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts
ReactComponent のリファクタリング指針 - freee Developers Hub
エンジニアの id:t930 です。 freee Developers Advent Calendar 2017 19日目いきます。 React はその名前を聞くようになってから3年以上が経過し、Webアプリケーション開発の文脈においてはもはや枯れた技術と言えるでしょう。会計freeeでも2015年ごろに Backbone.js から React へのリプレースを行い、現在では Reactコンポーネントだけでも900近いファイルが存在しています。当然このような規模でやっているとリファクタリングも必要になってくるわけで、本記事ではそんな中で得られたReactコンポーネントにおけるリファクタリングの指針について紹介していきます。1 適切な単位に分割する React に限った話ではないですが、巨大で見通しの悪いコンポーネントはメンテナビリティや再利用性の低下を招きます。表示領域、責務、意味付けに
Swift リファクタリング実践 Tips1 - Qiita
label.text = { if /* condition */ { return "a" } else if /* condition */ { return "b" } else { return nil } }() この処理の意味するところは「label.text の値を条件に応じて設定している」なのですが、before の場合、「何か条件分岐してるな」などの伝えたいことの本質とは少し外れたステップを読み手に"最初"に考えさせてしまいがちです。 「ぞれぞれの条件のとき、何がおきるのかな」→「なるほど。label.text の値を設定しているのだろう。いや、もしかして、label.text ではないものに対しての処理も紛れてないか？」→「紛れもなく、label.text の値を設定しているのだ」と、心配させてしまうかもしれません。 一方、after のようにすると、その処理群が何をし
Swiftのコードレビューの時に確認しているポイント24選 - Qiita
概要 「自信が無いエンジニアこそコードレビューをするべき」なんて偉そうな記事を書いてから 半年が過ぎた今日この頃、コードレビューやリリースを繰り返し、これはレビュー時に確認しておいた方が良いな、と思った項目をまとめます。 こういうポイントも見たほうがいい！などあれば是非コメントでご意見頂きたいです！ レビューポイントは自分の中で大まかに分けて以下の2つにあります。 クラッシュ、不具合系 リファクタリング系 この枠に沿って、ポイントをまとめていきたいと思います。 コードレビュー時に確認しているポイントまとめ クラッシュ、不具合系 外部からのAPIを使う時にレスポンス内容がおかしいときを考慮してハンドリング出来ているか？nilが許容出来ない作りになっていないか？ 配列操作で配列の操作外を指すようなコードはないか？ OSVersionの違いで落ちたり、画面が崩れるようなコードは無いか？ バックグ
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
気軽にコードレビューするならGitHubではなくRefactor.ioでも良いと思った - Qiita
2016年に流行りそうだけどまだ殆ど知られていないエンジニア向けサービス10選を見ていたら、Refactor.ioというサービスがあって気になったので軽く使ってみた。 https://www.refactor.io/ Refactor.ioとは コードレビューやリファクタリングを気軽に依頼できるサービス。依頼したいコードを投稿するとレビュー用のページが作成され、そのページのURLを依頼者に共有、もしくはそのページを訪れた人にコードレビューやリファクタリングをしてもらう事ができる。 何ともシンプルなUI。画面右上に「GitHub Login」というリンクがある通り、GitHubとも連携出来る。連携の設定をしておくことで依頼したコードにコメントが入るとその旨をメールで受け取ることが出来る。対応言語は以下の通り。 ・JavaScript ・JSX ・CoffeeScript ・LiveScrip
Swift Code改善tips - Qiita
swiftらしいコード書けるように最近ずっとリファクタリングしてて、正しいかどうか自分もわからないけど、一応自分いいと思ったtipをまとめたいと思います。 Stringよりenumを使う 例: stroyboard からview controllerを取得 let searchChannelListViewController = UIStoryboard(name: "Search", bundle: nil).instantiateViewControllerWithIdentifier("SearchChannelList") guard let searchChannelListViewController = searchChannelListViewController else{ return } Stringのデメリット: nilではありえないとわかったとしても毎回nil判
5524行→233行リファクタリング！！！ はてなフロントエンドの秩序を支えるスピリット #nodefest #nodefestB
【2023/12/20】【更新】まとめ作成時のツイートの取得や投稿にエラーが表示される場合がありましたが、現在復旧しており正常にご利用いただけます。ご迷惑おかけいたしました。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
リファクタリングを助けるGitHubのScientist
良いコードとは
フロントエンドに秩序を取り戻す方法 〜はてなブログ編集画面をリニューアルするためにやったこと〜 // Speaker Deck