保守が困難＝ソースや設計が悪い？

レス22

（トピ主 0 ）

🙂

トピ主

2022年02月09日 22:34

仕事

自社サービスのwebエンジニアです。改修を重ねてサービスが大きくなってくると、保守や改修、新規機能追加が困難になってくる。そしてそうなるのは設計やプログラムが駄目だからだ。素晴らしいシステムはメンテナンスが容易であり、可読性の高いプログラムで書かれている。言っていることは分かりますし理想ではありますが、世の中の動いているサービスは実際そうなっているものでしょうか？たくさんのシステムを見てきたわけでもないので一般的にどうなっているか分かりませんが、顧客からの要望を実現するのにそんなに簡易な設計やプログラムになるとは限りませんし、一人の人が作っているわけではないので統一性も低いと思います。何よりも思うのは、多少設計やプログラムが分かりにくかろうが、設計やプログラムをきちんと理解できないエンジニアそのもののスキルが足りないのも大きな問題だと思うのですが、この考えは間違っていますか？今までの設計・プログラムが全てゴミだみたいに言って理想を語る人がいるのですが、皆様の職場にはそういう人はいるでしょうか？

トピ内ID：674e72d6ff706aaf

#上司

#同僚

これポチに投票しよう！

ランキング

このトピを見た人は、こんなトピも見ています

その他も見るその他も見る

前のトピ

次のトピ

レス

レス数22

このトピックはレスの投稿受け付けを終了しました

まず質問が分かりにくい

🙂

普段は節約家

2022年02月10日 10:49

トピ主は本当にエンジニアなんでしょうか。ずいぶん質問が分かりにくいです。大体、タイトルと内容があっていませんよ。まず保守が困難なのは、設計やソースが悪いと思っています。一番よくあるパターンで、教科書にも載っているぐらいなのに、今でも問題になる例として、同じじゃないと困る定数値が、いろんな場所で定義してあるという物がありますよ。最初は同じ値だったから問題なかったけど、誰かが一箇所だけ変更して、残りを変更しなければ不具合になります。これって、ソースや設計が悪いと思いませんか？で、トピ主が担当しているシステムはどうなんですか？良い設計とソースで保守が楽なんですか？次にスキルが足りないと言っていますが、具体的にどういう能力なんですか？スキルなんて無数にありすぎて、満足するスキルを持っている人なんていませんよ。だから、複数人で分担していますが、一体、トピ主が必要だと思っているスキルとは何ですか？案外、国語の能力じゃないかと思えますけどね。それに、スキルが低いよりも、設計書がおかしいとか、ソースと設計書が一致していないのが問題じゃないのですか？過去が悪いという人はいますよ。実際に私の部署は過去の企画部隊の設計ミス（検討漏れ）で現在苦労しています。それで、トピ主の担当しているソフトは素晴らしい出来なんでしょうか？とまあ、こんな感じですが、結局、トピ主が担当しているソフトはどうなんでしょうか？

トピ内ID：39e527e5aa2908e2

...本文を表示

逆じゃない？

🙂

匿名

2022年02月10日 10:49

＞改修を重ねてサービスが大きくなってくると、保守や改修、新規機能追加が困難になってくる。そしてそうなるのは設計やプログラムが駄目だからだ。これは本当にそうだと思います。センスない人が設計してると特にその傾向あると思います。＞何よりも思うのは、多少設計やプログラムが分かりにくかろうが、設計やプログラムをきちんと理解できないエンジニアそのもののスキルが足りないのも大きな問題だと思うのですが、この考えは間違っていますか？間違ってると思う。分かりにくいプログラムを理解できる人は、自分以外の人がわかりやすいようなプログラムにするし、メンテナンスが容易なように設計します。それに、わかりにくいプログラムを理解するために多大な時間がかかるのは時間の無駄ですよね。＞素晴らしいシステムはメンテナンスが容易であり、可読性の高いプログラムで書かれている。そうだと思うし、実際そうでないと何か仕様変更がある際にバグも多くなりやすいしトラブルの元だと思います。＞今までの設計・プログラムが全てゴミだみたいに言って理想を語る人がいるのですが、皆様の職場にはそういう人はいるでしょうか？あなたの職場の設計やプログラムを見てないからわからない。でもあなたのトピを見ると独りよがりのコードを書く人が多いのかなと。他社から転職してきて、良いシステムばかり見ていた人なら、もしかしたら本当にゴミみたいな設計の可能性もあるかなと思います。

