Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts

Wednesday, December 4, 2013

Code Readability

Go 1.2が12月1日にリリースされました。 そして、同時くらいに社内のGo readability approverの一員になったので、ちょっとCode Readabilityについて書いてみようと思います。

Google社内では、主要なプログラミング言語について Readability というのが存在します。 「C++のReadabilityを持っている」とは、C++のコードをスタイルガイドに従ったコードを読み書きできる能力があることを意味しています。社内のコードベースと一貫したコードで開発できるということです。Readabilityをもっていない人は、Readabilityを持っている人にcode reviewしてLGTM/Approvalを貰わないとコードをrepositoryにcommit/submitすることができません。

readability approverは、ある開発者がその言語のReadabilityを持っているかどうかを判定する/ある開発者がその言語のReadabilityを持つよう教育する役です。

スタイルガイドは言語ごとに、それぞれの言語の特性にあうように決められています。これらのスタイルは、言語のベストプラクティスや、誤りがちなコーディングを避ける方法を示しています。最初は「ルールがたくさんあって、そんなのいちいち気にしてコードなんか書けない」と思うかもしれませんが、慣れてくるとスタイルガイドにしたがっていないコードに違和感を感じるようになってきます。そしてそういうところにバグが潜んでいることが多いような気がします。

個人的な印象としては…

C++の場合は、かなりGoogle独特のルールがあります。が、code reviewする時に、このスタイルガイドに沿ったコードになっていれば、reviewする範囲をchangeで変更した周辺を見ればすむことがすむ場合がけっこうあるようなかんじです。とはいっても言語の罠が結構あるので、ちゃんとreviewするのはなかなかしんどいです。ツールとしては cpplintがありますし、最近は clang-formatなども使われだしてきているようですね。 C++は言語として自由度が高すぎるというか、これといったスタイル標準がないせいで、例えばChromiumWebKitではだいぶ印象が違って、別の言語というかんじもします。

Pythonの場合は、基本的にはPython標準と似たかんじだったと思います。ツールとしてはpylintがあります。 Pythonとかはdocstringをきちんと書いておかないとコードが増えてきたときに厳しいですね。しかもそれはしょせんコメントなので、実際のコードと一致してなかったりするとバグの温床になってしまいます。 code reviewする時も、コードの断片からコードが正しいかどうか見分けるのは困難です。文字列にしてもstrかunicodeなのか気をつけてないと、"Failure: 'ascii' codec can't encode character u'\xNN' in position N: ordinal not in range(128)."みたいなエラーがカジュアルにでてしまうし。Pythonはコードを書きやすいのかもしれないけど、正しくないコードも簡単に書けてしまう/コードが正しいか間違っているか判断するのが難しいという印象です。ちゃんとやるにはテストも大量に書いておかないとだんだん不安になる言語です。

Go言語の場合、基本的なスタイルはgofmtでそろえてくれます。コンパイラもwarningはださず、なおすべき点があればコンパイラがエラーをはきます。 他にもgovetgolintとかもあってよくある問題はコンピュータがみつけてくれます。 Go言語のReadabilityはidiomをちゃんと使っているかどうかという点になってきます。Go言語にも言語の罠はないとはいいませんが、言語仕様もシンプルなので、コードはだいたい見たとおりになっているのもcode reviewしやすいです。

というかんじで、最近は「非常に短いほぼ使い捨てなスクリプト」ならshellとかPythonで書くこともありますが、main以外の関数とかclassが欲しくなってきたら、もうGo言語で書いたほうがいいと思いますね。簡単なものならgo run hoge.goでそのまま実行できますし。また既にある程度書かれているperformance criticalなC++プログラムとかは、そのままC++で変更・追加していっていますが、一から開発するんならGo言語で書くほうが楽しいですよ。

Thursday, June 9, 2011

創造情報学連携講義VII - 大規模分散処理システム

東京大学の工藤客員准教授の創造情報学連携講義VIIの第3回の講義をしてきました。
内容は、大規模な分散処理の特徴およびGFS, Chubby, MapReduce, BigTableなどの具体的なシステムでのやり方などについて説明しました。

Thursday, June 26, 2008

ソフトウェアシンポジウム2008

