リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある｢埋められない人材格差｣ →ユーザー側に必要な能力がないとプロジェクトの成功確率は落ちる
中野 仁 (AnityA) @Jin_AnityA ユーザー側とシステムを本業にしているベンダー側で組織の能力差がでるし、結果的に情報の非対称性が拡大する 外部に発注するにもユーザー側に必要な能力というのはあるし、それがないとプロジェクトの成功確率は落ちる 日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある｢埋められない人材格差｣ president.jp/articles/-/819… 2024-06-01 07:41:21 リンク PRESIDENT Online（プレジデントオンライン） ｢プッチンプリン｣の出荷停止に､ゆうちょ銀行の入金遅延…日本企業でシステムトラブルが相次ぐ根本原因 SIerとユーザー企業の間にある｢埋められない人材格差｣ 江崎グリコのシステム障害によりプッチンプリンなど一部商品の出荷が停止している。4月にはゆうちょ銀行で入金遅延が起きた
あなたはプロジェクトリーダー。いまはプロジェクトのピーク。あるメンバーに「この作業お願いしてもいいですか？」と聞いたら「嫌だって言ったらやらなくてもいいですか？」と言われました。なんて返しますか？？→あるあるすぎて、骨身に染みる
わんこPM @dx_saru あなたはプロジェクトリーダー。いまはプロジェクトのピーク。あるメンバーに「この作業お願いしてもいいですか？」と聞いたら「嫌だって言ったらやらなくてもいいですか？」と言われました。なんて返しますか？？ 2024-06-20 22:57:00 わんこPM @dx_saru ゴリ押し、説得、下から相談（負けて勝つ的な）、諦め… いろいろですよね このときは、忙しいなかで「お願いできない？」という疑問形にちょっと反発したかったようです。どうせやらせるくせに聞くなよ！みたいな。正面から「お願いします」で良かった。 これに限らず、納得するまでやってくれない職人かたぎの人がいたり、とりあえず拒否から入る人がいたり、それぞれで。一回断られたくらいで折れない心を持ってないとやってけないですね🙁 2024-06-21 07:53:47
「わし詳細設計書書くのやだよ」システム開発で細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない話に賛否両論
しのゆ𝕏酒くずエンジニア @shinoyu 新宿で社長やってるソフトウェアエンジニア18年生のおかまちゃん / 💻技術🎧 V系 🎀ロリィタの人 / 170スペ110 スプリング、骨ウェーブ、顔ソフエレ / 絡みない鍵とスパムは🚫 / 原則IT関連業のみフォロー /たまに会えるかも @shinjukudist しのゆ𝕏酒くずエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書
PHPerKaigi 2024の登壇資料です。
HTML HTMLの仕様策定には複雑な歴史があります。詳細は他の解説記事に譲りますが、簡単に述べるとW3CとWHATWGのダブルスタンダード状態が長い間続いていました。2022年現在はWHATWGによってLiving Standardとしてまとめられた仕様が実質的な標準となっています。Living Standardという名前が示す通り、バージョンはなくエディターによって随時更新されています。 CSS CSSの仕様はW3Cが策定しています。現在は、CSSとして1つの標準仕様があるわけではなく、数多くのモジュールに分かれて標準仕様の策定が進められています。草案、勧告候補などを経て勧告に至るプロセスと、Levelという概念で整理されたバージョン管理が特徴です。年に1度、SnapShotとしてその時点での標準化の概況が公開されています。 JavaScript JavaScriptは主にWebブラウ
プログラミングの条件式で、>= や <= の比較演算子がロジックに含まれる時にロジックのテストで「値が等しいケース」を書かない人には、重要な設計を任せられない話
悉生 游漩 @StewEucen The creator of x-ninja a new JavaScript front-end framework. 「悉生 游漩」「Stew Eucen」の読み方は「しちゅう ゆうせん」です。「ゆうせん」と呼んでね。 Please call me "Eucen" :) x-ninja.org 悉生 游漩 @StewEucen プログラミングの条件式で、>= や <= の比較演算子がロジックに含まれる時。 其のロジックのテストに「値が等しいケース」を書かない人には、重要な設計を任せてはあきませぬ。 （・ω・）＜おわかりか 2024-06-27 16:54:42
システムの要件定義をやってると、「これ、そもそも業務を整理した方が良くないですか？」みたいな場面に遭遇することが良くある→様々な要因で結局整理できない
ℍ𝔸𝕃＠猫と個人開発 @HAL1986____ システムの要件定義をやってると、「これ、そもそも業務を整理した方が良くないですか？」みたいな場面に遭遇することが良くある。 で、いろいろ話を聞きながら、あるべき形を模索してみるんだけど、「ここはこういう事情が」「ここは顧客が対応出来ない」「ここは法律でこうなってる」とか、結局大して整理できずに終わることが多々ある。 「なぜこの業務に落ち着いたのか」と言うところは、周りから見ただけでは分からないので、安易に批判するのは良くないなと感じている。 2024-06-04 06:57:54
仕様書を書くしごと - トレタ開発者ブログ
こちらはトレタAdventCalendar2023 18日目の記事です。 qiita.com こんにちは、トレタでトレタO/Xという飲食店向けモバイルオーダーのプロダクトマネージャーを行なっている北川です。 前回の記事で私がプロダクトマネージャーとして日頃行っている仕事内容について書きましたが、今回はプロダクトマネジメントの仕事の中で半分くらいの割合を占めている仕様書を書くというドキュメンテーションについてまとめたいと思います。 とはいえ、今のやり方がベストプラクティスとはまだ考えておらず日々アップデートをしつづけている最中です。ドキュメンテーションのやり方は組織や人によって千差万別だと思うので、あくまでも一つの例としてドキュメントライティングをしている人の参考になればと思います。 toreta.in TL;DR この記事では以下の内容について記載しています。 合意形成のために書く仕様書の
swaggerとは 古の時代、API仕様書はwordやexcelで表現され、各所に共有されるというのが一般的でした。 ですが近年、API仕様を表現する際にはswaggerを利用するのが最も効率的で、保守性が高く、世間一般で仕様化され、見やすいというのもあり、一般化されてきたのではないのでしょうか 今回はそんなswaggerの書き方について、まずは書くために覚えておきたいポイントを解説していこうかと思います！ どう書いてくか swagger editorで書く 公式がWeb上に提供しているツールを利用し、すぐにでもswaggerの執筆が可能となっています！ なにをインストールする必要もなく開始1秒で利用できるので、私も重宝してます なお、ページを開くとサンプルAPI仕様がすでにある状態でのスタートとなり、記法の参考などにもなります vscodeで書く 必要なプラグインをインストールし、vsc
京 @honnokoto_kaku #読了 #安藤広大 さん 『とにかく仕組み化』 性弱説と属人化の危険性を前提に、仕組み化の有効性を説明した本。 「人を責めるな、ルールを責めろ」が組織を形成するためにいかに合理的か理解できる 章ごとに復習があるのと、Web記事のように改行が多いのも読みやすい理由の1つだと思いました pic.twitter.com/wmTNks1JfN 2023-06-13 13:51:49
システム開発における外部設計書（基本設計書）の作り方について、まとめてみます。 文字だけだと分かりづらいので、個人的なメモ書きです。 機会があれば、テンプレートを作れたら良いなと思います。 大事なポイント「相手に伝わっているか」 これに尽きると思います。 伝わるか、という意味では設計書はドキュメントなので、伝わりづらいと思います。 なんだか矛盾していますが、最低限必要な仕様をまとめておく必要はあると思います。 1.業務要件 ユーザーがシステムを開発したい目的、要件をまとめます。 システムを開発する際には、ユーザーの要件がベースになります。 ・背景と目的 なぜシステム化が必要なのか？ システム化に何を期待するのか？ といったあたりを記載します。 ・用語の定義 システムに関連する用語をまとめます。 ・業務の概要 業務の概要は要件定義をして、ユーザーからヒアリングします。 業務要件定義書を作って
『プロジェクトのトラブル解決大全』⇒「まずは腹をくくれ。とか書いてあるけど、かなり泥臭くリアルに「取るべき行動を具体的」に書いてくれてるので、良い感じ。読み終わったら、ペライチにして時々見返そうと思ってます」
ざき@IoTエンジニア @zaki134rp プロジェクトのトラブル解決大全 本日の新幹線のお供 まずは腹をくくれ。とか書いてあるけど、かなり泥臭くリアルに「取るべき行動を具体的」に書いてくれてるので、良い感じ。 読み終わったら、ペライチにして時々見返そうと思ってます。 pic.twitter.com/66OAuWSumn 2022-11-06 08:55:42 もとやま📚著書『投資としての読書』 @ysk_motoyama プロジェクトの火消し術において比類ない本『プロジェクトのトラブル解決大全』 実に86もの火消し術が紹介されていますが、特に実践するなかで効果を痛感した学びが3つあります。 学び1：思考停止せず、とにかく書く 学び2：消火の仕組みを作る 学び3：嫌われる覚悟で関係者と接する 学び1：思考停止せず、とにかく書く ━━━━━━━━━━━━━━━━━━ 本書では86個ものテ
アプリ開発における画面遷移図の作成方法｜Sho
事業計画ツール、LPと作成してきたのでより具体的なイメージを作成するためにアプリケーションの画面遷移図を作成します。 色々なツールがありますが、個人的に一番簡単なもの（draw.io）を説明します。 目的から考える画面遷移図を作る目的 ・ページごとに作成することで全体のイメージが作れる ・仲間との意識の共有ができる ・各ページの関係性・機能を明確化することで抜け漏れを防ぐ などがあります。加えて、どこまでやるか ①画面遷移図でデザインまで考える ②画面遷移図ではイメージ共有に止める どちらにするかにより、使うソフトが変わります。 ①画面遷移図でデザインまで考える場合 方法はadobe XDなど有名なもの含めて色々ありますが、無料の範囲内ではfigmaがオススメだそうです。 上記のような綺麗なデザインと共に、アプリのイメージを作ることができます。作成後にCSS(デザイン用のコード)に変換する
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パフォーマンスを改善するには仕様変更が1番はやい
AIが「理解」するから、API仕様書のコピペでアプリができあがるローコード開発環境「Flowise」を試す【イニシャルB】
HTML, CSS, JavaScriptの標準の仕様書はどこにあるのか
今日から始めるswagger入門（最低限書けるようになる） - Qiita
『とにかく仕組み化』⇒『「人を責めるな、ルールを責めろ」が組織を形成するためにいかに合理的か理解できる』
外部設計書（基本設計書）の作り方｜スペ@リモートワークのシステムエンジニア