Aikの技術日記

技術的な進捗とか成果とかを細々と投稿するブログです。時々雑記も。

コーダー経験をしてみて感じたことまとめ

はじめに

お久しぶり?です、筆者です。

最近お仕事で「デザイン経験10年程の方のレビュー付き」HTMLとCSSを組む機会がありまして。
こちらの記事でもちょっと書いたやつですね

前回の記事では「レビュー自体にフォーカスを当てた話」をしましたが…。
「レビューを経て学んだ事」についても書き留めておきたいなと思いまして。

というか、HTMLとCSSを独学で学び、「見栄え自体はそこそこなコードが組める」筆者にとっては目から鱗な知識がいーっぱい学べましてね…。
記憶が新しいうちに、こうしてブログにしたためておきたいなと思った次第です。

それではいきましょう。

学んだことその1: div依存症からの脱却

レビューを受ける前の筆者は、HTMLについては最低限のタグの知識しか持っておらず…。
sectionタグやarticleタグを使わず、要素の塊は全てdivタグで定義しておりました。

まぁもちろんダメ出しを食らうわけで。
「divdivしい」と形容されたそのコードは、たくさんのdivタグで埋まっていました…。

ただ、筆者はdivタグをどう使うのかが良いHTMLなのかわからず…。
レビュー担当者の方に聞いてみたところ、「divタグは何かをグルーピングするときに使う」と言ってくれました。

「それなら要素の塊もグルーピングじゃん」と思いましたが…。
「要素の塊を定義する時はsectionやarticleタグを使おう」と言われてなるほどと感じました。

これらの様な「要素の塊を定義できるタグ」は他にもいくつかある様で。
代表的なものだと下記の6つですかね:

  • section: 汎用的なセクション(文書やアプリケーションの一部分となる、意味や機能のひとまとまりの)に対して用いる
  • article: 記事に対して用いる
  • aside: 補足情報(余談や補足情報など)に対して用いる
  • nav: ナビゲーションのまとまりに対して用いる
  • header: ヘッダー部分に対して用いる
  • footer: フッター部分に対して用いる

これらのタグにももちろん意味があり、その意図どおりに使った方がもちろんいいです。

ちなみにこうしてタグを使い分けるのが何故いいのかというと「ブラウザ側、つまり計算機側が要素を適切に理解してくれる様になるから」とのこと。

全てがdivタグで埋め尽くされたHTMLでは、「どの要素がページ内の題目部分なのか」「どこから何処までがヘッダー部分orフッター部分なのか」計算機が読み取るのは不可能です。
しかし丁寧にマークアップされたHTMLなら、「どこから何処までがどんな意味を持つ要素なのか」が、計算機でもわかる様になります。

これはそのままSEO対策にも繋がるとのこと。
筆者の勝手な推察ですが…適切なマークアップのおかげで「このページがどの様な情報を持つのか」が分かりやすくなるから、ですかね?

ちなみに…。
もし自分の組んでいるHTMLに自信がなくなってきた場合は、CSSを外してHTMLを表示させるといいとのこと。
CSSを外して自分の意図通りの内容がきちんと伝われば」、HTMLとしてはまず問題ない様です。

学んだことその2: 拡張性に富むコードを組むという概念

これまで筆者はJavaScriptC#などよ「プログラムのソースコード」については「保守性や拡張性に富んだ作りにしよう」と考えていましたが…。
その考えをHTMLやCSSに当てはめた事がなく。
HTMLやCSSがその後改修されメンテナンスされていく事を意識したことなどありませんでした。

レビュー者から「後での改修が容易になるようなコードを組むと色んな方が助かる」と言われたのは衝撃的なことでした。

…しかし思えば、保守開発フェーズにいる筆者も何度も「構造が分かりにくいHTML」に悩まされたなと。