ソフトウェアシンポジウム2008のパネル・ディスカッション「FLOSSは日本のソフトウェア技術者を救うか〜Don't trust anyone over thirty」にひろのぶさんかずひこさん, Matzさんとともにパネリストとして参加してきました。 FLOSSの4つの自由でソース読んだりいじったりすることでソフトウェアの技術が身につくんですよ、上流→下流よりもコア→アプリケーションなんじゃないんですかね、簡単なことを簡単にできないようでは難しい問題にはかないませんよ、できる人は仕事がはやいからどんどん作ってどんどん改良していくのですぐれた成果物がだせるんですよ、ソフトウェア開発はyak shavingになりがちだけど、やってみないとわからない問題というのはたくさんあるわけで、yak shavingすることで技術力がつくし、その中に真の解決すべき問題があるのかもしれませんよ、Done, Get Things Smart、コードレビューするのは大事ですよ、継続することが大事でそのためには好きであるほうがいいですよ、つまらないと思っているタスクも見方をかえるとおもしろい問題なのかもしれませんよ、とかそういう話をしました。 Q&Aではmatzを説得する方法とかMatzさんに限らず一般的にFLOSSコミュニティで活動する上で大事ですよ とか、コミュニティは大事だけど特に単なるお客さんになりがちなユーザーコミュニティとかはどうか とか。 しかし、ほとんど「上流→下流」な仕事はしたことないのでそういう世界は実際どういうかんじなのかわからないんですが、コード書けない人が設計やっているとか聞くと、それでよく作れるなーとか思うんですがどうなんでしょうか。もしコーダーは設計を機械的にプログラムにおとしているだけというのなら、そこはまさにコンピューターでやってしまうべき(自然言語なんかで記述するよりなんらかのDomain Specific Languageで書いてしまったほうがよさげで、コーダーみたいな人は不要)だと思うし、そうじゃないんなら、そこにはそれなりにややこしい問題が潜んでいることもあるわけで、重要な部分は技術力があって経験豊富な人がしっかりと実装しないと駄目だろうと思うわけです。実装しないと設計の問題がわからないことはよくあることです。実装しなくてもきちんと設計できるっていうのはよほどすごい人か、そもそも大して難しくないシステムかのどっちかじゃないかと。 仕事もあるんで、シンポジウム自体は3日あるけど初日のキーノート、パネル、懇親会だけでてさっさと帰ってきました。 さて、高松に来たからにはうどんを食わなければ、というわけで3食たべてきました。 まず高松空港からリムジンバスで到着した高松駅の近くで発見した「連絡船うどん」 夜は懇親会で結構食べたけど、その後町のほうにでかけて「北古馬場ごえもん」 朝早く起きて駅の近くの「味庄
大きな地図で見る

Thursday, April 24, 2008

WEB+DB PRESS Vol.44

WEB+DB PRESS Vol.44に「優れたソフトウェアを作る プログラミング5つの鉄則」というタイトルの特集を書きました。 一応 新社会人あたりをターゲットに、きちんとソフトウェアを開発するにはどうしていくのがいいのか という話をまとめてみました。 去年の ITPro Challenge! の時に、技評の編集の人につかまって「書いてみませんか」ということで書いてみたのですが、いざきちんと説明しようとするとなかなか難しいものですね。 特に最近フリーソフトウェアいじりをあまりしていないので適当な具体例がなかなか思いつかずに苦労しました。Google社内の開発手法はちゃんとしていると思うのですが、それはあまり具体的なことは説明できないので…。 Google社内では、プログラムをきちんと設計・開発できる人ならこうしたほうがいいと考えているようなある意味あたり前のことをきちんとやっているだけなので、それを説明できればいいんですが、あたり前に感じてしまっていることを、まだはじめたばかりの人にちゃんと理解してもらえるような説明を決められたページ数でするというのは難しいものですね。 もっと詳しく知りたい人はCode ReadingCode QualityCode CraftShip It!My Job Went To Indiaあたりを読んでもらうといいかと。

Tuesday, September 11, 2007

ソフトウェア技術者はまずソフトウェア技術のことをもっと知ったほうがいい

