PuppeteerでいらないCSSを消す
@pirosikick の発表資料です。 https://mentaico-js.connpass.com/event/132416/
@pirosikick の発表資料です。 https://mentaico-js.connpass.com/event/132416/
jqのGo実装 gojq を作りました！ ― スタックマシン型インタープリタによるイテレータセマンティクスの実装 - プログラムモグモグ
jqはとても便利なコマンドです。 JSONを返すAPIを実装するときや、SaaSのAPIから特定の情報を抜き出してシェル変数に代入するときなど、web開発や運用には欠かせないツールとなっています。 しかし、私にとってjqのクエリを一発で書くのは容易ではなく、思い通りの出力が得られないことがよくありました。 難しいエラーメッセージに悩まされて、jqで書くのを諦めて別の言語で書き直すこともありました。 jqの十八番と思える場面で使いこなせないのは、なかなか悔しいものがあります。 ツールを使うのが難しいなら、同じものを作ってしまえばよいのです。 jqの全ての機能を実装する jqを言語としてきちんと書けるようになる jqを完全に理解する jqの全ての機能を自分で実装してしまえば、jqがどういうものか、クエリがどのように処理されるのか、詳しくなれるはずです。 jqを得意な言語と言えるようになって、ク
はじめに チーム開発でシェルスクリプト（特にBash Script)を書く際に守るべきルールをまとめます。 シェルスクリプトのコードレビューをする際等にお役立てください。 スクリプト名 -区切りの小文字英数字（いわゆるkebab-case）をつける。拡張子は.sh. これは特に理由があるわけではないので_区切りでもよいし、チーム内にzshやfish等の他Shell愛好家がいる場合は拡張子は.bashでも良い。どちらにせよチーム内では統一しておかないと混乱の元となる。 改行コード LFを使用する。CRLFだと動作しないので書く際に間違うことはないが、Windows上のgitのautocrlf設定によってはご丁寧にCRLFでチェックアウトされてしまう。 避けるためにはgit config --global core.autocrlf inputとするか、.gitattributesをレポジトリ
良いコードの書き方 - Qiita
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
2022年5月15日(日)に開催されたSRE NEXT 2022 Day 2の登壇資料です。 ▼SRE NEXT 2022オフィシャルサイト https://sre-next.dev/2022/ ▼発表の概要 https://sre-next.dev/2022/schedule#jp20
なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ システム開発会社「アクシア」の代表として、自社・他社含め、さまざまなエンジニアのコードを読んできた米村歩さん。そんな米村さんの持論は、「コードの可読性は生産性に多大な影響を与える」ということ。可読性の低いコードはどんな弊害をもたらし、どうすれば改善できるのか――。チーム開発を効率化するコードの「可読性」について綴っていただきました。 プロフェッショナルのエンジニアには、「可読性」の高いコードを書くスキルは必要不可欠です。単に目的とする処理が実行できればよいわけではありません。しかし実際の開発業務の中では、可読性は意外と軽視されてしまいがちです。 経験の浅い駆け出しのエンジニアにとっては、可読性の重要さを肌感覚で理解するのは難しいかもしれません。また、新人エンジニアに対してプログラミング言語や開発ツールについて
【資料公開】レガシーコードからの脱却
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエピソードとコードをプロダクトオーナー（引き継ぎ前のコードを書いた本人）の許可を得て使用しています。登場するコードは全て本物、登場するデータは講演用の架空のものです。
はじめに こんにちは。コミュニケーションアプリ「LINE」の Android クライアントチームの石川です。 先日、コードの可読性についてのプレゼンテーション (https://speakerdeck.com/munetoshi/code-readability) を公開しました。 今後、このプレゼンテーションについてのちょっとした解説を、本ブログ上で不定期に連載していきます。 今回は、このプレゼンテーションの概要と、最初の章 "導入と原則" についての解説を行います。 このプレゼンテーションについて このプレゼンテーションは、コードの可読性を向上するためのアイディアをまとめたもので、以下の8つの章からなります。 導入と原則: 可読性の高いコードの重要性、プログラミング原則 命名: 名前の示す内容、文法、語の選択 コメント: ドキュメンテーション、インラインコメント 状態: 状態遷移の管理
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
DiscordがGoで書かれていたコンポーネントをRustに移行しているらしい。Windowsの低レイヤ層の一部で採用されるなど、近年どんどん注目を集めているRustだが、DiscordはなぜRustを選んだのか。その最大の特徴である「パフォーマンスを妨げる要素であるGCを排した上でメモリセーフな言語」であることにクローズアップした面白い内容だったので、えっちらおっちら和訳してみた。英語が得意というわけでもなく、無理やり翻訳しているところも多いのであしからず。ほとんどGoogle翻訳のままというのは内緒。 追記: 7/31にはてブでいっぱいブックマークされたみたい。気になったブコメへの返信を末尾に追記した。 原文: Why Discord is switching from Go to Rust - Discord Blog Rustは様々な分野において第一級の言語になりつつあります。Di
最新の省略テクニック、コツ、秘訣で、JavaScriptコードを最適化する。 開発者の生活というのは常に新しいことを学ぶことで、その変化についていくことは決して難しいことではありません。私は、フロントエンド開発者として知っておく必要のある省略形や機能など、JavaScriptのすべてのベストプラクティスを紹介して、2021年の生活をより快適にしたいと考えています。 JavaScript開発に長く携わっている人でも、コードを追加しなくても問題解決できるような最新機能を知らないこともあるかもしれません。ここで紹介するものは、クリーンで最適化されたJavaScriptのコード記述にも、2021年のJavaScriptの面接準備にも役立ちます。 これは新しいシリーズで、2021年版のJavaScriptコーディングチートシートです。 1. 複数の条件を持つif 配列に複数の値を格納し、includ
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
テストの自動化とテスト駆動開発
組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について
こんにちは、開発チームのアーキテクトをやっている竹野（@Altech）です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して
リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～で発表した資料です。 【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P7 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ◆P17 リーダブルテストコード / #vstat ◆P43 見てわかるテスト駆動開発 ◆P46 JaSSTレポート（過去のJaSSTの講演資料などが載っています） ◆P47 Agile Testing Condensed Japanese Edition ◆P48 A Practical Guide to Testing in DevOps Japanese Edition ◆P49 The BDD Books - Discovery (Japa
Googleのソフトウェアエンジニアリング文化
フルスタック開発者のためのBallerina: バックエンドAPI開発ガイド この記事では、REST API開発のためのプログラミング言語"Ballerina"の直感的な構文について解説します。さらに、認証や承認、OpenAPIツール、可観測性、SQL/NoSQLクライアントライブラリなど、重要な言語機能についても論じます。記事を読み終えれば、Ballerinaが次のバックエンドAPI開発の有力な候補である理由がよく理解できるでしょう。
プログラミングにおける設計力を高めるには 〜 良いコードを書くために | Social Change!
プログラミングとはコードを書くことだけではありません。どういった構造にするのか、データはどう扱うのか、どのライブラリを使うのか、いくつもの設計を踏まえてコードを書くのです。設計を表現したものがソースコードです。 設計の良し悪しは品質に影響します。では、良い設計を作るスキルは一体どうやって身につけることができるのでしょうか。プログラミング言語の文法は知識なので、独学でも学ぶことができますが、設計に関してはそうはいきません。 本稿では、プログラミングにおける設計力を高めるためにはどうすれば良いのかを考察します。ここで言う設計は、画面や仕様ではなく、ソフトウェア内部の設計ですが、抽象化するとクリエイティブな仕事全般に通じるかもしれません。 本稿の内容は「良い設計」について論じたものではなく、どうすれば身につくのかを考えたものになります。また、私たちソニックガーデンで行っている、良いコードを書ける
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
66分かかる同期処理を10分以内に短縮せよ！～商品情報同期システムでの、処理速度と運用の改善～ - MonotaRO Tech Blog
はじめに この記事では、モノタロウの基幹系を構成するシステムの一つである、商品情報管理システム（PIM：Product Information Management システム）の導入プロジェクトで、商品情報を基幹系と同期するシステム（商品情報同期機能）の性能や運用環境の改善を行った話をご紹介します。 背景 モノタロウの基幹系は、長年内製のシステムで支えられてきました。基幹系のシステムは、少数のWebアプリケーションと多数のバッチから構成されています。中でも商品情報の管理に関するシステムは、在庫や仕入先に関するシステムと一体化していて、商品情報に関する数多くのマスタメンテナンス画面を備えたやや複雑なシステムです（図１）。 図1 基幹系の概略図 当社のシステムは、もともと自分たちのビジネスに必要な機能を提供する手頃なパッケージ製品がなかったため、すべてを内製でまかなってきたという経緯があります
プロジェクトで使われている技術と ESModule の状況について UIT では、 SPA 開発のプロジェクトにおいて Vue.js と React が多く利用されており、既存の多くは Babel を利用した JavaScript で、新規のプロジェクトでは TypeScript を利用して開発が行われています。 FYI: 【LINE DEV DAY 2019 番外編】UIT Front-end Tooling Survey 2019 技術選定は勿論、プロジェクトにおける細かなコーディングルールについては、プロジェクトのコードオーナーに委ねられており、プロジェクトごとに裁量を持った意思決定を行っています。 その上で、私が携わるプロジェクトにおいては、 default export を可能な限り避けるように心がけています。 import 側の裁量で対象を自由に命名できてしまう 今回は「『Da
老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦！ 出前館の改善について和田卓人さんが聞いた - はてなニュース
新型コロナウイルスの影響下で、食の宅配などO2O（Online to Offline）サービスが好調です。なかでも有名漫才師を起用したテレビCMも話題となった出前館は、2020年8月期の連結決算で利用者数が前期比で31％増、売上高も前期比で54.6％増となりました（ただし広告展開やシステム投資などの先行投資により営業利益は赤字となっています）。 この背景に、株式会社出前館とLINE株式会社が2020年3月に締結した資本業務提携があります。LINEが出前館の経営に参画し、広告だけでなくサービスの提携も進んでいます。2020年11月には「出前館」アプリがLINEアカウントと連携し、出前館のOEMだったLINEデリマは12月にサービス統合されました。 ただしLINEでは、出前館を「LINE」アプリの関連サービスではなく、独立したO2O事業として継続的に成長させたい。そのためLINEのエンジニアを
フロントエンドにおける「単体テストの考え方/使い方」
本稿における「単体テスト」とは自動テストにおける単体テストを指します。手動テストのことではないので、ご了承ください。 単体テストの考え方/使い方という本を読みました。筆者自身、「単体テストはプロダクションコードの付属」という意識がどこかにありました。この本を読んで、単体テストについてあまりに何もわかってなかったことに気付かされ、単体テストの設計はプロダクションコードの設計と同じくらい重要という意識に変わりました。何のために単体テストをやるのか、いいテストとは、「単体」とは、など多くの点で学びを得られ、また、多くのプラクティスとアンチパターンを知ることができました。 本稿はこの本を読んで得られた学びを、フロントエンド開発、特にコンポーネント開発に適用することを試みた際のまとめです。より詳細な解説を求む方には本を手に取ってもらう前提で、できるだけポイントを抑えられるようにまとめることを目指しま
十行程度のプログラムが読めること プログラミング言語の文法を知っている 分岐とループを追いかけることができる 変数の状態変化を追いかけることができる 関数呼び出しを追いかけることができる 十行程度のプログラムを複数回書いたことがある プログラムを読んでプログラムの動的な振る舞いを想像できる プログラムの主な処理の結果を想像できる 主な処理の終了条件がわかる プログラムから主な処理を読み取れる 似たようなプログラムを書いて、動かしたことがある 既知のプログラムと読んでいるプログラムの違いがわかる イディオムを知っている イディオムを書いたことがある プログラムがどう動くか知っている 重複したソースコードを関数に抽出できる 重複したソースコードがわかる 同じ入力と出力をもつコードブロックがわかる コードブロック単位で入出力を比較できる プログラムのある機能がソースコードのどの部分に依存している
はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。本連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理
テストコードを書き始める前に考えるべきテストの話 #DevSumi / Developers_Summit_2020
以下のイベントの投影資料です。 https://event.shoeisha.jp/devsumi/20200213/session/2364/ 発表時の諸注意など http://nihonbuson.hatenadiary.jp/entry/2020/01/31/090000 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P2 Agile Testing Fellow https://agiletestingfellow.com/ P15 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf P20 概説テスト分析 http://ww
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
銀座Rails#26の登壇資料です https://ginza-rails.connpass.com/event/189892/
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
計算ファースト vs. 型ファースト / Computation First vs. Type First
Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画（第1
テスト駆動開発：実はそれは設計技術です
テスト駆動開発（TDD）は、より優れたソフトウェアを持続的に早く提供するための確立された手法です。TDDは単純な考えに基づいている。製品コードを書く前に失敗するテストを書くことです。新しい行動が必要ですか？失敗するテストを書いてください。しかし、この一見単純な考えをうまく実行するには、スキルと判断が必要です。 TDDは本当に設計のためのテクニックです。TDDの基礎は、小規模なテストを使用してボトムアップを早急に設計することであり、システムへの信頼を構築しながら迅速に何らかの価値を得ることです。よりよい名前はテスト駆動設計かもしれません。 設計方法としては、集中と単純さです。目標は、開発者が価値を提供する上で不要な余分なコードを書くことを防ぐことです。問題を解決するのに必要最小限のコードを書くことです。 多くの記事がTDDを行うことのすべての利点を誇りにしています。そして多くの技術会議の講演
シェルスクリプト リファクタリング ～遅いシェルスクリプトが供養されてたので蘇生して256倍に高速化させました～ - Qiita
はじめに ことの始まりは「シェルスクリプトでツールを作ったけど速度が遅くて使い物にならなかったので供養」というツイートを見たからです。コードを見てみると、実例をあまり見ないシェルスクリプトのリファクタリング例として丁度良い内容と分量だったため記事にいたしました。記事を書くにあたりコードの利用を快く承諾していただいた @Hayao0819 様にはこの場を借りて御礼を申し上げます。 内容は章立てで構成しており、序章で事前調査をし、第一章で一般的なリファクタリング、第二章でパフォーマンスを重視したリファクタリング、終章で少し余談をして締めくくっています。最初はパイプは並列処理されるから速くなるというのは神話（そうとは限らない）についても書いていたのですが流石に長いので分けました。それでも書きたいことを色々書いていたらめちゃくちゃ長くなってしまいましたので読み物として私がどんなことを考えながらリフ
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション（既存データの移行）、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
@herablog さん、@shunke07 さんと共に Muddy Web #3 で発表した資料です。 https://cyberagent.connpass.com/event/261115/ news.ameba.jpは5年前にデスクトップ版ではReact化、モバイル版ではAMP化が行われました。当時は最先端の技術でしたが時が経つにつれて技術的なトレンドも変化しています。TypeScriptやTanStack、Core Web Vitalsの登場によりWebフロントエンドの技術構成は日々進化しています。 時代の流れに合わせてAmebaNewsでは、脱AMP、脱SPAやTypeScript化などを行いましたので紹介いたします。
先に境地を 個人開発の場合、少ないコード・最低限のシステム構成は正義。 なぜなら、時間やお金に制限がある個人開発者にとってサービスの継続に関わる問題だからです。 例えば、自分のサービスを世に広めたいとか、一発当てたいとか、作ったサービスで生活をしたいとか、 なにか目標があるなら達成する方法は、達成するまでやめないことです。 なのでサービスを提供し続けることは最も大切なことです。 これまで個人開発者としては↓の気持ちで開発を進めてきました。 しかし、この経験の後にこの↓の名言の大切さを改めて感じることができました。 シンプルにしておけ愚か者 また、本記事本文より たくさんプラグインやモジュールを入れたシステムはメンテナンスがしんどいです。「デフォルトで使う」ということの魅力を改めて実感しています。リソースが限られている個人開発の場合、このような時間の消費は極力なくす方向にしていくべきです。
リファクタリングチームに入ってから学んだ理解しやすいコードを書くための基本的なこと - クラウドワークス エンジニアブログ
こんにちは！ 去年の４月に新卒入社してからお酒ばかり飲んでいるエンジニアのd4teです。 4月から11月まではUX改善チームにてお仕事検索画面のフロントエンド開発を担当しておりましたが、11月からはリファクタリングチームにてcrowdworks.jpのリファクタリングをしています。 現在のcrowdworks.jpの状況 過去の記事にもあるように、crowdworks.jpはサービスインから約8年が経過し、30万行を超えるモノリシックなRailsアプリケーションになってきていて、コード行数の増加量やファイル変更数の推移は年々鈍化してきています。 内部には開発生産性を低下させる技術的負債が溜まってきており、技術的な投資がしづらくなってきているという課題があります。 自分が所属しているチームは、外部から見た動作を変えずに内部のコードを整理するリファクタリングで技術的負債を解消し、開発生産性の向
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bash Scriptの作法 - Qiita
たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
コードの可読性についてのプレゼンテーション紹介 vol. 1: "導入と原則" 編
なぜDiscordはGoからRustへ移行するのか - MISONLN41's Blog
2021年に知っておきたいJavaScript最適化技術34選 - Qiita
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
テストコードにはテストの意図を込めよう #vstat
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
技術的負債は開発者体験を悪化させる - mtx2s’s blog
なぜ default export を使うべきではないのか？
プログラマにできるとよさそうなこと - @ledsun blog
どうしてあなたの共通化は間違っているのか：目次 - Qiita
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
Railsで考えるドメイン駆動設計のコアドメイン
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
10年でどう変わった? はてなブックマークでのPerlの使い方
サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal
リリースから5年、Webフロントエンドの経年劣化と向き合う
【個人開発】収益化したサービスのコードを50%以上削除して得られた境地