「ここの部分をちょっと間隔開けたい…」となっても該当箇所にclass属性が付与されてなかったり、既存のCSSの影響からpタグで囲った要素が大きく表示されたりと、非常に苦労する日々を過ごしました…。

この様な悲劇を生まないためにも、拡張性に富むコードを最初から組んでおくのは重要な事だと改めて気づきました。

余談ですが…。
「HTMLの組み方は人それぞれで個性が出る」とレビュー者がよく言われてました。
確かに自分の作成したHTML構造と、自分が関わるプロダクトのHTML構造はかなり違います…。

今絶賛保守開発中のHTMLを触るにあたり、「どうしてこの様なHTML構造になっているのだろう?」となる時も多々あり。
そう言う時は、コードを作った本人に聞くしかないですが…。

…コードを作った当人が、プロジェクトから抜けたと言うか、もううちの会社にいないんですよね。
もしそうやって抜けられたとしても、分かりやすいコードを書くためにも、分かりやすいHTML構造を作るのは大事だなと感じました。

学んだことその3: コーダーの方の凄さ

今回のコード作成を通し、「コーダーの方の凄さ」を理解できたなぁと。
今回学んだものの中で、最も重要だなぁと思った事がこれです。

美しいコードを作るには、HTMLやCSSの知識だけでなく「様々なレイアウトパターンを理解し、その状況状況にあった最適なレイアウトパターンを利用しないとだめ」な事が分かり。

それこそ、2カラムレイアウトを組む方法だけでも:

  • flexを使うパターン
  • floatを使うパターン
  • gridを使うパターン

の3パターンがあり。
どんなデザインを組むか、どういうデバイスに対応させるかでどのパターンが最適か変わってきます。

CSSは色んな書き方や解釈があるが、重要なのは「どの書き方がどの様な特性を持っているのか理解すること」。
その理解を踏まえた上で、この「状況に応じた最適なパターンを選びコード化する」…。

これは非常に難しいことなんじゃないかなと思います。
HTMLやCSSの基礎知識の他にも、たっくさんのデザインパターンを頭に入れないといけないですからね…。
一朝一夕では身につかないものでしょう。

また、この学んだことから:

  • 優秀なコーダーがいかに鍛錬を積んできた人材であるか
  • HTML/CSSコーディングの大変さ
  • HTMLとCSSコーディングにどれだけ作業工数がかかるかの把握
  • 今後HTML/CSSの上達には様々なレイアウトパターンを理解し吸収していく事が肝要

…であることが分かりました。
上記知識は「今後行うHTML/CSS組み」作業中に非常に活かせる経験だと感じますし、今後コーダーの方と一緒にお仕事をする上でも覚えておきたい知識だなと感じます。

おわりに

今回はコーダー経験を通し感じた事についてまとめてみました。

今回感じたことは、今後お仕事をする上での大きな糧になるだろうなと確信しています。
おまけにたった2週間のコーダー経験で、ここまでの所感を得れたことも大きいなと。

こうした濃密な経験をしていくと、いい成長を産めそうですね( ˘ω˘ )
それでは|д゚
)

情報処理技術者試験(FE)の過去問を解いた所感まとめ

はじめに

筆者のPC内部ファイルを大整理してると、2年前…。
「2018年度の基本情報処理技術者試験」に向け、過去問を解いた感想が書かれたメモファイルが見つかったので、折角だし公開しちゃおうかなと。

「過去問を解いていた中で感じた所感のメモ書き」なので、過去問の解説とかを書いてるわけではありません。
総じてあまりタメになるような事は書いてないかも…。
ご留意をば。

それではいきましょう。

試験形態

  • 午前と午後の問題に分かれる
  • どちらも2時間半(180分)
  • H21年度以降より問題形式が変わったらしい
    • 過去問解く際はH21年度以降のものに取り組もう

H30春〜H28春の4回分をやった手応え

