SE語はよしてくれ!

SE語というのは「〜コマンドを叩く。」「〜例外を投げる。」

のような、エンジニアが会話でつかう言い回し。

この記事がよくまとまっています:
不思議の国のSE用語 - Qiita

上記の記事に挙げられている他に、「〜する必要があります。」「〜することが可能です。」のようなものも、エンジニアはよく使いますね。

口頭で使うなら、まあ「エンジニアって変だなぁ」で済むのですが、中には文章でもSE語を使う人がいます! 文章ではSE語は使うな!絶対に!

読み手がSE語の話者とは限らない。

なぜSE語を使うべきではないかというと、要するに ムカつくから なのですが、もう少しフォーマルに説明すると以下の通りです:

実際のところSE語を話す人はそれほど多くありません。「SE語」と言いつつも、SE語を使わないエンジニアも少なくない(場合によっては多数派な)のです。その意味では、「SE語」は方言であり、悪く言えばスラングにすぎません。

書いたり、話したりするときは、読み手・聞き手の言語に合わせる(合わせようとする)のがマナー。 仕事とはいえ、内輪でしか通じないスラングを読まされるのは不快です。

ムカつかなくても、SE語は使うべきではない

また、たとえ相手が不快に思わなかったとしても、文書ではSE語は使うべきではないと思います。SE語を使った文書は、曖昧になる傾向があると感じるからです。

例えば、同じ文書内で「送出する」「投げる」「発生させる」「起こす」「生起する」が同じ意味で使われているケースなど・・・。 これについては、また別の機会に書きたいと思います。

まとめ

文章ではSE語は使うな!絶対に!

広告を非表示にする

奥が深い症候群

ソフトウェア開発の職場でよく発症する症状

奥が深い症候群

使いにくいツールに「奥が深い」と言ってのめり込む症候群。
往往にしてもっとシンプルな解決策が他にある。

弊社フレームワークTexC++PerlVimEmacsなどで発症しがち。

理由があるはず症候群

不合理(に見える)仕組みを見つけた時、
「こうなっているのにはきっと理由があるはず」と推測して、手をつけようとしない症候群。

実際には、

- 過去に必要だったが現在では不要になったものだったもの
- 継ぎ足しで実装して複雑になってしまったもの
- 原作者の無知によって誤った実装をしているだけのもの

といった、真に不合理であることも多く、こういったものは取り除くべきである。

また、理由があって変わった仕組みになっている場合も、
推測するのではなく、原作者やドキュメントに当たって本当の理由を調べるべきだ。

レガシープロジェクトのメンテで発症しがち。

現実を見ろ症候群

ソフトウェアのバージョンが古い、テストが未整備であるなどの問題について「だが、そんな時間は無い。現実を見ろ!」と、無視してしまう症候群。

ビジネスでは時間や人手を効果的に配分しなければならないが、果たして、メリット・デメリットを十分評価した上で、Rails 4.0 をつかい続ける判断をしたのだろうか?新機能を使えないプログラマーが不満を持つというだけでなく、セキュリティホールを抱えてしまう恐れもある。

また、「時間がない」のはテストが不十分で、不具合修正に追われているからかもしれない。

こうすればイケるよ症候群

ツールの欠陥を、ツール自体の改良ではなく、使い方で回避しようとする症候群。
奥が深い症候群に似ているが、プログラマーと言うより、プログラムを使う社員に発症しがち。

パブリックなソフトウェアだと、不具合報告しても直してもらえないことが多いので、運用でカバーするしかないことが多いが、同じ社内でそれをしだすと結局は誰の得にもならないことが多い。

エンドユーザーは忌憚なく不満を伝えるべきだしし、プログラマーは真摯に対応するべき。

だってわかんないもん症候群

ツールの機能を深く理解せずに、目先の目的を達成するためだけの誤った使い方をし、それの尻拭いを他人にさせてしまう症状。

