少ない努力でプログラミング？
「え～変数の宣言、設定の方法は…」それは入門書を読んでください。
条件分けif文の基本、繰り返しfor文の基本、関数の定義、文字列操作、演算子、正規表現など、入門書の巻頭のインデックスに記載できそうな項目はたくさんあります。プログラミングでは「できること、やりたいこと」が多岐に渡るので、学ぶ人に合わせて隅々まで教えるというか、つきっきりで手取足取り教えることはできません。逆に言うと、考え方次第では意外と少ない努力で利用可能なツールを作成することができるということです。
「少ない努力」とは他の検定試験や資格試験よりは少ないかもということです。司法試験対策の勉強よりは覚えることが少ないと言えます。(細かいことを言えば、同じかもしれない。プログラミング言語もかなり奥が深いから。)
プログラミングとは、専門性の高い技術だと思われがちだが、応用範囲はむしろ生活に密着している。思考力を高めるほうが有用性が高いと言える。確かに司法試験に合格すれば、しばらく安泰かもしれない。しかし、今後グローバル、経済格差、個人活動への流れが進んでいくので、弱肉強食の要素がいまより強くなっていくと思う。だから、筋肉を鍛えるように思考力を鍛えないといけない思います。
Javascriptの入門をまとめようと思って書き出したが、出だしから感想になってしまった。
私が書くまでもないなと思いました。むしろ素人が書くとデタラメなこと書きます。それに世間には素晴らしい参考書が出回っているので、結局それらをなぞるだけです。自分で書く目的としては自分のために書いているのかもしれません。自分で書くと当然「自分寄りの記事」が出来上がります。
例えば演算子の説明。入門書では「+」から始まり「-」「」などすべてを網羅する書き方をします。いや、入門書はそうでなければいけません。しかし、自分は日々のプログラミングで「+」以外の算術演算子をあまり使ったことがありません。(そうです素人プログラマーです。)使ったことはあります。しかし圧倒的に利用頻度が少ないです。「これらの-、、/を使わないと八方ふさがりだ！」という時まで使おうとしないかもです。（そうです、あたすが変なプログラマーです。)
自分の鉄板を大事にする。
「自分で書いたコードを説明できますか？」
コードを書いてツール、アプリ、サービスを作ったら、一度コードを読み直すことをおすすめします。そうやって自分の中でデータを積み上げていって、傾向と言いますか、クセが見つかると思います。それが良くも悪くも「目的通り動いている(やりたいことが達成できている)」のであれば、自分の鉄板として懐に大事にしまったほうがいいです。そして、いつでもどこでもソラで書けるように可用性100%にすることが理想です。それができなければドキュメント化しておいていつでもどこでもアクセスできるようにしておくのが大事です。誰のコードでもない自分のコードだからこそ覚えも早いと思います。
でもコーディングルールは合わせないと他の人が困るよ
そうですね、他の人と一緒に何かを作るならルールが必要です。
共同作業時の「コーディングマナー」問題。
逆にそんなことあります？自分のスタンスとして「書いたアプリ、サービスが軌道に乗って需要があり、マネタイズが十分に行われている状態」になっているときは報酬払って他人に保守させます。リファクタリングも結構です。潤っているときは自分が誰かと共同でコードを書くことはないです。うまくいって他人を雇えるようになったときの話ですよ？それ以外はまだまだ自分1人で出来るからルールなんて必要ないんです。うまくいったときの話ですよ！
ちなみにこんな自分でも労働者として会社で働いているときは、ルールを無視したり、独りよがりの業務フローで振る舞っていた人は、人として受けれ難かったです。会社員ですから、その辺は我慢して生活のためにやりましたけど…。だからプログラミング頑張ろうと思っていたのが懐かしいです。ひとりなら何をどうやったっていいと思います。
ドキュメントとはルールである
そう考えると「ドキュメント」ってかなり大事ですね。
言い過ぎかもしれないですが「いいドキュメントは人類の宝ともなり得るかもしれません。」もちろん誰をターゲットにしたドキュメントかを見極める力も必要です。独りよがりのドキュメントなのか？工夫されたドキュメントなのか？逆に「いいドキュメントを書くことも難しい」と言えます。だから「いいドキュメントに出会うことも稀」ということです。世に出ている本がいいドキュメントとは限りません。本はお金で出版できますから。
会社のファイルサーバーに埋もれたク〇みたいなドキュメントはホントにゴミでしかないです。ゴミなら捨ててもいいんだけど、たちが悪いのが「一応取っておこう」と言う人がいることです。結果、ファイル検索のときに邪魔になるんですね。
世の中がいいドキュメントだらけになったら「良い悪い」がなくなるんですね。「良い」が当たり前になるんですよ。そこで「悪いドキュメント」があると今度は逆に悪いドキュメントが目立つようになります。まぁそういう世界になったら、悪いドキュメントを書く人が少なくなったということなので良いことですけどね。
ドキュメント作成時に注意すること。
「人はロボットのように作業はしない」ということです。例えばやることを箇条書きにドキュメント化します。その作業が自分にとって無責任ならばドキュメント通りに作業を行うかもしれません。
余談ですが、私も経験あります。工場ラインでご飯にタレを塗る仕事。あれは厳密言えば責任あるでしょうけど、ほぼ無いです。だってスプーンでタレ伸ばすだけですから。そもそもドキュメントもルールもないですよね笑。ちなみに「職業に貴賤なし」と言っておきます。
いまの自分を例にした場合、私の作業対象はパソコンやネットワーク、特定のソフトウェアです。これらの設定ドキュメントを作成したとします。再構築をするときに問答無用でドキュメントに書いてある通りに作業するとは言い難いです。そこには私自身が「再理解と再納得」を必要としているからです。(記憶力ある人がうらやましい悲笑。余談ですが、この前「ド忘れ」って言葉をド忘れしていました。ちょっと不安です。)
でもこれって、本来は「ドキュメント通りに作業、書いてある通りに事がうまく運ぶ」のが正解です。例えば、バイト君を雇って、私のタレバイトと同じようにソフトウェアの設定を、作成したドキュメントをバイト君に渡して、その通りにやらせたとします。バイト君には「再理解と再納得」は関係ないわけですね。となると「ドキュメントとは要望を達成するもの」とも言えそうです。
達成例(社内ネットワークについて)
- AからBにつながること
- VLANは2つ作成する
- お互いにアクセス不可にする
- UTMの機能利用すること
- VPNサーバーを動作させること。
- APをつけること
作業者がバイト君だとしても、これらが達成さえすればOKなのです。たどり着き方はいろいろあると思います。大事なことはやりたいことをはっきりさせることですね。
ドキュメント作成のコツ
やることはもちろん書きますが、その際に3か月後の自分に宛てて作成することも大事です。またバイト君でも出来るようにという意識も大事だと思います。「詳しいことは忘れていているけど、なんとなくわかっている状態」の自分に対して書くことが大事です。