6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

ディップAdvent Calendar 2019

Day 12

`レガシーコードからの脱却`をクリスマスプレゼントにしてみてはいかが?

Last updated at Posted at 2019-12-25

フラゲ 申し訳ありません。 フライング土下座

はじめに(まとめです)

レガシーコードからの脱却Google先生に訊いてみる と沢山の感想が在ります。

『Qiitaユーザーが選ぶ、2019年に読んで良かった技術書』アンケート結果発表 - Qiita Zine にも!

個人的にもオススメしたい一冊です。

特に、エライ人に読んでほしいです!

金銭的・時間的に余裕のない方も、上記をはじめ他の皆さんの感想を読んでみると良いと思います。


が、読了してみて思った事(あるある・納得感だけじゃなく、モヤモヤ感)が日々(の出来事を見聞きする度)どんどん積み上がって来ているため、お目汚しとは思いますが 随筆?エッセイ? チラ裏を書き捨てさせていだだきます。

ここから先は そっ閉じ 推奨!


そもそも

レガシーコードとは

世の中的には様々な定義がありますが、レガシーコードからの脱却には

レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。

と書いてあります。

  • バグを多く含み
  • 壊れやすく
  • 拡張が難しい

バグを多く含んでいる

× 本番で(一見)正常に稼働しているソフトウェアは、十分な(手動)テストもしているのでバグは(あるかも知れないが多くは)ない"はず"

壊れやすい

× 本番で(一見)正常に稼働しているソフトウェアは、最善の設計・コーディングをしているので壊れやすくはない"はず"

拡張が難しい

× 本番で(一見)正常に稼働しているソフトウェアは、メジャーな言語・フレームワーク・設計を(利用)しているので拡張は難しくない"はず"


表現は異なるかも知れませんが、概ね『否定(NO)』的な認識が大多数ではないでしょうか。

いやいや、そんなことはない。私(我々)は常に危機感を持っているよって方が居たらごめんなさい。

個人的な印象としてはこんな感じなんです。

己を知る

個人的にも苦手意識しかないのですが、やはり己を知るのは重要なのではないでしょうか。

自分への戒めも含めて・・・

技術的負債

蛇足

初っ端から蛇足なんですが、技術的負債 というキーワードが最近とみに見聞きするのではないでしょうか。バズワードってやつですかね。

改めて Wiki を見てみたところ、なぜか関連項目の方が気になってしまいました。自分は Lisp に疎いからなのか、大きな泥だんご は初見でした。

パッと見、日本語訳も無さそうなので、その辺もあるのかな?

結構昔のキーワードなんですが、廃れるより寧ろ流行っているのでは?と思わせる内容です。

原文(Google翻訳)でも大体の内容はわかりますので、お時間ありましたら是非ご一読をオススメいたします!

蛇足(つづき)

アジャイル・スクラム・XPと技術的負債、大きな泥だんご、メテオフォールまで

  • 改めて英語力は大事だと痛感。日本に広まるまでのタイムラグが絶望的。
  • 途中抜けてますがご容赦を・・・

1986 The New New Product Development Game (スクラム)

1992 The WyCash Portfolio Management System (技術的負債)

1995 SCRUM Development Process (スクラム)

1997 Big Ball of Mud ( 大きな泥だんご )

1999 Pattern Languages of Program Design 4 (大きな泥だんご)

1999 エクストリーム・プログラミング (XP)

2001 アジャイルソフトウェア開発宣言 (アジャイル)

2001 Agile Software Development with SCRUM (スクラム)

2003 技術的負債

2004 エクストリーム・プログラミング(第2版) (XP)

2007 The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method (スクラム)

:
:
:

2018 メテオフォール型開発 - 実践ゲーム製作メモ帳2

2019 スケールドメテオフォール開発 - hogepiyohoo’s blog

アジャイル/スクラム、ウォーターフォール、メテオフォール

本題


キーワードをもとにGoogle先生に訊いてみた結果(の一部)。

星は個人的なオススメ度(の様なもの)。

個人的には本題から横道に逸れた管理についての気付きが思い掛けない成果でした。

やはり英語は難しい・・・。

皆さんはキチンと区別して管理を取り扱えていますか?

私は今の今までアヤフヤで勝手な解釈で使ってました。