現実を見ろ症候群に似ているが、「だって、難しくてわかんないもん」と感情的に反発するのが特徴。

また、プログラマーでも発症することがある。、PlayやRailsなど(患者から見て)エッジなフレームワークを触ることになったとき発症し、作法をよく理解せずに実装、バグをしこんでしまう。

発症するときは、ツールの利用側と開発・運用側とが没交渉であることが多い。まず、顔を合わせて話すことから始めよう。

あとがき

 書いていてどこかで読んだことがあるな、と思ったら、この本でした。

この記事より、もっと多く、もっと深い内容が書かれているので、お盆におじいちゃんにもらったお小遣いで買って読んでください。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

  • 作者: トム・デマルコ,ピーター・フルシュカ,ティム・リスター,スティーブ・マクメナミン,ジェームズ・ロバートソン,スザンヌ・ロバートソン,伊豆原弓
  • 出版社/メーカー: 日経BP
  • 発売日: 2009/10/22
  • メディア: 単行本
  • 購入: 10人 クリック: 156回
  • この商品を含むブログ (46件) を見る
 

 

広告を非表示にする

今までに使ったプログラミング言語

仕事でまともに使っている言語

Ruby

Ruby on Rails のために使っている。 汎用言語としてはRubyが一番完成度が高いと思っている。 「標準ライブラリのメソッドが豊富」といったレベルだけではなく、 周辺ツールが充実している。依存関係したければBundler、カバレッジにはSimplecov、スタイルチェックしたければRubocopと、定番がありそれらを使っていれば100%困らない。

Scala

Playのために使っている。

静的型なのに、Rubyに近い自然な書き方ができるのだが・・・いま一つ「これじゃない感」がある。 必要だと思う機能はあるが、それを上手くアレンジできていない感じ。 例えば、「case classの “case” は形容詞ですか?」といった所。

また、Rubyに比べて周辺ツールが未成熟な感じがある。 sbt で依存関係をダウンロードするのに2時間も3時間もかかるのは辛い。

Java

レガシープロジェクトの触ることがある。

不具合修正しかしないせいか、Javaのコア言語は世間で言われているほどひどいとは思わない。

ただ、DIとかアノテーションとかビルドツール等が、ブラックボックスになっている感じがある。 機能も落とし穴もいっぱいありすぎて理解できない。 Javaに習熟したオジサンたちには分かるんだろうが・・・。

JavaScript

WEBアプリを開発するのに当然書くのだが、オマケ程度であり、 ガッツリ書くことは無い。 また、半分は純正のJavaScriptではなく、JSX (Reactの方。DeNAのではない)を書いている。

嫌いと言うほどではないが、Arrayを配列に使えなかったりするのがタマに辛い。 また、1年おきにパッケージマネージャが変わるのも辛い。

CoffeeScript

既存のRailsプロジェクトの不具合修正で触れる。

昔は「スゴい!画期的だ!JSはいずれCSに置き換わるに違いない!」と 思ったのだが、そうはならなかった。まあ、JSの機能が充実してきてるのだから、仕方がない。

でも、「.coffee を .js で書き直した」というコミットを見ると悲しい。

シェルスクリプトBash

ちょっとしたコマンドを書くのに使っている。リリースやCIのスクリプトとか。

エラー処理等をちゃんとするなら、Rubyなどの高級言語で書くべきなのだが、 Bashで書く方が圧倒的に楽。

最近使わない言語

Python

かつては(今も?)Windowsでまともに使えるLLはPythonしか無かったので、 Windows PCしか持っていなかった学生時代にフリーウェアを書くのに使っていた。 仕事では何故かPythonプロジェクトを担当する機会が無い。

言語としての機能は、RubyJavaと同等と言うか好みのレベルだと思う。

ただ、パッケージマネージャが長年中途半端な状態が続いているのがタマにキズ。 例えば、pip をインストールするのに easy_install が必要だったり、 setup.py を正しく書くのが難しかったり。 最近は pip が(ようやく)インタープリタに同梱されるようになったりしたようだけど。

