2020年4月5日日曜日

コーディング規約の重要性

こんにちは。

今日は、コーディング規約の重要性について書いてみようと思います。

結論から言うと以下になります。
  • コーディング規約を無視したソースコードは読み辛い
  • フレームワークを使う場合はフレームワークのコーディング規約を使う
  • 独自コーディング規約よりも公式のコーディング規約を使おう
個人でWebサービスやソフトウェアを作っている時は、コーディング規約なんて気にしないと思います。

でも、チームで開発する時は、コーディング規約はとても重要です。

この辺を、私の経験を踏まえながら書いていきますね。

コーディング規約を無視したソースコードは読み辛い

チームで開発をしていると、コードレビューをします。

私も何度もチームメンバーのコードレビューをしてきました。

でも、コーディング規約を無視して書かれたソースコードは本当に読み辛いです。

コーディング規約を無視してコーディングする方は、大体がソースコードは動けばいい、くらいにしか考えていない方が多いです。

でも、考えてください。

システムは、一度作ってしまえは終わりと言う時代は昔の話です。

今は、システムは、育てていく時代です。

つまり、自分が書いたソースコードは、いつかは修正されるのです。

読み辛いソースコードを書いていると、修正をする方がとても苦労します。

苦労するだけじゃなくて、修正に時間がかかってしまい、修正する方へ大きなストレスを与えるのです。

私も、プログラマとして働き出したばかりの頃は、コーディング規約を重視していませんでした。

でも、時間がたった後で、自分のソースコードを修正する時、自分ソースコードなのに読み辛く、修正に多くの時間が必要でした。

自分の作ったソースコードに対して、「誰だこんなソースコードを書いたのは」と突っ込んでいたくらいです。

なので、チームを持つようになってからは、コーディング規約に沿ってないソースコードは、時間がなくても書き直してもらうようにしています。

若いプログラマの中には、不平・不満を言う方もいます。

そういうプログラマには、コーディング規約の重要性と、今のシステムを育てて、今後もっといいシステムにしたい意思を伝えるようにしています。

フレームワークを使う場合はフレームワークのコーディング規約を使う

仕事としてシステム開発をしていると、フレームワークをよく使います。

最近では、いちからスクラッチで開発することはほぼありません。

フルスクラッチで開発する時も、laravelやreactなどのフレームワークを使用します。

その場合は、laravelやreactのコーディング規約に沿ってコーディングを行うことで、読みやすいソースコードになります。

例えば、Wordpressのプラグイン開発をする場合を考えてみましょう。

Wordpressのプラグインを開発する場合、Wordpressで公開されている関数をよく使います。

そんな時、Wordpressのコーディング規約を知っていると、公開されている関数や変数を探しやすくなります。

また、他のプラグインと連携するのも容易になります。

これが、全く違うコーディング規約を使ったらどうなるでしょうか。

まず、Wordpressで公開されている関数を見つけるのに時間がかかってしまいます。

もしかすると、同じような処理をする関数を1から作ることになるかもしれません。

でも、自作した関数は、セキュリティ的に大丈夫か、想定外のデータを取得した場合の処理は適切かなど、検討しなければいけないことが増えてしまいます。

他のプラグインとの連携でも同じことが考えられます。

Wordpressのコーディング規約に沿って開発するだけで、少しでも手間が省けるのです。

以下にワードプレースのコーディング規約へのリンクを貼っておきますね。

Wordpressコーディング規約 (外部リンク)

独自コーディング規約よりも公式のコーディング規約を使おう

大手のシステム企業では、独自のコーディング規約を設けている所もあります。

でも、これからコーディング規約を作るのであれば、公式のコーディング規約を使いましょう。

何故かというと、コーディング規約を作ることが、あなたの企業の業務ではないからです。

そこに、時間をかけるくらいなら、システム開発をすることに注力した方が充分に利益につながります。

何度も同じコーディング規約を使用していると、少しずつ足りないなと思う点が見えてきます。

