この記事はエイチーム引越し侍 / エイチームコネクトの社員による、Ateam Hikkoshi samurai Inc.× Ateam Connect Inc. Advent Calendar 2021 4日目の記事です。
はじめに
私のチームでは1年ほど、生産性向上や不具合発生抑えるための取り組みを行ってきました
その中で開発をする際に強く意識するようになったことがいくつかあります
私が普段意識していることを少し共有できればと思います
手を動かす前に一度落ち着いて設計を行う
いきなり手を動かすのではなく、まずは設計をおこないます
何を実現する必要があるのか、どうすれば実現できるのか、既存に影響しないかなどを考慮し、設計を終えた後にコードを書いていきます
いきなりコードを書き始めると、大きな手戻りが発生してしまう可能性もあります
確かにやってみないとわからない部分はありますが、ある程度は書き始める前の設計でカバーできると思っています
チーム内で設計の相談を行う
設計がある程度終わり、実装方針が決まったらチームのメンバーに設計の相談を行っています
どうしても一人で設計を行うと抜け漏れが発生してしまいます
メンバーの負担は若干増えますが、説明する過程で問題に気がついたり、抜け漏れに気がつくことで手戻りがなくなればやって損はないと考えています
コードレビュー前に設計や仕様の共有を行うのも有効です
レビューはどうしても時間がかかってしまいますが、事前に要点を伝えておくことで効率的に行うことができます
困ったらペアプロをする
ペアプロは賛否両論あるかもしれませんが、ときには誰かの力を借りるのも大切だと思っています
複数の目が入ることで問題にも気が付きやすいですし、他者の意見がはいることで自分では想像しなかったアイデアが出てくることもあります
他人がコーディングしている様子から学べることも多いので、ペアプロは積極的に行っています
可読性と保守性を意識する
基本的には作って終わりということはなく、私たちは書いたコードを保守していく必要があります
また、自分が書いたコードを読むのは自分以外の他人です
そのため可読性と保守性の高いコードを書くために大きく3つのことを意識しています
- 重複をなくす
- 1つの関数に多くの機能を持たせない
- 品質の低い部分をそれ以上汚さない
1.重複をなくす
いわゆるDRY原則のことです
同じ処理が増えてしまうと修正がとにかく大変です
保守しやすいように共通化できるコードをは共通化していきます
2. 1つの関数に多くの機能を持たせない
役割ごとに関数を分割しておきます
関数が小さくなるとメリットが多いです
- 1つ1つが単純になるため、保守がしやすい
- 命名と機能を一致させやすい
- 再利用しやすい
など
3. 品質の低い部分をそれ以上汚さない
コードの品質が低い部分を改修するときにそれ以上品質を落とさないことは重要です
意識していないと「ここは既に品質が低いから多少汚しても良いか」となってしまいます
工数的な問題などでリファクタまでは難しかったとしても、それ以上汚すことは避けるべきだと考えています
まとめ
開発者それぞれで意識していることは違うと思いますが、私が普段意識していることを書き出してみました
誰かの参考になれば幸いです
次回
Ateam Hikkoshi samurai Inc.× Ateam Connect Inc. Advent Calendar 2021 4日目の記事は以上です。
読んでくださった方、ありがとうございます。参考になれば幸いです。
明日は @namiita です。ご期待ください！！