「リファクタリング」を含む日記 RSS

はてなキーワード: リファクタリングとは

2018-06-17

Twitterで見聞きする機械学習界隈人材の残念さ

レベルが低いとか高いとかの話はしたいわけじゃない。レベル相対的ものだし、別にどんなレベルの人が何をしていようがそれ自体別にいい。

実際の能力とあれこれ言ってる内容の乖離が残念すぎる。

俺は何でもできるみたいな主張をしている奴が、実際に会って議論してみると学部生程度の理解しかしてなかったりコード全然書けなかったりする。ビジネス理解?そんなクソみたいな奴に備わってるわけないだろ。偉そうに「自分の主張をしてくことが大事で〜」とか言ってるが、結局自分のことばっかりで周りのステークホルダーを含めてうまく物事を進めていけない局所解にいる奴らだ。所詮機械学習やらせてもヘボい局所しか見つけられない奴らだからお似合いだが。

そしてなぜかキャリア論みたいなのを語りたがる。何なのあれ?自分が時流に乗って比較的高待遇の職に就いただけなんだから語ることなんか無いだろ。世の中にお礼を言って感謝の正拳突きでもしとけや。

Twitter文字数制限が厳しいから賢い人間擬態できるというのが増長を促してるんだよな。中身はなくてもそれっぽい言葉を並べているだけで何か凄そうな感じがしてしまう。「線形代数重要から勉強しといた方がいいです」って、何を指してるんだよその線形代数ってのは。お前の言う線形代数は単なる単語としての線形代数しかなくてその具体的な中身なんて皆無なんだろうな、いつまで経っても中身の話が出てこないから見てれば分かるよ。こういう奴らに限って「◯◯を勉強した」とか「◯◯を理解した」とか言ってるんだよな。でも考えてみたら別に間違ってるわけじゃない、こいつらは中身の話をしてるんじゃなくて単に言葉を知ってるかどうかだけの話をしてるんだから。そういう意味ではGoogle検索を使いこなしているのかもしれない、えらいえらい。

やたらとExcelとか人とのコミュニケーションとかを馬鹿にする層も被ってる気がするんだよな。圧倒的にそういうことをしてる人の方が社会を回してるんだけどな。市井ITリテラシー考慮した代替案を出すわけでもなく、自分たちのやりたいことが通じる井戸の中でゲコゲコ言ってるだけ。無限井戸に落ちてシュレディンガー方程式でも解いとけ。

プログラミングに関してもやれクソコードとかこの言語のここがダメとかそんな話ばかり。所詮与えられたものの中でしか物を考えられず、しかもそれが大して深いわけでもなく、自分薄っぺらさをただただ喧伝していることに気づいているのか?笑えるのがそういう奴らが国の施策とかでイノベーションを起こすみたいな話にダメ出ししてたりする。そんなに自信があるならお前らが行って企画立案実行してこいよ。オリジナリティの欠片もないお前らには税金使ってほしくないけどな。結局お前らは他人様に与えてもらった状況の中でマスタベーション代わりのリファクタリングでもし続けてるのがお似合いだ。

それとkaggleとか競プロが偉いのは分かったから、そこで学んだことが具体的にどうやって活かされてるのかもっと教えてくれよ。傍から見てると会社の金を使ってゲームしてしかもなぜか自信満々で偉そうにしてるようにしか見えないわ。お前らは事業の何に貢献してんの?

学生ヤバい。なぜかは分からないが自信満々に社会会社がどうのこうの言ってる。若さゆえのイキリもあるんだろうが、あまりにも社会がどんな仕組みで出来ているかに考えが及んでない奴らが多すぎる。「みんなたくさんお金もらえた方がいいよね」みたいなただただ自明な話をさも俺いい指摘をしてるぞみたいな感じで書いている。その後にある現実課題とその解決策に関してはまるで空虚学校で何を学んでいるのだろうか?アカウントの中身は中学生運営してるんだなという理解に落ち着いた。

そして自分能力客観的理解できてない点もヤバい社会人が世の中の売り手市場で戦っていくためにする「最近学生は優秀」みたいな根拠ゼロの話とか高待遇オファー出したりするせいで、完全に勘違いしている。お前らにそんな価値はないんだよ、大体教科書とかネット知識を薄く身にまとってるだけなのに物事を深く理解してると勘違いしてる奴らにできることなんてたかが知れてんだよ。バイト待遇を上げろ?社会が態度だけは一丁前で大したことができないバイトの奴らの面倒見るのにどんだけコスト掛けてるか分かってるのか?何もできないから金払って大学に行って学ばせてもらってるんだろうが。