足りない点を既存のコーディング規約に追加していけばいいだけなのです。

私が勤めている会社でも、数年前に独自のコーディング規約を作ろうとした時期がありました。

いろんなコーディング規約のいいとこ取りをしようと考えていたのですが、結局、公式のコーディング規約を使用することになりました。

理由は簡単で、いろんなコーディング規約を読んでまとめる充分な時間が取れないというのが理由でした。

また、公式のコーディング規約には、基本的なことは定義されています。

基本的な規約に沿ってソースコードをコーディングするだけでも、読みやすいソースコードになりますし、システム全体の統一性も保たれます。

以下に、私が勤める会社で使用しているコーディング規約のリンクを貼っておきますね。

PHP Standards Recommendations(外部リンク)

まとめ

コーディング規約は、チームで開発する時には、とても重要です。

でも、ベテランのプログラマでも、コーディング規約を軽視している方が結構いるように思います。

ただ、自分が書いたソースコードを、後々、誰かが読んで、もっといいソースコードに書き換えてくれると考えると、コーディング規約に沿ってコーディングする大切さが分かるのではないでしょうか。

では、今日はこの辺で。

おまけ

システム開発ついて書いた過去のブログを以下に紹介します。




2020年4月3日金曜日

企業で働くエンジニアが注意しないといけない言葉


こんにちは。

今日は、企業で働くエンジニアが注意しないといけない言葉について書いていこうと思います。

結論から言うと以下になります。
  • できません
  • 簡単です
  • すぐできます
この3点については注意しましょう。

お客様とミーティングしていると、つい言ってしまいそうになる言葉です。

しかし、このような言葉に注意しないと、無駄な作業が増えることになりますよ。

私も、何度もこのような言葉で失敗してきましたので、その経験も含めて書いていきます。

できません

お客様からしてみると、企業で働くエンジニア はプロです。

なので、欲しい機能をどんどん言ってきます。

簡単な機能ならばまだしも、難しい機能になると、つい「それはできません」と言ってしまいそうになります。

でも、よく考えてください。

論理的な機能であれば、手間がかかるかもしれませんが、ほとんどが作り込むことが可能なのです。

私の場合、つい「できません」とその場で言ってしまったばかりに、仕事を失注してしまったことがあります。

あとで知ったのですが、そこまで手間をかけずに作ることができたのです。

論理的な機能なら作り込む事もできますし、一般的な機能ならばWebで調べると簡単にロジックやプラグインがあったりします。

なので、「できません」と言う言葉は控えるようにしましょう。

では、難しい機能の場合どう対応するかと言うと、「難しいです」と言うことを正直に行った上で、「検討させてください」と伝えましょう。

あとは、必死に調べる、または、聞き回ることで、簡単に作り込む方法を考えましょう。

簡単です

システムを発注する企業は、ITの知識が低いことがよくあります。

そのため、どうでもいいような機能をどんどん追加してきます。

その大半は、エンジニア にとっては簡単に作り込むことができます。

ただし、企業でエンジニアをしているということは、自分がプログラミングしている時間はビジネスの時間なのです。

作っているシステムは、企業の商品なのですよね。

私も、「その機能簡単にできるので追加しましょう」と言って、最終的に時間が足りなくなったことがあります。

そしてどうなったかと言うと、開発チームから外されることになりました。

結局、開発チームの利益を使ったことになるんですよね。

ただ、個人的には、お客様が欲しいと言っている機能は、できるだけ組み込みたいと思っています。

すぐできます

この言葉も気をつけた方がいいです。

自分の裁量で判断できるくらいの簡単な機能なら、私もこっそりと組み込んだりもします。

ただ、企業でエンジニアとして働いていると、スケジュールがありますよね。

スケジュールって、他の機能との兼ね合いもあるので、遅れると結構怒られます。

それが自分の技術不足によるものなら、まだスケジュールが悪かったと言えるのですが、こっそりと機能を組み込んだばかりに遅れると、かなり問題になります。

