若手エンジニアを不幸にしないための開発の「べからず」集 - Qiita

若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 単体テストされていないモジュールを受け入れて結合テストをする。 作業の優先順位に対して十分に考えずに結果として間違った指示を出す。 前工程での不具合に対して、「それはソフトで対応してね」を受け入れる。 無理なことを「無理」と言わせない状況をつくる。 問題を必要以上に難しくする項目を受け入れてしまうこと。 複数の厄介さを同時に...

記事へジャンプ

みんなの反応

はてなブックマークでの反応
1int128@hatena 2017/02/03 10:43
なんという既視感
2efcl@hatena 2017/03/20 17:47
アンチパターン的なOpinion集
3hiroomi@hatena 2017/03/20 20:15
“テストの重要性を考えない設計(あるいは要件定義)をする。”テストは一回こっきりじゃないよ。
4yo_waka@hatena 2017/03/20 21:26
“漠然とした「ベスト」は、開発の目指す目標をあいまいにして、開発チームの時間・体力・予算を奪ってしまう危険な言葉” わかりすぎる
5kei_0000@hatena 2017/03/21 00:40
テストの重要性、現状の設定を疑う、データ構造の重要性、既存の技術の見極め、単純化、階層化、コスト、ハードウェア選択、バージョン管理の差分表示、作業の優先順位を十分に考える、その他
6fumikony@hatena 2017/03/21 02:02
ながい
7afternoonteeee@hatena 2017/03/21 02:07
実際に経験した(やってしまった)ことのある事例を、読んでて思い出した。
8yamak@hatena 2017/03/21 06:51
指摘そのものはいいんだけど、やってはいけないことの中に、たまにやってほしいことが書いてあって、文章として非常にわかりにくい。素直に"やってほしいこと"に文体を統一したほうがよいのでは
9itouhiro@hatena 2017/03/21 07:43
「テストを考えた設計しろ。将来の拡張への影響を考えろ(SOLID原則)。標準的データ構造・信頼性高いライブラリを使え。項目追加時に対応しやすい設計。単純化が重要。適切な階層化。直交性よく設計。作業の優先順」
10zhihong@hatena 2017/03/21 07:56
非常に有用
11barm@hatena 2017/03/21 08:43
とりあえず多すぎると思う。
12uturi@hatena 2017/03/21 09:04
納得のいく内容だけど、『べからず』と『してほしい』が混在してるので分かりにくい。各見出し部分は『べからず』にして、内容を『してほしい』に統一すると読みやすいかも?
13tenten0213@hatena 2017/03/21 09:10
伝えたい内容をダラダラと書くべからず。。。
14gusyazero@hatena 2017/03/21 09:15
思ったより長文だけど、知っておきたいので後で読みます
15perl-o-pal@hatena 2017/03/21 09:19
単純否定と二重否定を混在させるべからず。
16kayamak1@hatena 2017/03/21 09:59
“SOLID原則”
17te2u@hatena 2017/03/21 10:01
やってほしいこと、気にしてほしいことをまとめる、ではダメだったのかな。
18koji28@hatena 2017/03/21 10:09
「べき」集にリライトしてほしい(応援ブクマ)
19kenzy_n@hatena 2017/03/21 10:20
心折るべからず
20su_zu_ki_1010@hatena 2017/03/21 10:37
多分いいことも書いてあるんだろうけど、読みづらいので「このような文章を書くべからず」(自省も含めて)
21masatomo-m@hatena 2017/03/21 10:57
これだけの量をまとまりもなくダラダラ書いて伝わると思ってるなら、この人の下に付いた若手は不幸だなあと思った
22cl-gaku@hatena 2017/03/21 11:26
あれ?べからず?となったけどブコメもみんなそうだった
23ksh@hatena 2017/03/21 11:34
内容自体は有用なものを「読みづらい直せ」とか安易にブコメするべからず。また、そんなブコメにスターつけるべからず。
24jhoshina@hatena 2017/03/21 11:45
長ない?
25masayoshinym@hatena 2017/03/21 12:04
長々と書くべからず。
26snowcrush@hatena 2017/03/21 12:14
全項目の文頭にnotつけながら読まないといけないのでパースしんどいです…
27hiro_curry@hatena 2017/03/21 12:24
具体的すぎて共感しにくい感じ?
28delphinus35@hatena 2017/03/21 12:28
途中で読むのを諦めてブコメ見たら自分と似たような感想ばかりだった……
29sai0ias@hatena 2017/03/21 12:36
いいこと書いてある(けどまだ全部読んでない)
30sase@hatena 2017/03/21 12:40
“「それがどれだけ厄介か」を強く(それなりにわかりやすく言ったつもりでも)言っても、(わかろうとすることを拒絶している人からは)ただの頑固な技術者としてしか見なされない”
31north_god@hatena 2017/03/21 12:48
放置するべからず
32hdampty7@hatena 2017/03/21 13:28
なげぇ。やっぱり、よい点を気楽に伸ばした方が楽しそうかな。
33fikah@hatena 2017/03/21 13:43
技術的には優秀なのに、日本語が不自由なエンジニアが多いのはなぜなのか・・
34gonta616@hatena 2017/03/21 14:13
若手じゃ無いけど
35katzchang@hatena 2017/03/21 14:17
たっ、たいへんだー(あんまり読んでない
36cad-san@hatena 2017/03/21 14:58
条件式は、否定形ではなく肯定形で行うこと(リーダブルコード7章より)
37mtane0412@hatena 2017/03/21 15:00
疲れてるのか岩手エンジニアに見えた
38tekimen@hatena 2017/03/21 15:13
「したほうがいい」かつ最低限にしたほうがいいかな。「べからず」は「絶対にしてはならない」「したら法律により罰せられる」くらいにとどめておかないと無限にリストは増えるしたぶん動けない
39kazoo_net14@hatena 2017/03/21 17:56
3回くらい読み直したが、この内容で伝わるのかな。
40Xray@hatena 2017/03/21 19:08
いいと思うけど、肯定形で書いた方が受け入れられやすいというのは覚えておくべきテクニック。
41ka2hik0@hatena 2017/03/21 19:11
バッドノウハウと改善策がまとめてグチャッと書かれてるからちょっと混乱する
42akabekobeko@hatena 2017/03/21 22:39
アンチ パターンと改善方法を書くときは前者を短く具体的、後者は長めに思想を含めながら書くとわかりやすそう。これ系の資料でよいと思ったものは大体そうなってた。例えば「SQLアンチパターン」とか。
43userhiro@hatena 2017/03/21 22:43
全体的に大したこと書いてないけど、頑張ってるからとりあえず全部見て考える
44tooooomin@hatena 2017/03/22 10:22
“バグを憎んで人を憎まず。”
45UDONCHAN@hatena 2017/03/22 17:43
長い
46teppodone@hatena 2017/03/29 11:37
#てぽめも
47koogawa@hatena 2017/08/17 10:37
良い内容なんだけど、「べからず」の中に「〜しないこと」が混ざっていて !isNotNull っぽかった
48twainy@hatena 2017/08/18 16:05
説明するのが苦手なマネージャってつらいよね。。。
49nihonbuson@hatena 2017/08/19 12:36
「テストの重要性を考えない設計(あるいは要件定義)をする。」 を一番最初に書いているのがとても良い。
50Youchan@hatena 2017/08/30 19:16
この人、組織にヘイトが溜っていそうでつらそう
コメント内容の著作権は、投稿者に帰属します。
削除依頼、不適切コメントのご連絡はこちらにお願いいたします。
2017-03-20 16:09:01:1489993741:1527450094
comments powered by Disqus
※メールアドレスは公開されません。
人気の反応