新人エンジニア必見！エンジニアとして成長するための6つメソッドとは？

しょごたん

2015.08.27

4. よく使うロジックは共通化する

1つのシステムに対して、実際にどれくらいの文字数記述をしているか・・・なんて数えたこともないし数えたくもないですけど、それこそ何万文字、何万行と記述しております。

ただ、それらを1から毎回全部書く、なんてことはしません。
必要なロジック、よく使うロジックなどは共通化し、ときにはプラグインとして使いまわします。
よくネットでは備忘録として、こういう記述をすればええねんでって掲載されてるものがありますが、あれも共通化ですね。ウチもよく使う関数、こういうときはこの関数、みたいなロジックセットをまとめて使っています。

たとえばWordPress周りで画像のあしらいを毎回書くのが面倒だったときは、

// あらかじめテーマへのパスURLとノーイメージ画像のパスを定数宣言しとく
define('ITEM_URL', get_stylesheet_directory_uri() .'/');
define('NOIMAGE', ITEM_URL . 'images/noimage.png');

/**
 * アイキャッチを取得、なければノーイメージを返す
 */
function _get_eyecatch_data($post_id, $thumbnail, $noimage = NOIMAGE) {
    if (has_post_thumbnail($post_id)) {
        $image_data = wp_get_attachment_image_src( get_post_thumbnail_id($post_id), $thumbnail, true );
        return $image_data[0];
    } elseif(empty($noimage)) {
        return false;
    } else {
        return $noimage;
    }
}

とかを用意していますね。

この関数の第1引数にpostid、第2引数にサムネイル設定の名前を渡せば、必要な大きさのアイキャッチ画像が取得できます。ノーイメージ画像がいらなくて、画像がないときは非表示にさせたいのであれば第3引数にfalseを与えればいいのです。
ただ、基本画像のsrcに設定するURLしか来ないので、アップしたアイキャッチのwidthとかも欲しい場合は例外です。。

時にはコピペでもいいんです。エンジニアって、いかにラクして構築できるかもポイントだと思うんですよね。

エンジニアがWeb製作で作業を効率化できる便利なハードウェアまとめ

しょごたん

2014.04.15

上の記事のように、多ボタンマウスやキーボードを利用して物理的にラクするというのも一つの手ですね。
最近モニターを横から縦にして扱ってみたいと思ってるんですよねー。（ﾁﾗｯﾁﾗｯ
べ、別にサボってるとかそういうんじゃないんだからね！　か、勘違いしないでよね！ﾌﾟﾝｽｶ

5. 誰でも途中から開発・引継ぎができるよう可読性も視野に

開発した人しか対応できないものにしてしまうと危険です、休めません。
それこそ24時間いつでも休み関係なく対応しますよ！って意気込みがあるならいいですけど、ウチはそんなんイヤや、いけずや。

いざというときのために、容易に引き継ぎなどができる準備はあったほうがいいです。
gitやCVSでソース管理を行う、システム仕様やサーバ情報など重要情報をドキュメント化する、などはもちろんのこと、ソースの書き方も気をつけておくべきだと思います。

コレも人によってさまざまでしょうけど、ソースコードのガイドラインを社内共有して誰もが同じようにコード記入していると、いざ他の人が引き継いだときも対応が早いですし、何より誰でもフォローできるって、素敵やん？
条件分岐でも三項演算子を使った書き方は好きじゃないですね、読みにくいし。endif;とかendforeach;とか使う書き方も同様。。

こちらは企業の特質で色々変わってきますが、その点も議題にして話し合うべきだと思いますね。

6. 不具合が起こったら9割以上自分のせいと思う

がっちり設計してても実装中にうまくいかないときがあります。それでデバックするんですけど、めちゃくちゃ時間がかかってる人を何人も見てきました。
そういうときにフォローで入ると、ものの数分であっさり解決できちゃったりするんです。

別にコレは経験値の高い低いや、知識の多さとかそういうんじゃなくて、意識改善する必要があると思うんですよ。解決に時間がかかる人は大抵「なぜダメなのか？！うまくいくはずなのになんで？！」と焦っていると思います。
このままだと思考がとまってしまってしまいます。

言っておきますが、不具合の9割以上は自分の実装ミスが原因です。1割かそれ未満で、使ってる言語やバージョンやブラウザの仕様、APIの不具合とかです。

冷静にいま何が起こっているのか、どこまではセーフでどこでアウトなのか。自分がどこで何をやらかしたのか。意識的に流れを追っていきましょう。
そこでダメなところが明確になれば、以前記事にした対応策の調査方法のように時間短縮に繋がると思います。

バグの存在しないシステムなんて絶対ないですから。。。悲しいことに。。。あ、もちろん限りなく0に近くするよう努力して作ってますからね！か、勘違いしないでよね！！ﾌﾟﾝｽｺ

まとめ

いかがでしたでしょうか。
最新技術やツールを追いかけるのも大事ですけど、それ以前に最低限エンジニアとして満たしていかないといけない考え方や思想って必要だと思います。
もちろん一朝一夕でできるものでもなく、数をこなすことで身につく経験則などもありますけど、いきなりばーって始まってばーって終わるより慎重に物事を見て動いても良いんじゃないかと思います。
新しくエンジニアを始めた皆さんにとって、少しでも成長の参考になればと思います。

それでは。

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。

Webサイト制作の実績・料金を見る