また、近頃は統計や機械学習の分野で人気のようだが、これも仕事では縁がない。

Elm

Haskell ベースのAltJS。すごく未来的な感じがしたが、実際にはELMを使う未来は訪れなさそうだ・・・。

しかし、しれっとRailsが5.1からElmをサポートしていたりする。

十進BASIC

教育用言語。高校レベルのグラフを書くのには最高だと思うが、高校は卒業してしまった。

http://hp.vector.co.jp/authors/VA008683/

広告を非表示にする

コードの格付け++

  • ランクA ~ コメントを読まなくても、関数名だけで使い方がわかる
  • ランクB ~ コメントを読めば使い方がわかる
  • ランクC ~ 中身を読まないと使い方がわからない
  • ランクD ~ 書いた人の心を読まないと使い方がわからない(or 心を読んでもわからない)

元ネタ:[開発]ランクCのゴミコードを生産し続けないために、、、

広告を非表示にする

レガシ―プロジェクトを引き受けた時、最初に準備するべき七つのこと

「営業一課で使っている■■ってPHPアプリがあるんだけど、メンテナの○○さんが退職するから、4月からは君に任せるよ」

そして、ソースを見てビックリ!!

テストは無い、リリース時の手順書も無い、仕様書ももちろん無い。

一方で「ログインできません」「なんか『Internal Server Error』って出てます」「表が崩れます」という不具合報告の数々。

ここで、プレッシャーに押しつぶされて「とりあえず、簡単な不具合から早く直そう!」と思うかもしれませんが、ちょっと待った!その前にやっておくべきことがあります。

※この記事でイメージしているのは「社員25人に使われている」という程度のレガシーアプリです。「3度の会社合併を経た40年もののCOBOL製基幹システム」には役立たないかもしれません。

1. 協力者を確保する

以下の人たちを確保してください。他のプロジェクトと兼業で構いません。

  • アプリの仕様を知っている人(前任者 or ユーザー)
  • コードレビュワー
  • テスト担当者
  • インフラ担当者

コーディングは自分でやるとしても、専門外の分野では無理せずその道の人に頼りましょう。 相談できる人がいると大いに助かります。

また、ユーザーや偉い人と交渉する時に、1人より5人の方が交渉しやすいでしょう。

2. 仕様をドキュメント化する

ユーザーに聞いたり、コードを読んだりして、アプリの仕様をドキュメントにしましょう。

ここでは、完璧な仕様書を目指す必要はありません。 正確性・網羅性よりも、ともかくドキュメントを作ることが大事です。

というのも、ドキュメントが無い状態だと、みんな想像で物を言うので、議論が迷走しがちになるからです。

ドキュメントという形に結晶化すれば「ここの記述は実態と違う」とか「ここを変えましょう」と、生産的な議論ができるようになります。

3. 手動テストをドキュメント化する

最終的には各種自動テストでカバーするべきですが、最初は手動でテストしなければいけません。しかし、レガシープロジェクトの場合は、手動テストもロクに無いことがあります。

とにもかくも、既存のテストケースを、ドキュメントに起こしてください。 TestRailなどの管理ツールが望ましいですが、Excelでも構いません。

テストもドキュメント化しなければ生産的な議論はできません。

  • どの部分のテストが足りていないか?
  • テストケースが重複していないか?
  • ユニットテストで確認できる内容ではないか?

等など。

また、テストケースが一覧になっていれば、テストにかかる工数を正確に見積もれるようになりますし、 必要に応じて複数人で分担して実施できるようになります。

4. Jenkinsを導入する(CIツールを導入する)

レガシープロジェクトでは常に時間が足りなくなります。

Jenkinsからボタン1個で、ビルド、ユニットテスト、リリース、コーディング規約チェックなどの定形作業をできるようにしてください。Jenkinsはシェルスクリプトをコピペするだけでジョブが作れます(そもそも、定形作業がスクリプト化されていないこともありますが・・・)。