トピ内ID：d012c440a22c48a2

この投稿者の他のレスを見る

...本文を表示

作り直す

🙂

よつば

2022年02月10日 10:33

理想から離れたら作り直すんだと思います。 WindowsもMacOSもAndroidもiOSも、全部バージョンアップしますよね。バージョンアップ直後は「絶対前のほうが使いやすかったのに」と思いますが、世の中の流れには逆らえないので新しいものに慣れていきます。バージョンアップで切り捨てられる機能もあります。でも、世の中はそうやって新陳代謝しているのです。保守が困難になったら、1から設計を見直すしかないです。その手間を惜しむから、困難が続くのです。トピ文を読む限りでは、理論や思想も含めてトピ主の技術力不足を言い訳しているだけの気がします。

トピ内ID：dea244d3a4b6a9d7

この投稿者の他のレスを見る

...本文を表示

行く川の流れは絶えずしてしかも元のシステムにあらず

🙂

おらっち

2022年02月10日 11:05

お客さんの都合も変わりますしね。歴史的建造物を壊さないようにしながら最新のインフラを後付けするのと一緒。中世に寺院を建てたときには、後世で空調入れたり電話線を引いたりインターネットを使うことは誰も想定してなかったわけでしょ、でも当時の寺院の設計図はゴミだったか？いえいえ、その時代の人智の粋を集結した素晴らしいものだったはず。まあちょっと比較対象が悪いとは思いますが。保守が困難になるのは、経年とともにしょうがないんです。経験から学べばいいだけです。現在のやり方は「素晴らしい」、過去の知恵は「ゴミ」と切り捨てるエンジニアはダメですね。その素晴らしい「今のやり方」が否定されるかもしれない未来に対して謙虚になるべきです。

トピ内ID：de4870d7190c8950

...本文を表示

言葉遊びがしたいのよ

うら

2022年02月10日 11:05

お疲れさまです。【物質は経年劣化を避けられません。ホコリも着けば紫外線で変色もする。人は老化を避けられません。シミ・皺・脂肪。細胞が変質して癌化までする。オフィスの人間関係も然り。慣れて遠慮が無くなる一方しがらみが増える。積み重ねた我慢のダムがある日決壊したあげく同僚の脚を縛って貧乏ゆすりを静止する(嘘です、しません)】改修を重ねて変容したシステム群はせいぜい端っこをいじるくらいしか出来ないよね。無駄を削ぎ落としたロジカルに美しいプログラムを見たいなら新規に作り直したものを持って来るしかない。でもそれいま走って回してるシステム止めなきゃならないから無理。無理だけどピカピカの新築に一掃出来たら気持ち良いだろうなぁ。と。解って言っているのです、理想を語るAさんは。「メンテナンスが容易で可読性の高い優秀なプログラムをあなたが作って見せて下さいよ」で終わらせたくなるでしょうけどそれを言ってはつまらない。【ダメで使えないシステムなら手を入れてまで使い続けられませんよ。九龍城は一夜で出来た訳じゃない】言葉遊びを欲しているAさんには【】こんな風に、トピ主さんが暇な時に相手をしてあげれば良いと思います。たぶん日常レベルの愚痴と理想語りですから正面から向き合う必要は無いです。トピ主さんは気楽に受け流して下さい。

トピ内ID：2a00079ddfe8d6c5

...本文を表示

予算内でその時に欲しい機能を追加していく

🙂

お疲れ様です

2022年02月10日 11:05

だいたいどの現場でもタイトルのようなことをやってるのでメンテナンスの簡便性までを見越した設計にはどうやったってなりようがないと思います。そういうことが分かってない人が言いたいことをいろいろ言うもんです。その人以外はみんなわかってるのでスルーしときましょ。

トピ内ID：25955e9b5b5b1195

...本文を表示

その思考が問題

🙂

エリーナミヤイ

2022年02月10日 11:32

〉多少設計やプログラムが分かりにくかろうが、設計やプログラムをきちんと理解できないエンジニアそのもののスキルが足りないのも大きな問題あなたは「多少」で、保守エンジニアは「大きな」になるんですか？あなたそのものののスキルが決定的に足らないんだと思いますよ。