言うに及ばずだがちゃんとした人ももちろんいる。Twitterだと声がデカい奴が目立つのであまり観測されないが。

虚ろで肥大化した自己像を他者認識させるのが戦略的はいいんだししょうがないよな。デカい声でTwitterという肥溜めにクソを撒き散らしていくのがこの界隈での生存戦略なんだ。何で実際の自己との不一致に悩んで精神を病まないのか?感心するくらいだよ全く。

2018-06-14

コメントが欲しい場面

自分コードを書くとき

 

他人コードを読むとき

 

そんなかんじかなー?

コメント不要になっていく理由は、上記の裏返し?

各種ツール支援が充実して、コメント無しでも特に困らないなら、コメント無しでもOKと。

 

anond:20180614075256

2018-05-03

anond:20180503094133

相手のことを賢い人だと思ってるから、その単語を知らないとは思ってない。

最初の「リファクタリング…?」も、言葉を知らないんじゃなくて、数ある選択肢からリファクタリングが最適解なのかな…?と悩んで疑問を浮かべてるのだと受け止めてる。

次の「リファクタリングって何ですか?」も、リファクタリング意味を知らないんじゃなくて、Aさん自身の知ってるリファクタリングと違うBさん流のリファクタリングがあるのだろうか?とリファクタリングの再定義を求める質問と受け止めていて、それに対して「いや何も特殊なことはない、普通リファクタリングだよ。単純なことさ」と返しているのが最後発言

 

もしくは、相手無知なのをわかった上で、あえて無知人間に対して懇切丁寧に説明するような面倒なことをしたくないので、相手レベルにあえて合わせずに突き放す話し方。

こういう会話する奴って何考えてるの?

A「すみません、こういう場合ってどうすればいいんですか?」

B「あー、そういう場合リファクタリングすれば、いいんだよ、リファクタリング

A「リファクタリング……?」 

B「そう、リファクタリングリファクタリングリファクタリングすればいい。」

A「…すみませんリファクタリングってなんですか?」

B「え、リファクタリングリファクタリングでしよ。何がわからないのかわからない。何も難しくない。」

2018-04-19

anond:20180417223141

丸一日の尋問など生ぬるい。我が総統などは完成したプログラムにはテスト用のデータはもちろん不正データをたらふく食わせ、それでも正常に動くとウィルス入りデータなどを食わせて誤作動を起こさぬか確かめておられる。斯くも過酷尋問に耐えたプログラム総統自らの手により比類なきリファクタリングを施され、ひとつの処理が不要かつ不可解なまでに多くのローマ字関数に置き換えられるほか、「漢は不要なことを一切口にせぬどころか必要なことさえ一切言わぬ」という男の美学実践されておられるゆえコメントなどは一切残さぬ。それどころか他人の書いたコメントライセンス表記まで正規表現を駆使して削除される始末。

あと、記憶違いでなければ語り部一人称はワシであるぞ。

2018-04-11

つらい

SIerだけどもうつらい。今月もほとんど終電。入る会社間違えた

営業

  • 全部開発に丸投げ。提案依頼で協力を求めてもガン無視

開発

レベルがとにかく低い。見積して客に詰められたときに、行き着くところが開発のレベルの低さだったりするのでどうしようもない。無能なほうがお金もらえるのおかしいよね

マネジメント

2018-04-08

anond:20180408162722

コードが汚くても人が注目する製品には金が集まる。金が集まれリファクタリングできる優秀な人材を確保できる。

一方でコードが綺麗でつまらない製品はその逆。金が集まらいから注目される製品にまで成長できない。

2018-03-23

リードエンジニアとは

リードエンジニア役割はなんだろうと思っていたが、実際に体験してみてわかってきた。

・全体の設計

コードレビュー

・他のメンバーが開発に集中できるようCIの設定やリファクタリング

メンバー特性に応じてのチケット割り当て

技術観点から必要タスクの洗い出し

ざっくり言うと自分の下に寄せ集めのエンジニアを集めてもちゃんとした品質ソフトウェアを作れるのがリードエンジニアスキルなのかなと思う。

2018-02-28

せんぱいぷろぐらまーのおにいさまへ

おにいさまは言語文法を全部記憶しているの?

おにいさまは知らないことがあったとき英語公式リファレンスを調べているの?

おにいさまは英語論文を読んで情報収集しているの?グーグルスカラーを愛用しているの?

おにいさまは古典や名著といわれる本は読んでいるの?コードコンプリートは何周もしているの?

おにいさまはテスト最初に書いてるの?

おにいさまはコードを読みやすくするためにリファクタリングを完全にしているの?

おにいさまは要件定義も詳細設計も基本設計デザイン実装テスト保守もできるの?深夜も対応しているの?

