ダメなコードを改造しなくてはいけなくなったときは、ダメさを片っ端から潰していくしかない
仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか
技術系ブログを書いてくれてる人に申し上げたいこと６つ
はじめにいつもお世話になってます！ 助かってます！ ありがとうございます！ 解説サイトの人は特にありがとうございます！ How to doは多いけど、Why I did in this wayで書かれてる記事が極端に少ないことたぶん備忘録として書いている人が多いと思うんだけど、マニュアルのような書き方が多い気がします。いやまあマニュアルがないよりは遥かに嬉しいことなんですが。重ね重ねいつもありがとうございます。 『AしてBしてCすると、コレができる！ かんたん！』で終わっていることが多いです。多いというか、ほぼこれです。 『ほげほげのためにA、もげもげのためにB、FUBARのためにCすると、コレができる』というように書いてくれると相当嬉しいです！別に『これこれをクリックして…』とか『bashとはうんたらかんたら』とか詳細を書かなくてもいいので、こういう目的のためにやったと書いてくれると嬉し
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
組織も人も最適化の果てにあるのは緩やかな死
なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか？画面にボタンが多いほど、マニュアルが厚いほど初めてのユー
気づいたらプログラマになってた話
@mizchi / Quipper 自己紹介 @mizchi- 竹馬 光太郎 ソフトウェアエンジニア / Quipper まず名古屋方面へ 自分について よく燃えるブログ うるさいTwitter 経歴 2008 大学入学(文系) 2012.3~ Aiming ゲームエンジニア(フルタイム) 2013.9~ Quipper ソフトウェアエンジニアに中途転職 2014.3 学部6年生で大学卒業 来年度から業界3年目の新卒？？？？ それはさておき 大学時代にやってたこと 最低出席日数を確保し、 サークルへも入らず、 バイトもせず、 家にこもってTwitter 家にこもってゲーム 家にこもってプログラミング独学 ↑ これの話する 当時(2008年)のTwitter ほとんどエンジニア みんなリテラシー高い(非エンジニアもすごい) なんか楽しそうだしプログラミングやってみるか 大学以前のプログラミン
サービスを作る気力がなくなりつつある - morishitter blog
Webサービスを作りきる気力がなくなってきてるなーって感じてしまった。 これはヤバいと思って、なんでこうなったのか考えてるといろんなことを思った。 サービスを作るのってすごく気力が必要で、まずどんなサービスを作るのか考えないといけないし、どういう見た目にするのかも考えないといけない。 考えてみると僕は普段から「こんなサービスを作りたい」とか「今どんなサービスが刺さるのか」とか「このサービスはデザインがイケてる」とか考えるタイプではない。 大学で情報系の学科にいて、遊び呆けて3年の頃には全然授業がわからなくなった。 他の大学ではどうなのかわからないが、情報系の学科ではプログラミングができる人はできない人から見ると、回りから頼られるしものすごい人に見える。そして自分もそうなりたいと思ってプログラミングの勉強を始めた。 僕のいる学科ではプログラミングは何かを作るための手段でしかなく、何を作るのか
全てプログラミングで解決しなければならないという思い込みを捨てる - 武蔵野日記
2時間しか眠れなかったが、なんとか起きて出勤。朝はアルゴリズム演習の授業。先日台風で休講になった日の補講なのだが、3限以降は休講にならなかったので、1-2限だけの補講のはずなのに、1限の授業が休講だったので、実質自分の授業のためだけに学校に来ている人がほとんどだったらしい……（出席しなくてよいし、課題を出すだけでもよいと伝えていたところ、1/3の学生が出席。） 今年度の講義はこれで全部終了。来年は今年度やる予定でウォーミングアップに3回かかってしまったためにできなかったデータ構造と、ソートアルゴリズムをカバーしたいところである。 お昼は学内のお仕事に関係する説明会。どういう分担か事前に知らされていなかったのだが、1時間半あった説明のうち、自分に関するところは1分くらいで、残りは全部自分に関係ないところだった。説明会のあと、コース内の先生方に自分がやる予定の仕事がどういうものか教えていただい
プログラムは手段だけど、せっかく作るなら儲かって綺麗にこしたことはない。 - お前の血は何色だ!! 4
コードは綺麗だけど儲からないプロジェクトと、 コードは糞汚いけど儲かるプロジェクトのどっちがいいですか？ もちろん、コードは綺麗で儲かるプロジェクトがいいのは理想ですが、今回は、この2つです。 コードは糞汚いけど儲かるプロジェクトの場合、次期バージョンとかの予算を確保することができます。 そこで、汚い部分を捨てて書きなおすことだって出来ます。 コードは綺麗だけど儲からないプロジェクトは、次のバージョンの改修費用もでずにゴミ箱に送られる運命です。 プロジェクト解散、メンバーは散り散りです。 フリーソフトの場合は、儲かるをユーザに使ってもらえるソフトとか支持されるソフト、 ゲームの場合は、儲かるを面白いゲーム、支持されるゲームとかと適当に読み替えてください。 コードは綺麗に越したことはないです。 だけど、プロジェクトとして成立しないことには意味がありません。 コードは綺麗だけど、誰も遊んでくれ
プログラミングの話 - 鳩舎
この辺見て、いつも思ってること。 プログラミングはアプリを作ることの手段なのか - 銀の人のメモ帳 プログラミングはそれ自体が目的であっていい - mizchi log プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 プログラミングは手段です。僕にとっては。 「動けばいいコード」は糞コードだ でしょうね。としか言い様がないです。 あえて例え話にして、プログラミングを車の運転だとします。プログラマは運転手です。 でまぁ、アプリを作るってのが伊豆の旅館に行くことだとしましょう。この時、僕の運転する目的は伊豆に行くことです。間違っても運転することは目的じゃないです。なので別に運転に特に気を使うことはありません。 そこに突然 F1 ドライバーがやってきて、『お前のカーブの曲がり方は下手くそだ』とか『もっといいルート選択がある』とか『こんな運転の仕方じゃガソリン代がもったいな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goの変数名が短い理由（あるいはGoがほかの言語と違う理由） - Qiita
Martin Fowler氏の語る“犠牲的アーキテクチャ"
作りたいものを作るには結局大量のコードを書かないといけないことについて - Qiita
私が考える安全なプログラムを書くために必要なこと