汚いコードはよくない (2024.9.22 追記:続編を具体的にかきました!) コードを書くと、コードは増える プログラムは、ソースコードと呼ばれる文字列を記述する事で作成されます。このことを、単にプログラムを書く、コードを書く、などと言ったりします。 ほとんどの場合、プログラムを書くときには、その目的があります。 なにかの目的を達成するために、ソースコードと呼ばれる文字列を記述します。 この記述方法にはいろいろなものがあり、同じ目的を達成するにも無数の方法が存在します。 どの方法を選ぶかは作者に任されている、という言い方もできます。 ところで、ソースコードを記述していき、プログラムで実現できる事が細かくなるにつれて、文字の数はだんだんと増えていきます。 コードの増え方にもいろいろある この文字が増えていく様子を比喩的に表現することを考えます。例えば書類を積み上げることや、積み木を積み上げ
「Cybersecurity News」は2024年8月26日(現地時間)、セキュリティ研究者が「Windows」で発見されたTCP/IPスタックに存在する重大な脆弱(ぜいじゃく)性「CVE-2024-38063」の概念実証(PoC)コードを「GitHub」に公開したと伝えた。 CVE-2024-38063は「Windows 10」「Windows 11」「Windows Server」など広範囲の複数のバージョンに影響を与える深刻な脆弱性で、悪用された場合、リモートコード実行が可能になる。Microsoftは問題の深刻さから、2024年8月の累積更新プログラムで修正プログラムをリリースし、ユーザーに対して速やかなアップデートを呼びかけている。 Windowsの重大な脆弱性に対するPoCがGitHubに公開 悪用の懸念も この脆弱性は、WindowsがIPv6パケットを処理する際に発生する
ソースコード管理の進化:Excel管理からGitHubまで、エンジニアの戦いを振り返る! プロローグ 先日、弊社のとある案件内での会話です。 熟練エンジニア(以降「熟練」と表記):GitHubのプルリクが来てたからコードレビューしておいたよ。 若手エンジニア(以降「若手」と表記):ありがとうございます。助かります。 熟練:他の人のコードにも指摘した内容がキミのコードにもあったので指摘しておいた。他の人のプルリクは見ていないの? 若手:いや、他の人のプルリクは見てないですね。。 必要ですかね・・? 熟練:必要だよ。昔はそういうのやりたくてもできなかったんだから! 若手:(はじまった、熟練さんの昔語り・・。長いんだよなぁ。。)なるほど!そうなんですね。他の人のコード読んで勉強します! はじめに 皆さん、こんにちは。エンジニア歴約20年目の立脇です。今日は、エンジニアにとって切っても切り離せない
はじめに ソフトウェア開発において、コードの可読性はプロジェクトの成功に直結する重要な要素です。読みやすいコードは、メンテナンスや拡張を容易にし、チーム全体の生産性を向上させます。 しかし、「読みやすいコード」 の定義は人によって異なります。個々のスタイルや好みによって解釈が分かれることもあるでしょう。それでも、できる限り多くの人にとって理解しやすいコードを書くことが、プロフェッショナルとしての責任です。このガイドでは、そんな読みやすさを意識した具体的なテクニックなどを紹介していきます。「もう知ってるよ!」と思った方も、今一度できているかを確認してみてください。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 注意点 こ
はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原則や技法へのリンクを記載した。 要約 7つの観点の要約を先に示す。 (変数や関数の)名称は分かりやすくする (変数や関数の)役割は1つにする (変数や関数の)参照は狭くする (変数や関数の)状態は変えられなくする (関数やクラスの)面積は小さくする (関数や
技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。 最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期(それぞれRubyの会社で働いている)と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。 この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。 とても大事な疑問を見つけられたんだなあと思います。 「良さとは何か」ということに向き合う必要の
文章の折り返しはウェブ制作において意外と難しいものです。URLが文章に含まれている場合、URLがレイアウトを突き抜けてしまった、という経験をみなさんはお持ちではないでしょうか? この記事では、国内のウェブ制作において「開発者が考えることが少なくてよくなる」安全なCSS指定を紹介します。 結論から説明すると、以下の指定を提案します。 body { overflow-wrap: anywhere; /* 収まらない場合に折り返す */ word-break: normal; /* 単語の分割はデフォルトに依存 */ line-break: strict; /* 禁則処理を厳格に適用 */ } この記事では上記の指定にいたった理由と、折り返しの理解について必要なoverflow-wrapとword-breakプロパティを中心に解説します。 overflow-wrap overflow-wrapは
先日のJJUG CCC 2023 Fallの懇親会でクソコードを研究しているという学生がいたのだけど、クソコードの研究は難しいという話をした。 人工的にクソコードを再現しても、あの野生のクソコードのクソさには全く足りないわけで。 トルストイが言うように「すべてきれいなコードは互いに似通っているが、クソコードはそれぞれにクソの趣を異にしているものである」なので、なかなか「これがクソコード」のように類型化するのも難しい。 典型的なクソコードを書いてみても、なんだかきれいなクソコードができてしまう。 クソコードはネットに出回らないので、資料の収集もまた難しい。ネットにないということは、ネットの情報に基づいている「AI」もホンモノのクソコードには触れていないことになる。 クソコード収集サイトをつくっても、実際のクソコードは業務固有処理も含まれるので、掲載できる形に整理していくと本来のクソさが薄れて
はじめに 一般的には、コードの再利用は推奨されていることかもしれませんが、かえって時間がかかってしまいました。再利用というとすでにあるコードに多少手を加えて簡単に作れると思いますが、今回は逆でした。 シンプルなWebサイトを作ろうと思い立ち、仕様的に機能のあるコードをベースにして、不要な機能のコードを削り取ってゆきました。この作業が思ったよりも時間がかかり、再利用としては失敗だったかなと思っています。 今回の再利用 シンプルなyoutube検索再生プラグインを作ろうと思い、前回作成したプラグインをベースにしました。ところが、このプラグインのコードが整理されてなく、そのことが再利用にあたり、困難を極めました。 このプラグインは、二つのタブが連携して動作します。このことも障害の原因になりました。タブは親子の関係で動作します。 困難だった作業 (1) ベースとなるコードの複雑さ content.
こんにちは、つくぼし(tsukuboshi0755)です! 最近ChatGPTがGPT-4Vを発表し、AI業界がさらに盛り上がりを見せてますね。 GPT-4Vを用いる事で、ChatGPTがユーザ側から入力された画像を読み取った上で、応答を返してくれるようになります。 GPT-4V(ision) system card この機能追加により、なんと以下のようにAWSの構成図を読み取って、IaCコードを生成できる事が話題になっていました。 本日をもって引退します pic.twitter.com/fygAQDQ5kj — 電気ひつじ(onoteru) (@teru0x1) October 13, 2023 これを見て私もGPT-4Vを試してみたくなったので、今回はChatGPTを使って、様々なAWSの構成図を入力し、どこまで正確にIaCコードを生成できるか確認してみます! GPT-4Vを利用する際
どんな人向けの記事? レビューによって心理的なダメージを受けやすい方 非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方 業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方 コピペできるコードも公開します 初回レビューをAIに任せると、いろんなロールの人の役に立つ レビューは得意ですか? 優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。 しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。 実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。 今回の記事は、レビューを作成してくれるAI C
アマチュア驚き屋のきしだです。 ChatGPTが画像入力に対応するよという話があって、来週くらいに使えるようになるかなーと思ったら、もう使えるようになってました。 で、写真から「カレー食べてる男の人です」くらいを言えるイメージで試してたら、なんかふつうに画面設計やクラス図からコードを書いていてびっくりしてしまいました。 まあ、起きたらこういうのが来てたわけですね。 で、まあ試してみて「あぁ、いままでのマルチモーダルよりちゃんと画像認識してるなー」くらいに思ったわけです。 で、NetBeansでの画面設計を読ませてみたらこう。 こういうコードが生成されました。 import javax.swing.*; import java.awt.*; public class SimpleForm { public static void main(String[] args) { JFrame fr
www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている(ご存じの方は彼にご一報を)。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80%、いやもしかしたら90%をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく
はじめに 仕事におけるプログラミングの現場においては「リーダブルコード」を求められることが往々にして多いことでしょう。もちろんアーキテクチャやデザインパターン、流行りの機能、書き方を学ぶことで解決することもありますが、「なんか使ってるんだけどわかりづらいな・・・」と思うことがあったりしませんか? 読みづらいメカニズム まず読みやすくなるためのテクニックを語る前に、「何故読みづらいのか」を考えてみました。 こう思い返してみると、アーキテクチャやデザインパターンやらに依るところはなかったと言っても過言ではなかったかなと思います。 1. そもそもの処理の認識が誤っている 一見読んだだけで理解できないコードがあったときに、書いた方に「これはどういう処理ですか?」と聞きます。そうすると一定のケースで「説明される内容(日本語)がそもそも正しくない」に分類されることが多いのです。 そうしたときには、その
みんなお世話になっている TypeScript のコードを読みたいと思ったことはないだろうか。読んだ。 一週間ぐらいかかった。完全に読み切ったとは言えないが、概要は掴んだ。 なかなかに複雑でドメイン知識を得るのが難しかったので、これから読む人向けに、登場人物や概念を整理して紹介したい。 読んだのは 2023/6/8 時点で git clone したコード。 最初に: 自分のゴール設定 複数ファイルにまたがった参照を、 TypeScript の Language Service が提供する findReferences() や findRenameLocations(), goToDefinitions() を使って、インクリメンタルに書き換えたかった。 Terser を使うと、今触ってるオブジェクトが何で、何のメンバを書き換えたかの情報が残らない。これを TypeScript のレイヤーで
この記事について 私はWeb基盤を提供している企業でWebアプリケーションエンジニアをしています。 インフラや顧客基盤など複数のバックエンドAPIが動いており、それらを結合したアグリゲーション(BFF)の作成とフロントエンドの実装を担当することが多いです。 言語はTypeScriptとC#を選択する事が多く、フロントエンドではReact.jsとVue.jsを使用しています。これらをコンテキストとして私が「良いコード」を書くために日頃意識しているTipsを投稿していきます。 やらないこと インデントを揃える、命名基礎、アクセス修飾子などの基礎的な内容は割愛しています。 コードはTypeScriptで書いています。ですが特定の言語に特化した内容にはしていません。 プログミング全般に掛かかった内容であり、フロントエンドやバックエンドなど特定のレイヤーに特化した内容にはしていません。 良いコードと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く