DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
「締め切りは絶対に守るもの」と考えると世界が変わる
2011年にインプレスジャパンから「エンジニアとしての生き方」という本を出版して以来、書籍よりは「メルマガ（週刊 Life is Beautiful）」の執筆を優先して来た私ですが、この度、とある編集者に説得されて「時間術」の本を出版することになりました。 『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』（文響社） 「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術の本です。 「いつも締め切りに追われている」「締め切り間際にならないと本気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたい本です。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「
ほとんどJSが書けなかった新米デザイナーが、ベンチャー入社半年で学んだチーム開発で大切な「7つのおもてなし」 - コネヒト開発者ブログ
こんにちは！デザイナーのきよえし(@kiyoe_furuichi)です。 この度10月でConnehito.incに入社して半年が経ちました！めでたい！ ほとんどJSが書けなかった私も今ではフロントもごにょごにょするデザイナーになりました。 良いタイミングなので今回のエントリーは、半年の間に学んだことの共有として、 デザイナーもできる、チーム開発で大切な「おもてなし」についてご紹介したいと思います。 チーム開発における「７つのおもてなし」 0. どうして「おもてなし？」 入社した当時を振り返った時、自分の開発過程やメンバーとのやりとりを見ていかに早く自分のタスクをこなせるかを優先した"オレオレ"デザイナー だったことに気づかされました。その衝撃をきっかけに、"チームとしてサービスを作り上げる"にはどうすれば良いのかを意識して考えるようになったんです。 それから、チーム開発で大切なことはメン
コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
Your Job Is Not to Write Code
Dear Engineers, Your job is not to write code. I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well. But it’s not your job. Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
グーグル、アイデアからプロトタイプの検証までたった5日で完了する課題解決メソッド「デザインスプリント」を公開 - BRIDGE（ブリッジ）
グーグル、アイデアからプロトタイプの検証までたった5日で完了する課題解決メソッド「デザインスプリント」を公開 Google Venturesが開設したDesign Sprint専用ウェブサイト グーグルのベンチャー投資ファンド部門「Google Ventures（グーグル・ベンチャーズ）」は、2015年1月30日、専用ウェブサイトを開設し、デザインにまつわる独自の課題解決メソッド「デザインスプリント（The Design Sprint）」を公開しました。 デザインスプリントは、ホームオートメーションの開発に取り組むNest Labsやロボット開発企業Savioke、サンフランシスコ発の人気コーヒーショップBlue Bottle Coffeeなど、様々な業種で実践された成果をもとに、スタートアップ企業に向けた“DIYツール”としてまとめられました。 プロトタイプを短期間でつくりあげてユーザー
多くの若きプログラマたちが学ぶべきこと | POSTD
私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
iOSアプリ開発にチームで取組むチャレンジ - ワザノバ | wazanova
http://vimeo.com/109624121 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 Michele Titoloについて取り上げるのは、 「モバイルAPIデザインのまとめ」 「Ruby RoguesメンバとiOSエンジニアのAPI議論」 に続いて三回目ですが、今回はiOSアプリづくりにおけるチーム内の連携がテーマ。 彼女は現在、redditのiOSチームのリーダーをしながら、Objective-Cプロジェクトの依存関係の管理をしてくれるCocoaPodsの開発と、非営利団体 Women Who CodeのCEOを兼務しています。 redditはwebで大量のトラフィックとユーザを抱えてますが、スマホのアプリに注力しはじめ、切り口を変えた複数のreddit閲覧アプリづくりにチームで取組
ソフトウェア開発におけるリスクと居心地の悪さについて - 表道具
アウトライン ソフトウェア開発には，時間の見積も，できるかどうかすらもわからない，リスクのあるタスクがある リスクのあるタスクには，逃げたり既存の工数などに載せないで，特別扱いしてちゃんと負担を減らしながらリラックスして取り組む環境を作るべき はじめに 何で自分がソフトウェア開発という分野に居心地の悪さを感じるのか考えていた．納期の短さが原因だけではないことは明らかである．やればできるし，ただそれだけだからである．それよりも，常につきまとう漠然とした不安が物事を見えにくくしている． 特にインタラクティブ・システムや拡張現実感技術，コンピュータビジョン，機械学習などの分野は，まだ単にライブラリを持ってきただけ機械的にシステムを構成できる分野ではない．そうでなくても，ある程度大規模で複合的なシステムなら，バグ1つの解消にえらく時間がかかったりする． このように，ある機能を実装したり，バグを取っ
不慣れなコードベースで短期間に生産性を高めるための7つの方法 | POSTD
新しい仕事やプロジェクトを始める時に、コードベースを一から作ることはめったにありませんよね。なじみのないコードと格闘するのは骨が折れますし、新たに取り込む情報の多さを考えると、気の遠くなる思いがします。Rubyを使っていた環境からNestoriaに移った私の場合は、新しいコードベースの学習に加えて、Perlまで勉強しなくてはならなかったため、二重の苦しみを味わいました。そんな私が、できるだけ短期間で生産性を上げるために使った7つの方法を紹介します。 謙虚になろう プログラミングと聞いて、真っ先に”謙虚さ”を思い浮かべる人はいないかもしれません。何しろ”傲慢”が プログラマの三大美徳 の1つに数えられているくらいですからね。そうは言っても、なじみのないレガシーコードに出くわしたら、あまりにも分からないことが多すぎて、何度もミスをしてしまう自分にきっと嫌気がさすでしょう。このような場合は、謙虚
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
綺麗なコードと汚いコード。どちらのプログラマと一緒に働きたい？～可読性を意識したプログラム言語はRuby, CoffeeScript, Elixir #Ruby #CoffeeScript #Elixir｜CodeIQ MAGAZINE
綺麗なコードと汚いコード。どちらのプログラマと一緒に働きたい？～可読性を意識したプログラム言語はRuby, CoffeeScript, Elixir #Ruby #CoffeeScript #Elixir 2014.02.04 Category：技術コラム Tag：CoffeeScript ,Elixir ,Ruby CodeIQの出題者である@tbpgrさんからの寄稿記事です！どうして汚いコードができてしまうのか、どうやったら綺麗なコードが書けるのかをわかりやすくポイントで解説しています。 また、綺麗なコードを書くには、言語の特性も関係するということで、可読性を意識したプログラム言語として、Ruby、CoffeeScript、Elixirを挙げています。 これであなたのコードも綺麗になる！？ by CodeIQ運営事務局 プログラムの可読性について CodeIQでRubyやCoffeeS
仕事の進め方とアーキテクチャの相関関係 - ワザノバ | wazanova
http://rubyrogues.com/176-rr-rails-as-an-soa-client-with-pete-hodgson/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 「システムの設計は、その組織のコミュニケーション構造を反映したものになる。」というコンウェイの法則について、ThoughtWorksのPete Hodgsonは、それを逆のかたちで、つまり、採用すべきアーキテクチャの特性を活かすために人と人とのコミュニケーションをどう改善するかということに、かなり時間をとっていると語っています。 コンウェイの法則は、重力のように不可避なもの。うまく活かせるように変わるか、対応できずにダメになるかの二者択一だ。 各サービスの担当チームが細分化されている大企業の顧客において、SOA（
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【前編】エンジニアの会社でデザインがうまくいくワケ〜「エンジニア病」にはダメ出しされよう
大規模 JavaScript その設計と実装と現実
