Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 3行 クソコードは無知から生まれる 個人的にコーディングのときに心掛けていることのまとめ ここに書いてあるのが全て正しいわけではないので参考程度に、という保険 クソコードを滅ぼしたい おはようございます。デブです。 早速タイトルと趣旨が食い違っているような気がします。 さて「クソコード」という言葉があるようにコードにもピンキリがあります。 因みにピンキリの語源はポルトガル語のpintaとcruzらしいです(諸説あります)。 時としてクソコードは見た者の精神を破壊します。 私の場合は、年上で先輩で異性であんまり話したことのない方のコードを
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
DIはインタフェース定義しなくても十分実用的だし、むしろそっちの方が本質だよ、という話をします。C#や.NETを使っていますが、それに限らず普遍的な内容です。 インタフェースと実装に分けるとか無理。DIなど不要！ 中堅社員のA氏は、**「DIっていちいち実装とインタフェース分けないとダメなんでしょ？。さすがにやってられんわ」**と言って頑なにDIを導入しようとしません。 DIはテスタビリティと併せて語られることが多かった為か、A氏は「注入するクラスは基本的にインタフェース定義しましょう」という記事ばかりを読んでいたのです。 インタフェースと実装を分けるとは、例えば次のような事です。 services.AddScoped<IMessageStore, MessageStore>(); public interface IMessageStore { string GetMessage(str
公開日 : 2021年10月14日 (2023年10月11日 更新) カテゴリー : アクセシビリティ / ユーザビリティ ウェブのフォームにおいて、サブミットボタンをデフォルトで無効化しておいて、ユーザーの入力不備がなくなったときにボタンを有効化する UI があります。たとえば、利用規約などの文書を読んで同意する旨のチェックを入れないと、あるいは、入力必須フィールドにすべて正しく情報を入れないと、ボタンがアクティブにならない、というものです。 サブミットボタンがデフォルトで無効化されているフォームの例。 このような UI は、アクセシビリティやユーザビリティの観点で、以下の問題があります。 そこに存在しているはずのサブミットボタンが使用できないことに対して、その理由をユーザーが理解できずに、混乱してしまう恐れがある。(ユーザーの側に誤っているという自覚がなくても、ちょっとした見落としや入
Goodpatchでは、UIの構造設計を重視したデザインプロセス「モデルベースUIデザイン」を推進しています。最初にコンセプト定義やユースケースを定義し、情報整理をして最終的に機能やビジュアルなどの具体的なところを詰めていく考えをとっていくプロセスです。 今回は、マネーフォワードさんと「デジタルプロダクトのUI設計のプロセスと考え方を学び、実践することでスキルのベースを身につけること」をテーマに、モデルベースUIデザインについて理解・実践するワークショップを開催しました。本記事では開催の背景から当日の様子をご紹介します。 参加いただいたマネーフォワードのUI/UXデザイナーさんによるnoteもぜひご覧ください！ マネーフォワードがGoodpatchさんとUIデザインワークショップを実施しました！ ご相談いただいた背景 「お金を前へ。人生をもっと前へ。」をミッションに掲げる株式会社マネーフォ
Photo by Ruiwen Chua こんにちは。倉内です。 皆さんは「開発系のITエンジニアの業務」と聞くと、システムを開発するためにコードを書くというのがまず浮かぶのではないでしょうか。 それも間違いではないのですが、実務では要件定義・設計・開発・テスト・運用といった工程があります。すべてを担当するかは開発規模や企業にもよりますが「書いたコードをテストする」という作業は必ず発生するため、ITエンジニアにとってテスト工程は避けては通れない道だと言えます。 しかし、実務経験がない方にとっては、「テストってなんとなくは分かるけど、具体的に何をするかはよく分からない…未知の領域…」という感じかもしれませんね。 テストは突き詰めるとかなり奥が深い（それこそ分厚い参考書になるくらい）ですが、今回は「なぜテストをやるのか？」「どのようなテスト方法があるのか？」など、システム開発における「テスト工
iOSDC 2021 での登壇資料となります。 登壇内容 https://www.youtube.com/watch?v=yWO47AFkDls 以下、スライド内に登場するリンク一覧です。 MoT Teck Talk vol.3 「タ…
こんにちは、エンジニアのオオバです。 Vagrant was unable to mount VirtualBox shared folders. This is usually because the filesystem "vboxsf" is not available. This filesystem is made available via the VirtualBox Guest Additions and kernel module. Please verify that these guest additions are properly installed in the guest. This is not a bug in Vagrant and is usually caused by a faulty Vagrant box. For context, the c
実証環境 Windows10 Apache2.4.10 PHP5.6.4 MySQL8.0.15 (旧)MySQL5.6.43 PHPはmod_phpでApacheと連携、MySQLにはPDOで接続しています。 経緯 開発環境で使用していたphp5.6.4＋MySQL5.6.43をMySQL8に移行しようとしました。 MySQL8.0.15をインストールして、既存のMySQL5.6.4から必要なDBだけdumpして移行する予定。 MySQL8.0.15をインストール後にphp5.6.4から接続確認をする時にハマりました。 テストDB MySQL8.0.15をインストール後に下記DBとTABLEを作成。 テスト用のDB mysql> CREATE DATABASE test; テスト用のTABLE mysql> CREATE TABLE sample(id int,name text); テ
プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。 この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してない
はてブで単一責任の原則（Single responsibility principle）について、もう一度考えるといふ記事を見掛けて、なんとなく懐かしい気持ちになった。久し振りにこの言葉を見たなって。 「一つのモノに一つの責任 (役割) を」といふモットーは、初めて聞いた時にはすごくもっともらしく聞こえるんだけど、いろいろ考へてくと結局「責任が一つであるとはどういふことなのか?」「といふか、責任って一つとか二つとか数へられるものなのか?」といふ疑念を抱くよね。俺も昔さう思ひました。 で、この菅野さんの記事では「責任が一つであるとは、一人の利用者 (アクター) に対してだけ責務を果たすこと」といふ話をしてゐる。その理解はたぶんそんなに間違ってはゐないと思ふ。ブコメに「作者の人そこまで考えてないと思うよ」とかいふコメントもあったけれども、菅野さんの記事が信用できないと思ふんならボブ本人による記
TL;DR 「可読性が高い」とは、「理解するために使う脳内メモリの量が少ない」ということである。 理解するために使う脳内メモリの量 = コードを理解するのに必要な情報量 - コードについての予備知識 「そのコード 1 行を単独で理解するのに必要な、追加の情報を意識する。その追加で必要な情報が減るようなコードにする」というのが可読性を高めるための一つの大きなの指針としてアリなのではないか。 はじめに 可読性についての細かい Tips は様々ありますが、「結局」何をどうすればいいのか？という漠然とした問いには答えられていない気がします。細かい Tips を包括する大きな指針をがないかと考え、まとめたのがこの記事です。 可読性の高いコードとは？ 脳内メモリの消費を抑える 可読性とは、コードが頭に入ってくる時のスムーズさと言えると思います。すなわち、いかに直感的に、余計なことを考えず、脳内メモリの
はじめに C#のORマッパーといえばEntity Framework（以下、EF）が有名で、データベースの接続を調べると真っ先にEFの名前が出てきます。ORMの機能を充分に備えたライブラリはEFしかありませんが、致命的な欠点があります。欠点については後述しますが、これを解決するには他のライブラリを使うほかありません。本記事では、EFを使わずにORマッパーの機能を使うライブラリとその組み合わせを紹介します。 ORMの基本的な機能 紹介する前にまずはORMで必要な機能を確認します。ORM（Object-relational mapping）は、オブジェクト関係マッピングと呼ばれ、オブジェクト思考とRDB間の非互換であるデータの違いをうまく吸収（これの逆をインピーダンスミスマッチと言います）して、簡単にデータを扱えるようにする技法です。基本的な機能は以下があります。 SQLを意識することなくコー
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
