Subscribed unsubscribe Subscribe Subscribe

リファクタリングを読んで。

リファクタリングについて

リファクタリングとは、プログラムの機能を変えずに、設計と実装を改善することです。 その目的は主に、現存するプログラムのscalability(拡張性)やMaintainability(保守性)を高めることです。 しかし、それがなぜ重要なのかを説明することや、実践することは難しく、すでに定着していない場合は導入がし辛いように思います。 現に現場の実務プロセスでは、バグ改修以外の理由でのコードの改変が認められていないプロジェクトも存在します。 それでもなお、僕はリファクタリングが開発を行う上で有用な考え方だと思います。 それは少し学習しただけでも、以下のような幾つかの気づきがあったからです。

リファクタリングの学習を始めたことによる気づき

  • 良い設計の適用方法のガイドラインになる。
  • IDEなどのツールの活用方法の理解を助ける。
  • テストを書く習慣づけを身につけることができる。

これらはあくまで学習と技術力向上という観点で見たリファクタリングのメリットです。 実際の開発でどのように役に立つかは、まだ経験がないため、その他の方へ譲ります。 つまり、プログラミング上での作法がなぜ重要なのか、それに反するものにどう対処すれば良いのかは学べます。

作法とリファクタリングの関係

例えば変数の命名には以下のような作法があります。 変数名は名詞で、省略せず、短く簡潔に意図を伝えるようにすること。

これを守ることで、同じ変数に対する複数回の代入は行いづらくなります。 なぜなら意味に反する値を入れるわけにはいかないからです。(プログラム上は出来ますが、論外です) すると、結果的にはそれによって式の結果を保持する一時変数が増えます。

ここで例えば、問い合わせによる一時変数の置き換えというリファクタリング手法を適用します。 式の結果を変数に格納するのではなく、式の結果を返すメソッドを作成し、それを利用する。というものです。 このメリットは、メソッドとする事で、その他のプログラムから利用できるようになる事です。

すると、必然的にメソッドが増えていきます。 そうなれば、クラスの抽出というリファクタリング手法が使えるかもしれません。

このように考えると作法が、これらの単純な設計上の問題を導き出すことがわかります。 このようにして、プログラムを書いている中で生まれる設計上の問題に対して、どう対処すべきかをリファクタリングの手法は教えてくれます。

実際のプロジェクトへの適用

個々人による開発能力を向上させることは、多かれ少なかれ全体へ影響を与えます。 上にあげたようにして、個人が良い設計を行なっていく。というような場合にはリファクタリングには大きな価値があると思います。 しかし、実際のプロジェクトへ抜本的に導入することは難しいかもしれません。

なぜならば、個々人の能力と取り組みに左右されることが大きいように思うからです。 それにあくまで拡張性と保守性への改善の取り組みであって、機能追加のような見える成果は出づらいからです。 しかし、よく整理されたプログラムは開発の速度へ影響を与えます。 開発期間中に要件が変わる場合、その場で拡張性が求められることもありえます。

日頃から、プログラマ個々人がすべき時にすることとして、徐々に始めるしかないのかもしれません。

まとめ

マーティン・ファウラーリファクタリングを読んで、実際に幾つかのテクニックを試してみて気づいたことをまとめました。 個人的に一番興味深かったことは、変更を加える際、既存のコードを残したままに変更を加えていた事です。 そうする事で、終始テストはグリーンのまま、レッドになった際は手順のミスが発覚します。 以前は、自分はいきなり破壊的な変更を加えるような事もあったため、安全な手順を踏んだ変更を加えるための手順と原則がわかった事は重要でした。

プログラマに必要な能力とは

プログラマに必要な能力といえば何が思い浮かぶだろう。 それぞれがそれぞれに考えがあるように思うけれど、自分にとってはその時々によって答えが変わってくる質問だと思う。 今の自分ならデザインパターンリファクタリングの手法を用いて、設計上の問題を解決する能力を思い浮かべる。

ちょうどマーティン・ファウラーリファクタリングを読み始めたばかりだが、自分はつくづく影響を受けやすいのだと思う。

この質問は時々問い直して、自分の答えの推移を見れたら面白いかもしれない。

SNSとしてのGithub

まず始めに、僕はGithubが大好きです。 なぜならGithubはエンジニアの理想を体現していると言っても過言ではないからです。

何かを食べた、何かを観た、聴いた。どこどこへ行ったというような情報はSNSに溢れています。 面白画像や動画、アンケート、ちょっと食傷気味になるくらいにいろいろなコンテンツがあります。 SNS上では人が何を考え、何をしたかを共有しています。

僕はGithubでも同じことが起こっているように思います。

例えば好きなアカウントをフォローすることができますし、Starを投げて応援することもできます。 コミットログはタイムラインに成りえますし、コードは投稿されるコンテンツです。

常に重要なことに目を向けたい、何かに貢献したい、そういう人達にとっては、一番楽しいSNSたり得ると思います。

1年目のプログラマとして今年を振り返る

はじめに