これは、私の経験です。

その時は、隠すことができずにバレてしまい、大目玉をくらいました。

なので、こっそり機能を追加するのであれば、スケジュールとの兼ね合いを十分に考えてから行いましょう。

企業で働くエンジニア としては、これも御法度なのですけれどね。

まとめ

企業でエンジニアとして働いている人は、このような言葉は使っていないと思います。

この3つの言葉、「できません」「簡単です」「すぐできます」は、結局企業の利益を潰しちゃうんですよね。

個人で仕事しているのであれば、普通に使っていいのかもしれません。

でも、企業でエンジニアとして働くのであれば、この3つの言葉には注意しましょう。

では、今日はこの辺で。

おまけ

エンジニア で働くのに役立つ過去の記事を紹介します。



2020年4月2日木曜日

社会人になって学ぶには


こんにちは。

今日は、社会人になって学ぶにはというテーマで書いてみようと思います。

結論から言うと以下になります。
  • 興味を持つ
  • 深掘りする
  • ビジネスを意識する
今日は、私が勤める会社でも入社式がありました。

新型コロナウィルスのため、みんなが集まって行う式は行いませんでした。

社会に出ると、学ぶ事も自由に決めることができます。

つまり、学ばないと言う自由もあるのです。

そのような中で、どのように学び続けていくかを考える必要があります。

興味を持つ

まずは、興味を持つことでしょう。

学ばないことを選択する自由も、社会人になると与えられます。

企業に入社する方は、その企業の事業に興味を持ったからでしょう。

どこに興味を持ったかは別として、興味を持ったところから、まず学んで見るといいのではないでしょうか。

私の場合は、最新の技術に興味があります。

なので、最新技術の情報は、すぐに目に飛び込んできます。

人によっては、アンテナを張るという言い方をする方もいますが、実際、私はアンテナを張れているのか分かりません。

でも、ネットニュースを見ていると、新しい技術はすぐに目に入ってきますね。

深掘りする

興味を持って学び出したら、さらに深掘りしてみるといいです。

深掘りすることで、さらに興味が湧き、学びたい欲求が増すことがよくあります。

また、深掘りすることで、詳細な知識が着き、先輩との話についていけるようになります。

すると、さらに面白くなってくるのではないでしょうか。

私が新人の頃、組み込みシステムの開発をしていたのですが、深掘りして学んでいて、先輩と話が合うようになり、さらにシステム開発が面白くなりました。

先輩と話が合うと、仕事も来るようになるので、同僚に少し差をつける事もできますよ。

ビジネスを意識する

やはり、学んでいることがビジネスに直結すると、学び意欲は湧きますよね。

学ぶことで、お金が稼げるのですから、一石二鳥でしょう。

さらに、ビジネスを意識しながら学び続けると、経営者と同じ意識に近づけます。

つまり、経営層の方々と話ができるようになるのです。

新しく社会人となった方にはピンと来ないと思いますが、経営層と話ができるというのは、かなり難しいのです。

例えば、システム企業の経営層は、システムを開発してどのようなビジネスを行うかを考えているのに対して、末端にいる私たちは、目の前の開発やシステムの機能のことしか考えていません。

つまり、見えている世界が違うため、話が噛み合わないのです。

まとめ

つまり、興味を持って深掘りし、どうやったら儲かるかを考えると、学ぶ速さも早くなるのです。

特に、ビジネスを意識するのは大切なことです。

たまに、知識をつけることが好きという方もいますが、知識を身に付けてもお金を稼げないと生活もできませんよね。

新しく社会人となった方は、学生時代と違って全てが自由です。

その自由を何に使うかによって、これからの人生が変わってきます。

頑張って学んでください。

では、今日はこの辺で。


















2020年3月31日火曜日

プログラムが動かない時の対処法

こんにちは。

今日は、プログラムが動かない時の対処法について書いてみます。

結論を言うと以下になります。
  • ロジックを追って確認する
  • ログを埋め込んで確認する
  • デバッガで確認する
