技術的負債をなくすには - Qiita
技術的負債をなくすには http://apps.wiki.fc2.com/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5%E3%82%92%E3%81%AA%E3%81%8F%E3%81%99%E3%81%AB%E3%81%AF C# Objctive-cだけ使う VisualStudio Xcodeだけ使う VisualStudio Xcodeを機能をフル活用する WindowsServerを使う 一定のシェアを獲得したDBを使う デザパタを覚える コミュニケーションはOffice 365やredMine,イラレGit Svnを使う 社会的に技術的負債をなくすには 動的言語は使わない。 動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい) 動的DBは使わない。リレーションのない動的DBは使わない(mongoDBや
技術的負債 - Qiita
この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。 たとえば、省略可能なプロセスを飛ばす事で開発の高速化を行う事があり、初期開発を高速に行う開発者の中には意識的・無意識的問わずこれを行っている事例が多々存在する。このようにして抱えられた技術的負債は長期的に見た場合に問題を引き起こ
実はテスト駆動開発ってしっくりこないんです - Qiita
内容はあくまで私の主観です。いつも通りコメントは大歓迎ですが、長文であれば別途投稿してもらえたほうが有益だと思います。 自分のスタンス 自動テストは素晴らしい。どんどん利用していくべき。 テスト駆動開発の主張に同意できない。 TDDの何がしっくりこないか TDDの主張がしっくりこない TDDの肝は「テストを先に書くことで思考をクリアにし、実装を早くする」「Red-Green-Refactoringの繰り返し（以下、TDDのサイクル）というガイドを用意することで開発者を安心させる」だと思っている。 まず一つめが納得いかない。世の中のプログラマは本当にテストが無いと行き当たりばったりで全く保守できないような実装をしてしまうのだろうか。少なくとも私はテストの有無に依らずそれなりの設計をする自信がある。 最初にテストがあれば「テストしやすいコードを強制させる」ことができるのはまあ正しいだろう。しか
コードカバレッジですか？もちろん100％ですよ、静的な意味で - Qiita
タイトルに反して、どうやらWikipediaによると型チェックはソフトウェアテストではないらしい。 プログラムを実行し、正しく動作するかどうか確認する作業 （略） 欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。 型チェックは一部ではあるものの、プログラムを実行するまでもなく正しく動くことを確認でき、欠陥が存在しないことの証明ができてしまうからだ。 しかし型チェックはテストコード同様、「プログラムの動作部分ではないが、プログラマのミスを避けるために追加で書かれるコード。本質的には無くてよい」ものであることに違いはない。 型チェックもソフトウェアテストってことにしておこうよ 従来のソフトウェアテストを「帰納的テスト」、型チェックのようなものを「演繹的テスト」と呼びたい。 型チェック自体をテストとすれば多くのソフトウェア開発でTDDを行っていることになる。これは単な
Readme駆動開発を和訳してみた - Qiita
rebuild.fmで話にあがっていた「Readme Driven Development」について、 原文がどんな内容なのか気になったので訳してみました。 英語力が低いのでGoogle翻訳等をフル活用していますので、 間違っているところや日本語的に怪しいところなどありましたら、ご指摘お願いいたします！ 最近TDD（テスト駆動開発）やBDD（ビヘイビア駆動開発）、エクストリームプログラミング、スクラム開発、スタンドアップミーティングなど、より良いソフトウェア開発のための様々な種類の方法論・開発手法の話題をよく耳にする。 だが、開発しているソフトウェアに対して、それらの方法論・開発手法がマッチしていない限り、全く意味は無いものになっているだろう。 別の言い方をすると、粗悪な設計書に基づいた完璧な実装のように価値がないということだ。 同じようなもので、ドキュメントの無いビューティフルな技術を用
The Expression Problem - maoeのブログ
この記事はHaskell Advent Calendar jp 2010 : ATND向けに書いたものです。 最近、ふらふらとネットの波をさまよっていたら、Channel 9でRalf LaemmelさんがHaskellの型クラスを解説する動画を見つけました。これです。 C9 Lectures: Dr. Ralf Lämmel - Advanced Functional Programming - The Expression Problem | Going Deep | Channel 9 C9 Lectures: Dr. Ralf Lämmel - Advanced Functional Programming - Type Classes | Going Deep | Channel 9 The Expression Problemと呼ばれるプログラミングにおける古典的な問題をネタに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