1年目のプログラマが、今年一年で触れた技術について振り返りたいと思います。 現在はWeb系の受託開発及び技術者の人材派遣を行っている企業に勤めています。

プログラマとして働き始めたのが去年の10月ですが、今年が1年目ということもあり、自分が触れた技術と資料などを忘備録としてまとめようと思い立ちました。

ちょうど友人が来年度からプログラマとして就職するという話も聞いていて、1年前の自分と彼に記事を書くとしたらどんなものが良いかな、と思いつつ書きました。

アウトライン

今年使用した技術

言語とツール

今年を振り返って

1年を振り返れば主にWebを基盤としたシステムの開発に携わっており、Javaをメインに開発していました。 自主的にRubyを学習したり、案件で必要だと言われPHPを学習したり(結局業務では使わず)、目標を定めずに学習してしまったのは効率が悪かったなと考えています。 しかし、それぞれの文化的な違いや記述の違い、得意分野などを大まかにでも知れたことは良かったと考えています。

来年の目標

来年度は合目的的に学習することを目標として、 今後も業務でも多く用いるであろうJavaをメインに、Rubyを自学したいと思っています。 理由としては以下が挙げられます。

  • Javaとその周辺技術に興味がある
  • Web系のBtoC開発を行う事を目標としていること

まず一つ目ですが、型による補償が手厚い言語の元で開発、テスト、デバッグの基本を身につけられたことは良かったと思っています。 データ構造やアルゴリズムを学習していくと、Javaの堅さはそれらに基づく抽象データ型を表現するにはメリット足り得ると気づけました。

二つ目ですが、自分がやりたいことは、BtoCのWeb開発だということ気づいたため、それを目標としています。

その為そこでの需要があるであろう言語に熟達したいという事、 またタイプの違う二つの言語に触れることはプログラマとしてのスキルを磨く良い方法だと考えているからです。

動的型付け言語に対する興味もありますが、コミュニティの文化の違いも個人的には興味深いです。

開発環境

去年初めてプログラミングを始めた際には、苦しみながらC言語を学んでいました。 そのため、ターミナルでソース作成、コンパイル、実行を行っていました。 何故Cなのかという話ですが、単純に何も知らなかった上、プログラミングとやらが出来ればそれで良いと思っていたからです。 仕事を始めてからは、ほぼほぼEclipseを使ってJavaで開発していました。 もともとキーボードショートカットマニアなところがあり、効率的に作業ができそうな場合には、都度調べて統合開発環境のキーボードショートカットを覚えていきました。 それを社内で公言していたこともあり、たまに先輩などからも質問されたりと、自分のキャラクターになってきているのは自分でも良い傾向だなと思っています。

zsh, vim, tmuxは b4b4ro7さんのqiita記事、さいつよのターミナル環境を構築するを読み、思い切り影響を受けた結果です。 Dotfileを作成しましたが、実務ではほとんど利用できず、メンテナンスもできていないことが残念です。

来年度の目標

来年度は、Javaの開発環境に関しては業務上レガシーな事が多かったため、自宅で最新の環境を構築する事と、rubyの学習を含めターミナル環境をメンテナンスすることを目標とします。

情報収集と学習

全体的にインプットに対してアウトプットが足りていない事が問題だと考えています。 読んだ書籍について、自分で解決した課題について自分自身でまとめるだけでも定着度が違う事は経験でわかっていますが、焦りから大量に情報を欲する癖があるため、それらの整理が来年度の課題になると考えています。 対策として、以下を定期的に行える環境を作るつもりです

  • ブログやqiitaなどで記事を書く
  • 社内での発表の機会には学習した事を発表する。
  • 個人プロジェクトの公開を目標に、計画的に学習をする。

書籍

読んだ書籍に関しては、 趣味として読んでいたプログラマとしての心構えや方法論について書かれたものがほとんどです。 こちらはよくネットで進められているものを、出退社時や昼休みに読んでいました。 個人的には良い頭休めと、知識の下地になったと思っていますが、意識に技術と環境が追いついていない感覚が常にありました。 実際の現場では、本で読んだアンチパターンが沢山起こる事、本を読むだけではコードは書けない事を学びました。

技術書に関しては、必要に迫られて読んだものが多く、Java関係が3冊にRuby関係が1冊、PHP関係が1冊という結果です。 実際に手を動かしたものに関しては、振り返ってみても定着しているため、来年度は技術書の割合を高くして、手を動かしつつ読む事にします。

指南書

入門書

専門書

Web記事

やはり最新の情報を集めるには、Web記事はいいなと思います。 環境構築の手順や、ツールの利用方法、サンプルコードが載せてある記事からはとても恩恵を受けました。 しかし、それらを体系的に管理するツールを知らず、ほとんど記録を残せていないことは勿体無いと思っています。 今後は、ウェブクリップでも良いので、何か良い方法を見つけて管理したいと思っています。

ただ、1年間で公式の情報に敵う情報はないことだけはわかりましたので、公式のドキュメント読む前にググることはもうやめます。

