とある外資系プログラマーのブログ -3ページ目

とある外資系プログラマーのブログ

このブログは、主に開発に関する備忘録を共有する場所です。プログラムのコーディング、問題の解決、技術的な発見、そして学んだことを記録しています。開発者やエンジニアのための情報を提供する一方で、その他の興味深いトピックにも触れています。

術後から1年経ちました。

 

 

前回からも比べ鼻の違和感や痛みは大分良くなってきた気がします。

 

ただ、術後から気になっていた右鼻の中に小さいおできが2週間くらいの間隔で、できたり治ったりを繰り返しています。

 

鼻に触れると少し痛みを感じる程度ですが、術前はこんなこと無かったので検診の時に再度診てもらいました。

 

 

主治医からは、手術の後遺症の一つとして、鼻中隔に小さな穴が開くことが稀にあると説明を受けていました。

 

どうやら、今回の手術でピンホール程度の穴が開いちゃったらしいです。まーいわゆる鼻ピアスって感じですかね。

 

(なんてこった。稀の後遺症にあたっちまった。。。全く穴が開いている自覚がないが。。)。

 


それで、恐らくその開いた穴のせいで、右鼻が炎症(おでき)を起こしやすくなっていると考えられるかも?

 

術後1年経っているので穴はもう塞がらないと思うので、しばらく炎症は続くかもしれない。

 

と言う事でした。

 

 

まだまだ続くね。

 

 

 

 

 

 

 

鼻中隔湾曲症 術後5日目 その14~総合病院:入院7日目(退院)

 

 

 

システムの品質が悪い主な要因は、大体こんな感じかなと思っています。

  • 仕様を理解せず開発する。
  • 仕様を理解していてもスキルが足りない。
  • 影響範囲を把握できていない(大規模アプリにありがち)。
  • 開発中に仕様が変更される。

2ポチ,3ポチ、4ポチは正直、まーしょうがないとして、1ポチ目は絶対に無くしたいです。

 

 

理想な開発の流れとしては、

  1. 仕様を理解
  2. フローチャートを作成(頭の中(もしくは紙面))
  3. 設計書作成
  4. 頭の中のフローチャートをエディターにトレース(ようはコーディング)
  5. テスト仕様書作成
  6. デバッグ・テスト
かなと。
 
この手法が身に付いている人は、メッチャコーディングが早く品質も高いです。

 

自分が新卒で入社した会社では、フローチャートが書けるようになるまでPCに触らせてもらえませんでした。

当時は何なんだ??と思い理解できませんでしたが、今となってはとても良いやり方だなと思っています。

 

 

今から上記を実施するのは、難しいと思うので、

 

一般的な開発手順は、

  1. 仕様を理解
  2. 設計書作成
  3. コーディング
  4. テスト仕様書作成(単体・結合)
  5. デバッグ・テスト

ですが、

  1. 仕様を理解
  2. 設計書作成
  3. テスト仕様書作成(単体・結合)
  4. コーディング
  5. デバッグ・テスト
に手順を変えます。
 
「3.コーディング」「4.テスト仕様書作成(単体・結合)」 を入れ替えることで、仕様の理解を確認できるようになります。
仕様をしっかり理解した上で、開発が行えないようになるので、恐らく品質も向上すると思います。
 
ぜひ、お試しください!