社内のプロジェクトで使用する汎用ライブラリについて
ユーティティ系のライブラリであったり、DBアクセス周りのクラスであったりについて。
現状の問題点
- プロジェクトによって使うライブラリが違う
- 同じライブラリでも、適宜手を入れられているためプロジェクトによって微妙に違う
- 汎用ライブラリなのに例外に対する処理が適切ではない
理想
- どのプロジェクトでも同じライブラリを基本的に使用
- ライブラリはバージョン管理すること
- 誰でもライブラリの修正に参加できる環境にあること
- 例外への対処やログの出力は適切にしてあること
ってことを考えるとGitHub等を使って管理していくのが一番だなって思います。
誤った実装は誰でも指摘できるようにし、それを受け入れる環境ってのは重要だと思います。
社内でそうした環境を整備し、部をまたいで共有したりってことができれば、生産性あがるんじゃないかと。
また、こうしたライブラリのコーディング方法や例外処理への対処方などをお手本にするようにしてもらえば
各プロジェクトのつくりもあわせていけるんじゃないかと。
数百ページもある退屈な社内コーディング基準書を見るより、実際のコードのお手本で学べます。
配属された新人も、学ぶものがはっきりしているので、分かりやすいんじゃないかと思います。
以下余談
今のプロジェクトで使用してるDB周りのは
SQL投げたときにDBから例外が返ってきたとしてもcatch句でreturn nullするような超絶仕様でした。
なのでエラーでこけたときの情報がヌルポだけですし、その他いたるところでthrow exみたいに再スローしてるので
StackTraceからも追いづらいです。
そもそも例外が発生する箇所でcatch処理がかかれていなかったり、ガード条件ではじいてなかったり、
例外はすべてExceptionでcatchしてたり。
ログを出力する機能もないですし、デバッグの方法はエラーメッセージから、自力で追うんだよ！って教えられました。
ライブラリ修正するように提案していたら、今までの実績があるから君が手を加えることは許されないっていわれました。
今のプロジェクトはC#なので、DB周りはDapperとか使用したらいいんじゃないですかって提案したら
フリーのライブラリは信用できないから導入できない。実績がない、といわれました。
例外をnullで返すような自前ライブラリよりはいいと思うのですがね。
社内のいたるところでこうした不幸な思いをしてる人いっぱいいると思うのでなんとか改善したらいいんじゃないかなと思います。
SIerでも自社の技術力が必要になってくるのではないか
（※以下、自社の話なのでSIer業界すべての話だとは思ってまいません。）
SIerの技術力云々の問題は今更書くまでもないと思うので割愛しますが
最近思うことは、エンプラ系のシステムのユーザビリティの部分は
web系のサービスに近づいていくことが求められてるんじゃないかなと思います。
業務システム(webシステム）の開発において、顧客から出る要望のなかに
「ここはAmazonのあれっぽくしてほしいな」
「ここはあのwebサイトのあれっぽくしてほしい」
「もっとデザインを今風な感じにできないかな」
「検索一覧はページングしないでスクロールしたら自動で読み込んでよ」
みたいなことをちょくちょく聞きますが、自社のSEの対応をみていると
「それは難しいので、前と同じの方法にしませんか」
で片づけてしまいます。
というのもwebでは当たり前のjavascriptやcssに関する知識やajaxなどの非同期通信
に疎いからだからだと思います。
数年前からVisualStudioでプロジェクト作ると標準で入っているjQueryも、「何だそれは？実績はあるのか？使えない人がいるからダメだ！」
で一蹴されてしまいます。
何もAngular、Knockout等のフレームワークを使おうなんて言いません。
デザインに関しても1990年代のHPみたいな見た目ばっかりです。
自前のよくわからんcss使うよりは、Bootstrapを利用すれば綺麗な見た目が簡単に手に入ります。これもVSでは標準で入っていますね。
実績がないから、学習コストがかかるから導入できない、というのは分かりますが
いつまでたっても、同じことを言い続けていて果たして成長するのでしょうか。
顧客の要望を満たすことができるのでしょうか。
システム開発のシの字も分かってない若造がふざけるな！と思うかもしれませんが
「webでよく見るあの機能ですね、作ってみます」
「このダッシュボードにTwitterみたいな簡易メッセージ機能つけてみたらどうでしょう？」
みたいに提案できるのがプロなんじゃないかなって思いますし、それによってビジネスの幅も広がるのではないかと思います。
そのためには、ベースとなる技術力が必要ですし、顧客との打ち合わせでこのような話ができるようになるには
PMや設計者（SIerでいうSE)自身がその技術を身につけなければなりません。
実装や技術的なことは全部外注に丸投げではダメですね。
それからプログラミングができない人がSEになる、みたいな現状も。
そうして技術力に関心をもっていけば
良いシステム、保守性の高いシステムを作るには？日々の作業をもっと効率的にできるんじゃないか？ってところにたどり着きますし
そうすると
MVC,MVVMなどのアーキテクチャやRESTなどの概念
バージョン管理や、CI、チケット管理などの各種ツール
テスト駆動やドメイン駆動、チケット駆動、アジャイル、スクラムなどの開発スタイル
などを学ぶ/使っていくんではないかなと思います。
とはいっても、今までの文化を変えることは難しいと思いますし、結局のところ
各個人がプログラミングに関心があるか？向上心があるか？
ってことに行き着いてしまうので、なかなか大変ですね。
・人月商売
・プログラムを作るのは外注任せ
という発想が普通ですから、技術力を重視するとは思えないですし
そうした構造ができあがっているため
・プログラムは興味ないけどSEになろう
・未経験OKだし1カ月の研修でなんとかなるだろう→現場に投げ出される
みたいな業界になってしまったのではないかと思います。
パワーポイントのバージョン管理
VisualStudio 2015からの便利機能
beachside.hatenablog.com
便利機能がまとまっている。
インターフェースの実装見たり、Alt + 矢印 で移動は便利そう。
最近勉強になったもの
例外処理について
.NETの例外処理 Part.1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
.NETの例外処理 Part.2 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
.NETの例外処理 Part. 3 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
MSDN Blogs
.NETとJavaの例外処理の違い - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
例外処理に関する考え方や設計がまとめられています。
とても勉強になりました。
上記で紹介されていたイベントログの書き込みに使う
Exception Management Application Block を調べてみたいと思います。
アーキテクチャを決定する上で重要なのは、100 点満点の唯一無二の正解を求めることではなく、80 点の内容でもいいからシステム全体でそのアーキテクチャ（設計ポリシー）を一貫させること
いい言葉です。
スレッド処理とメモリの使われ方について
スレッドとオブジェクトインスタンス
MSDN Blogs
この本を読むといいらしいのでチェック
この方のブログは勉強になることがたくさん書かれていました。何度も読み直したいと思います。
とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
CentOS7.2にredmineを入れた時のメモ
Redmine 3.2をCentOS 7.1にインストールする手順 | Redmine.JP Blog
gemパッケージのインストールの項の下記コマンドでエラー
bundle install --without development test --path vendor/bundle
下記パッケージインストールで解決
yum install ImageMagick-devel