おにいさまはセキュリティ対策も万全なの?xssもddosもへっちゃらなの?

おにいさまは手取り15万円なの?

おにいさま、すごい!

2018-02-27

anond:20180227150225

クラス設計の仕方とか、メソッドをどれぐらい細かく切り分けたらいいかとか……。

データと処理をひとまとめにしておくと楽そうなものクラスとして設計し、

1関数につき50行以内という目安を立ててメソッド化しとけばだいたいOK。

最初はがむしゃらに大きなプログラムを書いて、あとから少しずつリファクタリングして

良い感じに書き直してゆけばいい。今はそれでいい。

2018-02-18

プログラミング勉強法

  1. 他人コードを読む
  2. 自分コードを書く

以上。

例:

他人アプリ機能拡張

新たな機能を足すには、その構造が大きくかかわる。

機能Aは簡単に加えられたが、機能Bは難しいというようなことが起こる。

よりよい設計を考えられるところまで踏み込めるとよい。

他人コードリファクタリング

読みにくいコードがあった場合、えいやっとリファクタリングしてみる。

よりよいコードの追求

コードを読み解き、なぜ、そのアプローチに至ったのかを解明してみる。

よりよいコード検討し、自分で書き、実際に比較してみる。

その他:

学ぶプログラミング言語機能をすべて調べる

ありとあらゆる機能を調べつくす。分からないことは後回しでもいい。

実験コードを書いて、その機能体験してみる。

実験コードはちゃんと保存しておくこと。

ライブラリ化する習慣を作る

プログラム単位で重複するコードライブラリにする。

誰かが既にライブラリ化していたら、そっちを使う。コード管理他人に任せよう。

コードを書くときプランAとプランBを立てるようにする

時間があれば、その二つのプランコードを書いてみて、長所短所比較してみる。

最終的にはプランA,B,C,Dの四種類程度を立てられるように目指す。

2018-01-15

anond:20180115025904

テスト自体はひとまずとりあえず書けでいいと思うんだよね。過剰気味に。

ただ書き連ねて積み上げたものはどこかで見直して規模をシュリンクできたほうがいいとも思う

テストリファクタリングってのを考えていければいいのかな

2017-12-31

anond:20171231012734

汚いコードで素早く実装し、長期にわたって使われると気付いたらリファクタリングして綺麗にしておく。

そうすることで、更なる改造欲求にも素早くこたえられる。

2017-11-30

リファクタリング、好きだけど十分大きなディスプレイがあれば手数が計算できる作業として心地よいとかそういう意味合いなので、時々創造性を発揮して苦難を乗り越えてリファクタリングかいう話を見ていると、そこまで苦手なら得意な人を雇えばいいのでは、という気持ちになる

2017-10-07

技術負債

今、俺が抱えてる技術負債

前提:

社内システム在庫管理等をWebアプリで開発し運用している。

素のPHP+JavaScriptで、フレームワークは使っていない。

ライブラリはjQuery及びそのプラグインのみ使用

前任者・・・開発経験のない者 自主学習で見よう見まねで作った。

・・・上記システムを引き継ぎ無しで受け取る。開発経験あり。

問題点

(1)バグ、潜在バグが多くある

変数比較において型を含める厳密な比較を行なっておらず、

ユーザー入力した値によっては想定した動作と異なる事がある

MVCモデルオブジェクト指向?なにそれ?

(2)異常系が想定されていない

すべて正常なデータが投入されたという前提で稼働

ファイル削除にしても存在チェックや削除できたかどうかも確認していない

(3)コメントが無い

コメントがほぼ無いので埋め込まれマジックナンバー意味が解らない

迂闊にデータを触れない

(4)すべて絶対パスハードコーディング

ローカルテストする前提でコーディングされておらず

常に本番機で開発している

これらに対し、細かい分野でリファクタリングしている。

リファクタリング対応できないほど大きい問題リメイクするしかない

2017-09-19

今日見た雑誌AIプログラマー仕事を奪うという記事があった。職業プログラマーとしてそれは大いに結構なんだが、多分もしそうなったら思っている使われ方はしないだろうなと。

思っている使い方は要件インプットするとdreamweaver並に汚いソースコードアウトプットするから、それをプログラマリファクタリングして納品。実際の使われ方はデザイナーが汚いソースコードを一切見ずにテストもせずに納品。コピペと変わらない。プログラマでさえ時間が無いとか自分言い訳してリファクタリングせずに納品しそう。

AIが来たら、ただでさえレベルの低い野郎どもが更にレベル低くなるだろうなって

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-08-30