トピ内ID：c53bbbd3967e5c02

この投稿者の他のレスを見る

...本文を表示

OSに範を見る

🙂

esezou

2022年02月10日 11:32

windowsご存じですね、どれほどリソース割いて開発されているかを。 UNIX（とその派生全て）どうですか、比較してみて。またJAVA系はどうでしょう。理想を言うのは簡単。でも詳細仕様に落とし込み１からコーディングできる人、今までの歴史で何人いたのでしょうね。あんたやってみなはれの世界でしょう（笑） web開発も同じですよ、まともに書ける人は一握り。凡人は精々マネすること位、ほとんどゴミ同然は事実。

トピ内ID：43c4c276d45ba741

...本文を表示

ちょっと何言ってるのか分からない

🙂

青銅の魔人

2022年02月10日 11:48

会社の業務の問題や課題を、社外に漏洩させるのは良くないですね。上長に提言するとか、同僚に相談しては如何でしょう？

トピ内ID：552de4bb474474f9

この投稿者の他のレスを見る

...本文を表示

金さえあれば

🙂

くものかよいじ

2022年02月10日 11:48

＞今までの設計・プログラムが全てゴミだみたいに言って理想を語る人もちろん居ます。中途半端な知識で、そこそこの地位にいる人たちだから、困りものです。（前世紀のシステムを使い続けているものもありますから、言ってることは間違っちゃいませんが）私は、怖いもの無しなので、平気で下記のように言い放ちます。「おっしゃる通りです」「システムの総入れ替えがベストだと思います」「このプログラムだと１行2000円くらいですかね」「一つのユニットで8000行くらいだから、1600万円」「多分20ユニットくらいは必要でしょうから、ざっと３億円あればできると思います」「詳しい見積取りますか？　調査費用だけで2～300万は掛かりますけど」こんな具合です。　因みに話が進んだことは無いです。「今の時代、お金さえあれば大概のことは出来ます」と追い打ちを掛けます。煙たがれてますけどね

トピ内ID：80caf9314403d21b

この投稿者の他のレスを見る

...本文を表示

大昔にシステム設計していました

🙂

昔のエンジニア

2022年02月10日 11:48

＞改修を重ねてサービスが大きくなってくると、保守や改修、新規機能追加が困難になってくる。＞そしてそうなるのは設計やプログラムが駄目だからだ。＞素晴らしいシステムはメンテナンスが容易であり、可読性の高いプログラムで書かれている。そうだねー、そのとおりだねー（棒読み）そのシステムだって当時最良と思われるものを組み上げているのですよ。将来どんな新機能、新技術、新要求など出てくるかわかっていたらそれに合わせて組みますって。確かにね、昔は今ほど教育機関も整ってなかったからエンジニアの質がかなり低い人もいましたよ。ですが古くからのシステムって後から後から「あれ追加して」「これ追加して」って要求されるんですよ。当初設計したときにはない機能を後から必要になったからって追加するんですよ。聞こえは悪いけどある程度の行き当たりばったりの追加設計もありますよ。当時の予算や納期の都合ってものもあるんですよ。大きく仕様設計しないときれいなソースにはならない、効率が悪い、と分かっていても数年後に大きく予算を取って最新システムにするから今とりあえず支障なく動けばいいと要求されることだってあるのです。 30年も前だけど当時でさえそういうぼろぼろのシステムを修正する仕事もしたことありましたしね。今はどうかはわかりませんがエンジニアの能力だって千差万別玉石混淆です。人材も費用も納期も万全なんて言う場なんてそうそうないんじゃないですか？＞今までの設計・プログラムが全てゴミだまあね、今の時代のレベルから見ればそうでしょうね。ですがそうなってしまうのは致し方がない部分ってやっぱりあるのです。だって未来って見えないもの。そう言い放つ人、そうとしか見れない人であるならばその人こそ視野が狭いので将来そのように言われるシステム設計をしているんだろうなぁと思います。

トピ内ID：5a3a899f22fc8f02

...本文を表示

サービスが悪いのでは？

🙂

わーまま

2022年02月10日 11:41

