技術戦略策定のための Fact 収集術 - スタディサプリ Product Team Blog
こんにちは。@chaspy です。プロダクト開発部の技術戦略グループのマネージャをしています。 技術戦略グループでは、日頃開発する上での課題の投げ込みや議論、解決するための計画をボトムアップで行っています。技術戦略グループの活動については過去のアウトプットもご覧ください。 blog.studysapuri.jp また、本稿のテーマである、組織やシステムの状況を把握するための Fact 収集については技術戦略 DevOps WG が担当しています。以前発表した資料もご覧ください。 このように、技術戦略グループではエンジニア1人1人が課題だと思うことを表明、宣言し、その課題をトリアージすること、および課題を評価するための Fact の発見・提供を行う仕組みが組織としてボトムアップで行える状態になっています。一方、開発部長として、事業戦略と結びつける形で技術戦略を策定する際には、現場のエンジニア
レガシーシステムをDockerコンテナ化する場合に直面した4つの壁 - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。 このプロジェクトで「WEBアプリケーションのDockerコンテナ移行」にまつわる検証を進めているので、その中間報告を共有しようかと思います。 本検証での想定環境 CIに不必要な部分は後回し 既存アプリでコンテナ化の障害になった部分 OSコマンドを利用している ミドルウェアとの密結合 オンライン系とバッチ系の密結合 ひとまず目指す状態 プロセス相乗りの影響 ログが複数出力される まとめ 続きの記事も書きました。 tech
新入社員ソフトウェア研修「レガシーコード改善ハンズオン」を実施しました！ - NTT Communications Engineers' Blog
こんにちは！ 今年もう2ヶ月ほど経ちましたがまだまだ寒い日が続いていますね。 イノベーションセンターの原田です。 本日は2021年11月頃に実施しました新入社員研修の取り組みについてご紹介します。 研修の概要について このハンズオンは新入社員が半年ぐらい業務に携わった頃に おそらく対峙する or したであろうレガシーなコードについて、 どのように立ち向かうべきか?を5日間チームで手を動かしながら学習していただく研修です。 この研修には2つのゴールがあり、1つ目が「レガシーコードを安全に変更するための土台作りの方法を学ぶ」、2つ目が「どのようにレガシーコードを戦略的に改善していくか意識付ける」です。 受講生は 20 名で、2021 年度入社以外の社員も数名参加しました。 また講師・メンターを社員7名が担当し、 研修は全体を通してオンラインで行いました。 下記は全体のスケジュール表になります。
週刊Railsウォッチ（20200630後編）Shopify流テスト削減、仕様化テストでレガシーコードと戦う、PostgreSQLのarray_agg()ほか｜TechRacho by BPS株式会社
2020.06.30 週刊Railsウォッチ（20200630後編）Shopify流テスト削減、仕様化テストでレガシーコードと戦う、PostgreSQLのarray_agg()ほか こんにちは、hachi8833です。ruby-jp Slack、ひと頃より落ち着いてきた感ありますが、油断すると未読たまりますね😅。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 ⚓Ruby ⚓実行するテストを減らして「ときめく」には（Ruby Weeklyより） 元記事: Spark Joy by Running Fewer Tests – Shopify Engineering つっつきボイス: 「お、Shopifyの記事」「動的解析やらいろいろ
「レガシーフロントエンド安全改善ガイド」を商業出版します #技術書典 - memo_md
※2019/11/8: 無料サンプルと目次を記事内に追加しました。 2019年4月に開催された技術書典６で頒布した「レガシーフロントエンド安全改善ガイド」ですが、このたびインプレスR&D社さまより商業版を刊行することになりました。 自分が商業版の技術書を書く日が来るとは思わなかったのでビクビクしています。 メディア: この商品を含むブログを見る nextpublishing.jp 表紙イラストは同人版と同様、鍋料理さんに描いていただきました。「安全な感じで！」という相談から、カワイイ工事現場が仕上がりました、とても気に入ってます。工事現場本と呼んでください。 タイトルに「迷わない！困らない！」という強気ワードが付いててちょっぴり恥ずかしいですが、迷わず困らない内容になってる・・はずです！ 同人版との違い / 加筆・修正した点 紙の本で比較すると、ページ数が110ページ程度→200ページ超と
レガシープロジェクトを引き継いだ時、最初にするべき７つのこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 営業一課で使っている PHPアプリを保守してくれないかな？ ○○さんが１人で作ってメンテしてたやつなんだけど 皆さんは上司からこんな仕事を振られたことはないでしょうか？私は過去に何度か経験した1のですが、こういった仕事はなぜか： 正確な仕様を知っている人はいない（知ってた人は辞めた） テスト計画書・デプロイ手順書・仕様書といったドキュメントは無い ソースコードはもちろんスパゲッティ でも、業務ではガッツリ使われているので廃止できない というレガシープロジェクトばかりでした。この記事では、レガシープロジェクトを引き継いでしまった時に、最初
レガシーなフロントエンドコードを整理するためにどう立ち向かったか - Misoca開発者ブログ
2エントリ連続でこんにちは、@mugi_unoです。 名古屋には台湾ラーメンイタリアンという名物があるそうです。 富山県民の私には理解が追いつきませんでした。 フロントエンドでの金額計算処理 さて、Misocaは請求書作成サービスなので、金額計算処理が欠かせません。 フロントエンドも例外ではなく、消費税額や合計額を算出するロジックが存在します。 機能変更が必要になった!! 諸事情により、そのロジックに変更を加える必要が生じました。 長くプロダクトを支えてくれていた存在ですが、内容的にはいわゆるレガシーなコードで、たびたび開発者ミーティングでも課題として挙げられることがありました。 git log で確認してみると、該当コードに対しての機能的な変更は2015年の冬から行われていません。 何が問題だったのか？ DOM操作と計算ロジックの混在 Misocaでは、新しくコードを書く際はVueやRe
legacyシステムからGoogle Cloudへの道のり - Qiita
GYAOのtsです。 我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。 経緯 今回も前回と同じ少し脱線です。 ある大企業の話だがコンテナ技術や、仮想化技術を完全にオンプレミスで使用しているが、 かなり独自拡張もされており、使いにくく保守もしにくい状況。且つ、申請ベースな部分が細かく残っており、何か「ものづくり」をする際に結構な時間を要する。正確には時間を要すると言うよりかは、手順が多くて面倒くさい。 下記は何かシステムを作るときのざっくりとした例だが ポート開放依頼・・・事前に登録依頼（依頼自体は10分くらい） DNS登録依頼・・・事前に登録依頼（依頼自体は10分くらい） アプリケーションアカウント作ってシステムに登録しておく・・・5分くらい 社内ネットワークからのみアクセス可能な仮想サーバーの調達（例え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
