2011年のGWも終わってしまいました。夢のようなGWは、夢のようであるが故に儚く終わってしまいました。また社畜の日々が始まりますが、皆さんいかがお過ごしでしょうか。 さて、唐突ですが良いプログラムであることの条件とはなんでしょうか? この手の話を始めると宗教戦争が勃発するので、よほど気の合うエンジニアか、もしくは酒の席で話した方が良いですが、今年からソフトウェア品質管理をとりしきるお仕事についたので、自分の考えを一旦整理しておこうかと思います。 僕の考える、良いプログラムの条件は以下の4つです。 シンプル 読みやすい ドキュメントに頼らない 動く 1つずつ詳しく説明していきます。 1. シンプル プログラムはシンプルな方が良いというのは割と言い古されていると思いますが、ではシンプルではないプログラムとはどのようなものでしょうか。シンプルの反対語は複雑なのですが、複雑なプログラムとはどういうものかとういうと、機能毎の結合が強いプログラムと考えます。 つまり、「プログラムは出来うる限り疎結合になっていた方が良い」ということです。
bugfix手順なんて今更感がありますが、意外とこういうのって先輩エンジニアから教えてもらったりしないよなーと思ったので纏めてみました。 仕事のデキる先輩方は、この手順を並列且つ高速に回しているので、傍目からは何をしているのか正確に把握するのが難しかったりします。そして、若手エンジニアが見様見真似で同じことをやろうとして、大事なポイントが抜け落ちて大怪我をする。。なんて場面を結構見てきた、もとい自分も体験してきました。 これに限ったことじゃないけれど、エンジニアの世界ってプログラム言語レベルのことは結構教えてもらえるけど、こういう仕事の進め方を教える風土がないような。。僕が今までに見てきた現場だけでしょうか。(そういう意味では、僕自身は恵まれてたとは思いますが。。) ここでbugfix手順をまとめることによって、後輩エンジニアの一助になれば。もちろん先輩エンジニアからの厳しい突っ込みも大歓迎です。 bugfix 手順 再現させる。 基本、再現確認をまず最初に行うべきである。顧客や他部署からどのような報告が入っていようと、再現させて自分の目で確認した方がいい。 仕様を確認する。 ここで言う仕様の確認とは、該当のロジックを製作したときにどのような仕様だと約束していたのか、ではなく、
今年から部署が変わり、システムの品質管理をすることになりました。去年までは自社Webサービスの開発がメインだったんですが、今年からはソースの管理やテストのレビューなどを主にやっていくことになります。 うちの会社は去年まで色々と適当だったので、運用フローを作るところから始まりました。全くのゼロスタートなので、相当大変です。そもそも僕、座右の銘が適当と言っても過言ではないので、品質管理って相当似合わない気がするのですが…。とにかく品質を管理しないといけないので、システム開発の品質管理について良い本がないか探してみました。 SEの「品質」力 (技評SE選書) そもそも品質にフォーカスして書かれた本が少なかったですが、こちらはなかなかの良書な気がします。 品質とは何か 品質(ひんしつ、クオリティ = Quality)は、工場で生産された製品や、サービス業が提供するサービスの有する特性、もしくは属性をいう。ISO・JISの定義では「