午前試験について

  • 全80問、1問1.25点
  • 1問2分でやると20分のあまり時間ができる感覚
  • 過去問から問題が出ることが非常に多い
    • 解説サイトには5〜6割とあったが、個人的な体感は6〜7割
    • 問題として出てくる分野にも偏りがある(システム監査人とかは毎年出ていた)

自分なりの解き方/試験の臨み方/勉強方法

※H30春〜H28春の4回分の過去問をやった手応えから感じた分のみ記載

解き方/試験の臨み方-午前問題

  • 大抵時間が余ることが多いので、慎重に丁寧に1問1問取り組もう
    • 残り時間の猶予は気にしなくておそらくOK(過去問やってる時も解説見ながらで2時間〜2時間半程度で終わってたし)
  • あまり時間がかかり過ぎれば飛ばして〜ぐらいで
  • 計算問題/頭使う問題は3分くらい時間かけてもいいかもしれない
  • 時間配分は下記のような感じで
  • 見直しを慎っ重に行おう
    • 過去問を解いていく中で計算ミスなどのケアレスミスが非常に多かった…
    • 見直しがしやすいよう、メモは丁寧にわかりやすいのを残しておこう
  • 用語がわからなくてもその用語の言葉の意味等を考えればわかる場合がある
    • 最後まで諦めないこと!大丈夫!
  • マークシート記入ミスには注意しよう
    • 特に午前問題は回答数が多いので、マークシート記入を見直す時間を10分〜15分くらいは取っておこう

解き方/試験の臨み方-午後問題

  • 頭を非常に使う問題、なるべく頭を使えるようにお昼しっかり休憩しよう
    • ご飯をすぐに食べてゆっくりしておくのがいいかも?外を散歩とかもしてみてもいいかも
    • 諦めることなく丁寧に1問1問考えよう
  • 問題の説明文が長いことが多いが、この説明文さえ理解すれば後は簡単
    • 説明文をしっかり読もう
  • 後からの見直しに備え、図示やメモを欠かさないように
    • 問題の説明文が長い問題については、その説明文の理解ができれば問題文自体は大した分量じゃないことが多い
    • 念のため開始直後に問題文の分量を確認することも大事かも
  • 午後問題は時間勝負、特に大問8と9のプログラミング問題には注意して臨もう
  • 時間配分は下記のような感じで
    • 大問1〜大問7: 10分〜15分
    • 大問8/大問9: 20分〜25分
    • 見直し: 25分
  • プログラミングの選択問題については、基本大問9のC言語を選ぶようにしよう
    • C言語によほど自信がなく、時間が余ってたらJavaに取り組んでみよう
    • Excel問題は…正直微妙、やめといた方がいいかも
    • C言語Javaも半分も取れそうにないって状態になったなら、この年はおそらくよっぽど難しい試験だった感じだと思うので…
  • 選択問題については、大問の概要欄や問題自体を見て解けそうな問題を選ぼう
    • わからない用語を求める問題/緻密な計算が求められそうな問題はパス
    • DBとソフトウェア設計問題は安パイ
  • 過去問で試してみたが、自分の「これいけそう」という感覚にハズレはないっぽい。自分の勘を信じよう

勉強方法

午前問題

  • 知識を問われる問題が多い
    • 短期的な学習でも十分に効果が見込める、1.5〜2週間程度勉強できれば十分かも
  • 過去問の復習を徹底的に行おう
    • 過去問と同じ内容が出るパターンが非常に多い
  • 選択肢になっている問題が別の年で聞かれることは稀だが、変わらず選択肢として出る場合はある
    • 消去法で選べるようにするため、選択肢になっている用語も余裕があれば抑えておこう
  • 当日ギリギリまで知識を詰め込もう、詰め込んだだけ力になる