打ち出さないと見えないとか言って、ネ申エクセルを量産するくらいなら、4Kディスプレイ支給して打ち出さなくても確認できるようにしたほうがデータの可用性も確保できるし

エクセルをクソみたいにリファクタリングする必要もなくなるから人件費の削減になる

老害死ね

2017-08-12

近年のアプリケーションファイルサイズ肥大化が嫌いだという話

私は、最近アプリケーション特に、やたら機能を詰め込んで肥大化したアプリケーションが嫌いだ。

とにもかくにも、起動が遅いのだ。

SSD等の高速なメディア使用すれば多少はマシになる」という意見もあると思うが、SSDHDDよりも記憶容量が(現時点では)少ないことが多い。

まりSSD内にインストールできるアプリケーションは限られてくる。

で、これに関して、私が最もストレスを感じるのは、Visual Studio特に2010以降のバージョンである

まず、起動が遅い。加えて、ソリューションファイルの読み込みも遅い。裏でなにかを走らせているのかわからないけど、モタモタする印象が拭えない。

加えて、これはC++プロジェクト等で顕著に現れるが、スタティックビルドした際、生成される実行ファイルサイズバカに大きい。最適化をしても平気で2MBとかになる場合もある(要根拠)。

Visual Studioは、確かに便利にはなっている。リファクタリング可能になったり、予測変換が賢くなったりしている。

ただ、それ以上に、私は前述の欠点が気になってしまう。

そのため、私は未だにVisual Studio 2008から離れられない。前時代思考だとバカにされるかもしれないが、私はこれくらいで満足である。軽快だし、生成される実行ファイルも、2010以降のソレと比べてはるかに小さい。

ハイスペックマシンを常用している人にはあまり関係のない話ではあるかもしれないが、私のようにそうでない人もいるということは、Visual Studio開発者の方々には、頭の隅に入れておいて頂きたいと思う。

補足

SSD導入云々に関しては、職場パソコン場合には導入がそもそも難しいケースも多い。資金面が十分でない企業場合コストから難しい。

ただ、そんな環境であっても、開発ツールは最新のものを使うしかないケースはままある。そんなとき、私はとてつもなくストレスたまる

2017-07-25

Qiitaプログラムを公開してみた

初心者から初心者ですって書いて割と初歩的なプログラムネスト無しif文とforeachとIOだけの60行のコード貼ったら

コメント欄でこうやって書いた方がいいで、ってアドバイスくれたんだけど、めっちゃ嬉しいな

思いついて作ったプログラムを書いて動いたらQiitaに載せてリファクタリングの流れは最高

2017-07-07

IT】開発スピードは全力で落とすべきである

頑張って一度速くやると、アホなマネージャー勘違いする

勘違いしたアホなマネージャーは、次もそのスピードを求めるし、他者にもそれを求める

マネージャーだけではない、別領域のアホなエンジニア勘違いする

「何とか間に合わせてほしい」に応じる必要もない

応じた結果品質が少しでも落ちたらこちらの責任にされる、説明無駄である

 

遅いチームはとても楽しそうである

全力でガバガバスケジュールを引いて、入念にコードをチェックして、楽しそうに議論を交わす

コードが正しいかどうか、高尚かどうかが最も大事ことなのだ

事業の都合とか考えなくていい

どうせ今取り組んでいる作業は売上につながらないのだから

リファクタリング設計は開発スピードを上げるために行うのではない

楽しいから、あるいはそれが絶対的に正しいからやるのだ

正しいかどうかは、チームの一番えらいような気がするエンジニアが決める

 

私のように大量の仕事をしてはいけない

何か問題があればコードを書いたもの自分責任になるのだ

極力既存状態を保持し、影響のないように書くべきである

でないと「元のコードが悪い」なんて言えなくなる

いか責任回避するかがこの仕事本質である

 

大抵の会社普段との差分しか評価をしない

粗暴の悪いヤンキーがたまに良いことをすると評価が上がるのと同じだ

常に頑張ってはいけない、全力でゆっくり仕事しなければ幸福は得られない

 

もし同僚が頑張っていたら可哀想から足を引っ張ってあげよう

簡単だ、ルールをいっぱい作ると良い

業務効率化するためです」と言えば誰も文句は言えないだろう

責任所在曖昧にするという方法もある

少人数だけで決められないほど、物理的に仕事が進まなくなり、ゆっくりはてブを読む時間ができる

 

ツライ

2017-06-26

https://anond.hatelabo.jp/20170626005657

本当の地獄リファクタリングなりモダナイズが終わった後にやってくるよ

何もする事が無い一人の部署

話し相手もいない

相談相手もいない

評価もされない

定時であがるし

給料も貰える

けど何も無い

行き止まり

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん