"コードレビュー"投稿一覧

まず、gitというツールがあります。
https://git-scm.com/
gitは変更管理ツールで、一連のソースコードをリポジトリという単位でまとめて管理します。
（実際にはソースコードのみで... 続きを見る

notionもありますよ。
https://www.notion.so/ja-jp/product

基本的には、同じと考えていいかと思います。

質問内容から推測するに、自社のエンジニアが誤ってコードやシークレットキーを公開してしまうことを懸念されているのではないかと想像しました。「GitHub コード 誤って公開」といったキーワードでGoogle検索すると、たくさんの事例がひっかかります。もちろん、これはGitHubの利用者が多いことの裏返しでもあるのですが。また、GitHubの利用者が多いが故に、コードをpublicなリポジトリで公開す... 続きを見る

後で見たときに、「なんだろこれ、消してもだいじょうぶそうだな」と見えそうなところにはちゃんと書いておきます。

またプルリクエストなどのときに「これはこういう理由があり追記しているコードです」のような、説明しないとわからない部分なども書くべきところである可能性のあるヒントになるかと思います。

「不要」なテストですので、「積極的に消すべき」と言うよりも、「絶対に消す」というか「最初からさせないべき」がベストです。

これは学歴主義の弊害で、テストを多くすると高性能で完璧な商品が出来ると思い込んでいるからですが、テストが多すぎると、販売時期が遅くなり、競争相手にシェアを独占されて在庫損です。

方や昔から経費削減のためか、必要なテストをしてないパター... 続きを見る

PMは、事業ドメインと言うか会計が解らないと駄目。要は、ビジネスが理解できないと、各々の影響金額がどれくらいなのかとか関連法規がわかってないと犯罪の片棒を担ぐことになる。「事業ドメインを理解して」が該当する。
ビジネスの内容やビジネスプロセスを分析して、利用者の意見を尊重しつつも駄目なものは駄目と言うこと「ユーザーの意見を尊重し」が該当する。
必要な言語やテクニカルスキル、最近... 続きを見る

私はコンサルなのでコンサル的な手法で失礼します。

クライアントサイドに立ってみると、失敗しているのは全員が自覚していますし、とは言え昔のこととは言え先輩の責任を明確に言葉にしたらそれを理由に足を引っ張られたり、と言うのが派閥のある大企業です。

そして、わからせるとありますが、これも無理です。気づかないで放置してた責任を問われているやうなものなので、うまく... 続きを見る

レガシーなシステムの相談はよく受けています。ただ、仕事になるか？というとそうでもないなぁという印象です。なぜなら、問題が難しいからだと思います。外部からとやかくいうのは簡単ですが、現場には現場なりの問題があります。これを理解して、良い方向に持っていくのは、おっしゃるように骨の折れる作業です。

ただ、仕事上、どうにかして良くしたいので、いくつかアプローチとしてやっていることはあ... 続きを見る

対応しないことに伴って発生する損失を数値にして明確に示してあげる必要は最低限あるかもしれません。これをやらずにそのままやるのと、やってからやるのは費用的に、時間的にこれだけ異なる、という部分です。
また求人の難しさ、人を入れてもやめていってしまう可能性の高さなどでわかりやすく。
（と言ってもだめな場合も多いと思いますが…）

いざそれをマージ後に該当箇所で不自然な挙動や記述が後になってわかることが稀にあり、もう少し実際の挙動と照らし合わせて手元でコードを確認すべきかと思っています

とてもわかります！
私は動作確認については個々人の責任だとして、あくまでわかりにくい書き方がないか、の部分だけ着目するようにしています。
いろんな可能性を考慮... 続きを見る

後から入ってきた人が迷わないように、コーディング規約やアーキテクチャに則った書き方になっているかはチェックしています。

その他、長期的にメンテナンスに関わっているサービスとかだと、そのサービスの仕様として考慮漏れが無さそうかも確認したりします。

スラッと読めるか、というところを自分は一番大事にしていると思います。

読むときに引っかかりを覚えたり、理解するときに頭を使ったな、と思ったときは、
これは自分よりさらに初学者なエンジニアが入ったときはもっと苦労するに違いない、という思いから、
わかりやすい変数名を付けるようにや、一度変数への代入をおこなうことを勧めたりして読みやすくしたり、
どう... 続きを見る