システムっていうのは道具とか手段であって目的ではないと思いますなんというか、サービスそのものが破綻してるんじゃないかなと感じました定期的にシステム障害の話を聞くように世の中も似たり寄ったりではないでしょうか？何が悪いって言ったら原因はあれこれあるんでしょうけどこれというものではないと思いますよ依頼する側も自分の要望を把握できないんだものどうしたって人間の作るものは完ぺきにはできないんだと思います私は障害がある前提で設計するものだと思いますよ保守という考えもそうですよね？ただ、理想論としてメンテナンスが容易であり、可読性の高いプログラムであるようにソースを書くものだと思いますそういえば、うちにも理想論とか正論を言ってくる人がいますね知見はあるので、存在していますがそれはそれ、これはこれだとは思います

トピ内ID：5699c7c11e7a3401

...本文を表示

一度だけ、見たことがある

🙂

ポインター

2022年02月10日 11:41

ちょっと大きな企業にいた事があって、保守の仕事をしていた時、すんばらしいコードを見た事があるのですよ。部分的な話ではなく、設計そのものが美しくて感動しました。システム全て、細部までムダがなく完璧と言うか。部門内で、エンジニアの神と呼ばれている人達の若い頃の設計でした（うち２名）。でも、凡人が作ったら、改修する度、読みづらくなったりするのでは？ただ、私は後輩から「これって、Aですか？Bですか？」と聞かれ（私が書いたコードではない）、「え？それを考えるのがアナタの仕事じゃないの？」と思った事は有ります。一応、そう、やんわり伝えてみたんですけど、後輩は「この場で〇さん（私）が、AかBか答えた方が早くないですか？」と言われて、こりゃダメだと思ったんですよね・・・。トピ主さんの言いたいこととは違うかもしれませんが（汗）そう言う人は、新規プロジェクトの方が上と言うか、改修を下の仕事だと思っていて、ケチを付けたいだけなんじゃ？（単にやる気がない）と思ったりもしました。

トピ内ID：a8fb041d87603c93

...本文を表示

メンテナンスする人≠作る人？

🙂

ochapi

2022年02月10日 12:11

トピ主さんの担当しているシステムがどうなっているのかは知りませんが、大きめのシステムだと作る人とリリース後のメンテナンスする人は違うのが普通です。システムのライフサイクルを考えるとメンテナンスを必要とする期間の方が長いのが一般的なので「メンテナンスする人が理解可能な設計・ドキュメント・実装」は基本設計する側が配慮すると思います。メンテナンスする人のスキルが低いことが分かっているなら、それに合わせて作らないとシステム運用で破綻します。スキルが足りないのが問題といっても、そういう人しかメンテナンスに使えないという与件に合わせて設計するのもシステム屋の仕事です。昔、金融系の人から聞いた話では「多次元配列使うとメンテできなくなるからダメ」というようなルールがあったとか。

トピ内ID：a31f100275cd40fb

...本文を表示

どんなにスキルが高くても

🙂

ぴたぱ

2022年02月10日 14:25

スパゲティコードを瞬時に理解できますかね。数年前ですが、他社さんが開発したシステムに機能を追加する案件に携わりました。エグかったですよ、そのソースコード。・コメントがほとんど無い・変数名がval1、val2 ・関数名がfunc1、func2 ・全く同じ処理が複数ファイルに点在している・1つの関数の行数が長い(700行くらいあったかな) ・「原因は分からないが静観対応」という不穏なコメントが入っている・設計書の粒度が荒く、内容も矛盾だらけ天才と呼ばれる先輩エンジニアが頭を抱えていました。その案件の辛い経験を経て、可読性とメンテナンスのしやすさを考えて実装するようにしています。

トピ内ID：e038a398341f8ba2

...本文を表示

注目!おすすめトピ一覧

すべて見るすべて見る

ついさっき、保守しました

🙂

頑張ってー！

2022年02月10日 15:36