マネージャーは本来マネジメントする人なんですよね。

我が身を振り返ってみると、コントロール主体になってしまっていたんじゃないかなぁと猛省。

(※現在、ボッチのため過去を振り返ってみました)

あと、荒ぶる四天王ってキーワードは上手いネーミングだなって思いました。

どの王が先鋒でしょうか・・・最弱。

メテオフォールのとかもそうですが、単純な擬人化じゃないところがイイですよね。

アジャイルとウォーターフォールはスコープの扱いが真逆ってところが面白いですよね〜

現実のウォーターフォールは殆どスコープ調整が発生するものだという認識(経験則)です。

予算(Cost)、納品(Delivery)の調整ってハードル高い事が多い気がしますが、とすると残るは・・・品質しかないですよね!

これが俗に言う技術的負債???

技術的負債の認識と立ち向かい続ける覚悟

  1. 現状を認識する
  2. 関係者各位に認識してもらう
  3. 計画する
  4. 改善し続ける
1. 現状を認識する

コード自体だけでなく、プロセスも大きく関係するのでしっかりと把握。

2. 関係者各位に認識してもらう

このハードルが高い気がする。

これだけ世間に広まっていれば、すんなり通じる気がするのですが・・・

この辺から上記己を知るに繋がりました。

質とスピード / Quality and Speed - Speaker Deck

これくらい分かりやすくまとまった資料を作れてプレゼン出来れば、可能?

3. 計画する

とりあえずやってみる事も大事。

ただし、闇雲に向き合っても↓に影響があるため、プランニングも大事。

4. 改善し続ける

ここ重要。

昔の人はいいこと仰る。

『継続は力なり』ってね。

話は変わって

ピープルウェア

1989年という私の業界デビューよりずっと昔に出版されたものですが、今更ながら読んでいます。(※読んでない方はまずは上記サイトがオススメ)

日本人の生産性が〜と言われる昨今ですが、弊社だけでなく多くのオフィス環境は様々な制約があって理想とは程遠い状況なのではないでしょうか。

そんな中、おそらく少なくはない方々が思い付いている事とは思いますが AirPods Pro 等アクティブノイズキャンセリングを導入するのが””なのではないだろうか。

『話しかけにくい』『無視される』等の弊害が阻害要因として考えられますが、例えばチャットツールのステータスのように周りの人達がわかるようなサインを掲げておけばよい(帽子を被るでも良いと思う)し、チャットツールの通知はONにしておく等のルールを合わせて導入すれば、本に書いてあるような劇的な効果は上がらなくとも費用対効果はプラスになるのではないだろうか。

これはとりあえず個人的に検証してみたいと思っているが、先ずは先立つ・・・ゲフンゲフン

言い訳

Qiita Advent Calendarという事で、企業・学校・団体として投稿内容を吟味して・・・等いらぬ事を考え過ぎて書くことが全然決まらなかったんです。
自分で勝手にハードル上げすぎ。
初歩的なミスです。ごめんなさい。
結果も、このような駄文となってしまい申し訳もございません・・・

・個人的なメモ [モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました - Graat(グラーツ)](https://www.graat.co.jp/blogs/ck1099bcoeud60830rf0ej0ix) [DevOps 技術: トランクベース開発  |  DevOps  |  Google Cloud](https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development?hl=ja) [Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita](https://qiita.com/TsuyoshiUshio@github/items/51c6662cd45bded95389)   [Feature Toggles (aka Feature Flags)](https://martinfowler.com/articles/feature-toggles.html)   [GE幹部を「ウン」と言わせる資料の作り方:日経ビジネス電子版](https://business.nikkei.com/atcl/report/15/260984/012700005/)   [SIerとWeb系の違いを知らずにエンジニアになると100%後悔します|未経験から独学でエンジニアを目指す人のためのブログ](https://asosori.com/sier-web-difference/) [【IT業界地図?】WebとかSIとか自社開発とかSESとか、言ってることわけわかんねえんだよ! | BAMV-LLC-blog](https://www.wantedly.com/companies/trash-briefing/post_articles/160402)   [IT人材が不足というウソとSE35歳定年説の謎 | BAMV-LLC-blog](https://www.wantedly.com/companies/trash-briefing/post_articles/116545)
6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?