上記の順で確認すると、大抵の不具合は解決します。

プログラムを作成していると、動かないというのはよくある事です。

調べていくとロジックのミスの場合が多いです。

ロジックを追って確認する

専門用語で言うと、机上デバッグと言います。

実際にソースコードがどのように動くかを、1ステップごとに追って確認する方法です。

大体、大きなロジックによる不具合は、机上デバッグで見つけることができます。

この段階で見つかる不具合は、詳細設計の段階で不具合が入り込んでいるケースが多いです。

ウォータフォールモデルでの開発では、ソースレビューを行うので、不具合がなくともレビューで見つかると思います。

ログを埋め込んで確認する

机上デバッグである程度動くソースコードができると、ログを出力して確認します。

机上デバッグでは、データの変動による不具合が見えにくいことがあります。

その場合は、ログに変数の値を出力し、なぜ動作しないのかを確認します。

私は、ログを埋め込む時に、どこのログか分かるように埋め込むようにしています。

特にループ処理の場合は、何回ループが回ったかを確認するようにしています。

たまに不要なループが回って、処理に負荷がかかっている場合があります

そういうのは、ログを埋め込んで確認するのが1番です。

デバッガで確認する

デバッガで確認するといろんな情報を取得することができます。

デバッガは、プログラムとは別のツールになります。

実際に仕事でプログラムを開発していると、ログを埋め込んで確認するのを飛ばして、デバッガでデバッグする事もあります。

上にも書いたように、デバッガは別のツールなのでいろいろと設定が必要になります。

ツールを使用できない事もあるので、ログを埋め込んで確認する方法も身に付けておきましょう。

デバッガを使用すると、様々な変数の値を見ることができます。

そこで、不具合に気づく事もよくあります。

まとめ

プログラムには不具合が付き物です。

不具合のないプログラムを組むことが理想ですが、最初から不具合のないプログラムはありません。

なので、プログラミングの後に試験を繰り返し不具合を叩き出すのです。

その時必要となるのが、上にあげた3点になります。

では、今日はこの辺で。

2020年3月29日日曜日

ブラウザとザーバーの関係

こんにちは。

今日は、ブラウザとザーバーの関係について書いてみようと思います。

結論から言うと以下になります。

  • ブラウザとサーバーは常に接続している訳ではない
  • サーバーはテキストのみを出力する
  • ブラウザはテキストを解析する
Webサービスを開発していると、経験の浅いメンバーから処理をどこに書いたらいいのかと言う質問をされることがあります。

その場合、ブラウザとサーバーの関係を理解していないことが多いです。

なので、ここでまとめてみようと思います。

ブラウザとサーバーは常に接続している訳ではない

開発をしていると、画面と処理をサーバーに置くため、ブラウザでWebサイトを開くと常に接続状態になっていると勘違いするようです。

しかし、実際は、ブラウザに表示するリソースが取得できれば、ブラウザとサーバーの接続は切断されます。

ブラウザは、必要な時のみサーバーに接続します。

実際、常にブラウザとサーバーを繋いでおく事もできるのですが、今回は、もっとも基本的な処理を扱います。

サーバーはテキストを出力する

サーバーからは、html、css、javascriptのテキストが出力されます。

実際には、それぞれのテキスト内容がデジタル化された状態(0、1のデータ)でサーバーからブラウザへ送られます。

テキストをデジタル化する処理は、Webサーバーソフトが行います。

実際に開発するのは、htmlを作るための処理です。

ブラウザはテキストを解析する

ブラウザは、サーバーから受け取ったテキストを解析してサイトを表示します。

まず、ブラウザは、htmlで画面構成を解析します。

次に、cssから画面に装飾を行います。

javascriptは、画面の動作を定義します。

まとめ

つまり、サーバーとブラウザは、テキストを受け渡すことでサイトを表示しているのです。

そのテキストを作成することが、Webサイトの開発となるのです。

では、今日はこの辺で。