ごく簡単なHTMLでしたが。まぁ、書き方が汚い。なんでここで改行？！なんでここにこんなコメント？！ span付けても良いけど、付けなくても全く変化ないよね？！ aとhrefを改行して分ける意味て、何なんでしょう… 他のコマンドも、なんでここ？！てところで改行入りまくりでした。かと思えば、1000文字も改行しないで複数多種のコマンドを含めて繋げまくりだし。読んでわかるのと、パッと見でどこに何があるのかわかりやすいのとでは、保守性に格段の差がありますね。保守性に格段の差があるということは、普通に文字を目で追うだけの意味での読むのにも時間がかかり、工数の無駄＝時間の無駄、つまりは会社として原価があがり、売上が落ちて、従業員みんなの給料が減る、増えない、ということです。今までの設計が全てゴミというのは言い過ぎと思いますが、ゴミコード、ゴミ書き屋は存在する、と思います。適度に改行したり行間を開けたり、部品を活用したり。完璧には無理でも、綺麗なコードを書こうと努力するのは良いことだと思います。開発屋さん、期待してます！

トピ内ID：53d44e43eb9b6712

...本文を表示

ぴたぱさん、分かる〜！！！

🙂

頑張ってー！

2022年02月10日 17:04

会社の大先輩が、項目名の付け方がソレでした！レコード長くて項目が数十を超えてて、考えるのがメンド臭かったのでしょうけど。最低限、資料のほうには内容的に各項目の意味が書いてあったから対処できましたが、できなかないけど全部の資料と首っぴきでないとできないっていう…泣開発から離れて忘れてましたが、そんな保守泣かせな名付けも、ホントに勘弁してほしいですよね汗

トピ内ID：53d44e43eb9b6712

...本文を表示

プログラムに限らず、なんでもそうですよ

🙂

合理主義

2022年02月10日 20:33

＞素晴らしいシステムはメンテナンスが容易であり、可読性の高いプログラムで書かれている。何でもそうです。システムメンテナンスに限った話ではありません。例えば、業務内容のマニュアルでも、「それを読む人は業務の知識のない人」である前提で作ろうと思えば、いきおい分かりやすく、視認性も高く、メンテナンスも容易なフォーマットを採用すると思います。作った人間にしか理解できないマニュアルに意味はないですからね。ミステリ小説でもそう。例えば医療系ミステリで、専門知識があるからと専門用語の羅列だけでトリックや動機を解説されて、読者からの支持が得られますか？トピ主さんもこんな言葉を聞いたことが無いですか？「頭の良い人ほど、分かりやすく平易な言葉で話す」ってね。要は、 1.能力がない人はそのタスクをこなすので精いっぱいだから「誰から見ても分かりやすいように」というところまで気を配れない。 2.半端な能力しかない人は「自分はこんなことができるんだ、こんなことを知ってるんだ」とひけらかしたい。自慢が目的だから無意味に複雑にしてみせる。 3.そこそこ能力はあるけれど、想像力が足りないので「自分が知ってることは他人も知ってて当然」という前提で作業してる。(メンテや機能追加のことを考えない) ということです。搭載する機能が多岐にわたっても、ベースはシンプルに汎用性高く作ることは可能なはずです。それを「理想論だ」と切って捨てるのは、己の能力不足を晒してるだけですよ。

トピ内ID：ba854a7251ba2d95

...本文を表示

組み込みエンジニアです

🙂

よる

2022年02月10日 21:47

職種違うので捉え方も違うかもしれませんが… 現実問題チームで作業しつつ長年流用・機能追加・バグ修正…と繰り返すと冗長な記述が増え、メンテしづらくなるのはあるあるですね。トピ主様はこのような事態はある程度仕方のないことで、これを解読できないエンジニアのスキルの方に問題があるとお考えのご様子。程度問題で、確かにちょっと荒れたソースを全然読めないというのアレですが…個人スキルに頼るのはそれはそれで現実的ではないかなぁと思います。私のチームでは定期的に改善担当を指名して、リファクタリングを行なっています。即ち、メンテしやすい構造・可読性の高い記述への修正作業です。もちろん部分的です。実施するそばから別の修正や機能追加が入っていきます。が、やる意味はあると思っています。この作業は担当者の教育も兼ねており、レビューを経て悪い記述・良い記述を学習することで全体のスキルを底上げし、結果的にメンテを容易にすることが目的です。全ての現場で同じことができるとは思いませんが、経験も能力も望んですぐ手に入るものではありませんので、開発効率を上げるためには現実的な対策が必要です。既存ソースをゴミと言って切って捨てるのも、こうなるのは仕方ないから解読スキルを磨けと言うのも、どちらも本質的な解決にはなっていないというのが私の感想です。