エセ医療系サイトの問題もありましたし、悲しいことにWebは今あまり綺麗ではないのかもしれません。 プログラマの心構えや基本的な考え方についての記事に関しては、プログラマが知るべき99の事とリーダブルコードで必要な知識は十分揃うと思いますし、似たような記事は多いです。

ただ、独自の主張をしている記事は面白いですし、むしろ本では手に入らない生の声に近いものがあると思います。 個人的に以下に今年印象に残った記事をまとめました。

最後に

最後に、今年一年を振り返って

良かった点

まず良かった点から振り返ると、

  • 1日に一問問題を解くことを始めた
  • 多くのものから貪欲に吸収しようとしていた
  • 空き時間を有効に活用できていた

今年の後半から始めましたが、プログラミングの問題を1日一問解くことを初めてから、少しずつですがコードの質が上がったように思います。 データ構造やアルゴリズムといったアカデミックな知識に対する意欲も生まれるという副次的効果もありました。

また、自宅で自分自身で興味を持ったことを積極的に試していたことは、評価できるように思います。

通勤時や昼食休憩時、意図せず列に並ぶ羽目になった時には、本を取り出す、kindleまたはpocketにためていた記事を読む、podcastを聞くと言った行動を選択するように心がけていたことも、○です。

反省点

次に反省点ですが、

  • 仕入れていた情報が古いことがままあった
  • 自分自身の方針が不明瞭だったこともあり、触った程度で全く身についていないものも多くあった

原因を分析すると、 一点目に関してはアウトプットが少なかったことと、それによりフィードバックが足りていないことによるものと思われます。

二点目に関しては、元来飽き性なことと、事前知識が乏しいままに色々なものに手を出した結果、手を出しては引っ込めの繰り返しが多かったためだと思われます。

今後の目標

反省点に対する改善策としては

  • 計画的に物事を進める
  • 積極的に他者と関わり、新たな情報を仕入れる。
  • アウトプットを行った上でフィードバックをもらい、改善に努める

  抽象的な目標としては、 また現在わからないことは、わからないと認め、それを表現すること。 全てを自己解決しようとしないことは、学習や成長においては大事なことだと思います。

また年が明けた際に、上記に沿った具体的な目標を立てていこうかなと思っています。

それでは皆さん、良いお年を。 

ブログを始めてみる

ブログを始めてみることにした。

簡単に自己紹介と、このブログの趣旨、ブログを始めるに至った経緯をまとめる。

 

まずは自己紹介

職業: アシスタントプログラマー

趣味: 音楽、読書、プログラミング、たまにゲーム

好きなもの: 音楽と、キーボードショートカット、文字のみのコミュニケーション

 

なぜブログを始めるのか

一言で言うと、自分の考えを表現することが必要だと考えたからだ。

それを細かく分けるなら、主に3つの理由がある。

さらにそれらをリストにまとめると、

  • 社会人1年目として業務をこなす中で、自分の考えを表現する能力が求められているため
  • 日々の中では消化できない疑問について、自由に考える場所が欲しいため
  • 自分自身の発表の場を持ち、それらを人に見てもらいたいため

以下に、それぞれを詳しく考えてみたものをまとめる。

 

資料を作成する能力

アシスタントプログラマとして、

業務をこなす中で気づいたことは、

想像していたよりもドキュメントを作成することが多いということである。

会話でのコミュニケーションも多かったが、成果物としてのドキュメントを求められることがとても多い。

 

例えば、業務ではコードを書く前に、まず設計書というものを書くことになる。

プログラミング言語でのコーディングの前に、自然言語によって要求と仕様を明らかにするという為だ。

 

いきなりコードを書こうとして、失敗した経験も確かに多かった。

それならばいっそ、文章を書き、人に伝える、という能力を身につけようと思った。

 

日々の中で生まれる疑問について考える

例えば、もっとうまくやれるのではないか?

なぜこれをしているのか?

これを突き詰めていって初めて、自分ならこうするはずだという考えが出てくるのだと思う。

 日々の疑問点をそのままにせず、自分の考えにまで昇華させたい。

そう思ったのが二つ目の理由だ。

 

自分自身の発表の場として

昔から創作に対しての興味が強く、絵を描いたり、音楽を作ったりしては遊んでいた。

今では自分自身仕事でシステム開発などに携わっているものの、個人でツールやゲームを開発している人にはそういう意味でも憧れがある。

 

そのために日々勉強したこと、自分で何か作ってみたこと、そしてそれらをまとめ、発表する場所がと考えたことが三つめの理由である。

 

これが一番単純な動機だが、単純なことってそんなに悪くないじゃん。とも思う。 

 

とまあ、始めた理由はこれで良いとして、では何をしますか?という話だ。

 

ブログの趣旨について

簡単に言えば、音楽、プログラミングについて、日々の学習や創作のまとめをしようと思う。

 

以下に、その頻度と、トピックについてまとめる。

メイントピック: 創作の息抜きと、やりたいこと

サブトピック: 学習メモと、そこからの発展

たまに: 時事ネタと考察

上の三つを軸に、継続しながら考えてゆけたらと思う。

 

大事なことは継続と、気楽にやること。

 

三日坊主にはならないように。

 

ではでは。