エンジニアの次のステップへの勉強法 - Qiita
言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的に成り立ってしまっているので、それ以上成長をする必要がないのです。 まあ、そういう生き方もありかな？って思うので、それでいいやって思う人は続きは読まなくてもいいかなって思います。 ここから先はエンジニアとして技術を伸ばすことが楽しい、ものを作ることが楽しい、
"体系的" に開発サイクルを回して "効果的" に学びを得るには - クックパッド開発者ブログ
会員事業部エンジニアの新井( @SpicyCoffee66 )です。 Splatoon2 で各ルール S+1 以上になるため日々奮闘中のところに MHW が発売されました。 加えて最近ぷよぷよを始めたので、どう考えてもいろいろ計算が合わなくなってきました。 本日おこなわれた Cookpad TechConf 2018 では「クックパッドの "体系的" サービス開発」と題し、社内でどのような点に気をつけて開発サイクルが回されているかをお話しさせていただきました。 動画・発表資料は後日アップロードされる予定ですので、よろしければ合わせてご覧ください*1。 今回は、TechConf 2018 での発表内容から、BML ループの運用について、多少の補足や要約を交えながら書きたいと思います。 サービス開発は難しい まず前提として、サービス開発は難しいです。 その難しさの大部分は、以下の２つの要因から
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
