長年やってきたチームでのシステム開発で気を付けていることを記載します。
色々な考えを持つ人達と組んで開発を進めるため、円滑に進めるためにも工夫は必要です。
私の考えとしては作っておしまいではなく、その後も正しく運用できるシステムを作りたいと思い開発を行っています。
そこで、開発で重要だと感じることをコーディング４つとコミュニケーション３つに分類しました。
この記事では、コーディング４つの気を付ける事を記載します。
・コーディングルールに準拠する
・ただ動くだけではなく、保守・改修がしやすいこと
・設計が間違っていないかを考える
・コンフリクトが起こらないように作業を行う
では、実際にどのようなことを気を付けるかを記載していきます。
コミュニケーション偏はこちら
内部リンク：
★コーディング
コーディングについて私は４つ気を付けていることがあります。
チームで行うにあたって、他の人が自分の書いたコードを見るということを忘れてはいけません。
そして、今一緒に働いていない未来のメンバーも自分のコードを見る可能性があります。
色々な思考を持った人が、見た際に少しでも理解しやすいようにしてあげて、
それによって工数が少しでも少なくなり、バグとなる要素が減ればよいなぁと思っています。
★１．コーディングルールに準拠する
現場にコーディングルールやコーディング規約があるのであれば、確実に理解し、それに準拠したコードを記載しましょう。
コードがファイルやメソッド毎に書いてる内容がバラバラであると非常に疲れます。
なので、コーディングルールは最低限必要で、別の人が見る場合は重要なことになります。
もし、現場になければGoogleが公開しているルールなどを皆で参照するよう働きかけてもよいです。
外部リンク：Google Style Guides
以下のように大体あります。
This project holds the C++ Style Guide, Objective-C Style Guide, Java Style Guide, Python Style Guide, R Style Guide, Shell Style Guide, HTML/CSS Style Guide, JavaScript Style Guide, AngularJS Style Guide, Common Lisp Style Guide, and Vimscript Style Guide. This project also contains cpplint, a tool to assist with style guide compliance, and google-c-style.el, an Emacs settings file for Google style.
日本語訳をしてくれてる有志の方のサイトもネットにはたくさんあります。
参考にしてみてください。
コーディングルールは、小さい事でも後で大きな恩恵を得られます。
★２．ただ動くだけではなく、保守・改修がしやすいこと
ただ作って動いて終わりであれば、誰でもできると思います。
対価としてお金をもらっているのであれば、プロとして未来のことも考えて作るのがよいと考えています。
無駄な変数を用意していたり、ネストが無駄に深かったり、同じコードをいくつも用意したりなど、これまでたくさん理解するまでに難しいコードを見てきました。
これらの問題は、理解するまでの時間がかかるため問題が起きたり、新たな機能を追加するときに非常に足をひっぱりやがります。
自分の書いたコードだけでもそうはなってほしくないと思いコーティングしています。
複雑にならないようにメソッド化を有効に活用する
変数名やメソッド名は意味の分かる名前にする
１メソッドがあまり長くなりすぎないようにする
など
どうしても難解な記載をしないと実現できない場合は、コメントをしっかり用意しある程度の慣れていない人でも意図がわかるようにします。
自分よりも優れている人もいれば、劣っている人もいます。
チームであるという事を正しい意味で理解しましょう。
自信がないときは、優秀だと言われている同じPJの人にコードレビューしてもらうといいです。
★３．設計が間違っていないかを考える
設計をしているのも今のところ人間なので、考慮ミスがどうしても発生してしまいます。
なるべくなら設計書に書かれていることが合っているかを理解しながらコードを見たほうが良いです。
私の場合は、コーディングを始める前に関連するコードを一度まとめてから理解します。
その際に設計が間違っていないかを確認するようにしています。
メンバーとして参画していても、リーダーとして参画していても、全員でバグが減るように動けたらなぁと思います。
★４．コンフリクトが起こらないように作業を行う
バージョン管理で開発を行うことが最近では当たり前ですし、Git や SVN などを使えるのでだいぶ楽ではありますが、それでもコンフリクトはなるべく避けています。
結構な物量を直すとコンフリクト解消するだけでやはり中々のエネルギーを使うためです。
UtilクラスやCommonクラスを触るときには、どうしても同じコードを触ることになってしまいますが、
なるべく声掛けしてコミットしたら、取り込んで修正する。
など工夫して、コンフリクト解消による時間ロスが最小限になるようにしています。
マイルストーンを確認して完全に作業をずらせるなら、ずらしてしまいます。
ストレスを感じることはなるべく減らした方がいいです。
バグを減らす事にもつながります。
★まとめ
私は、これまで２人の小規模開発から数百人関わる銀行案件や海外向けの資産管理システムを海外拠点も含め一緒に開発する開発など、２０を超えるPJに関わってきました。
短い場合は数週間、長いものは３年など期間もバラバラでした。
数々のコードを見てきましたが、しっかり作られているところと何も考えずに作られているところでは、改修にかかる工数は倍以上違います。
そして、バグの潜み具合も全く別物になります。
もし今後新たなシステムを作っていく方がいたら
少しでも品質のよいものができるとよいなぁと思います。
読んで頂き、ありがとうございます。
この記事が誰かにとって、一つの参考となれば幸いです。
私自身、これからも好奇心・感謝・努力を忘れずに精進していきます。
コメント