JavaScriptを有効にして再度、お越しください。nishinoソフトウェア開発を長年していて、後天的に、共感力が低下してしまっている気がしますが、以下の内容には"とても"共感することが出来ました。共感力が下がったというより、共感するポイントがフツーの人と違ってきているんじゃないか?と思ったりします。GIGAZINEhttps://gigazine.net/news/20190621-things-i-learnt-the-hard-way/プログラマ同士で話をすると、きっと意気投合できる気がします。...と言っても、私の周りには肝心のプログラマが少ない気がします。勇気を与えあうことが出来たらイイんじゃないか?と思います。以下、私が思ったこと。<コメントやドキュメンテーション>一つ一つの動作をコメントに残すことドキュメントは将来の自分へのラブレターコメントは超重要ですね。昔、コメント消すプルリクが来た時は、申し訳ないケド、無視しました。OSSでコメントが少ないのは、サプライサイド都合なんだと思いますが、それを「カッコイイから。」と言う理由で単純に真似るの、くそダサくないですか?って思ったりします(こういう人はファッション・コントリビューターなんだと思います)。あと、ドキュメントもコメントと同様に重要だと思います。<テスト自動化、CI/CD>テストはAPIをより良いものにしてくれるテストはコマンドラインで行える方が良い自分のコンピューターで実行できない場合は生産性が落ちてしまう(テスト)コードを捨てる覚悟を持つことローカル環境でのCUIでの迅速なビルド&テスト実行は、プロジェクトの成長に伴い、重要性を増して行くと思います(某弊プロジェクトでも、NuGetパッケージ・マネージャ対応、クロス・プラットフォーム対応で、まさに、こう言った感じになって来ている)。昨今、流行りのテスト自動化、CI/CDに関しては、適合するドメインがありますので、先ず、最優先すべきは、ローカルでの迅速なビルド&テスト実行だと思います。テストコードについては、オフショアしていたものを実際に、一度捨てたことがあります。現在、新たに別のテストコードを書いていますが、各種検証の寄せ集めになりがちで、凝集度が低くなりがちですね。いう意味で、細かくやり過ぎると、最終的にテストコードを捨てることになるかもしれません。諸々考えると、疎通テストのレベルで止めたテストコードが、最もコスパが高いと思いますので、未着手であれば、先ずソコを狙うのがイイと思います。振り回されるのは時間の無駄ですね。これは、熟練した老害だけではなく、新興技術でカタストロフィを狙う若者を含め、老若男女問わず、自分のスキルセット内の技術を擁護してしまうモノなので、自分が、コノ低俗な情報の発信者にならないように注意しましょう。自作>プロジェクト外部のものに手を出さないこと必要に応じてライブラリを作成すること私もNuGetパッケージは沢山利用させて頂いていますが、以前にも報告させて頂いた通り、必要に応じて、重複した開発ライブラリ開発を行うケースもあります。何を利用して、何を開発すべきか?思慮深いプロダクトのオーナーなら判断できると思います。<度重なるビルドシステム・エンハンス>「簡単」の誘惑に抵抗する簡単に書ける記法を利用する場合は正式な記法も学んでおくべきコレ、翌々読んでみると、IDEとビルド・システムの話だったりします。私も「ビルド・システムのエンハンス」とか言うWikiページを作成してあるぐらい、コレには苦労させられています。Studio)を用いたビルドと比べ、MSBuildなどのツールを使用したビルドの敷居は高いです。最近、SAML2スクラッチ実装なんかも行いましたが、(違う意味で)「難しいなぁ。」と思うのは、殆どこのビルド・システム系だったりします。Studioのバージョンが上がる毎に、苦労させられている感があり、この辺、何とかして欲しいなぁ。自分の書いたコードの利用に責任を持つ完成していないのに「完成した」と言ってはいけないプロジェクトの行動規範は利用者を守るもの私の場合、行動規範を明記してはいないのですが、適用先のプロジェクトが厳しい(言い方が悪いけど、クレーマーレベルで厳しい)事もあり、"彼ら"を無視した行動は取れません(≒暗黙の行動規範)。実際に"彼ら"を無視した場合、ユーザは、蜘蛛の子を散らしたかの如く、一目散に逃げ出して、ユーザ基盤を失ってしまう気がします(書いていて、"彼ら"と言うのは、エンプラSI界隈の商習慣なんだろうな。<コミュニティ関連>コードレビューではスタイルではなく設計を確認するべきコードやアーキテクチャに文句を付ける人は注目してくれている本ブログでも、度々、ステークホルダー・エンゲージメント・マネジメントについて言及することがありますが、上記は、誰が重要なステークホルダーであるか?を見極めるために重要な情報を提供していると思います。人々の反応に注意するトラブルを無視するのではなく、トラブルから学ぶ前述のステークホルダーの反応は、重要だと思います。面倒なトラブル報告をしてくれるようなユーザは、確実に重要なステークホルダーであるので、当然、無視したらイケナイし、無視するようなプロジェクトは長続きしないと思います。口が悪い人からは距離を置くべき無意識であっても差別的な言動をする人からは距離を置くのが良い逆に、ステークホルダーではない外野の誹謗中傷は無視してイイんじゃないでしょうか?Twitterでありがちですが、本質を捉えていない誹謗中傷は無視してイイですね。評判を落とす原因にもなるので厄介ではあります。人間はネガティブな情報に敏感らしく、これを、何時までも検索上位に表示してしまうGoogleの問題かもしれません(きっと、広告ビジネスに傾倒し過ぎると、検索エンジンも、その信頼を失う、という構図なんでしょう)。<disconについて考える>ヒーロープロジェクトを行わなければいけない日が来る辞める決断をするべき時を学ぶdisconの類はイヤなものですが、このdisconに対して無策で抵抗し続けること程、人生時間を無駄にする行為も無いと思います。私も、価値が下がってきて継続が難しくなってきた機能やテンプレート、コレまで幾つもdisconにしてきました(某M$製UIサブシステム関連の機能やテンプレートに多かったですね)。...と言う事で、disconをコントロールすることは、極めて重要であり、決して諦めてはイケナイ事だと思います。ステークホルダー・エンゲージメント・マネジメントを含めた予算取り。やれる事は沢山あると思います。日式企業の組織内プロセスとしてまだ浸透していないので、仮に、あなたがdisconに対処しようとしても、その辺りから是正して行く必要がある気がします。<ルーティーン>しょうもないミスで1時間以上無駄にした時は記録を残すこと馬鹿げたやり方をブログに残すのは何もしないよりは良い紙のメモはなんだかんだ役に立つ私の場合、インターネット上にコミュニティが運営しているWikiを持っており、職務の特性上、顧客情報や、クローズドな技術情報に触れることが殆ど無いので、オープン系技術の話であれば、ほぼ、コチラに書き込むことが出来ます。管理職から見た場合、このフィルタリングは難しいと思いますが、昨今の「組織体の環境要因」の下では、なるべく技術情報開示を行うようにして行けるとイイのではないでしょうか?...と言うより、直接マネタイズ可能な技術を除き、サービスの治工具関係のソフトウェアは、オープンにしないと、「組織のプロセス資産」としても続かない時代ではあると思います。オープン系技術に関して、インターネット検索をするエンジニアは多いですが、イントラネット検索をするエンジニアは少ないと思います。イントラネット内にオープン系の技術情報を掲載するのは馬鹿のすることなんじゃないか?と思ったりもします。PMO関連の組織は、その辺りについて、再考した方がイイ時期に差し掛かっていると思います。