なお、別のCIツールでもよいですが、Jenkinsは汎用的でお手軽なので、とりあえずJenkinsを使うのがベターでしょう。

5. コーディング規約をチェックするツールを導入する

さて、ようやくコーディングの準備が整ってきました。しかし、タブとスペースが混在したようなコードを編集しようとしても、ストレスが溜まりますし、つまらないミスも犯してしまいます。

コーディング規約を定め、全てのコードが規約に従うようにしてください。

ここで、どのコーディング規約を採用するかはあまり重要ではありません。 規約をRubocopやCheckstyleのようなツールで自動的にチェックできることが重要です(コードレビューの際にスタイルについて指摘する/されることほど不毛なことはありません)。

むしろ、ツールに合わせて規約を選択するくらいでよいと思います。

ツールは以下の基準で選んでください

  • 簡単に使えること
  • 簡単な内容(スペースなど)は自動修正できること
  • チェック対象にしないファイルを指定できること(全ファイルを一度に書き直すのは時間がかかるので、あまり変更しないファイルを後回しにできるとよい)

また、ツールにはスタイルを細かく設定できるものもありますが、時間の無駄なので、デフォルト設定のまま使いましょう。

6. 便利な新言語(less・scss・haml・slim・TypeScript・Kotlin など)を導入する

WEBアプリであれば、大量のHTML・CSSJavaScript のソースが含まれているはずですが、 これらは決して書きやすい言語ではありません。

書きにくい言語と格闘してもしょうがないので、less・scss・haml・slim・TypeScriptなどを導入してストレスを減らしましょう。これらの言語はHTML・CSSJavaScriptの上位互換なので、拡張子を変える以外の作業は要りません。

また、alt-JavaのKotlinは、文法的にはJavaの上位互換ではありませんが、Javaから自動変換することができます。

なお、拡張子の変更・自動変換であっても、変更の後にはテストが必要になりますが、それは他の変更のテストのついでにやればよろしい。

7. (まともな)テスト環境を(複数)用意する

まれによくあることですが、サーバーが本番環境の1台しかなく開発者のマシンで適当にテストした後いきなり本番適用する(そしてバグる)。

あるいは、テスト環境と称する環境はあるが本番環境と設定が違ってしまっているので、テストがテストになっていない。

本番環境とできるだけ同じ設定のテスト環境を作りましょう。 その際にAnsibleなどを使うと後々便利ですが、ともかく「テスト環境が無い」では話にならないので方法にはこだわらずに急いで用意しましょう。

また、テスト環境は複数作っておくべきです。後々、テスターの人数が増えたり、自動テストを導入したりしたときには、テストを並列で行うことになるからです。

終わりに

ユーザーや上司からは、とっとと不具合を直せと言われるかもしれません。

しかし、戦いには準備が必要です。 初見のコードにいきなり手を付けても、直しきれなかったり、エンバグしてしまう可能性大です。

また、メンテは長丁場です。あなたはきっと、何年もメンテを続けなければなりません。 ですから、最初の時点で、作業する時のストレスを減らす手立てを講じてください。

広告を非表示にする

Scalaの最も難しいところ

仕事でScalaで書いたプロジェクトを担当する機会がありました。

Scalaは難しい」と時々言われます。

私の感想は やっぱりScalaは難しい

しかし、それはScala大好きな人たちが想像するのとはちょっと違うところ。

続きを読む
広告を非表示にする

「サービス層」「DAO層」はアンチパターンだ

転職して、Java(Jersey)とScala(Play)で書かれたWebアプリケーションをメンテを1年半ほどする機会があったのですが、Java界隈で特によく使われている(ような気がする) 「Resource / Service / Daoの3層に分ける設計」アンチパターンであると思えてならないので、思っているところを書き出してみます。

続きを読む
広告を非表示にする