午後問題

  • 頭を使う、地頭の良さが問われそう
  • 正直短期的な学習で効果が出るとは思えない
    • 過去問で最初から既に60点くらい取れるのであれば、問題形式に慣れる/どの問題が得意か見定めるくらいの勉強でOK
    • この場合4回くらいやれば感覚は掴められそう、2週間程度勉強できれば十分かと
    • 理系で日々プログラミングに慣れ親しんでるとかであればかなり楽に行けそう
    • 過去問で20点くらいしか取れないのであれば、かなり長期的に勉強しないときついかも
    • 2ヶ月、3ヶ月単位で考え方になれるかコツを掴むかしないときついかなぁ
  • 毎日1個ずつ過去問/類似問題をこなす感じでいいかも、その後の見直しより考え方や解き方を学んでいく感じで
    • 前日に復習とかは正直いらないかも
    • 解き方や考え方に触れ直すくらいでいいかな?

おわりに

改めて見ると、ざっくばらんな感想って感じですね…。
余談として、基本情報処理技術者試験の個人的な所感を書いてみました。
もしよければ見てやってください。

それでは|д゚).

余談: 基本情報処理技術者試験の個人的な所感

ここからは余談として、基本情報処理技術者試験の個人的な感想をば。

本試験について、筆者は下記の様に感じています:

  • 資格がある事よりも「その過程の勉強に価値がある」もの
  • 情報系の学生なら取らなくてもいい(授業でやってるはずだから)
    • 腕試しで取るのはありかも
  • 文系プログラマになるなら取っておいた方がいい資格
    • この資格の勉強の過程で、情報系大学に通う学生の半分程の知識がつきそうだから

また…。
最も感じる点としてはこの資格があるからと言って技術力があるというのは誤解を招きそうだという事です。
※個人の所感です

本資格は「基礎を固める」という点においてはいい資格だと思います。
プログラムとは何か、PCもとい計算機とは何かなどの「普段PCに触れているだけでは気づかないであろう概念」について広く浅く取り上げてくれているからです。

ただ、この資格勉強をしたからと言って「最新の技術知識を身につけられる」事はありません。
※個人の所感です

技術の世界は日進月歩であり…。
本当に技術力を付けるには、日頃から常に技術情報をキャッチアップしていかなければならないはずです。
※個人の所感です

最新の情報を得たいなら試験を受けずとも、ネットに転がっている記事を読むだけで十分じゃないかなぁと思います。

コードレビューを受けて気づいたことを書いてみました

はじめに

お久しぶり?です、筆者です。

最近筆者が勤める会社にて、HTMLとCSSのレビューを受ける機会がありました。
会社ではこれまでC#JavaScriptのレビューしか受けた事がなく…。
また、レビュー者もこれまでのレビュー者とは異なる方であり。

HTMLやCSSの知識も付きましたが…。
異なる方々のレビューを受け、 レビュアーによるレビューの質の違い をまざまざと感じました。

結論から言うと、両者ともレビューの質は良かった様に思えます。
…が、両者とも「異なる方向性で」良いなぁと感じましたため。
今回の記事ではこれらの違い等を書いていければと思います。

