プログラミングを学ぶ

1.学ぶ開発言語を選ぶ

プログラミングに全く触れたことが無い場合、最初に学ぶのは何でもよい。

ただいきなりC、C++といったコンパイルが必要な言語よりも、インタプリタ型の言語のほうが取っつき易い。
またインタプリタはランタイムさえインストールされていれば、コードを書いた直後に実行結果を確認することができるのでストレスも少ないので、LL言語と言われるPHP、Python、Ruby、JavaScript/TypeScriptから学んだほうが良いだろう。


2.プログラムにはフロントエンド、バックエンド、サーバーサイドがある。

概ね今のシステム開発は3層構成になっている。

フロントエンドは、人間が直接手を触れて操作をする画面系(人間に伝える役目)。
バックエンドは、サーバー(主にDB)と通信して計算処理をし結果をフロントエンドに伝える役目。
サーバーサイドは、サーバー側だけで処理をし結果はDBに保存するかバックエンドに伝える役目。

3.開発言語以外 SQL、正規表現。

データベースを操作するのにSQLは欠かせず、今あるどんなシステムもデータベースなしには無しえない。
また正規表現は文字列を整理し操作するフォーマッターで、こちらも様々な文字列を操作するときに頻繁に利用される。特にログ解析やJSONなどを操作する上では無くてはならない存在である。

SQLと正規表現は学んでおくべきである。


4.基礎的なこと

文字列操作、四則演算から、データ型などのプログラミング上の書式から始める。


5.デバッグとログ

一筆書き、ワンストップで作れる方はいいが、大抵はステップごとに書いていって動作を確認すると思う。
その確認方法がデバッグであり、処理経過を一覧式で見るのがログである。

デバッグの方法はconsoleログを出して確認する方法、
ステップイン/アウト/オーバーを使う方法、
ツールを使う方法などがある。
単体テストの方法も早めに習得しておくと良い。


6.プログラミングするとき

ある程度学んだら、作ってみたいものをコーディングする。
ビルドイン関数/メソッドやOOP(オブジェクト指向)をある程度覚えていて暗算できる人は頭に描いたとおりコーディングしていってもらっていいが、そうではない場合は まず「文章」で書いていく。

ただ何がしたいと書くのではなく、どういった処理の流れで、この処理は何が目的で、結果はどうあるべきかを書く。
処理のフローを、1処理ごと1行ずつ書いてゆき、それらを全てコメントアウトして #TODO にする。
コメントアウトの内容に沿ってプログラミングしてゆき、
一通り書き終えたら実行して結果を確認する。

バグがあればエラーログを確認し、不具合箇所を見つけて修正、再度実行して結果確認。この繰り返しである。


7.分からないところは「TODO」または「メモ」する

何をしたい、何が出来ない、生じてるエラーを解決できない。といったことは頻繁にある。
なるべくそういったものは「TODO」化しておく。

TODOとは一般的にはソースコードに実装する内容をメモしておくことを指すが、ここではマイ・タスクとして管理していく意味である。
このTODOを全ソースから拾ってサマリー化し、重要度や優先順位を付けて管理していけば課題が1つずつ減っていく楽しみも増える。


8.作業時間と処理時間を測る

作成するアプリのパフォーマンスだけでなく、現場(職場)では作業者のパフォーマンスも注視される。
この処理を作ったことがあるのか?
作ったことがあるならどれくらいの作業時間で作れるのか?
作ったアプリのパフォーマンスは何秒で結果を出すのか?

常に問われるので即答できるくらいやり込んでおくと良いだろう。


9.学ぶ

会社に入れば先輩や過去製品のプログラムを見れる機会に出会うと思うが、そういう恵まれた環境にない場合もある。
そういった場合は、Githubや大学が公開している講座、企業が公開しているサンプルコードなどを見て所作などを学ぶ。

なかなか自分にあったコードに巡り合える機会はなかなか無いが、片っ端から見て、気になるものはブックマークをして真似る。


10.管理する

web版Jira/Confluence(個人は無料)や、スタンドアロンで利用するならRedmine、Tracなどを使ってスケジュール管理、タスク管理を行うと良い。
ExcelやGoogleSpreadSheetを使って管理しても良いが、なるべく職場でよく利用されているツールを使った方が、現場に行ってからが楽になる。

なおMSのProject(1250円/月、15000円/年)やBacklog(2970円/月、35640円/年)は現場で利用されているツールだが、いずれも有料なので余裕と興味がある方は。


バグ

バグは、仕様書や設計書にある期待値でない結果が出た場合がバグである。

よくゲームをやってバグだバグだと言われることがあるが、それはバグではなく不具合という場合がある。
例えば本当は行ってはいけない操作をユーザーが行ってスタックした場合はこの不具合にあたる。
バグであれ不具合であれ、いずれも修正しなければならない問題点であることに違いはない。


*

タグ:

入門
最終更新:2024年03月28日 17:02