【IT】さらばスパゲティコード、「マイクロサービス」で分割
■ このスレッドは過去ログ倉庫に格納されています
システムを構成する機能を切り分けた「マイクロサービス」の活用が進んでいる。プログラムが複雑に入り組んだ「スパゲティ状態」に陥る事態を避けて、開発や運用を容易にする。眼鏡専門店「JINS」を運営するジンズは、あらゆるモノがネットにつながる「IoT」基盤に採用した。
【前回記事】クラウド仮想化の進化形、「コンテナ」の正体
「アプリケーションやデータの種類を柔軟に変えられるようになった」。眼鏡販売大手の…
https://www.nikkei.com/article/DGXMZO44083340T20C19A4000000/ うちのC++の1関数2万行のコードも直してください
もはや残っているメンバーの誰一人手を付けられません
大手です
こんなプロジェクトばっかです
世界で勝てるわけ無いです パソコンの背中の配線群の事かと思ったが
違うんだね。 途中途中でリファクタリングの工数と予算を要求すると蹴られるんだよな
で、ス→スパ→…→スパゲッティ、と
スの段階でリファクタリングすりゃ、最小の混乱で済んだのに スパゲティは半分に折って茹でると
食べる量が1割〜2割程度減る的なお役立ち情報? プログラムがスパゲッティなのの半分は仕様がスパゲッティだから 参照関係の洗い出しはそれほど難しくはないよ。
しかし、 コンテナ使おうが何しようがスパゲッチーは変わらんやろ… スパゲッティーしか作れない人材がマイクロサービス構築できんのか? >>3
2万行程度なら簡単そうだけど
無理だと思うなら捨てて作り直した方が早いんじゃね >>10
人間そんなに頭良くないから、最初から完璧な完成形なんて設計できねぇんだよ。
金が無きゃフェーズフェーズで90点くらいで出来上がると60点くらいになる。 何が言いたいのかサッパリわからん
プログラムの事を知らない人間が記事を書いてるのでは? ソースを全て解読しようとするから無理なわけで
ソースを機能で分解して、分解できないなら一から作って結果突合の方が精度高い >>19
お前みたいなやつのせいでいろんなことに苦労したもんだよ
分からないなら今すぐその業界をやめなさい。センス無い。 なくならないとおもうけどな
コード化する以前にどういうふうに
するかを頭にえがかなけければ
構造化のほうがましかも 業務内容を精査・整理して、作り直した方が早いだろう?
特に企業統合が多い時期なら尚更だ。
極端な話、開発費を1/2、1/3に出来る >>16
オープンソースのプログラマーの話で、まず、完璧に動くものを作り、次に、それをふまえて、ゼロから作り直すという
作業手順でやってるって話を聞いた。優秀な人でもそうなんだよ。 >>21
ファイル数増やして仕事した気になってるスパゲティならぬスカスカコードを量産するお前みたいなバカだな 相互依存関係が強いと改修コストが高い
1つ完結で小さなサービスの寄せ集めなら影響しない 現状の気ままな、アバウトな業務をある程度整理するだけでも
意思決定が速くなるという嬉しい副産物も得ることが出来る。 発注者自身が、自社の事が判らないと手の付けようがない。
勝手に進めると怒られるだろうし。
それではできませんと言う勇気が無いと後で重大トラブルになる。 masmで10万行のプログラムを作成・メンテ・サポートしてたけど、
始めから(隠れ)リファクタリングを頻繁に行い整った状態を維持すれば、
どうってことない規模だったな >>3
辞めて、さっさと他にうつれば?なぜしないの?出来ないの♪ マイクロサービスって何?って聞くと
答える人によって違うんだろうなw 再利用とどちらを優先するか
あと、粒度を間違えると大変 「旅行のご予定はいつですか?」
「夏になるか、秋になるか、2月になるかもしれません・」
「ご予算は・・・。」
「20万円になるか、ボーナスが減れば10万円で、
宝籤に当たれば50万円になると思います。」
「・・・。」 まぁ、実際WiFi系ISPのDC側制御を全てシェルスクリプトで済ませたことあるな。
インフラ屋としては、これだけ小さなプログラム群が充実してる中、
プログラマが態々専用の制御プログラム組んで工数消費してくれた挙句、
システムに余計な制限付けたり、あまつさえ不安定にしてくれる意味が分からない。
ユーザー向けのUIだけ作ってくれってかんじ。 出来上がった時のイメージをキチンと共有できるかどうかも有るしなぁ・・・。
後から、違うと言われても困るだろうから >>3
1関数で2万行って・・・
何をどうしたらそうなるのか。 あとで分析して違う言語に移し直すとかなったら、スパゲッティの方が効率よく
かつ何の誤植なり差異もなく移せると思うがねえ
なんでもかんでも細かく書くやつの気がしれん 関数なんて使わない。呼び出しだけで何クロックかかることやら。ただひたすらジャンプあるのみ。 日経記者、解ってねぇな
スパゲティによる保守性悪化の問題じゃなくて、モノリシックによる柔軟性欠如の問題
これ脱却するのはマイクロサービスアーキテクチャで、その実行運用に便利なのがコンテナ
この構造を理解せずに、コンテナ使えばプログラムが良くなると勘違いしてる馬鹿が大杉
そこで、スパゲティなモノリシックを、そのまま巨大コンテナにして、その中でマルチスレッドやらWeb三層やら動かそうとして、8コア32GBメモリとかを使う
でもって、k8s不安定、オラクル使えねぇとかで、コンテナ仮想化はまだまだ未熟だとか、偉そうに評論してる
ちなウチ、大手SI >>3
当時のコーディング担当者の気持ちを今の保守担当者に乗り移らせるしかないな
複雑すぎてソース解析ツールが停止し前代未聞の「解析不能」判定になった関数を保守したことがある
20年以上使われた1000行以上の巨大関数に潜在不具合が2件あったよ
ソースを見て移植し検証完了まで三ヶ月かかった テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00620/040900010/
必要もないのにやたらと色々手厚くして更新頻度を下げるとクソサービスになる 今頃になって「時代はマイクロサービス(キリッ」とか頭おかしいです >>24
それオレが言うところの2パスプログラミングだ。
(もしくは習作・清書プログラミング)
1パスめが洗い出し、2パス目がほんちゃん
2パス目は視点が遠くなって将来を見据えられる。 Service Oriented Architectureのパクリ バローズのFortranの
プログラムのメンテ
二度とやりたくない 今度はそのマイクロ同士がどう連携してるのかが分からなくなり
結局同じ羽目になる予感。 >>49
>>3の所に行って助けてやれ。
>>51
結局関数の粒度が荒くなっただけなんだよね。マイクロサービスって。
呼び出す側の問題がこれで解決されるとは限らない。 >>1
例えるなら 単に 外注してるだけ。 逆にその外注先が 突然 提供サービス変更したら 自社で修正や再構築するコストが発生するだけ。
小さい企業なら いざ知らず、デカい企業が サービス停止で信用を失えば 活動継続すら出来なくなる。
これ 外注するマイクロサービスの数に比例してリスクが増える。 IF ( >>1 == true ) then go to >> 53 プログラムを小分けにして、分かりやすく、バグ取りしやすくするのは昔からやけどな。
なんか目新しい事あるけ?この記事? マイクロサービスアーキテクチャはSOAの進化系
関数の粒度が粗くなったという感覚は当たってるね
それだけじゃなく、APIをなるべくステートレス、非同期にしてマイクロ同士を疎結合にし、重複呼び出しにも冪等性を持たせる部分が、従来とは違う
これをやると、性能足りない部分のスケールアウトが容易になるし、機能追加や変更も簡単になる
ただ、モジュール分割のセンスが良い人が作らないと、中途半端で再利用性が悪い似た機能のマイクロが乱立したり、入出力を変換するESBみたいなマイクロが乱立したりして、オーバヘッドばかり大きくなる
その辺りは、SOAから変わってない気がする。結局はセンスが重要。 AIでさ先人達が作ったコードを整頓して見やすくしてくれるなら有難いけど
人が作ったPGは何がどうなっているのやら 物理的なスパゲティ状態もなんとかしてもらえませんか >>57
結局いつの世もスパゲッティーを作るのは人なんだよな
理解してない人が使えばどんなものだってスパゲティーにできる
スパゲティーの魔法使いが日本にはたくさんいる マイクロサービスってなんぞ?
ってWikipedia見てきたけど、要はモノリシックでやるんじゃなくて個々のサービスを組み合わせてやるって話だな
サービスの分割とサービス間のインターフェイスがまともに作れればうまく行くと思う
性能は当然劣化するけどそれを気にしなくても良くなったから出てきたんだな プログラマーで仮想通貨で儲けられなかったやつは負け組かな >>61
ウチの場合、スパゲティ屋よりもモノリシック屋ばかりなのが課題
要求仕様ベースでの個別開発が染み付いてるもんで、内部をモジュール化するセンスが欠片もなく、やらせたら画面遷移の単位でDB操作までをやるコンテナが並んで、コンテナ間はDB共有での超密結合
結局、モノリシックから一歩も抜け出せないもので、冗長化や性能はハードの単位、要求仕様外の機能追加は無理ゲー。俺が入って丸ごと作り直し >>63
それでいいんだよ
各々が独立してるからおかしい所から直して行ける
モノリシックだと直すのも大変だしデグレード地獄もあるし >>66
一箇所直したらそこに繋がってるモジュール複数から不具合発生する光景が >>62
ここ数十年「疎結合で蜜凝縮な設計にしましょう」っていうのは
プログラミングの最初に教えられてるはずなんだが、アプリレベルではなかなか
守られてないのが実情なわけで、マイクロサービス導入したら解決するなんてのは
宣伝の中だけの話だよ。 記者がマイクロサービス分かっていない、ってのは分かった。 スバゲッティを大皿に山盛りにするから、絡まり易くなり食べるのが大変
大皿を止めて小皿に1本ずつ盛れば絡めるのが大変な位に簡単になる
でも、小皿でテーブルが溢れ、どの順番で小皿を取ればいいのか判らなくなる アーキの実力次第でどうとでもなりそうだけどな。
マイクロサービスだから優れたもの作れるわけじゃない。ちゃんとそれを使いこなせないと全く意味ないわけで。
これベンダーはiSiDのやつ?最近流行りのAWS使うサーバレスで基盤作ってるやつじゃないかな。 >>68
小さい単位に分ければ良いってもんじゃないのを、現場は経験則で判ってる
どの程度の大きさが適切か?が最大のポイント そんなに心配しなくても、近い将来AIが勝手に上手い事やってくれる時代が来るだろ
中身は完全にブラックボックスだろうけどw、ちゃんと動くなら問題ない >>71
同じ事をやってたのでは、高い金をとれない
高い金を客から取るために、時々、目先を変えて、
「今までとは違う素晴らしい方式ですよ!」のアピールが必要
何を持ってくるかは、変遷があるが、昔から繰り返される詐欺商法 >>69
日経だものw
>>56
正解、ベテランは違うw >>65
「ほら、稼ぎが増えただろ?」
って本気でも思ってる奴が多いという恐怖 >>72
ミニでもナノでもない
マイクロってことだね returnの位置を間違えてただけで3日も悩んだ俺に死角はない! >>24
うはー・・・贅沢なw
でも、それできるとかなりキレイなの書けそう 突如退職したやつが遺したコード立派なスパゲッティに仕上げてやったぜ >>67
インターフェイスがちゃんとしてたらそんな酷いことにはならないよ
>>68
性能問題があったからね
まあ関数にデータを引数で渡すのは非効率だ!
とか言ってた老害もいるからこういう概念を理解できないアホがいても不思議じゃないw クラス設計にしろ、組み込みのタスク分割にしろ、マイクロサービスにしろ、結局は作る人のスキルだと思う。 インフラが分からない開発者は
だんだん仕事が減っていくんだろうな。 >>82
ちゃんとしたインターフェースを設計してそれを保守し続けることが難しいんだよ。 COBOL構造化プログラミング
ダイクストラ、OSPF こういう小難しい事が全然わからない底辺プログラマです >>84
まあ極論だけど事実昔のプロセッサは元々の性能低いしスタックポインタからの相対アクセスが不得意だったりしたのでバッドノウハウとしては仕方がなかった面もある >>87
そりゃそうだけど、そう言う分割に関わる設計はどこかでは必要になるし >>86
コンテナPaaSになると、アプリ屋もインフラを意識して、作らなきゃならなくなるから、インフラの知識が必要
だが、インフラ屋が貴重になるわけではなく、多くのインフラ屋は逆にPaaSに仕事奪われ、少人数で済む様になる >>34
シェルスクリプト、ものすごく古い技術なのに、手練れが扱うと魔法みたいに凄いよね
残念ながら自分のような凡人プログラマには呪文にしか見えないが ある種の必然、たとえば制御構造の貧弱なプログラミング言語や初心者プログラマが関わるとそのようなプログラムが生まれる。
これは一種の笑い話と言ってもいい。
しかしこの問題はもっと本質的かつ普遍的なもので、その時点でのアーキテクチャ(CPUの性能、言語の表現力、OSの能力、
メモリ搭載量、ストレージ、ネットワーク)では賄いきれない要求が出されたときに、優秀とされるプログラマの多大な努力の結果として
余人には理解しがたいプログラムが生まれただけのことだ。美しくないだの言っている場合ではない。そうしないと仕事にならなかったのだ。
十年前やそれ以前程度ではこれは普通にあった。プロセス間通信などしていては速度が出ないよ。引数のコピーなどしていては速度が出ないよ。
仮想記憶はあるけどそれによる性能低下は困るよ。
他の世界、たとえばwebサービスはしばらくは余裕があった。しかしc10kだの言われ出して過去に否定したパラダイムをあたかも最新
技術であるかのように讃えてスパゲッティの海を泳いでいるではないか。
そしてもっとすごい奴が控えているぞ。
顧客に「このAI、こういう時だけおかしな動きをするんだ。これは不具合だから直してね。あ、運用始まっているから再学習はNGね」
と言われてニューラルネットワークのデバッグやリファクタリングをさせられる未来はもうすぐそこにある。 粒度にあわせて適切な通信方法を選びなさいと言う要請がスパゲティ化の原因。何かから何かに情報を伝えたいだけなのに場合ごとに違うやり方になってしまう。 引数でリレーしてると、もうこれグローバル変数だろ、ってならないの? スパゲティリスクを取るかセキュリティリスクを取るか ならない。下で書き換えたとしても上に影響がないのが引数の良いところ。 今あるスパゲティコードを、AIの力でマイクロコード単位に
分けてくれる神サービスじゃねえのかよ
期待して損したわ スパゲッティコードをマイクロサービス単位で捨てやすくなるだけで
今あるスパゲティコードをマイクロサービス化はしてくれないんだな。残念 トマト缶+コンソメ+塩コショーのシンプルなソースが好き 結局のところアプリケーションの人格まではサポートしてくれないわけで、
マイクロサービスの組み合わせがスパゲッティ化するというオチは回避できるのか?
なんか業務をBPRにアジャストできなくて結局使わなくなったアレコレを唐突に思い出した。 あと、要求する機能がサービスになかった場合とか、分割した結果パフォーマンス的にアウトになった場合とか。 開発に入る人数が多くなったら作業単位を分割しましょう、ってだけだろ、本質は... 滋賀県大津のびわこ競艇
ボートレースの有名選手
43歳の守田俊介選手
SNSには不適切な投稿多数
回転寿司でお茶の粉末とガリ七味で富士山
https://i.imgur.com/Fx9BE6R.jpg
https://i.imgur.com/oXDug9q.jpg
ボートレースびわこ
滋賀県大津市茶が崎1一1
077―522―0314 関数長いとかは、範囲選択してリファクタリングで、正しく自動的に関数化してくれるから、
分けていくのは楽っしょ。
設計レベルで見直すなら大変だけど、
余程汎用性が高いもの以外、
殆ど流用ってされない。 ソースがスパゲティになるような現場ではマイクロサービスとか無理だぞ。
だってそもそもカプセル化すら分かってない連中がプログラム書いてるんだからw >>3
修正加えるときに
ちょっとずつ治すしかない <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
まで読んだ >>68
結合度に凝縮度か。
業界にそんなこと意識してる奴が何パーセントいるやら。
そういうレベルでの設計の良し悪しが論じられる現場なんて5分の1も無かったなあ。 プログラミングをはじめる遠いあの昔w
さすがにしっていたからスパゲッティだけはやらないようにしてきた
go toレスの常念頭にと
ある仕事で、元ソースを参考に(仕様書なしw)
数百本のをやってくれといわれ
スッパのは無視して構造化でつくりかえた
全部作り変えてもいいか?と言ったら
よいという返事だった、あの上司最高w ほんでめがねとなんの関係があるのや
どうでもいいか >>3
一つの関数、違う言語なら1つのメソッドで2万行か。狂ってる。 go toでとんでもないところに
とばすって酷いな
そこからまたはじめるためかw
そういうのをはじめてみたとき
びっくりした
それでも動くからええのやぁと
言っていたひとがいたあの当時 リファクタリングしたいのに実際はできない
予算と勇気が要るからな >>125
少なくとも単体テストの自動テスト環境ないとやってられんよ ファイル数が増えると逆に探す手間が増えるのでは?
ネットだとちょっとしたラグも積もり積もって気になってくるし。 >>3
2万行だって
・どうでもいいコメントは全部削ってgitの中にだけ残す
・使われてないプリプロセッサも(略)
・同じようなパターンをテンプレート化
・処理ステップに応じて関数分割
ってやりゃ20行くらいの関数群になるだろ
ちょっとずつ分かるとこから整理すりゃいいのよ 運用マニュアルと設定情報がスパゲッティーになるだけなんだよなぁ
複雑なものは何やっても複雑なんだよ >>3
土建業界主導の日本産業がイカンのだわ。
未だに、ソフト開発を体張らんた易い仕事とバカにしてる。
超高層ビルの建設と同じように考えてもらわんとな。
構造設計をちゃんとやり、施工のための詳細な図面を作らせ
そのレビューを重ね、現場が整然と遅滞なく施工を行えるように
段取りをする。 さらに、施工の進行状況を細かくチェックし
監督指導する。
膨大な手間と費用がかかる。それだけの効果を引き出そうとするとするなら
当然のことだわな。 >>127
ファイルが増える?
1サービス1ファイルじゃないぞw
>>129とかもそうだがまともなソフト組んだことないだろ… >>130
それ設計に縛られて改変ができないパターン
車の低層制御みたいにガチガチに作るならともかく
市場向けソフトなら必ず起きる
将来のフィードバックに対応できんよ
高層ビル設計するんじゃなくて
丈夫な鉄筋とか、柔軟に組み換え可能な
パーティションなんかを設計すべき >>131
まともなソフト開発する部署が少ないしそういう人が増えるのもやむをえん w
まともに開発したくてもできないしがらみが多いかもしれん。 マイクロサービスがスパゲティ的に接続されるのなら
やはりそれはスパゲティ 元記事読んだが、これ使うって
自社のソフト要員が余程へっぽこなんだな
普通にjsnodeとsqliteとpython機械学習で
モジュール組み合わせ自在に作れそうだけど マイクロサービスアーキテクチャは
関数型プログラミングに似たバグの少ない設計と、スケールアウトのしやすさが利点
非同期処理による状態の増加が欠点
全体としてプラスになるかマイナスになるかは結局設計者の能力次第 >>3
そのくらいならできるやつ結構いるぞ
俺も何度かやらされたし
金渋らなきゃいい 非同期処理ってできるやつ半分くらいになるぞwwwww
まあ昔と違ってクラスやらクロージャやら使えるからまだマシだろうけど。 >>140
際限できない複雑なバグの宝庫になりそうではある そして10年後、どの部分にどのマイクロサービスを使ったか誰も把握しているものはいなくなった… スパゲッティーコードより他システムとの連携の方が困難だろ。 スパゲティコードはコードのモジュール構造をどうするかっていう話だけでは解決できない
何世代ものプロジェクト改修を経る過程で出現するゾンビコード(不要と思われるが誰もメンテしていないコードや
不要かどうかが断定できないコード)のほうがより深刻なスパゲティ状態を生み出す
コードセットは10年くらいのサイクルで改修ではなく完全リプレースが必要でマイクロサービス化による
大きなメリットの一つは部分システムの完全リプレースによるゾンビコードの排除がやりやすくなることだと思う スパゲティコードって、gotoを多用するオレが書くコードのこと? >>148
おおむねそう。
今は仮想関数や依存性注入なんかで実際に動かしてみないとどこ走ってるかわからないものも含む。 >>129
わろた
こういうレベルのやつが否定してるのか
なんのためにプログラムがあるんだよwww >>152
本人気の利いた事言ってるつもりなんだからスルーしとけ パスタとスパゲッティの区別ついてない奴は昭和の老人か マイクロサービスに幻想抱きすぎだろ
構想と実装だけ進んで環境整備追いつかなくてデバッグ死ぬ >>158
疎結合で組みましょうってだけだぞ?
どんなもんを想像してるんだよw クラウドサービスの提供者がこういうアーキテクチャ欲しくて作っちゃった気持ちはよくわかる。
そしてそれは既存のシステムには何の影響もなく、これから作るシステムはそうなるだろうってだけの話で
これまで出てきた数多のプログラマや鯖缶の恨み言を解決あるいは低減してくれるものではない。
まーアレだ。「スパゲッティ」なんて書くからプログラマばっかり釣れちゃって無駄にヘイト上がってるけど、
dockerfileとかdocker-composeとかapplicationContext.xmlとかstruts-config.xml書くの好きな人が
盛り上がるべきだったんだろうな。 >>161
マイクロサービス自体は
サーバータイプのインフラ上でも出来るぞ?
そりゃ、コンテナベースの方が便利だろうけど >>162
そういうインフラ部分を業者に丸投げ出来るのが良いのに 最近じゃクラウドで分散してるから
鯖焼いて葬ることもできんな playgroundでSwiftで勉強してるわ
プログラマになれば儲かるんでしょ? >>157
ペンネじゃスパゲティプログラムにならんわ >>167
儲かるようになるのは
「もう無理やめる」ってな修羅場を
3回くらい経験してからだぞ
金払いの良い客は大抵無茶言ってくる
プログラムに理解ある客は
要求は極めて妥当だが儲からない >>169
そういう次元じゃなくて
年収300万とかの話なのでは。 >>169
俺の経験では、無茶を言ってくる客は金払いが悪い。 >>169
俺の経験でもアホなこと言う客ほど金払い悪い ■ このスレッドは過去ログ倉庫に格納されています