((結構容赦なく比較してるので、この記事をレビュー当人が見ない様に…と思いつつ…。

それではいきましょう。

両者の違い

まずは、レビュアーのざっくりとした方向性から。
C#JavaScriptを見てくれた方(Aさん)と、HTML&CSSを見てくれた方(Bさん)2人の違いを端的に言うとこうです:

  • Aさん: レビュイーの「成果物に対して」レビューをする
  • Bさん: レビュイーの「技術力に対して」レビューをする

それぞれについてもう少し深く言うと…。
Aさんは「提示されたソースコードの範囲内でしか」レビューをしません。 それに反し、Bさんは「提示されたソースコードから伺えるその人の技術力を推察して」レビューをなされます。

もう少し深掘りしていきましょう…の前に。
両者とも実は、レビュー環境が違いますのでそちらの話から。
((2人とも異なるプロジェクトに所属してるので、レビュー体系が違うんですよね…。

2人のレビュー環境の違いについて

まず、AさんからのレビューはBitbucketのプルリクエストを用いて行っております。

BitbucketやGithubなどのコード管理が得意なツールをご利用の方は分かると思いますが…。
プルリクを投げると、マージ先のブランチとの差分が見られ、またコード一行一行に対するコメントが可能です。

先に述べた様に、Aさんが細かなレビューをしてくれるのはこの体系だからと言うのもあるかもですね。

次にBさんですが…はい、みんな大好き(筆者は大嫌い) Excel シートを使ってレビューしてくれます。
「コードの何行目に」「どんな指摘点があるか」を事細かに書いてくれます…。

個人的な意見としては…。
レビューされる側が「何行目に提示された指摘点があるのか」探すところから始まるので、ぶっちゃけめちゃ大変です。

個人的には言わずもがな、Bitbucketでのコードレビューの方が嬉しいです…。

Aさん(成果物に対してレビューするタイプ)について

成果物に対してレビューするタイプと評した様に、Aさんは「提示されたソースコード以上の事を言及しません」。
ソースコードの悪い点のみを指摘し、それ以外については何も伝える事はありません。

オジサマによくいる「個人の技術力や成長に関して説法を解いたり」…なんてことはしません。
((Aさん自身はちょいオジサマな年齢です.

また、強い口調で何かを指摘する事なく「このコードはこう治しましょう」と伝えてくれるタイプです。
個人的にはこの「強い口調での指摘がない」と言うのはとても凄い事だと思います…。

また、コードに関する相談、特に「このコードとこのコード、何方がいいか?」的な相談をすると…。
「どっちがいいと思う?」や「こっちのコードにはどんなメリットがあると思う?」と問いかけ、相談者自身に考えさせる機会を与えてくれます。

もし、相談者がそこで詰まったらAさん自身の意見も聞かせてくれます。
ただし、Aさんは意見をくれるだけで決定はしません(Aさんが決定した方が合理的な場合を除く)。
あくまで決定させるのは筆者側と言うスタンスです。

この対応は、筆者が「自分で考え物事を決定するのが好きだから」そう対応している…と思います。
自分で決め切れない性格の方や、状況であればAさんはきちんと決めてくれると思います(多分)。

なお、付加情報として「Aさんは筆者の上司」でもあります。
PL兼PMの方であり、筆者のタスク管理もしてくれてるので…。
Bさんよりも筆者の技術力やキャパシティへの理解、仲の良さは異なります。

そのためか「筆者が自分で判断できそうなレビュー指摘点」については、判断を促す様なレビューをしてくれます。
※もちろんその回答が合っているかのレビュー付き

成長に寄与できる素敵なレビューをしてくれるなぁといつも感心してます…。
((それに、考えさせた方がレビュアーとしても楽な時もあるでしょうしね

また、相談をした際に話が煮詰まってきたり、互いにズレた認識をしてる事が察せられると「一度仕切り直して」「自分がどう感じてその話をしてるのか」を伝えてくれます。
((「僕はこう思ってるんだけど、筆者さんはどう感じてる?」という風に話してくれます

相談事になる様な事は、明確な答えがない場合もあるため…。
無駄な話をして気を揉んでいくのが防止され、効率的に話ができるいい手段だなぁと感じます。

また、Bさんと比較して「口頭での指摘がほぼありません」。
レビューに関するやりとりは全てチャットで完結できるほどです。
この辺りは「Bitbucketのプルリクで行っている」レビュー環境に起因する部分も多いかもですがね…。

ただ、一つ気になる点としては「コードについて褒めたりすることがないこと」です。
「ここの書き方いいですね!」という様なコメントはしません。

筆者は「+の評価をしてくれると、それが自信に繋がり学習意欲にも繋がる」タイプなので…。 個人的な感想ですが、調子に乗らせない程度に評価してもらえたらもっと良いなと思います。

((こうして書くと、Aさんレビュアーとして優秀すぎますね….

Bさん(技術力に対してレビューするタイプ)について

技術力に対してレビューすると称した様に、Bさんは「提示されたソースコードから窺い知れる技術力」にレビューをする傾向が見られます。

レビュー対象分野がHTML&CSSという「ど素人が適当に書いても見た目的には整ってしまう」物であり…。 「デザインの意図や今後の改修性を考慮して書かれたコードであるかどうかを見ている」
= 「提示されたコードがどんな意味を持って書かれているコードなのかを推察してレビューする必要がある」
…からこそ、コードよりも「どういう意図を持ってこのコードを書いたか」に重きをおいたレビューをしているからしれません。

もちろん、見た目が整っているだけのコードがレビューを通るはずもなく…。
その様なコードを提示しレビューをされた時は:

  • HTMLのdivタグはタグが示すdivisionと言う意味を考えて付けて欲しい、例えばこのタグは〜
  • CSSのmax-width属性は「width属性で指定した値が相対値である時に」「この値以上は広がって欲しくない時に使うもの」であるので、max-widthに相対値を付けるのはよくない

…など、タグや属性が持つ考え方や意味をという指摘が多くありました。
個人的には、概念や考え方レベルで話してくれると理解が深まるので、ありがたい限りです。
((その分レビューに時間をかけちゃいますが…

また、先の様な深いレビューがあるからか…口頭でのレビューが多い印象もあります。
個人的には、口頭で伝えてくれる知識は非常に深イイ物ばかりなのであまり気に留めてはないです。
((こちら側が求めることなく深い知識を伝えてくれるのは、ありがたい事です….

それに、先に挙げた様な深い知識を文章に起こすのは大変でしょうしね。

なお、口頭レビューの内容はそこまで重要じゃないためか、「ソースコードの何行目にどんな指摘があるか」が記載されてるレビュー結果シートにはその内容が書かれる事はまれです。

「キチンと書いてくれよ!」と思わなくも無いですが、「口頭でのみ伝えられた指摘点が修正されてないからと言って再度ツッコミが来る」事は今のとこないので…。
「最低限これだけ修正すればOK」な事が書いてあるシートが別途あるのは個人的にはありがたいです。

ちなみに…。 Bさんはコードについて相談事をすると「相談事の範囲から少しズレた大きな話」までしてくれる事が多いです。
…まぁ、欠点としては言わずもがな、「業務時間を無駄に取られる」事ですかね。

レビューされる側の所感

※ここからは、筆者の率直な感想が記されています。
あくまで一個人の感想として、捉えていただければと思います。

総合的に見て、筆者はBさんのレビュー体系の方が好きです。
レビュー環境(プルリク方式)もそうですが、必要最低限のレビューしかしないBさんの方式の方が、レビューをする側もされる側も負担が少ないなぁと。

また、Aさんのレビューは基本「文書ベースで解決する」と言うのもいいなと。
口頭でのやりとりが少ないので、緊急事態に陥り遠隔地からしか仕事できなくなった!…と言うような状態でも、Bさんの様なレビューなら受けやすそうだなと感じます。

技術力的な成長に繋がるのは確実にBさんであると思います。
「こちらが聞かずとも、ためになる知識を勝手に供給してくれる」方というのはとても貴重だと感じます…。

ただ、あまり学習意欲のない方があのレビューを受けると苦痛だろうなとは思います。 筆者は日頃から学習意欲旺盛な様に周りから見られているっぽいので、その様にレビューしただけかもしれませんが。

Bさんが「学習意欲が無さそうな方には、相応のレビューをされる」様な方なら、レビュアーとして最高だろうなと感じます。

おわりに

今回は異なる性質を持つレビュー者の違いについて、自分の思いを書いてみました。
今後、もしまた何か感じる事あれば別途記事化して投下したいと思います。

それでは|д゚).