ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
20140131 万葉帰社日発表 チーム積み重ね 公開版
2014年3月の発表資料 2014年7月の資料 => http://www.slideshare.net/hiroosak/ca-36830962
ドメインモデル貧血症 - Strategic Choice
Anemic Domain Modelどういうこと？マーチン・ファウラーさんの著書「エンタープライズ・アプリケーション・アーキテクチャ・パターン」で紹介されている、「ドメインモデル」パターンを使用した場合の、「アンチ」パターンです。本来のドメインモデルは、「対象となるビジネスエリアをモデル化したオブジェクトのレイヤ全体を挿入する」ということです。モデル化したオブジェクトは、オブジェクト指向設計の基本概念通り、データとプロセスを結合し、対象となるデータと関係しているプロセスを集積します。ドメインモデル貧血症は、一見、本物のドメインモデルに見えます。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。ただし、それらのオブジェクトにはわずかな振る
レイヤー設計とか、オブジェクト指向とか、DDDとか、その辺 - まっつんの日記
自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。 ---------------追記 2020/09/27 この記事は「ユーザーのメンタルモデルを反映させる」というMVCの本来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。 MVCの本来の考えはOOUIの本や、コプリエンのLean Architecture本が良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをや
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
Stack Overflow Developer Survey 2016 Results
Overview Developer Profile I. Geography II. Developer Occupations III. Programmers, Engineers, and Developers IV. Age V. Experience VI. Gender VII. Diversity VIII. Education Technology I. Most Popular Technologies II. Most Loved, Dreaded, and Wanted III. Top Tech on Stack Overflow IV. Trending Tech on Stack Overflow V. Top Paying Tech VI. Correlated Technologies VII. Development Environments VIII.
Atom と PlantUML で快適シーケンス図駆動開発ライフ | DevelopersIO
サーバーサイド開発担当のエンジニアが「設計と実装を進めようとしている」という背景で話を進めます。 PlantUMLは強い 「認識合わせ」という名目でホワイトボードに図を書いて会話することがよくあります。共通言語で会話してあいまいなところを少なくしたら、マネージャーも安心感がありますし、プログラマも自分がやるべきことに集中できますね。 …3日経ちました。あのとき描かれていたホワイトボードの図のとおりに、実装することになりました。認識の齟齬をなくしてくれた貴重な図です。写真に撮りました。どこに保存してたっけ。やっぱり変更したくなったらどうしましょう。またホワイトボードに書き起こす？DRYじゃないですねえ。 そこで、UML図 が登場します。表現したい図を電子データで作成、保存できて、あとで見るときも役に立ちますね。が、しかし、UML図はそれはそれでやや手間がかかるところもあります。作図を助けてく
たった1人から始める社内テストコード文化
# -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
