「メリハリのある TypeScript」で運用しながら型安全性を高めやすい TypeScript リプレースを行う - Mobile Factory Tech Blog
こんにちは、21 卒エンジニアの id:d-kimuson です。 モバイルファクトリーでは、最近のプロダクトではフロントエンドに TypeScript を採用していますが、僕がアサインされているプロダクトは歴史が長く JavaScript で書かれていて、今回 TypeScript へのリプレースを行いました。 既存プロダクトの TS リプレースではしっかり型付けすることは難しいので、型チェックオプションを緩くしてリプレースすることが多いと思います。しかし、既存コードからリプレース後のコードまで全て型安全性が担保できなくなってしまうので、後からの strict 化は非常に大変になってしまいます。 今回のリプレースでは、型チェックオプションは緩くしない代わりに @ts-nocheck や @ts-expect-error を使用することで、段階的に型安全性を高めやすい形でリプレースを行いま
PR TIMESにおけるリファクタリングデー | PR TIMES 開発者ブログ
こんにちは、業務委託でPR TIMESにJOINしているuzulla (”うずら”, twitter, GitHub)です。本エントリではPR TIMESで行っているリファクタリングデーについてお話したいと思います。 リファクタリングデーとは？なぜ必要か？ PR TIMESは歴史あるサービスです。サービス・機能は追加され、削除され、結果古いコードが大量に存在します。今後もスピード感を維持しつつ成長を続けるためにはそれらの整理・改善・削除、つまりリファクタリングが重要なことはいうまでもありません。 日々の業務においてリファクタリングが行われていれば問題ありませんが、日々サービスの成長にフォーカスしていくとやはり後回しになりがちで、タイミングを失います。 その為に「リファクタリングデー」という「リファクタリング作業を定期的に実施する日」をとりきめて実施しています。現在は月に一回程度開催され、３
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回
税理士ドットコムにおける技術課題への取り組み｜飯沼遼
この記事は、弁護士ドットコム Advent Calendar 2019 - Qiitaの8日目の記事です。 僕が所属する税理士ドットコムにおいて、技術的課題への取り組みとして行っている「カイゼンスプリント」についてご紹介します。 弁護士ドットコムの技術課題への取り組み税理士ドットコムにかぎらず、弁護士ドットコム株式会社では、各事業部でそれぞれに技術課題に取り組んでいます。例えば弁護士ドットコムではTechFocusDayといって毎週金曜日に技術的な課題の解消を、CloudSignでは1/5ラボとして技術的課題に関わらず各々が為になることに挑戦しています。このように、弁護士ドットコム株式会社は組織として課題に対して向き合っています。 税理士ドットコムの背景税理士ドットコムの開発チームは、他の事業部に比べて比較的人数規模が小さいです。エンジニア1人、デザイナ1人、そして業務委託のメンバーが6人
ソフトウェアエンジニアは事業を壊すかもしれないという話 - mya-ake com
この記事についてこんにちはみゃけです。 この記事はbosyu Advent Calendar 2019の24日目の記事です。 もうアドベントカレンダーも終わりますねー。 このタイトルで記事を書こうと思った背景タイトルは「ソフトウェアエンジニアは事業を壊すかもしれないという話」です。 そのまんまの意味でソフトウェアエンジニア（長いのでこの記事ではエンジニアと言ってしまいます）は会社の事業を壊したり、止めたりという原因に成りかねないという話です。 けっこう大それたタイトルなんですが、ここ数年しみじみと感じているので一度記事として書いておきたいなと思いました。 Webサービスやアプリなどを事業としているほとんどの会社にはエンジニアが在籍していて、日々そのサービスの開発をしていると思います。 満を持してサービスローンチを行い、多額の資金調達を行う会社はそれなりの数が存在します。 そこから順調に業績
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
組織にテストを書く文化を根付かせる戦略と戦術 #jopf - ブロッコリーのブログ
勉強会告知ページ connpass.com 発表スライド 組織にテストを書く文化を根付かせる戦略と戦術 from Takuto Wada www.slideshare.net 発表のねらい 戦略の話と戦術の話 自己紹介 昼はコンサルの仕事をしている いろんな組織にテストの書き方を根付かせるための活動とか 銀の弾丸はない レガシーコード改善に正解はない テスト自動化は銀の弾丸ではない 導入方法にも銀の弾丸はない 導入を目的にしてはならない 状況は現場によって全く異なる 勝ちパターンはだいたいある 「t_wadaが来たから大丈夫だ」ではない ジェラルド・ワインバーグの影響図 ストレスが増えるとテストの回数が減る テストの頻度が減るとストレスが減る どうやってこの無限ループを抜け出すか ノードを増やす？ テストではなく自動テストにする＆テストが先に来るようにする ケント・ベックの提案 テストを書
6万行の大規模リファクタリングを完遂する上でPOとしてやってよかった5つのこと - Qiita
この記事はCrowdWorks Advent Calendar 2018 の2日目の記事です。 はじめに こんにちは。 クラウドワークスでプロダクトオーナーをしている 柴田 @shiba_319 です。 私の担当するWEB開発チームでは、今年6月から10月の約5ヶ月間、クラウドワークスのコア機能の一つである「仕事依頼画面」の大規模なリファクタリングプロジェクトを行なっていました。 私は、普段コードを触るのはちょっとしたスタイル修正や簡単なコード修正程度の非エンジニアPOなのですが、 今日はそんな自分が 「約6万行の大規模リファクタリングを完遂するうえでPOとしてやってよかったこと」を書きたいと思います。 4名の開発チームで大規模リファクタリングをすることになった経緯 私たちの開発チームは、当時4名チームで、クラウドワークス発注者向けのUI/UX改善を担当していました。 （構成はエンジニア2
「書き直したい」 をグッと抑えて小さな改善を積み重ねよう | Recruit Tech Blog
この記事はRECRUIT MARKETING PARTNERS Advent Calendar 2017の投稿記事です。 こんにちは、2016 年中途入社の nobuoka です。 ソフトウェアエンジニアとしてキッズリーの開発に携わっています。 先日読んだ 『「書き直した方が早い」 は 9 割のケースで間違いだった』 というブログ記事に触発され、最近考えていた 「小さな改善を繰り返すこと」 について書き記します。 意識の話に寄っていて技術的な話ではないですが、是非読んでみてご意見をお寄せいただければと思います。 後半では、実際の製品開発での取り組みも紹介しています。 伝えたいことは一つだけ。 タイトルにある通り 「どうにも手が負えないから新たに書き直したい」 という気持ちに対して、一度それをグッと抑えて小さな改善を積み重ねよう ということです。 背景 : 新しく書き直すか、小さな改善を繰り
無法地帯にテストケースを追加する時にいつもやっている戦略 - laiso
数年開発続いてるけどテスト全くないみたいなよくあるコードベースを想定。 不具合を修正する時についでにリファクタリングしてドメイン層のテストを書く。 手動テストで不具合を再現 ViewからロジックをControllerへ移動し、Viewからは値の参照のみにする 移動したロジックをController内でプライベートメソッドに切り出す。返り値を(2)の値にセットする プライベートメソッドを外に出して関数→モジュール化する (4)のメソッドに対してテストを書き、失敗するのを確認する ポイントとしては 運用的観点ではなるべく早く不具合を修正してデプロイしたいので、リファクタリングだけ別のブランチでゆっくりやる 依存がでか過ぎで解決できなさそうなど問題があれば、その時点ではテストを書くのを諦める。行動したことで学んだIssueを起票する 具体的なリファクタリング方法は レガシーコード改善ガイド (O
ペイモのリファクタリングとの戦い
割り勘アプリ「ペイモ」がリリースされて早１年。僕がペイモiOSの開発に関わり初めたのはリリース直後だった。驚くべきことに、当時、弊社AnyPayにはアプリエンジニアが誰もいなかった。 誰がペイモを作ったのか。そう、完全に外部のチームがペイモiOS/Androidを作りあげたのだ。それもおよそ3ヶ月という短い期間で。さらに、プレスリリースの日付も決まっていたので、決して遅れることは許されなかった。今、当時の仕様書を振り返ってみても、よくこれをそんな短時間で作り上げたな…となってしまう。 では、そんな短時間でこんなハードな開発を行うとどうなるのか…。ブクブクに太ってしまったViewController。APIから受け取った配列データをDictionaryにマッピングした結果期待通りの順番が保証されていないデータ群。急に登場するTableViewController。どこで値が更新されているのか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビジネス考えてるかい？事業の持続的成長を促進させるシステム設計の考え方 / buisiness_purpose_system_design
GitHub - rectorphp/rector: Instant Upgrades and Automated Refactoring of any PHP 5.3+ code
リファクタリング 目的・パターン・思考 / reprotech