だいぶ日が経ってしまいましたが、13日の金曜日(!)、勉強会に参加しました。
勉強会というもの自体が人生で初めてで、完全なるビジネス素人がついていけるか不安でしたが、率直に言って楽しかったです。
定例会の最後に、宿題として感想文のご用命をいただきました。
しかし、私は昔から「超」のつくほど感想文が苦手で、夏休みの宿題もあまり提出できなかった人間でした。
なので、感想文というよりは、この度学んだ内容をレポートとして私なりにまとめてみることにします。
ただ、例によってまとめるのがへたくそなため、いつも以上に文字多めです…
あしからずご了承ください。
ブログもリーダブルにしないとですね。。。
参加の経緯。
ある日ツイッターを眺めていたところ、こんなツイートを発見しました。
「定例会、リモートで参加しませんか?」
…え、リモート?
このブログでVBAの記事を書くきっかけにもなった、憧れのタカハシさん。
地方在住のため今まで参加が出来ず残念に思っていましたが、絶好のチャンスと思いました。
緊張に震えながら少し前のめり気味にリプライを送ってみたところ、
「おお!お声がけありがとうございます!直接メッセージしてもいいですか?」
と、暖かく迎えていただきました。(…たぶん。)
早速、そのまま夜中に入会手続きを行い、各種SNSなどの準備を進めました。
(その勢いで、深夜にもかかわらずそのままタカハシさんに完了報告をしてしまいました…
その節は大変申し訳ありませんでした…)
概要。
定例会Vol.5 ノンプログラマーのための『リーダブルコード』超入門
というわけで例によって前置きが長くなりましたが、今回は、
ノンプログラマーのためのスキルアップ研究会(通称:ノンプロ研)の第5回定例会に興奮気味で参加しました。
今回のメインテーマは、ずばり
ノンプログラマーのための『リーダブルコード』超入門。
我流になりがちなノンプログラマー(=プログラミングを本職としていない人々)のコードを「読みやすく、かつ使いやすくするには?」というお話。
コンセプトや大筋の内容はタカハシさんの著書(↓)の後半とほぼ同じですが、今回はそれに加えて、実例とプラスαを学びました。
テクニックや、コーディングするにあたっての心構えなど、初心者事務員プログラマーにはなかなか自力で手に入れることのできない知識をたくさん共有頂きました。
(あくまでも、指導ではなく「共有」がポイントとのこと。)
みんなが主役!みんなで学ぶ!
それと、前回までは「セミナー」だったのですが、今回からは「定例会」に変更してみんなが主役!みんなで学ぶ!がコンセプトになったとのことです。
そのため、メインテーマ以外にも、いくつかライフハックのプレゼン(LTというそうです)もありました。
こちらはここでは具体的には書きませんが、こちらもとてもためになるお話でした!
そもそもノンプロ研とは?定例会とは?
ちなみに、ノンプロ研と定例会の内容について、詳しくはこちらもご覧ください。
ノンプロ研
コミュニティ「ノンプログラマーのためのスキルアップ研究会」についてのお知らせ #ノンプロ研
定例会の公式レポート
(主宰タカハシさんのブログです) なぜ「コードの読みやすさ」が大切なのか?その指針とテクニックとは #ノンプロ研
それでは、今回学んだ内容を、備忘録として記録していきます。
たとえばこんなテクニック。
メッセージの連結。
VBA2年生には知らなかったテクニックのひとつです。
Dim m As String m = “たとえば、“ m = m & “長いメッセージも” m = m & “こんな感じに” m = m & “1行ずつ分解が” m = m & “出来るんだって。” m = m & “すごい。美しい。” Msgbox m
改行のアレ( _
)とかVbCrLf
とか、要らなくなります。スッキリ。
そして出力のイメージ。
ほほー。
本職さんとノンプログラマーとの違い。
組織 vs 個人
ざっくり言うと、組織で動けるかどうかが大きな違いとのこと。
本職プログラマー様は、プログラミングを「仕事」として与えられるので、組織のフォローやバックアップ体制を得られるのが、大きなメリット。
さらに、チーム内で知識の交換・共有ができ、定期的なレビューもあるので、コーディングを一定の水準に保つこともできる。
対してノンプログラマーは、こっそり(?)コツコツ、あくまで「付帯業務」として取り組むしかないので、知識やテクニックが我流になりやすい。
だから俺様コードがどんどん生まれる。そして、過去のコードは負債化して行く…
他の参加者の方のブログ↓では、女性向けに「お姫様コード」と名付けていらっしゃいました笑
http://www.excel-prog.com/entry/2018/04/19/195118
(こちらのブログも、いつも楽しく勉強になるのでノンプログラマーにはオススメです!)
<2020/09/30追記>
残念ながら、現在はサイトごと削除されてしまっているようです…
独学は負債が溜まりがち…
当ブログでもいっちょまえに VBAリファレンス集 なんて偉そうに書いてますが、先日ここでも修正ポイントを見つけました…はぁ、負債か…
独学だと、知識の確認もアップデートも進まないんですよね。
せめてチームで出来れば、、、というのが孤独な事務系職のボヤキです。
そこで、敢えて自分の知識レベルを晒して、あわよくばレビューをいただきたいというのを、今後の当カテゴリの隠れ(?)ポリシーにしようと思います。
だからと言って誤りを広めていい理由にはならないけど…
コメントの残し方。
ドキュメンテーションコメント。
ネットでコードを検索すると、コードの上の方に長ったらしく説明が書かれていることがあります。
これを、ドキュメンテーションコメントというようです。
具体的には、何をするコードなのか、また、どうやって使うのかを残すもの。
今までずっと「コメントは少なければ少ないほどキレイ」と思い込んでいて、いつもコメントが増えるし邪魔だと思っていました…ごめんなさい。
「自分で作ったのだから意味が分かって当然♪」のはずが、時間が経つと自分ですら読めなくなり…
まして、第三者なら読めるはずも無く。
この視点、大事にしたいです。「俺様コード」にも通ずる話。
…邪魔だと思っていたのは、単に私に読み解くだけの知識が足りなかっただけのことですね。笑
ということで、できるだけ後世に残せるように書き方を学んでみます。
コメントの対象レベルは?
↑の話にも関係しますが、後半、「コメントをどの程度残すべきか?」との質問がありました。
タカハシさんからは、「あまり対象のレベルを下げるべきでは無い」とのお答え。
複雑な事をするのであれば、読み手にもそのレベルを求めても良いし、むしろお互いに評価しあえるようになるべき、と。
…なるほど。
もちろん、専門家レベルのテクニックだったり、入れ替わりの激しい企業とかでいつも新任者が多かったりすれば、この限りでは無いと思いますが、
コピペするにしたって、「ちゃんと」意味を知った上で使わなければ、後々事故につながる。
そのためには、書き手と読み手双方でスキルアップをしていかなきゃいけない。
ということですよね。
人に要求することがあれば、「完全に」ではなくとも、機能を理解してお願いするようにしよう、と。
命名は、センス良く、お行儀良く。
コメントの前に気を遣うこと
コメントも大事ですが、やっぱり…
「変数名」などの「命名」に気を使ってあげれば、そもそもコメントだって要らなくなる!
これは本にも載っていました。
本を読んでから、私も日々気をつけているつもりではあります。
ただ、「センス」が難しいんですよね…
Googleさんと翻訳ごっこしても、聞いたこと無いし意味もピンと来ない言い回しになるんです。
結果、日本語でコメント。THE 本末転倒!\(^O^)/
理想の名前
というわけで、正しい名付け方としては、
- 「何をするか」ではなく、「(それを使うことで)何が起こるか」を示す
- Boolean型を返す関数、プロシージャなら、is~, has~, can~などで「~かどうか」形式にする
- マジックナンバー(数値や文字列の直接指定)は定数にしちゃう
- キャメル形式とスネーク形式を使い分ける
▼参考 変数名の命名規則/**ケースの使い分け - Qiita
などなどを挙げられていました。
ちなみに、タカハシさんのブログでこのような記事↓もアップされていました。
変数のネーミングに悩む方にお勧め!プログラマーのためのネーミング辞書「codic」
まだ試せてないのですが、とても便利そうです!!
そして、私自身も少しずつセンスを勉強しなくては…
モノは試しで。
早速、
「何をするか」ではなく、「(それを使うことで)何が起こるか」を示す
↑を参考に、早速こちら↓も変更してみました。
'変更前(=条件付き書式をセットする) Sub setConditionalFormatting() '変更後 Sub setCheckSheet()
Conditional Format
は「条件付き書式」のことみたいですが、英語表記はVBA以外で見たこと無いし…笑
「条件付き書式」なら、まだ通じるとは思いますけど…
ちなみにちなみに、感想文とあわせて宿題のあった、現時点で私のベスト・オブ・変数名は、
MySweetMemories
です。笑
第三者が意味を理解できるかというと微妙なので、今回の宿題として求められているのとは多少意味が違うと思いますが…
メールサポートが仕事で、過去の対応履歴(アーカイブ)を個人的に残しています。
クレームも、ストレスたまる案件も、全部いまの私の栄養と思いたい。そんな意味で。
データは構造化。
ここは、本を読んでも定例会でも理解が追い付かなくて…
いまいちピンと来なかったので、少し調べてみました。
参考
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
https://www.graffe.jp/blog/1823/
<2020/09/30追記>
残念ながら、こちらの記事は削除されてしまったようです…
「構造化」とは?
こんな感じに解釈しました。
コンピュータはデータの計算や加工が得意です。
人間は、コンピュータを進化させながら、今まで色々な作業を覚え込ませて任せてきました。
そして、コンピュータが「パーソナル」になるにつれて、使う人のレベルや目的が変わってきました。
パソコンが広く普及したおかげで、扱うデータもどんどん多様化し、複雑になって行きます。
例えばエクセルで言えば、セルの「番地」は、関数やプログラムでよく使う大事な大事なデータ。
それなのにセルを「連結」したりすると、資料の作成など視覚的には便利ですが、他のセルは吸収合併の犠牲になり、「地名」が無くなります。
結果コンピュータには、確かにそこにあったはずの住所が隠されてしまうので混乱を招きます。
必然的にプログラミングも、複雑になり難しくなります。
そこで1つ、「構造化」の工夫が必要とのこと。
たとえばこういうのや
こういうのではなく、
こんな感じに。
※画像はイメージです※
見た目は落ちるけど、コンピュータにやさしい形に整えておく(=構造化)のが大事。
CSVファイルのような二次元配列が基本。
…という理解で合ってるでしょうか。まだちょっと自信が無い。
これ質問箱で聞いてみようかな。
まとめ。
最後に、ここまでの内容(とその他諸々)をまとめて、コーディングのスキルとして以下の3つを挙げられていました。
- (とりあえず)うごく
- (コードの意味が)わかる
- (良いコードの)書き方がわかる
これを、リーダブルコードの三段活用と言います(言ってない)。
これをマスターして、アン・リーダブルなライアビリティたちをソフィスティケートして、
クールなノンプログラマになりたい!と思いました。
…ああ、しかしまずこのブログがイケてないよ!!悔しい!!!!