【メモ】資料・仕様書・コーディングをする際の自分ルール(可読性)
プログラムの読みやすさ、重要ですよね。
わかりやすい仕様書・資料、大事な資産ですよね。
『プログラムが動けばよい』『納品すれば良い』『記載しておけばよい』というのは、その場限りでいえば正義かもしれませんが、後日の保守・運用側からすると最悪最低な行為です。過酷な作業環境で開発していたのであれば一考の余地はありますが・・・
今回は品質を担保するため(アウトプットのブレをなくすため)に律しているルールを記載していきたいと思います。
※基本的なことも書いてあったり、書いてなかったりします。これ以外にも守っていることはあるのですが、守ってるけど思い出せないものがあるので追記していく予定です。
１．仕様書・資料作成をする際に注意していること
- 見せる相手を意識すること.資料は今後管理され、後任者が読むことを意識すること
- 色による説明は色盲の方を考慮し行わない(現在はいなくても関連する部署や今後入ってきた人を考慮する)
- 理解しやすい資料を作成するため色を含めた表現を行うこと(色だけで意味を表現しない) また、無意味な色の設定を行わないこと.
- 概要では"ぱっと見"で伝えられる情報を意識すること.
- 文章の長さを意識すること. 長文は箇条書き等で分割する.
- 概要説明等、必要に応じて図・表での表現を取り入れること.
- 概要を説明してから詳細を記述すること. 全体像の説明してから部分の説明をすること.
- 章構成は意識すること. 章項目 について目立たせること(太字にする・文字の大きさを変える・段落を分ける)
- 仕様書を変更する際はバージョン管理をし、変更前の内容を仕様書には残さないこと(変更前を確認できる状態を保持すること)
２．コーディングをする際に注意していること
| 分類 | 内容 |
| メソッド | 名称は 動詞 ＋ XXXXX で統一すること |
| メソッド | 名称は 動詞＋名詞 の順で規定すること。 名詞 ＋ 動詞 とはしないこと。 |
| メソッド | 目的をはっきりともち、一つの目的を達成するための処理を記載すること。目的以外の処理は記載しないこと。 |
| メソッド | 1つのメソッドに記述する分量を考慮すること。100行(？)程度を目安とし、必要に応じて処理をメソッド化すること |
| メソッド | 同一処理を複数メソッドに記述しない |
| メソッド | 処理はブロック単位で連続性をもたせて記述すること. 例：”① メソッドを実行 ②変数にユーザ入力情報を格納する ③ ①のメソッド結果をチェックする ”の場合、 ②の処理を ①の処理の前で実行する。 ③ で""①の結果 と ②の値をチェックする"" 場合はこのままでよい。" |
| 変数 | 名称は動詞を使わないこと。形容詞, 名詞を利用すること |
| 変数 | 名称はメンバ変数・ローカル変数がすぐに理解できるようにしておくこと |
| 変数 | 格納値にジャンルやステータス等、決まった値を入れる際、null に意味を持たせないようにする. 例：○ 1:円, 2:ドル, 3:ウォン, 4:元 × 1:円, 2:ドル. 3:ウォン, 4:元, null:ユーロ" |
| コメント | 理由・目的を記述すること。処理説明は基本的にはしない。 メソッド内で処理をブロック化した際へのコメント等はつけても良い |
| コメント | XMLドキュメントは記述すること |
| 全体 | クラス名・メソッド名・変数名…etc において名称は"意味が推測できる"こと。 省略語を使わなず、かつ、長すぎないこと。※要するに悩め・考えろ。" |
| 全体 | １行あたりの文字数を考慮すること。横に長いとスクロールが発生し可読性が落ちる。 100字程度で区切ることを検討すること |
| 全体 | インデントは合わせること |
【手順】GoogleChromeを使ったリモートデスクトップ接続を利用してみた
リモートデスクトップ 、便利ですよね。GoogleからもChromeブラウザを利用したRDP(外部端末からアクセス)ができるので、今回はその手順を残してみました。
※RDPの取り扱いは気を付けてください。情報が洩れて他人からアクセスができるような状態になると、犯罪の手段として利用されます(外部からアクセスがあれば、ホストPC上で表示はでます)
■ホストPCで準備すること
- Googleアカウントでログインしておく
- chrome:appsにアクセスしてウェブストアを開く
- [ Chrome Remote Desktop ]を検索して以下のアプリケーションを追加する
- https://remotedesktop.google.com/access/ にアクセスし、案内に従ってインストールを続ける
■ホストPCで公開設定を行う
- Googleアカウントでログインしておく
- https://remotedesktop.google.com/access/ にアクセスし、[ オンする ] をクリックする
- アクセス名称を入力する。そのままで問題はない。
- PINを任意の値で入力する。※入力値は任意ですが取り扱いにはご注意を。
- アプリケーションをインストール(Andoroid/iOS)
Andoroid 
iOS - ホストPCの公開設定をしたアカウントでログインする
- ホストPCのアクセス名称が表示されるのでそれをクリックする
- PINを入力する
- ログイン画面が表示される(冒頭の画像)
【メモ】セキュリティに関する 10 の鉄則
有名な記事なんだけど、こういう思考的な記事って機会がないと見ないのでメモ。
当たり前といえば当たり前。ただその ”当たり前” をほんとうに理解できていますか？
--------------------------
- 鉄則 1: 悪意のある攻撃者の誘惑に乗って、攻撃者のプログラムをあなたのコンピュータで実行した場合、もはやそれはあなたのコンピュータではない
- 鉄則 2: 悪意のある攻撃者があなたのコンピュータのオペレーティング システムを改ざんした場合、もはやそれはあなたのコンピュータではない
- 鉄則 3: 悪意のある攻撃者があなたのコンピュータに対して物理的なアクセスを無制限に行える場合、もはやそれはあなたのコンピュータではない
- 鉄則 4: 悪意のある攻撃者にあなたの Web サイトに対して自由にプログラムをアップロードさせてしまうのなら、もはやそれはあなたの Web サイトではない
- 鉄則 5: セキュリティが強力であっても、パスワードが弱ければ台無しである
- 鉄則 6: コンピュータのセキュリティが守られているかどうかは、その管理者が信頼できるかどうかにかかっている
- 鉄則 7: 暗号化されたデータのセキュリティが守られているかどうかは、解読キーのセキュリティにかかっている
- 鉄則 8: 古いウイルス検出プログラム (ウイルス定義ファイル) はウイルス検出プログラムがないも同然である
- 鉄則 9: 現実の生活でも Web 上でも完全な匿名などあり得ない
- 鉄則 10: テクノロジは万能ではない
--------------------------
【日記】電子工作入門中
※日記なので挫折したら消えるかもです。
前々からこんなサービスあったらいいなぁと思うものがありまして。 探してみるんだが一向に出てこない。
構成考えてみるとわりと簡単そうだと思うんだけど・・・ でもない。
「ならば作ることもやぶさかではないかー・・・ きっといい経験になるよ、うん！」ということで、他の優先度高めの勉強ほっぽりだして、挑戦した軌跡をつけるための日記です。
(海外ではそれらしい情報があったりするけど情報が途絶えている・・・)
電子工作は全然ノータッチ。かすってすらいない。なのでまずは調査からかな。
===========================================================
■目的
Arduino を利用した簡易アラート機器の作成
■要件
Wifi/Bluetooth対応.電池による動作.できるだけ小型
■計画
- 初心者向けキットを購入
- 添付された参考書をもとに基本的な製造を経験<--- Now
- ESP32(?)を追加で購入。不足物などあれば合わせて購入。
- Wifi, BlueTooth の製造方法を確認
- プロトタイプの作成
■購入物
===========================================================
【メモ】仕様書ってどこまでかきますか？
現場で「仕様書どこまで書くか難しいよねー」って話が出てきたので考えてみた。
規模によったりすると思うが、だいたい以下のような準備が必要かと思うので忘れないようにメモ。
| 項目 | 記載事項 |
|
要件定義 |
問題点は何かを把握し、どのようなことが達成したいのかを定義。それらを踏まえたうえで対応内容の概要や必要項目の定義 ・背景の定義、課題の定義、改善範囲、対応内容の概要、納品物の規定、必要物の規定 |
|
基本設計 |
要件定義を踏まえ、解決手段および計画を定義する。 ・システム：作成物、機器環境/動作環境(サーバ、ネットワーク、利用者やファイル等)、利用シナリオ、システム構成、画面遷移、実装する機能概要 ・体制：開発方針、開発スケジュール、プロジェクト管理ツール等 |
| 機能設計 | 実装する機能について記載。 ・大まかな処理フロー、管理するデータの制定(ID規則等)/管理手段/データモデル・関係性、画面レイアウト、データ入出力、I/O情報 |
| 詳細設計 | 具体的な実装の規定について記載。 ・クラス情報/目的の定義、Exception対応、主要メソッドの定義およびI/O定義 |
| DB設計 | DB関連の設計 ・DB/テーブルの設計、カラム/文字コード/NULLの定義、インデックスの定義、ER図、トランザクションまわり、CRUD |
| 運用設計 | 運用にて必要な作業について記載。 ・バックアップ手順、マスタ情報定義、セキュリティ対応、定期実行設定など |
| 単体評価 | 詳細設計を元にしたメソッド/クラス単位の評価項目。 ・Exception評価、閾値評価、正常動作確認 |
| 機能評価 | 機能設計を元にした機能毎の評価項目。 ・利用者を想定した評価、正常動作確認、想定外動作確認(設定ファイル不備等)、バリエーション評価、処理速度・データ量評価 |
| 結合評価 | 他システムとの連携考慮する評価項目＋通常運用を想定した評価 ・連携箇所評価、想定外評価、想定運用実施評価、長期間動作評価 |
| リリース関連 | リリース方法やリリース前に必要のあるデータ、会社規定等で必要な申請等を規定。 |
| 非機能要件定義 | リソース消費(CPU/メモリ/通信速度/ディスクIO)の規定やセキュリティ、RASIS/SLA/SLO の規定 |
