GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリですYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる - Diary
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。 Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。 本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだい
long_time_work_cannot_finish_tasks
先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい？ 困ったことはない？」と尋ねられ、 僕は即座に「すごく楽しいですよ。日本で働いていた会社とは大違いです」と答えた。 「日本では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日本の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか？」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる
Androidでよくあるめんどくささ - Konifar's ZATSU
最近Androidを楽に開発するためにはどういうクラス構造にすればいいかを考えている。 巷にはMVP、MVVM、MVC、FLUXなど様々な設計が溢れているが、サンプルコードを見てもなかなかイメージがつきにくい。理由はサンプルが簡単すぎるからだ。シンプルなTODOアプリではメリットよりコード量の増加や見通しの悪さといったデメリットの方が目についてしまい、どうしても『なぜ』その設計や構造が必要なのかを理解しにくい。理解できても1週間後には忘れている。 Android開発においてなぜ設計が議論されるかと立ち返ってみると、考えることを少しでも減らしたいからだと言える。わかりやすいところで言えば、複雑なライフサイクル、画面回転を考慮したデータのロードにエラーハンドリング、その状態に応じた画面表示あたり。Androidの開発をする上で、考慮しなければいけない事象はバージョンアップのたびに増しており、そ
ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち | スラド デベロッパー
ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事
パフォーマンス３倍を実現した仕事術
当方都内ヴェンチャーSE。 俺がリーダーになってから試しに導入してみたルールのおかげでチームの生産性が３倍になった。 誇らしいことだが、果たして一般的に有効な方法なのかどうか気になるので広く反応を集めたいと思って書く。 そのルールというのは単純、「一日に５時間以上コードを書かない」というものだ。 勤務時間の８時間のうち、本当に仕事をするのは５時間だけに制限する。 そして残りの３時間は会議と称する息抜きタイムにした。 これで生産性は３倍になった。 社長も機嫌も俺の評価もうなぎ登り。 社長はモーレツに仕事をする人で、社員にも同じようにモーレツに働くことを求めていたが、俺は同調しなかった。 普通の人間は集中できる時間に限りがある。 凡人にはよくて一日５時間が限界だ。 それ以上の時間を使っても、単位時間あたりの生産性は下がるばかりだ。 ならいっそ、残りの時間は最高のパフォーマンスを発揮できる５時間
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
（第2回）ダメ発注その1、要件定義もできない“低クオリティ”
ユーザー企業には「発注責任」がある。しかし実際には、この当たり前のことをわかっていないユーザー企業は数多い。その結果、システム開発プロジェクトが頓挫し、ユーザー企業とITベンダーの双方が大きな打撃を受けるケースが頻発している。この特集では、ユーザー企業がシステム開発をITベンダーに発注する際に陥りがちな問題点を、発注のQCD（品質、料金、期日）の観点から分析する。 今回は“Q”、つまり発注の品質にフォーカスして問題点をあぶり出す。なお、この特集は日経コンピュータの2008年6月15日号に掲載した記事をベースに、内容を一部修正して著者の現時点での認識などを加えたものだ。オリジナルは4年半前の記事だが、ITベンダーの事業部長、営業部長クラスの人に匿名を条件に語ってもらった“事実”は、今でも全く古さを感じさせない。 一括契約はここが恐ろしい 発注の品質、つまり要件定義の問題は、ほぼすべてのITベ
Readme駆動開発を和訳してみた - 生涯未熟
rebuild.fmで話にあがっていた「Readme Driven Development」について、 原文がどんな内容なのか気になったので訳してみました。 英語力が低いのでGoogle翻訳等をフル活用していますので、 間違っているところや日本語的に怪しいところなどありましたら、ご指摘お願いいたします！ 最近TDD（テスト駆動開発）やBDD（ビヘイビア駆動開発）、エクストリームプログラミング、スクラム開発、スタンドアップミーティングなど、より良いソフトウェア開発のための様々な種類の方法論・開発手法の話題をよく耳にする。 だが、開発しているソフトウェアに対して、それらの方法論・開発手法がマッチしていない限り、全く意味は無いものになっているだろう。 別の言い方をすると、粗悪な設計書に基づいた完璧な実装のように価値がないということだ。 同じようなもので、ドキュメントの無いビューティフルな技術を用
エンジニアの「出来る」を正しくマネジメントする為に必要なこと - GoTheDistance
この記事面白かったです！ 「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。 私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。 実装可能と実現可能は別問題 前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。 技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた
2人の若者
2人の若者が同じプロジェクトにアサインされました。 一人はできる君、ひとりは残念君と言いました。 そのプロジェクトは優秀なPMとモチベーションの高いメンバーで構成されており、スケジュールやタスクなど大変見通しがよく、整理された進行状態を保っていました。極楽プロジェクトと呼びましょう。 できる君はプロジェクトの全体を把握し、自発的に自分にできそうなタスクを探し、プロジェクトに貢献しはじめました。すぐに重要なタスクを任されるようになりました。 残念君はプロジェクトを見通せておらず、自分に何ができるかも分かりませんでしたが、PJメンバーが彼にちょうど良いタスクを探したり作ったりして、彼に仕事を振っていました。残念君も頑張ってはいますが、重要な仕事はまだできませんし、PJのリソースを奪っている面も否定できません。 ある日残念君に転機が訪れます。ダメなPMが仕切り、モチベーションの低いメンバーが集め
オブジェクト指向について - きしだのHatena
参考までに、ぼくの基本的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織化のしかたを勉強することだと考えています。 現在のシステムは、データはデータベースに格納され、振る舞いとは分離して管理されています。そのような中では、システムをオブジェクトの集まりとして組織化することはできません。 局所的にも、ステートレスを前提としたHTTPの処理では、オブジェクト組織の必要な局面はありません。 個別のオブジェクトの共通化に継承を使うという点では「クラスは単にユーザー定義型であり、継承は部分型と差分プログラミングを実現する仕組みだととらえる」だけで充分だと考えています。 そうしたシステムにオブジェクト
「技術的負債」をコントロールする定量評価手法への期待
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます＆いつもすみません。 僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。 なぜ、そういう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。 スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じるこ
「実装をテストする」とは？ - bluebird
TDD界隈の議論で、「仕様のテスト」「実装のテスト」という話を聞くことがあります。 TDDのよくわからない言葉をどうやって説明するか悩んでいるという話 #SWTestAdvent — うさぎ組 明日からTDDをやってみよう！ - 部屋とアジャイルと私（仮称） 今日のTDD界隈で「仕様のテスト」「実装のテスト」という言い回しを一番よくしているのは私だと思うのですが、勉強会の場などでは話をすることはあるものの、こういう形で残してこなかったので、自分の考えをまとめたいと思います。 公開されているインターフェースの仕様を満たせるなら、API(「リファクタリング」で言う「公布済みインターフェース」)のエントリポイントの内側のクラス設計をどのように組み立てるかは、実装者の裁量に任されているはずです。 品質保証の観点からは、APIの仕様を満たせるテストケースを記述すれば、ソースコードに対してのある程度の
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
プロジェクトリーダはコードの読み書きできれば良いか - プロマネブログ
「コーディング技術にこだわり過ぎると～」の反省会 - プロマネブログ コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない - プロマネブログ そいえば、上記記事のブコメ欄でいただいたコメントの中で考えてみたいなと思うコメントがあったので、記事でまとめてみようかと。 プロジェクトリーダに必要となる技術はコード読み書きできればOK? どっちにしてもコードが読み書きできない人はソフトウェア開発に関わっちゃいけませんので、その辺何卒よろしくお願いします。 考えてみたいのは上記コメント。異論はないのですけど、プロジェクトリーダ(以下、PL。プロジェクト進行の話が中心なので、広義のプロマネって言うと話がごっちゃになるので)はコードの読み書きできるぐらいでいいのかってのはあります。 知っている限りのPL連中は、往々ソースの読み書きできます。 もともと、プログラミングやったこと無いって人も
mkoszk’s blog
はじめに USDMに関する記事をインターネット上で検索すると、「要求仕様定義ガイドライン」 に触れた記事がヒットします。ただし、内容について書かれたものは少ないようです。 そこで、どんな内容なのかUSDMとの関連に絞って書こうと思います。 USDMとガイドラインの関係 ガイドライン執筆の動機として、要求仕様書の品質が良くないため、ユーザ企業として何とかしたい。何を書けばよいのかは分かっているが、いかに書くかはよく分からない。どのような要求仕様書を書けばよいのか模索しているとき、清水吉男さんが提唱しているUSDMに出会い、USDMをベースにガイドラインを作ったということです。 なぜUSDMを採用したのか JUASがUSDMを採用した理由として次のようなものが挙げられています。 １．システム要求を二段階で記述すること。 ２．下位要求の基準があること。 ３．要求の下に仕様を記述することにより、仕
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブルックスの法則
CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」
【就活】「 プログラミングできなくても大丈夫です！」SIerにはコーディングスキルは必要ない？
