読みやすいコードは「読ませない」
経験の浅い人にちょくちょくするアドバイスとして、「コードリーディングのときにはあんまコードを読まないほうがいいよ」がある。コード全体を詳細に読むのではなく、名前やインターフェイスからコードの意図を把握することで効率的にコードリーディングできる。完全に下記の受け売り。 「実装は極力見ないようにして、インターフェイスと構造を理解するようにするんです。ダイヤグラムや、関係のグラフを書いたりして。実装はちゃんと出来ていると信じて、読んでいるメソッドやクラスのインターフェイスの役割やパラメータをしっかり理解するようにするんです。そっちの方が、実装を見るよりずっと楽ですよね。」 牛尾 剛「コードリーディングのコツは極力読まないこと 」 自分なんかは、エディタの畳み込み機能と変数名ホバーを使って、名前とインターフェイスしか見えない状態で読む。中身を読みたいなーと思ったところは畳み込みを解除して徐々に読ん
社内資料「プロダクトマネージャーのための検索推薦システム入門」を公開します - LegalOn Technologies Engineering Blog
こんにちは。LegalOn Technologies 検索・推薦チームの浅野（@takuya_b / @takuya_a）です。 先日、社内のプロダクトマネージャー（以下、PdM）を主な対象として、検索推薦技術の入門講座を開催しました。このたび、その資料を公開します。 資料の概要 この講座では、検索推薦技術とその周辺について、概要をざっくり理解できるように努めました。技術的詳細、とくに具体的なアルゴリズムにはあまり立ち入らず、できるだけ平易なことばで説明したつもりです。なお、広範な範囲を扱うため、各回1時間（質疑応答込み）で、3回に分けて実施しました。 公開した資料は、PdM だけでなく、エンジニアリングマネージャー（EM）やソフトウェアエンジニアの方々にも読んでいただけると嬉しいです。 以下は、各回で扱ったトピックです。 第1回 全体概要と検索技術入門・・・資料P3~ 検索・推薦とはなに
強い人達の調査/勉強法まとめ
ゆめみ/虎の穴ラボさんの「勉強法の勉強会」というのが好きで、そちらをベースに社内の強い人たちへのインタビュー（10名程度）をミックスして、みんながどうやって調査とか勉強とかしているのか、まとめてみました。 インタビュの結果、あまり共通項みたいなものがなく、結局勉強に関しても銀の弾丸はなさそうな雰囲気でした。ので、どちらかというといろんな人のいろんな方法を並べる、みたいになっています。いろいろ詰め込もうとしすぎたのでゴチャった感ありますが、誰かの参考になれば幸いです。 前提など
ケント・ベックに学ぶ良いコードの書き方🗒️ - Qiita
こんにちは、しが あきとし(@akitosihga)です。 先日あるMeetUpで良いコードの書き方について考える機会がありました。 『良いコード』の定義は幅広く様々な解釈があると思います。 その中でも、自分が敬愛するプログラマーのケント・ベックから学んだ事に焦点を当てて良いコードの書き方についてまとめました。 ケント・ベックとは テスト駆動開発(TDD)で有名なプログラマー アジャイル開発におけるエクストリームプログラミング(XP)の考案者としても有名 アジャイル開発関連の書籍に度々登場するCRCを発明したのも彼だったりする 代表的な著書は「テスト駆動開発」「エクストリームプログラミング」 TDDのイメージが強い彼ですが、実はコーディングに対して並々ならぬ情熱を持っているのです。 彼の著書「実装パターン」では以下のように語っています。 『 70年の人生は、20億秒を少し超えるに過ぎない。
単体テストだけでないDI（依存性注入）のメリット
はじめに DI（Dependency Injection）依存性注入という言葉を知ったのは単体テストについて学習しているときでした｡DIは単体テストをするときのためにあるというふわっとした認識だった｡ ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用を読んで 第7章の依存性注入に｢単体テストがアーキテクチャへの気づきの手段としてとても有効だが､DIを単に単体テストのためにやることいった目的観では視野狭窄｣といったことが書かれていたので､DIの他のメリットについて調べてみました｡ サンプルコード(Swiftで)を例にDIを使った場合と使わない場合の比較をします｡ DIを使わない場合のコード class NetworkService { func fetchData() { // ネットワークからデータを取得する処理 } } class DataManager { pr
コード×AIーソフトウェア開発者のための生成AI実践入門
この本の概要 GitHub CopilotやChatGPTなど生成AIによるコード生成やコードリーデイング支援が流行っています。これらは破壊的なイノベーションで，いずれはすべての開発者や企業が導入するものです。 ただ，現状では生成AI×コードを推進・導入している企業は多くはなく，さらに活用法については手探りの状況です。 本書では生成AI×コードでなにができるか，どうすればよりよく活用できるかを解説します。しっかりと活用していくための知識と，現場で活用できる実践が身に付く必携の一冊です。 本書のサンプル 本書の紙面イメージは次のとおりです。画像をクリックすることで拡大して確認することができます。 1. 生成AIがエンジニアリングの常識を変える 1. 変化は「今」起こっている — さて，どうする？ 2. 生成AIへの過度な期待と現実のギャップ 3. プロンプトエンジニアリングのテクニックはあま
コードレビューの仕方
コードレビューの仕方 このセクションでは、長年の経験に基づいて、コードレビューをする最良の方法に関するいろいろな推奨事項を説明しています。 各ページをひとまとめにすると一つの完全なドキュメントになりますが、便宜上、多くのセクションに分割しています。 全部を読む必要はありませんが、多数の感想によれば、ドキュメントを通読するのが個人としてもチームとしても非常に有益です。 コードレビューの基準 コードレビューの観点 レビューで CL を閲覧する コードレビューのスピード コードレビューコメントの書き方 コードレビュー中の取り下げに対応する CL 作成者のガイドも参考にしてください。こちらは CL をコードレビューしてもらう側の開発者のための詳細なガイドです。
AIコーディングツール導入のメリット、課題、企業の取り組み状況は？ GitHub調査
GitHubは2024年8月20日（米国時間）、米国、ブラジル、インド、ドイツの企業におけるソフトウェア開発者など2000人を対象に、ソフトウェア開発におけるAI（人工知能）コーディングツールの導入状況や導入のメリット、課題などを調査した結果を発表した。 同調査ではAIコーディングツールを、「生成AIとLLM（大規模言語モデル）を使用して、ソフトウェア開発サイクル全体を通じてエンジニアリング支援を提供する開発者向けツール」と定義している。 調査は、GitHubの委託によりWakefield Researchが2024年2月26日～3月18日に、米国、ブラジル、インド、ドイツの企業に勤務する学生以外の従業員2000人（各国500人）を対象にオンラインで実施した。内訳はソフトウェアエンジニア、開発者、プログラマー、データサイエンティスト、ソフトウェアデザイナーだ。 GitHubは2023年に、
『ドメイン駆動設計をはじめよう』がわかりやすすぎた｜ミノ駆動
こんにちは、リファクタリング大好きなミノ駆動です。 2024/07/20に発売された『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』を、訳者の増田亨氏よりご恵贈賜りました。 この記事は、この書籍の感想です。 著者の許可を得た上でのだいたんな意訳総評等の前にいの一番で伝えたいポイントです。 エリック・エヴァンス氏の『ドメイン駆動設計』は大変価値の高い知見が網羅されている一方、「ユビキタス言語」や「境界づけられたコンテキスト」といった独特の用語が登場したり、難しい言い回しをしていたり、読解がかなり難しい書籍です。 独自用語が登場するたびに「ユビキタス言語？なんだこれ？」とつまづきを覚え、内容理解に集中できず、読む手が止まってしまったことがある人も少なくないのではないでしょうか。 本書『ドメイン駆動設計をはじめよう』は『Learning Domain-Driv
GitHub、コードの脆弱性を自動的に見つけてCopilotが修正案まで示す「Copilot Autofix」正式サービスに
GitHubは、コードをスキャンして脆弱性を自動的検出し、コードの修正案を示してくれる「Copilot Autofix」機能を正式サービスとして提供開始すると発表しました。 コード分析エンジン「CodeQL」でコードスキャン Copilot Autofixは、GitHubが開発したコード分析エンジンである「CodeQL」を用いてコードをスキャンし、クロスサイトスクリプティングやSQLインジェクションなどを含むさまざまな脆弱性を検出します。 検出された脆弱性に対しては、Copilotがその説明と修正コードの提案を行い、開発者に提示します。 開発者は提示された内容を確認した上で「Create PR with fix」ボタンを押すと、提示されたコードの変更を含むプルリクエストが作成されます。プルリクエストがマージされれば修正完了です。 Copilot Autofixは過去のコードに対しても適用で
typosでtypoチェックをしよう - Qiita
typosはタイポチェックツールです。 恥ずかしい間違いをする前に入れておきましょう！ 実行サンプル インストール
生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムが生成できるというアイデアから生まれた、生成AI用の疑似言語「SudoLang」
生成AIに疑似コードで指示すると自然言語よりも効率的にプログラムが生成できるというアイデアから生まれた、生成AI用の疑似言語「SudoLang」 ChatGPTやCopilotなどの生成AIを用いてコードを生成しようとすると、多くの場合プロンプトを自然言語で書くことになるでしょう。 しかし自然言語で的確にプログラムの内容を表現するのは、ときに面倒だったり、あいまいさを排除することが難しかったりします。 一方で、プログラマが自分でコードを書こうとするとき、あるいは他のプログラマとコードの内容を議論するときに、自然言語をプログラミング言語のような構文で書く、いわゆる「擬似コード」を使うことがよくあります。 例えばこんな風に自然言語をコードっぽくホワイトボードに書いたことのあるプログラマの方は多いのではないでしょうか？ 入力値を処理するための関数（A、B）{ Aは数字かどうか確認する Bは日付か
アウトプットのお題に選ぶ、奥深い自作「TODOアプリ」。mattn氏が教える、さらなる技術力の向上を目指すためのノウハウとは
TOPコラムITエンジニアの自己発信ストラテジーアウトプットのお題に選ぶ、奥深い自作「TODOアプリ」。mattn氏が教える、さらなる技術力の向上を目指すためのノウハウとは アウトプットのお題に選ぶ、奥深い自作「TODOアプリ」。mattn氏が教える、さらなる技術力の向上を目指すためのノウハウとは 2024年7月8日 mattn 大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日本語化やプラグイン、Go言語などでOSS（オープンソースソフトウェア）の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。2021〜2023年 GitHub Stars。著書に『みんなのGo言語』（2016年、2019年に改訂2版、技術評論社、共著）、『Go 言語プログラミングエッセンス』（2023年、技術評論社
理解しやすいコードの書き方～理解容易性の7つの観点～ - Qiita
はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 （変数や関数の）名称は分かりやすくする （変数や関数の）役割は１つにする （変数や関数の）参照は狭くする （変数や関数の）状態は変えられなくする （関数やクラスの）面積は小さくする （関数や
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
テストコードを書く上で個人的に気をつけている5つのこと - Qiita
はじめに エンジニアの皆様、テストコードはちゃんと書けておりますでしょうか？（挨拶） どんな開発言語や開発手法を導入していたとしても、アプリケーションの機能実装とテストは表裏一体であると言えます。場合によっては機能の作り込みよりも時間をかけるべきケースが多いくらい重要である（・・・と信じたい）反面、デッドラインが近づくにつれて真っ先に工数が削られやすく軽視されがちな工程でもあります。 時間に追われてテストコードを書いた結果、テストの体をなしていないコードになっていたり後で見返したときに記述が煩雑すぎてメンテ不能になっていたり・・・といった苦い経験は誰しもがあるかと思います。かくいう自分もそんなことは多々ありました。 そんな今までの経験則を基に「自分がテストコードを書くにあたってどんなことを意識しているのか？」をいくつかピックアップして備忘録も兼ねて紹介したいと思います。 一応注意なのですが
オープンストリーム、コードの品質を向上させて知識の共有を行う「D-College コードレビュー研修」の提供を開始
「D-College コードレビュー研修」は、若手エンジニアを対象にしており、同社の企業理念である「情報技術と社員力でお客様を成功に導く」の実現を確実にするために、「ソフトウェア原則に沿ったレビュー知識の獲得」と「ワークを通じたレビューの実践」で構成されている。 同研修の特長は以下の通り。 「ソフトウェア原則」に従って効率的にコードレビューを学習 コードレビュー時に意識する必要があるソフトウェア品質についても学習可能 ワークを通じて実際にコードレビューを実施、回答提示と補足解説で知識の定着を促進 理解度テストを実施することで定着度を確認可能 コードレビューのイメージ なお、ワークにはJavaのコードを使用する。 研修内容は以下の通り。 コードレビューの目的と重要性 コードレビューの基本的な原則やガイドライン（DRY原則・KISS原則・YAGNI原則など） コードレビューを行うためのプラクテ
Vite ってよく聞くけど何なんですか？ あれは
初めに Vue.js の学習をしているとよく「Vite」という単語を目にすると思います。 一体全体あれはなんなのでしょうか？？ なんだかよく分からないコマンドを打つと、いつの間にかプロジェクトが作成されていたり、 ファイルを編集するだけでブラウザで動くようになっていたりします。 そもそも読み方も良くわかりません 😵💫 (ヴィテ...？ ヴァイト...？) この記事では、Vite についての基本的な情報をまとめてみます。 発音？ 発音の仕方は「ヴィート」です。こちらは公式ドキュメントにも書かれています。 Vite（フランス語で「素早い」という意味の単語で /vit/ ヴィートのように発音）は、 しかし、実はこれにはやや表記揺れがあって、「ヴィット」と表記されているところもあります。 例えば、話題になった Kawaii ロゴではそのように表記されています。 まぁこれらはカタカナ表記の限界
「尖った人ではなく、暗黙知を形式知に変換する人がほしい」 “均質人材”を育成してきた日本でこれから求められる能力とは
「プログラミングを学ぶ」ではなく「要件定義を学ぶ」 田中邦裕氏（以下、田中）：あと13分ぐらいになったので、今後の展望にいきたいのですが、その前に、質問が7個ほど来ているので、みなさんに聞きたいと思います。 一番投票数が多い質問が、「非エンジニアでAIを使ったスマホアプリを作りたいんだけれども、プログラミングをそもそも学ぶべきか？」という質問です。 生成AIがある今、何をどのように学ぶべきなのか。プログラムを学ぶべきなのか、それ以外になにか手段があるのか。目的によっても違うのですが、ざっくりとしたこの質問に対して、なにか答えられる方はいますか？ 比戸将平氏（以下、比戸）：じゃあ、私から。 田中：はい、お願いします。 比戸：先週ぐらいに、NVIDIAのジェンスン（Jensen Huang氏）が、「今後はAIがプログラムを書くから、もうプログラムを学ぶ必要はないよ」と発言したのが切り取られて、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発用適当ツールはGoで作るのがオススメ - Qiita
