【新人SE講座】 第１回『WBSがないのは死亡フラグ』 - Qiita主に新人システムエンジニア向けに、業務で必要になる知識やテクニックを解説していきます。 第１回のテーマはプロジェクト管理の基本である「WBS」です。 （評判がよければ第2回もやります。。。） まとめ
[初心者向け]破滅的なクソコードを書かないために意識したい3つのこと - Qiita
この記事で伝えたいこと ここでは、私が設計を勉強しながらコーディングした経験から、初心者でも簡単に実践できる簡単なルールを3つピックアップしました。 一つのクラスは150行以内に収める 循環参照はしない 継承はしない この3つを守れば、破滅的なクソコードであれば割と簡単に防げるかと思います。 この記事における「破滅的なクソコード」は「一切のリファクタリングの余地も残されていないほどのコード」を意味し、この記事の目的は、「破滅的なクソコード」から、「最低限リファクタリングすればなんとかなるコード」になる程度の手法を紹介することです。 マサカリは大歓迎ですがお手柔らかにお願いします。 読む上で留意して欲しいこと この記事はあくまで 「初心者のための破滅的なクソコードを書かないための簡単な方法論」 であって、「効率的で分かりやすい設計の方法論」ではありません。 この3つは「銀の弾丸」ではないです
![[初心者向け]破滅的なクソコードを書かないために意識したい3つのこと - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/dfc9cb7a7ae60a3ca220948d1de61937409038fa/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU1JTg4JTlEJUU1JUJGJTgzJUU4JTgwJTg1JUU1JTkwJTkxJUUzJTgxJTkxJTVEJUU3JUEwJUI0JUU2JUJCJTg1JUU3JTlBJTg0JUUzJTgxJUFBJUUzJTgyJUFGJUUzJTgyJUJEJUUzJTgyJUIzJUUzJTgzJUJDJUUzJTgzJTg5JUUzJTgyJTkyJUU2JTlCJUI4JUUzJTgxJThCJUUzJTgxJUFBJUUzJTgxJTg0JUUzJTgxJTlGJUUzJTgyJTgxJUUzJTgxJUFCJUU2JTg0JThGJUU4JUFEJTk4JUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJTg0MyVFMyU4MSVBNCVFMyU4MSVBRSVFMyU4MSU5MyVFMyU4MSVBOCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9OGRjNmFiYjBmYzRhNDk5NzU4NmNmNWIwMzY2NDY5OTY%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzYWthc3R1ZGlvXyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MzBjZmYwYjU1YTkwMDc5MDY3MWI4OTA3NjM0OWY3NGI%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D04db432a4edc064f3d26fb16f5b4291f)
SI系企業で社内独自のフレームワークを作りたくなる理由について
tl;dr社内フレームワークは開発生産性を高めるためと言われることが多いが、実際はシステムを守るために産まれる（ことがある）すべては複雑怪奇な業務をシステム化する人が、システムアーキテクチャや非機能面まで全て見れないことに起因する画期的なハックはなく、業務にもシステムにも詳しい人を増やしていきましょうはじめにSI系の大規模な業務システム開発に参加すると、社内独自の重厚なフレームワークに遭遇することがあると思います。ここでいう社内フレームワークとは以下の条件に一致するものを指すことにします。 クローズドソースであるその社内でゼロベースで開発されたり、既存のフレームワークを拡張・ラップしているなど、独自の背景・思想により開発されているそのため、フレームワーク独自のお作法や制約がある開発生産性の向上や、非機能的な要件を満たすことを目的とする社内フレームワークに思いを馳せる自分が経験があるのはJa
例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
シングルトンパターンの誘惑に負けない | プログラマが知るべき97のこと
シングルトンパターンの誘惑に負けない著者: Sam Saariste シングルトン(Singleton)パターンは多くの問題の解決に役立つパターンです。このパターンでは、クラスのインスタンスは必ず1つしか生成されません。そのインスタンスは使用前に必ず初期化されます。そしてシングルトンをグローバルアクセスポイントとすることで、設計をシンプルにできます。こう書いていくと良いことずくめのようですが、この「古典的な」デザインパターンに何か短所はあるのでしょうか 実はたくさんあります。それはよく考えてみるとわかります。確かにシングルトンパターンは魅力的なのですが、私の経験では、このパターンには利点よりも弊害の方が多いと言えます。まずテストの妨げになります。そして保守性の点でも不利です。残念ながらその事実は広く知られているとは言えないため、多くのプログラマを窓きつけているのです。つい使いたい誘惑にから
crontabのガイドライン - Qiita
cron (クーロン) と言えば定期実行してくれるおなじみのシンプルな機能だがそこには奥行きがあり様々なノウハウがある。 そこで設定するときのガイドラインをまとめた。 深くはあまり説明出来ないので気になる用語機能を見つけたら別途検索していただきたい。 cronの場所 /etc/crontab crontabの書式 意識してここに書く必要は現在あまり無い。 RedHat系は非推奨とか言われてるが根拠はよくわからない。 rootで実行される。 #crontabの書式 # （行頭の # マークはコメント行を示す） # +------------ 分 (0 - 59) # | +---------- 時 (0 - 23) # | | +-------- 日 (1 - 31) # | | | +------ 月 (1 - 12) # | | | | +---- 曜日 (0 - 6) (日曜日=0)
知性を感じさせない文章の特徴
サイトリニューアル中につきガチャガチャしてます。ウェブサイトデザイン、記事執筆、添削指導する側に興味ある方はご連絡ください。謝礼をお支払いいたします。 短い時間の間に審査員が見ているのは内容だけではありません。申請書から知性を感じることができなければ、審査員は決して高評価をつけることは無いでしょう。逆に、知性を感じさせる文章を書けたならば、あなたの申請内容についても審査員は高く評価してくれます。 では、どのような申請書であれば知性を感じさせることができるのでしょうか？残念ながら、これには明確な答えはありません。ただし、知性を感じさせない文章については明確な特徴があります（実際に知性があるかどうかは別の問題です）。申請書を書く経験が少ない学生などが持ってくる申請書は以下の特徴のいくつかを兼ね備えているケースがほとんどです。 １．取捨選択なく、そのまま書いている これは話し言葉にも共通します。
クソコードをクソで終わらせないために僕らが出来ること - 何か着ていればいいよ
あけましておめでとうございます。 新年最初のエントリーですが、こんな話題でなんだかな？って感じもしますが気にしない！ 本題 仕事でプログラマーをしていると避けられないのが、既存のくそコードです。 このエントリーではクソコードを プログラマーが読んでいると小声で「クソっ！」とか悪態が自然と出てしまうようなコード などと適当に定義しておきます。 クソコードにやられてばっかりいられない クソコードにまみれて地べたを這いつくばっている我々プログラマーですが、ただやられているのも癪に障りますよね。 そこで、なんとかクソとみそを美味しくいただけるようなアプローチは無いものか？と思案して最近やっていることをクソポエムとして残しておきます。*1 クソな部分を抜き出して一般化アンチパターンとして何か名前をつける なぜクソなのかを把握し、書き残す どのような経緯でクソにまみれてしまったのか？を探ってみる*2
SQLアンチパターン - ジェイウォーク
社内勉強会資料 追記: 2013-10-31 ついったで指摘( https://twitter.com/akuraru/status/395822183777202176 )を受けたので入れ子集合のノード追加の説明の所を修正しました。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
