業務プログラマーとなったばかりの人への心得を記載します。
その仕事は必ずしもあなたがやらなくていい
仕事を振られたとき、大事なことは決められた期限までに決められた品質のものを納めることです。
あなたが作業することは、上記を満たした上で、達成したいことです。
期限までに求められる品質のものを作れる見込みがないなら、作業指示者に話して、終わらせれる人に終わらせてもらいましょう。
その上で、後で作業してくれた人の作ったものを確認するなり、教えを請えばよいのです。
悩む、調べる時間は最低限にしましょう
あなたがわからないことの殆どは、別の人なら数十秒で解決できます。
一時間調べてわからないなら、多くの場合解決できません。
自分はどういう考えで作業を進めたのか、今何がわからなくて困っているのか、を、明確にして、別の人に聞きましょう。
困っているから力を貸してほしいと言われて嫌な気持ちになることはあまりないです。
ただし、すごく忙しそうにしている人、残業がかさんでいる人は避けてあげてください
作ったものは細かく確認しましょう
例えばあなたが3,000行のプログラムを書く場合、書き上がったときにそれが正しく動く可能性は0です。
必要な機能を細分化し、一つの機能を作成したら、それが正しく動くかテストするようにしましょう。
（テストの自動化をするのがベストです。テスト自動化は、熟練のプログラマーより、未熟なプログラマーに対して、より効果を発揮します。
あなたは、作る過程で何度もテストを実施し、そこで発覚した問題を解決するということを繰り返さないと行けないからです。）
テストが実施されていないプログラムをいくら書いても、管理者側から見たら進捗0です。
進捗は数値で報告しましょう
進捗を順調です、などと報告しても、主観なので判断できません。
機能が10あるうち、3機能はテスト完了、1機能は今作業中ですと、報告してもらえば、進捗は明らかです。
作成中でも、定期的にプログラム見てもらいましょう
あなたがうまくかけている、と、思っているプログラムは他の人からしたら、指摘が満載です。
それらは後で修正する必要があります。
定期的に、プログラムを見てもらい、指摘を受けて直しましょう。
指摘を受けた問題を以降の作業で繰り返さなければ、その分の修正時間を削ることができます。
コメントは書かなくてもわかるように製造する
初心者向けの勉強サイトや書籍には、ソースコードにコメントがいっぱい書いてあるので、それが当たり前と思ってしまうことがあります。
いっぱいコメントが書いてある状態は、普通にプログラミングできる人から見たら、どう感じるか。
こんな感じです。
この/時間、空間的に近いことを表す/記事/今見ている初心者プログラマーの心得の記事/は、初心者/経験、技術の浅いものの者/向けに業務/対価をもらって仕事をすること/でプログラミング/アプリケーションなどを作ること/をする上での心得/知っておいたほうが良いこと/を記載しています
大袈裟ではなく、本当にこんな風に感じます。
こう書いてくれればいいのです。
//この記事について
この記事は初心者向けに業務でプログラミングする上での心得を記載ています。
とはいえ丁寧に書かないといけないコメントもある
コメントは書かなくてもいいと書きましたが、しっかり書かないといけないコメントもあります。
- APIコメント
- 歪な設計になった部分
APIコメントとは簡単に言えばあなたが作った部品の使い方マニュアルです。
使い方マニュアルですので、どう作っているか、ではなく、どう使えばいいか、使ったら何をするかを書きます。
歪な設計になった箇所とは、
例えばシステムはわかっていない上司に言われて仕方なく作ったソースコードや
時間がなくて最適な実装方針が見つけられなかった箇所、創って動きはするけど、原理がわかっていない箇所などです。
これらは素直に、
〇〇という方法もあると思うが、上長からのし時により、実装
ググった結果を貼り付け。どのような処理なのか理解していない。
などとコメント記載してください。
このコメントがないと、あとから見た人が、なんでわざわざこんなことをしているんだろう？
なにか意味が合ってこんな創り方してるんだよな。でもなんだろう？
と、頭を抱えますよ。
報連相をちゃんとしろはおかしい
本筋とは話がずれますが、報連相をちゃんと上げろという管理者がいます。
本来チームの管理は管理者の仕事です。
管理者は報連相をしてもらうのではなく、状況の聞き取りをすべきです。
そのための仕組みとして、日次のミーティングや、積極的なメンバーへの声掛けなどをやるべきであって、
メンバーの報連相に任せるというのは、管理業務の放棄です。
とはいえ、そういうことを言ってくる管理者はいますので、言われるように報連相上げておきましょう