私は、プログラマー、SEとして、25年以上、システム関係の開発をしてきています。
転職は、プログラマーとしても、かなり多い方だとは思っていますが、
有難いことに、いつも仕事に恵まれて、やりたいことをやらさせていただいていると思っています。
現在も、某通販会社である事業会社のシステム開発者として、活躍させてもらっていることは、
本当に有難いと思っています。
設計とか、運用よりも、
常に実装に関わっていたいというわがままを通してきて、現職もプログラマーという役割という感じです。
事業会社ということもあり、自分たちの作りたいアプリケーションや、
業務効率化に大きく貢献できるであろうアプリケーションは、どんどんと作っていっている状況です。
でも、経営陣からは、それなりに、成果を求められるものです。
それは、売上であったり、コスト削減の実績だったり…
そういった状況で、要求も大きくなり、スピード感が求められるものです。
このような対応を適切に行うためにも、プログラミングには、
ある程度、先を考えて、コーディングする必要があります。
要件は曖昧のまま、実装せざるを得ない
要件がしっかりと確定して、実装を進める事が一番望ましいと思います。
プログラミング時に、色々と不明点を確認して、実装を進めるよりも、
作るべきものをしっかりと決めて、コーディングしていくべきだと思います。
しかしながら、新しくはじめる事業だったり、
実際に業務を始めてみなければ、わからない部分も多々あります。
そのため、ある程度、
どういった機能があると、新しく始める事業が円滑に進めることができるのか？
という、予測をしながら、実装していく必要あるのです。
そのため、ある程度、仕様変更に強い、設計を意識して、
実装を進めていく必要があります。
後でキレイなコードに修正しようという考えは捨てる
実装フェーズで、忙しくなってくると、
最初は、丁寧に、先々を考え尽くして実装していたような余裕がなくなる場合もあるかと思います。
そのような状況で、どうしても目先のことを考えて、
共通化できる部分を、重複して実装したり、
共通化できそうな部分を丁寧に検討して、共通化する作業を怠ることがあります。
とりあえず、コピペで実装をして、
後で、キレイにコード修正すれば良いのだと…
後で余裕など出たためしもないのに、その時は、自分たちの都合の良いように考えてしまうものなのです。
また、後でキレイにまとめようにも、
各機能が大きくなり、部分的な修正もしにくい状況になります。
そのため、後ではなく、
やはり、設計時、実装時に、しっかりと先々を考え抜いて、
ベストなコーディングをしていくことが重要だと思います。
最初は一人で実装していても、チーム化される
プロトタイプ的な実装からはじめて、ある程度の機能がまとまってくると、
さらなる要求を満たすために、増員して、機能を大きく追加することがあります。
この場合、自分だけで実装をしていれば、ある程度のスピードで対応は可能ですが、
増員してきたメンバーが、スムーズに実装できるように、解読しやすいコードを書いておく必要があります。
最初から、最後まで、自分自身で完結できるプロジェクトは無いものと考えた方が良いでしょう。
最初の状況からは、すぐに変わるものなのです。
そのため、増員メンバーの方々に自信をもって見せられるコードを意識しましょう。
開発する時間がなかったから…
という言い訳は、やはり、イタイ言い訳になってしまいます。
忘れたことの保守は、緊急度が高い
自分たちのアプリケーションが安定して運用してくると、運用担当者に運用業務を引き渡します。
また、自分も、新しいプロジェクトが立ち上がり、そのプロジェクトに集中している時期になります。
そのような状況でも、
運用中のアプリケーションに異常が発生した場合には、
自分たちが修正していくこともあります。
このような場合は、ほとんどがクリティカルな異常なので、
最優先に、迅速に対応しなければならない状況になります。
そのような時に、半年前のコードを読み返したときに、
スムーズに理解できるコーディングを意識しておく必要があります。
まとめ
いかがだったでしょうか？
今回記載した内容は、一部分だったので、
実装に携わったことのある方々には、ほかにも色々な意見があるかと思います。
とにかく、実装するからには、
キレイなコード、より良いコードを意識して実装することが大切ですし、
常に意識しておくことが、次のプロジェクトに活かせることが沢山あると思います。
開発者におススメの書籍
あまりにも有名な書籍なので、ご存じの方々も多いと思いますし、
既にお持ちの方もいらっしゃると思います。
特に良かったと感じている良書をご紹介いたします。
