Debian 9 へ OpenJDK をインストール

Debian 9 へOpenJDKをインストールする。

# apt-get update

# apt-get install default-jdk


複数のバージョンがインストールされている場合は、
下のコマンドでバージョンを切り替える。

 # update-alternatives --config java

 
切り替えたjava のバージョンを確認する。

# java -version

openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-8u232-b09-1~deb9u1-b09)
OpenJDK Server VM (build 25.232-b09, mixed mode)

# javac -version
javac 1.8.0_232


http://openjdk.java.net

レトロコードの不吉な匂い

最近の仕事は、過去に java で開発したシステムのバージョンアップを行っていますが
java のバージョンは過去のままで行っています。(レトロ)

10年くらい前に開発していたシステムですが、今見直すとリファクタリングした方が良いと思うコードがところどころあります。コードの「不吉な匂い」が...

 

数年前の自分は、もはや他人。
過去に自分が書いたコードも、現時点で見直すと「何か変」ということもあったりします。

コードが属人化してしまっているのを見ると他のプログラマーからの介入を防ぐためか、リファクタリングを避けて障壁を築いているのかと思ってしまうことがある...
(勘繰りが過ぎると!)

属人化は、長期的にみてプロジェクトチームや企業の損失なります。
他の人で対応できないため特定の個人だけで対応することになり
内部の問題が顕在化しないため、導入後に問題が発生したりするなど様々な弊害がでます。


改めて「リファクタリング」というのは
外部的な振る舞いを保ちつつ、内部構造を改善すること。
外部の動作や機能は変化しないままで、

内部コードの設計や構造を変更して改善すること。

 

「内部構造を改善すること」とは、

すぐ理解できるような構造にすること。

コードを見てその目的がわかるようにすること。

 

人が理解しづらいコードは、コードを見てもその目的がわからないため
コードが読みにくく変更や追加を行うのに時間がかかり、
かつバグを作りこんでしまうリスクも高くなります。

 

プログラムは完成した後も頻繁に仕様が変更されたり

機能が追加されたりするものです。
将来の仕様変更に備えてコードの修正箇所を正確に速く見つけてることができ

るようにしておくと作業効率が良くなり、バグが入り込む余地も少なくなります。


なので、常に、変更・追加がしやすいように理解しやすく見通しがよいコードに
保っておく必要があります。
オブジェクト指向プログラミングの利点を活かせるようにしておくことが重要です。
ポイントは
 ・可読性
 ・再利用性
 ・柔軟性


リファクタリングの目的
 ・設計の向上
 ・設計の劣化防止
 ・理解しやすいコードを保つ
 ・バグの特定
 ・プログラミングの迅速化

 

リファクタリングを始める前に、対象コードに対するテストコードを

書くことが必須です。

人の手が入るとどうしてもバグが入り込む余地がでてくるので
小さなステップでリファクタリングを繰り返して、その都度、自動テスト(JUnitなど)を行うようにするのが安全です。


リファクタリングのタイミング

 ・過去に作成したときに良いと思えた設計が現時点で

  見直すとミスマッチであると認識できた時点でリファクタリングを行う。

 ・重複コードを発見した時
  コードの重複部部をなくす。メソッド化する。
  それによって結果的にコード量を減らすことができます。

 ・コードを理解するときにリファクタリングを行う。

 

新年、明けましておめでとうございます。

あけましておめでとうございます。

今年もよろしくお願いします。

昨年の前半は以前から携わっていたシステムへの追加機能の開発と、後半は
過去に開発したシステムをベースに違うバージョンのシステムを開発していました。

今年も昨年後半の案件を継続して行う予定です。

 

「2020年の抱負」は、もっと多くの方とかかわれるようなことをやること。
今の仕事は継続して続けて行きたいのですが、さらに、もっと多くの方と

かかわる仕事もすることです。

 

昨年は、体調面では体の故障や不調が続きました。
左手のテニス肘、右ふくらはぎ肉離れ、肋骨の骨折、謎の発熱と神経痛…
整形外科と内科に頻繁に行きました。特に整形外科の込み具合は半端なかった。
午前9時に整形外科に行ったのだが午後を過ぎても診察の順番がまわってこなかった。
この時、もうここの整形外科のお世話にはなりたくないものだとつくづく思いました。


この間、仕事は休むこともなく続けていました。
肉離れした時は、松葉杖で出勤しましたが、かなり大変だった。
職場に着いたときはくたくた、怪我していない左足が筋肉痛になってしまった。

 

最近は右手でつっぱたり、右の手首を回すと痛くて
腱鞘炎なのかと思っていましたが、調べてみると症状が
三角線維軟骨複合体(TFCC)というのに似ています。

 

今年は、健康面でもっと注意する必要がありそうです。
普段の生活で無理しないようにするのと、もっと体を鍛えようと思います。

最近のお仕事

近況ですが、java での開発から C/C++, JavaScript を使った開発が今はメインになっています。

現在、ざっくりとした要求仕様から、[基本仕様]-[詳細仕様] が確定していない状態で開発するスタイルが板に付いています。実装(コーディング)前の設計段階で、曖昧な仕様箇所を redmine のチケットにあげています。曖昧な箇所は、レアケースな処理やイレギュラーなイベントが起こった場合の処理がほとんどです。エラーが発生した場合、内部でどのように処理を行うか、処理を継続するか、終了するか。外部ではユーザーにどのようにエラーイベントの内容を伝えるか。エラーメッセージを表示するか。初期状態にもどすか、など。

仕様が決まる過程で、いろいろと意見をいったり、仕様に納得できないときは、仕様の根拠を突き詰めて追及してしまうため、煙たがられる面もありますが恣意的で不合理な仕様に対しては、できるかぎり抵抗しています。

過去の仕事では、仕様確定の進め方・過程で考えさせられることが多かったです。要求仕様を出す側も、それを元に開発を進める側も、どの仕様がベストなのかがわからない場合いくつかの選択肢を抽出して、その内容をお互いで共有した後、内容について議論し合ってから要求仕様を出す側で仕様を決定してもらうというのがベストだと考えています。

思い出したように...

3年以上放置して思い出したように更新しています。

久しぶりにというか、書いていたことも忘却しかけている。しばらくすると放置状態になってしまうので、過去の仕事のことなどを日記に書き残していこうかなと思っています。長い間プログラマー・SEとして、仕事をしてきました。現在も継続しています。フリーになったのは今から13年ほど前で、今も現役のフリーでバリバリやっています。


フリーになるまでは、ソフトウェア開発会社, 所謂 Sler にいました。SIerは 2社経験しています。その前は電機メーカーのディーラー/販売会社で営業をしていました。経歴としては、もとはプログラマー・SEではなく営業職から転職したので、特殊だと言われることが多いです。


今、現在の仕事は自社の製品に搭載するソフトウエアの開発をおこなっています。なので仕事は製品が存在するかぎり継続しています。リリース後はプロジェクトはいったん終了しますが、基本はエンドレスです。

要求仕様問題プロジェクト その過程

 要求仕様に関しては、いつも確定しないまま実装に入ってインクリメンタルな開発を行うことが多かった。しかし、ついこの前の組み込み系通信システムの開発は完全なウォーターフォール型でした。結果はなんとか結合テストまで完了しましたが、その過程は散々でした。ウォーターフォール型では、設計に入る前に仕様が確定されることが前提ですが、T.B.D 項目以外にも仕様変更ではなく仕様漏れがけっこうありました。

 数人で実装しましたが、あいまいな仕様のまま実装した箇所は、結合試験ではまともに動作しなかった。当然といえば当然の成り行きです。短い期間で開発しなければならないプレッシャーがプロジェクトにあり、この圧力からプロジェクトリーダーは常にプロジェクトの建前上の進捗に執着して、実質的な問題点をおざなりにする傾向があったと思います。いや何が実質的な問題なのかもちゃんとわかっていなかったのではないかと思います。問題点をプロジェクトリーダーに報告してもその問題が根本的に解消されることはなかったし不明点が明確になることもなかった。開発時に、あまりにも不明点が多すぎましたが、それを問題としてクライアントにあげることができなかったのが致命的でした。クライアントへの進捗報告や打合せは、プロジェクトリーダーが行っていましたが、そこで問題点をクライアントに報告することをしていなかった。詳細仕様を設計段階で確定するとしても、それは要求仕様として本来確定すべきものであるとの認識がなかったように思います。
そのプロジェクトリーダーは結合試験前に、このプロジェクトから離脱しました。

【結論】

  • 不明点は不明点として顕在化させる。(報告する)
  • 短納期のプレッシャーに負けずに、本質的な問題を、把握して顕在化させる。(報告する)
  • 品質と納期に重点をおいて実現すべき機能に優先順位をつける。
  • それを踏まえて計画をたて、スケジューリングする。
  • その計画達成のための適切な開発手法を採用する。
  • 問題点の解決方法を検討する。

要求仕様化問題

3年以上も放置状態だったんですね。
久しぶりに更新します。

現在も、3年前とかわらずプログラマとして働いています。

この3年間の変化として、短期間ですが、違う開発のお仕事を経験しました。
未経験の開発環境、カテゴリでの開発でした。

  • 業務系のWindowsアプリケーションの開発(期間:約2か月)
  • 通信系組み込みシステムの開発(期間:6か月)

最初の業務系アプリケーションの開発も、次の通信系組み込みシステムの開発も
一番たいへんだったのは、仕様が決まっていない状態からの開発だったことです。
むかしからの要求の仕様化問題が、今現在も大きな問題であることを再認識しました。

開発工数の大半は、仕様が確定しないことによるものです。

それで、いままさに開発しようとしているシステムも同様の問題を抱えての
スタートになります。