トピ内ID：493a68e7714c4f8a

...本文を表示

誰に向けて作るのか

🙂

かなた

2022年02月11日 10:11

そこそこの大規模なwebサービスを運営する仕事をしています。サービスを家に例えてみましょう。当時はとても小規模で小さな家を建てたとします。部屋が足りなくなり増やしたり（新機能）・トイレやお風呂をを直したり（改修）を続けました。その度に、いつも違う工務店で材料（コード）を使っていました。 10年が経ち、気づけば色んな素材のめちゃくちゃな家になっていました。そりゃ、最初は小さな家ですから継ぎ接ぎしたらそうなります。そして新しくきた人が『ぁあ、最初から見越して作っておけば良かったのに。素材も統一できたのに』と言います。それは無理な話。だって、ここまで拡張する未来は最初は誰も想像できなかったのだから。私は、あなたが言う『作り手ならば、どんな状況でも読み取るべし』も『全部ゴミだ』と理想を語る人も違うと思います。サービスは日々成長していくもので、それと共に開発者は修正や成長していく必要があるのです。読み取るのが難しく運用が出来ないなら、リファクタリングの決断も必要です。ゴールはより良いサービスを、お客様を待たせず提供できるシステムを作ることだと思います。

トピ内ID：752dbb231c3e7da4

...本文を表示

設計が悪いだけです

❤

ミセスシンデレラ

2022年02月11日 10:30

>改修を重ねてサービスが大きくなってくると、保守や改修、新規機能追加が困難になってくる。これは当然のことです。ユーザーニーズに合ったものにすると必ず改修や新規機能追加は必要となります。これを当然と考えるかそうでないかで設計が変わってきます。 >そしてそうなるのは設計やプログラムが駄目だからだ。プログラムがダメって意味が分かりません。設計がしっかりしていればプログラムは仕様に沿ってコーディングするだけなので設計がダメです。 >素晴らしいシステムはメンテナンスが容易であり、可読性の高いプログラムで書かれている。その通りです。同じ処理でも10行で終わる人と100行でも終わらない人います。その差はどのメソッドを使っているか。メソッドを使ってるので結果は書いた通り一律。ソースを後から追ってても辿りやすいです。ただしこれは経験だと思います。あとで俯瞰して言えること。最初は小さいサービスだったけど段々と大きくなっていくとサーバーを変えたり色々なコアの部分も変えないといけない場合もあります。それをパッチをあてて運用していると某銀行のようになります。その場合最初から合理的なシステムに作り替えた方がいいのですが運用中だと難しい面があります。 WebならMVCで分けてすると保守がやりやすいと思います。新機能が追加する場合も基本それに沿って追加するだけなのと、概念が共通化しているので互いに理解しやすいと思います。 >今までの設計・プログラムが全てゴミだみたいに言って理想を語る人がいるのですが新しいことをする時には今までの否定から始まります。そしてそれを良くするための理想を語り具現化していくのです。あとはお手並拝見と行きましょう。

トピ内ID：1133bc5fa9a95bfb

...本文を表示

運用保守の仕事をしています

🤔

保守さん

2022年02月11日 12:18

＞何よりも思うのは、多少設計やプログラムが分かりにくかろうが、設計やプログラムをきちんと理解できないエンジニアそのもののスキルが足りないのも大きな問題だと思うのですが、この考えは間違っていますか？ここですが、少し間違ってるかなと思います。設計もプログラムも読み解くことができても、ただ、なぜそういった仕様になっているのかがわからないシステムが多いんですよね。なんなら、作った人も分かってない。そうなるとプログラムが読めても、設計図が読めてもメンテナンスはできません。なので保守が困難になる一番の原因は設計、開発が悪いというよりは、ドキュメントが足りないということが多い気がします。 (とくに大人数の開発だとドキュメントが不足したり、属人性が高くなったりして、明文化されない仕様が多くなりますよね) あとは運用設計ができているか。が大きいかな。まぁ、なのでプログラムの可読性が高ければ保守できるかというと必ずしもそうではないし、スキルがあれば保守できるかというとそれも違うかなと思います。今までの設計、プログラムがゴミだは極論すぎて…まぁ、たまにそういうシステムもありますがね。

トピ内ID：3a25f25ab7a26440

...本文を表示