GitHub、Copilotの将来像となる「Copilot Workspace」発表。人間がコードを書くことなく、Copilotが仕様作成からコード作成、デバッグまで実行。GitHub Universe 2023
GitHub、Copilotの将来像となる「Copilot Workspace」発表。人間がコードを書くことなく、Copilotが仕様作成からコード作成、デバッグまで実行。GitHub Universe 2023 GitHubの年次イベント「GitHub Universe 2023」が米サンフランシスコで開幕。同社CEOのThomas Dohmke（トーマス・ドムケ）氏は1日目の基調講演の最後に、GitHub Copilotの将来像となる「Copilot Workspace」を発表しました。 Copilot Workspaceは、人間が書いたIssueを起点にCopilotがIssueに対応した仕様を書き、実装計画を示し、それに沿ってコーディングや既存のコードの修正を行い、ビルドをしてエラーがあれば修正まで行うという、コーディングのほとんど全ての工程をCopilotが自動的に実行してくれる
SOLID原則に従って行うリファクタリング実践 | メルカリエンジニアリング
この記事は、Merpay Advent Calendar 2022 の21日目の記事です。 こんにちは。メルペイBackendエンジニアのfivestar（@fivestr）です。 本記事では「SOLID原則」と呼ばれる設計原則に沿って実際に行ったリファクタリングについて、メルペイの「あと払い」サービスの開発現場事情を踏まえながらご紹介していきます。 あと払いの歴史とコード負債 私が所属するCredit Designチームではメルペイの「あと払い」や「メルペイスマートマネー」といった与信サービスの開発を行っています。中でも「あと払い」はメルカリが2017年にリリースした「メルカリ月イチ払い」を前身とする歴史の長いプロダクトであり、単純な機能追加だけでなく、設計上大掛かりな変更を伴う修正を繰り返しながら今日まで成長してきました。 例えば、あと払いをメルカードの決済・清算のバックエンドとして統
バグを増やさないためにコードレビューのチェックリストを使う | Yakst
チーム内で良くある間違いなどをチェックリストにし、それをコードレビュー時に使う事で、コード自体のレベルを上げつつコードレビューの品質のばらつきをなくす取り組みについて。Trelloなどを開発するFog Creek社のブログの翻訳。 効果的なコードレビューについて書いた我々のブログ記事の中で、チェックリストを使う事を推奨した。チェックリストを使う事で、レビューが継続的にチーム全体でうまくはたらくようにできる。また、ありがちな問題を見つけたり解決したりするのを確実にする、簡単な方法でもある。 ソフトウェア工学研究所の研究によると、プログラマは15から20の良くある間違いをしてしまいがちだという。そういった間違いをチェックリストに追加しておく事で、問題が起こった時にそれを特定し、確実に駆逐するようにできる。 チェックリスト作りに取り掛かるに当たって、一般的な項目は以下のリストのようになるだろう。
コードレビューの際によく指摘するポイントについて - Qiita
このドキュメントについて レビューポイントっていうのは周囲のレベルや使っている技術によりまったく異なるのですが、割と汎用的に使えそうな部分について今の開発チーム向けに書いたドキュメントを共有 レビューチェックポイント(機能) 仕様と実装が合っているか 仕様が不明瞭な部分について勝手な仕様で実装をしていないか 違和感のある実装になっていないか ロジック・アルゴリズムが合っているか そもそも論理構造が破綻していないか 画面表示に違和感がないか 奇妙な文言、ユーザ視点で奇妙な動きになってないか 不正なユーザ入力で問題が発生しないかFatalErrorにならないか 入力に対し適切なvalidationが行なわれているか レビューチェックポイント(コード) 意味の無いロジックが含まれていないか コピペでコードを持ってきた場合にコピペ元の不要なコードが入っていないか そもそも基本コピペはNG コピペで
"クソコード"は人格攻撃ではないのか｜qsona
これは仮説というか自分がこうだという話なのだが、自分のアイデンティティを侵食されると怒りが湧く。たとえば、自分が非常に大事にしている価値観に対して、同僚から「君のその価値観は間違っている」と言われたり、あるいは、作品とか、経歴とか、家族とか、そういう自分自身と非常に密になっていて同一視されるようなものをけなされたら、腹が立つということだ。 プログラマーにとって、ソースコードというのは一つの作品だ。仮に経験が浅い開発者であっても、あるいは経験が浅いからこそ、1行1行に時間をかけて考えながら作りあげる。それに対してこれはクソコードだと言われたらどうだろうか。考えてみる。 よく、クソコードというのはコードがクソだと言っているのであって、お前がクソだと言ってるわけではないから切り離して考えるべきだという言説がある。僕はこれには微妙に賛同できない。その人が生み出したコードは、少なくともその人のいくぶ
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
コードレビューの基準
コードレビューの基準 コードレビューの主な目的は、Google のコードベースにあるコードの全体的な健康状態を時間をかけて改善することです。 コードレビューのすべてのツールとプロセスは、その目的のために設計されています。 これを実現するには、さまざまなトレードオフのバランスを取る必要があります。 まず第一に、開発者は自分のタスクを進めることができなければなりません。 コードベースに改善を提出できなければ、コードベースは改善しません。 また、どんな変更に対してもレビュアーがいちいち難色を示して変更を取り入れずにいると、早晩、開発者は改善を行う意欲を失います。 一方、CL の品質を確認するのはレビュアーの義務です。CL を取り入れてコードベースのコードの全体的な健康状態 (code health) がだんだんと悪化するのは問題ですから、きちんと確認しなければなりません。 これは骨の折れるやっか
コードレビューの観点
コードレビューの観点 （注）以下のポイントを検討する際にはつねにコードレビューの基準を忘れないでください。 設計 レビューで確認すべき最も大切なことは、CL の全体的な設計です。 CL のコードの各部分は相互にきちんと連携するでしょうか？この変更はコードベースに属するものでしょうか、それともあるライブラリに属するものでしょうか？システムの他の部分とうまく統合するでしょうか？この機能を追加するタイミングは今がふさわしいでしょうか？ 機能性 この CL は開発者の意図通りに動作しますか？開発者の意図はこのコードのユーザーにとって適切でしょうか？「ユーザー」とは普通、エンドユーザー（その変更によって影響を受ける場合）と開発者（将来このコードを「使う」必要のある人）の両方を指します。 通常、CL がコードレビューに至るまでには、コードが正しく動作することを開発者が十分にテストしていると期待できます
現在のGoogle HTML/CSS Guide コーディング規約/日本語訳
コーディングを勉強している方や、普段当たり前のようにコーディングしているけれど、上手く使えているのか不安な方向けにGoogle HTML/CSS Guideの翻訳記事を書きました。（2024年02月29日更新） 色んな方のコーディングを見ていると実に様々。情報や知識が古いままで、今では推奨されない書き方も散見されます。 特に仕事で使っていると、誰かに指摘されない限り自分のコーディングを見直す事は無いかもしれません。 ですがW3Cの定めたHTML5の廃止など、変化の速い業界では定期的な見直しは勿論、何か指標となる物があると安心です。 そこで今回はGoogleが用意しているgoogle html/css style guideのドキュメントを元に、Googleコーディング規約と要点を解説。このコーディングガイドラインが絶対的な正解では無いかも知れませんが、参考になれば嬉しいです。 Google
コーディング面接対策のために解きたいLeetCode 60問
自分がコーディング面接対策のために解いてよかった LeetCode の問題をコンセプトごとにまとめました。カバーするコンセプトは LinkedList Stack Heap, PriorityQueue HashMap Graph, BFS, DFS Tree, BT, BST Sort Dynamic Programming Binary search Recursion Sliding window Greedy + Backtracking です。 これらの問題が 30 分以内に実装できれば面接の準備は整ったと言っていいと思います。Easy と Medium で問題は構成されてます。進捗を管理するためにGoogle Spreadsheetを用意しました。コピペしてご自由にお使いください。 これらの問題は、LeetCode のリスト機能でも公開されています。クローンすれば自分がすでにど
「IntelliCode」がさらに進化し、行全体を候補として提案。まるでAIとペアプロしているように
マイクロソフトは、AIによるコーディング支援機能の「IntelliCode」がさらに進化し、コーディング中の行全体を提案できる能力を備えるようになったことを明らかにしました。 下記は「Re-imagining developer productivity with AI-assisted tools」から引用です。 IntelliCode now provides whole-line code completion suggestions mined from the collective intelligence of your trusted developer knowledge bases. This is like having an AI-developer pair-programming with you, providing meaningful, suggestion
保守性・可読性の高いPythonコードを実装するためにはどうすればよいか - はてなの金次郎
はじめに コードは理解しやすくなければいけない。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者:Dustin Boswell,Trevor Foucher発売日: 2012/06/23メディア: 単行本（ソフトカバー） コードの保守性や可読性を高めるために我々エンジニアはどんなことができるでしょうか？ テストを書く 推奨されているコードスタイルに準拠する コメントを書く DRY原則に則る 変更・拡張しやすく設計する ログを出力する・監視する 適切な命名をする etc... まだまだ意識すべきことはあると思いますが、上記の項目はエンジニアであれば恐らく一度は目にしたことがあるような内容であり、暗黙的に了承されたいルールです。 しかし、これらはただの心構えであり、体現するために実際には以下のような項目に落とし込む必要
かずき師匠にクソコードをレビューしてもらった学び - Qiita
わたしのコーディングの師匠かずきさんに、私のクソコードをレビューしてといったらオシャレなコードになって帰ってきたので、その学びを書き留めておきたい。 今回のゴール 私は Durable Functions というリポジトリに貢献しているのだが、前回実装した全件取得のメソッドに対して、検索条件を追加するメソッドを書きたいと思った。検索条件を表すオブジェクトをつくれば多分テストもしやすくていい感じのはず。 今回のクソコードの解説 最初に作ったクソコードはこんな感じ Builder 的な感じで作ってみた。TDDを使ってやってるのでテストもある。 リポジトリ TsuyoshiUshio/StorageTableQueryCore OrchestrationInstanceStatusQueryBuilder using Microsoft.WindowsAzure.Storage.Table; u
初心者プログラマが犯しがちな過ち25選 - Qiita
以下はThe Mistakes I Made As a Beginner Programmerの日本語訳です。 The Mistakes I Made As a Beginner Programmer 初心者プログラマが犯しがちな間違いと、それらを特定し、避けるための習慣を学ぶ方法。 まず最初に言っておくことがあります。 この記事は、誤りを犯すことを悪いと糾弾するために作成されたものではありません。 むしろ貴方が誤りに自ら気付き、あるいはその兆候を見いだし、それらを避けられるようにするために書かれたものです。 私は過去これらの誤りを犯し、それぞれから学びを得てきました。 今ではこれらを避けるようなコーディングを習慣付けるようにしています。 貴方もそうしましょう。 紹介は順不同です。 1) 設計せずに実装する 高品質なコンテンツは、一般的には容易に作成できるものではありません。 それには慎重
ウェブアプリをソースごとパクる業者に対する対策 - Qiita
こんにちは。みなさんもウェブアプリをリリースしたあとに同業者にソースごとパクられたことってありますよね。難読化しても難読化されたまま同業者のサーバで動くので困ったものです。そこで、私がとった解析しずらい対策をまとめてみたいと思います。 前提 多機能な画面をJavaScriptでゴリゴリ作ったのにもかかわらず、HTMLやCSS、JavaScriptファイル一式を自社サーバにまるごとコピーして、ライセンス表記だけ書き換えて使うような業者を罠にはめるということを想定しています。 当然通信をリバースエンジニアリングする人もいるので、自社サーバでは防げないという前提です。 HTMLにはauthorメタタグ よくあるMETAタグで権利者を明記します。これは権利の主張もそうですが、JavaScript自体に権利者が認定した権利者でなければ無限ループを起こすという処理のためにも使用します。逆に、権利者が我
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
Atomがめっちゃ便利に！ Web制作者が絶対入れたいプレビュー系アドオン7選
人気エディターAtomをもっと使いやすく、生産性を高めるパッケージの紹介です。プレビュー周りの機能を強化して、コーディングの効率をアップしましょう。 この記事では、コードエディターAtomで使えるパッケージを紹介します。このパッケージを使うと、タイプしながら変更点をプレビューしたり（特にWebサイト開発向け）、エディターからコンソールやIDEに移動せずにコードをコンパイルして実行したりできます。また、メリットについても記しました。 参考：ショートカットのCtrl|Cmdは、Windowsなら「コントロール」キー、OS Xなら「コマンド」キーを指します。 変更点のライブビジュアライズ プログラムのコーディングからビジュアライズ（結果確認）へと移動するのは時間のムダなだけでなく、認知のロスを伴います。つまり、タスクの切り替えにより集中力と精神力が失われるため、生産性が低下するのです（『The
2016年に見直したHTML5・CSS3コーディング手法6選 - ICS MEDIA
HTML・CSSコーディングを取り巻く状況は、数年前と大きく変わっています。最近では、2016年11月にHTML 5.1が勧告されたり、2015年8月頃にChromeのブラウザーシェアがInternet Explorerを抜いたりといったニュースがありました。また、2017年4月にはWindows Vistaのサポートも終了するため、今後対応すべきはWindows 7のIE 11以降となります（※）。当たり前だと思っていたコーディング技術を今一度見直す時期にきているのではないでしょうか。本記事では2016年に見直した、今の時代に即したコーディング技術を紹介します。 ※ 参考記事「Internet Explorerサポートポリシー変更の重要なお知らせ - Microsoft」 1. meta keywords設定は検索順位に関係がない ウェブコンテンツのキーワードを指定するmeta keyw
コードを書く際の指針として見返すサイトまとめ - Qiita
お勧めの記事がありましたらコメントなどで教えて頂けると幸いです。 Guidelines プログラマが知るべき97のこと 技術的負債 不慣れなコードベースで短期間に生産性を高めるための7つの方法 何も知らない人を育てるために(新人教育情報キュレーション) 保守開発に開発者として入って困ることのまとめ(実体験) 技術系の名言まとめ++ 真似をする前にバッドプラクティスかどうかを調べてみよう 読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） 技術的負債とどうやって戦うか Coding Style モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう 関数名や変数名に使えそうな動詞・名詞・形容詞のメモ Naming -名前付け- DRY原則をもう一度 -コンカレント・エンジニアリング- レガシーコードのメンテナンス担当になったら新人はどうすればいい クソコードに対する怒りとコー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/34
