コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
IoTプロジェクトでの技術的な反省点2017年
SI系、エンプラ系のエンジニアとして色々なおもしろい経験をさせてもらった2017年でしたが、今になって思えばもっとこうすればよかったという点もたくさんありました。特に技術的な面を振り返ります。 tl;drIoTでは、デバイス接続をいかにスムーズにして台数を増やすかが大事なので、デバイス側が楽になる側に倒すことが正義オンプレ運用はやっぱり大変だクラウドのベストプラクティスは従わない理由がない2017年にやったことIoTという文脈でやったことは主に２つでした。 工場のデジタル化・コネクテッド化を推進する、いわゆるIndustorial IoT（IIoT）物流などでトラックにセンサーをつけて分析する、いわゆるモビリティIoT特にIIoTは昨年からカウントして約1年間やっており、基礎的な機能群はとっくに保守運用フェーズに入っているのでこちらを中心に振り返ります。 採用技術・構成について工場内の制御
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