ソフトウェア開発者は製造業のことを知った方がよいから。製造業のことは詳しくは知らないので知った方がよいかどうかの判断はできませんが、ちょっと気になったところ。
我々の作るものには物理的制約がないこと
はよく言われるけど、そんなことないでしょう。少なくとも光のスピードを越えられない以上、計算速度の限界があります。それに実際問題として、速度と空間はトレードオフの関係にあることも忘れてはだめでしょう。 時間と空間(記憶容量)は我々に制約をかけてます。メモリ上なら(cacheにのっていればさらに)高速に計算できますが、メモリ(or cache)の容量は限られています。それ以上のデータを扱おうとすると ディスクもしくはネットワーク越しのサーバーを使わざるを得なくなりますが、それはとても遅いということはソフトウェア技術者ならば当然知っておくべきのことのはず。ディスクアクセスはそれこそ物理的制約(ヘッドのシーク)が効いてきます。 アクセスにどれくらい時間がかかるかについては"Numbers Everyone Should Know"としてよく知られています(See CS343 Spring 2007) それに、メモリがいくら速いとしてもそれなりの規模のデータになれば、適切なアルゴリズムを使わないと実用的な速度で使えるソフトウェアにならないことも忘れちゃだめです。 「大半のレイヤーが人為で作られた不確定要因だらけのソフトウェア開発」という不確定要因とは何でしょう。 設計・実装がしっかりできてないだけなのではないのですか?ソフトウェアをどのように作るべきか知らない人が設計したりしていませんか?わかりやすくメンテしやすく堅牢で性能のでるプログラムを書くための方法を知らないで、とにかく最初に思いついたコードを書いているだけではありませんか?トレードオフを考えよりよいコードにできないか検討して、改善していますか?なにか不可解なことがおこっても「相性のせいで」とか「バッドノウハウ」とかですませてしまって、深く追求していかないせいではありませんか? コンポーネントが十分に堅牢かテストしていますか? 書くべきドキュメントやコメントを書かなかったり、逆にテストコードで書くべきことを無駄にドキュメントにしていませんか?(不安定な)コンポーネントを「なんとなくこうすれば動くから」というようなやりかたでつみあげていっているから不確定要因だらけになってしまっているのではありませんか? ソフトウェア技術者ならば、ソフトウェアを作りあげるための部品・材料になにがあるか、その特性、その使いこなし方のことをまずもっと知るべきなのです。ということを最近ますます思うようになっています。

Saturday, September 8, 2007

ITpro challenge!

ITpro challenge! で「ハッカーのソフトウェアエンジニアリング」というネタでしゃべってきた。説明しようとするとある意味あたりまえなことの積み重ねでしかなくて、うまく説明できたのかどうか。 「エンジニアに必要なのは技術だけじゃない」というのを時々みかけるけど、「技術がない人はエンジニアじゃない」というのが欠けてるような気がする。とにかく基礎的な技術をつみかさねていくことが大事なんだということがひとつ。 ハッカーが実践していることは、フリーソフトウェア・オープンソースソフトウェアの世界でも、Googleの中とかでも実はあんまりかわらないのがもうひとつ。ITpro challenge!の他の発表者の人のを聞いてもやはりやり方としてはあんまりかわらないよなーと思いました。 あと追加するとすれば、知識をだしおしみしないほうがよいということと、ああいうイベントにでるとやはりいろいろ刺激をうけていいなあということかな。 面接についてはいろいろ面白い話があるけど具体的にいえないのが残念。ちなみにSoftware Engineer では、こんな問題 はだしません。 What to expect from your Google interview を見ましょう。 FizzBuzz問題が簡単すぎるという人はいろいろなバリエーションを考えてみるといいかも。例えばこういうの
  • 制限を加える(ループを使わないで書く、剰余を使わないで書く、…)
  • printせず list にしてかえす
  • FizzBuzzをテストするプログラムを書く
  • 3とか5がパラメータ化されているとして、出力からそのパラメータを調べる
来週は LinuxConference 2007 をよろしく。 2007/09/10 23:30 追記: ITProの記事

Thursday, May 31, 2007

Google Developer Day 2007

今日は Google Developer Day でホテル日航東京へ。 世界同時開催で、基本的にAPIとかそういう技術説明がメインだけど、日本スペシャルで「Software Engineer in Google」というタイトルで、Google の Engineering Cultureの説明をしました。 当日の内容は YouTube に投稿されています