Скачать презентацию
Идет загрузка презентации. Пожалуйста, подождите
Презентация была опубликована 11 лет назад пользователемstratoplan.ru
1 2013 Secret magic of developer productivity
2 Почему я об этом рассказываю Производительность разработчиков может отличаться в раз Часто люди склонны свою сравнительно низкую производительность списывать на обстоятельство необоримой силы (сопроцессор в голове ) Хочется развенчать идею о генетически запрограммированном превосходстве
3 Вопрос слушателям У кого сколько лет опыта разработки ПО?
4 «О любви не говори, о ней все сказано»(с) В какой-то мере эта строчка относится и к производительности труда разработчика Книг на эту тему очень много. Если их все читать, то времени на собственно разработку не останется. К счастью правило 20/80 тут работает, и путем незначительных улучшений можно достичь значительного прогресса
5 Step back: чем же занимаются разработчики? Мне нужна ваша помощь…
6 Жмут на клавиши На самом деле результат нашей работы в сыром виде это код. Да, мы решаем проблемы заказчика, делаем бизнес-анализ, коммуницируем. Но все-таки 95% работы разработчиков, в конечном счете, это код программ (работающих). Чтобы писать код, надо тупо жать на клавиши. Очевидно, что надо жать в правильном порядке на нужные клавиши. История о игре Life на Turbo Pascal
7 Немного математики За день в зависимости от проекта разработчик производит примерно в среднем от 10Кб до 30Кб кода. 30Кб кода с современными IDE (code complete и т.п.) это где-то 6000 раз нажать на клавиши. При довольно невысокой скорости печати в 120 знаков в минуту это получается 50 минут.
8 Ого!!! Получается, что для того чтобы за день добиться более чем впечатляющего результата (для сравнения 30Кб это код класса java.util.HashMap), надо потратить всего 50 минут. Почему-то в реальной жизни так не получается. Мы делаем паузы и жмем на кнопки с перерывами.
9 Что надо чтобы жать на клавиши без остановки?
10 Quick answers 1.Драйв/Мотивация 2.Знания 3.Фокус 4.Правильная организация работы в проекте 5.Умение «ловить поток» и не терять его 6.Научная организация труда aka ясная голова 7.GTD … список можно продолжать, но остановимся на красивой цифре 7
11 Драйв он же правильная мотивация Вам должно нравиться (очень очень нравиться) – Программировать вообще – Программировать на этой платформе – Работать над этим конкретным проектом – Работать с этими людьми – Работать … Без этой «чалмы» магия не работает. Вообще. Крутые профессионалы могут компенсировать отстствие драйва высокой з/п, но не долго и далеко не все. И им нравится быть профессионалами (что тоже драйв).
12 Знания Надо много знать. Чтобы понимать какие кнопки жать. Не знание одного конкретного аспекта это 1% вероятности фэйла и ступора. Количество вещей, которые надо знать для создания среднего проекта – >1000 Часто львиную долю времени работы разработчика отнимает чтение StackOverflow и документации /именно в таком порядке / Учите матчасть (с) анекдот
13 Фокус Четко понимать, что надо делать, как и зачем. Есть очень много путей к цели Исселедуя библиотеки, читая документацию, создавая свою архитектуру, слои бизнес логики и utility классы, можно потерять месяцы времени, не приблизившись к цели ни на шаг
14 Организация работы в проекте Требования План работ Координация, QA, utility tasks (design, веб верстка, нарезка картинок etc.) Кто за что отвечает, где, кого и что искать, кого спрашивать И т.д. В общем-то обычно это забота менеджера, но если человек не знает что ему надо, ему очень тяжело «продать» требования, план работ и т.д.
15 Умение «ловить поток» и не терять его Что такое поток и как его «поймать», я рассказывать не буду. На всякий случай, в двух словах…. В общем-то если бы вы этого не умели, то вы бы меня наверное сейчас не слушали
16 Поток: что тут важно Понимание что нет потока – нет кода. Если решили отвлечься, отвлечься – отвлекайтесь. Решили работать – ловите поток. Будете смешивать – не отдохнете и не поработаете. Умение не сбиваться. Сидеть на горной вершине с ноутбуком и кодить – не получится, и то что к вам приходят коллеги и пытаются вас из состояния потока выбить это нормально. Надо учиться не отвлекаться. По моим наблюдениям наиболее ушлые синьеры из потока не выходят, а интерфейс с внешним миром умело эмулируют, находясь непосредственно в потоке – сбить с мысли их либо очень сложно, либо вообще невозможно. Но у этого состояние есть хорошо известные недостатки.
17 GTD Search wiki: GTD aka «Умение разобраться с делами»
18 Будьте позитивны Есть два очень неприятных стереотипа: – «ААА! Мы занимаемся планированием иттерации, а заказчик спросил у меня чатом какого цвета кнопка на странице sales.php. О ужас! Как так можно работать! Он совершенно не понимает кошерный скрам, нас же нельзя отвлекать. Все плохо-плохо-плохо!!!» – «Ты посмотри, какой нехороший человек! Он написал i=i+1 вместо i++. Убить, расчленить и съесть.» Оба этих варианта не позитивны, не делают Вам чести как профессионалу и совершенно не конструктивны.
19 Интересное наблюдение Если раньше программа = алгоритмы + структура данных Сейчас это структуры данных + архитектура Фактически доля классических ветхозаветных программистов в современном мире
20 Мифы
21 Мифы: серебрянная пуля «Мы перепишем строк с Java на Ruby, т.к. на Ruby разрабочики пишут быстрее.» На самом деле, все современные mainstream платформы в плане производительности труда разработчиков совершенно одинаковы. Разница может быть в пределах 5-10%. Да, исторически переход с Assembler на C/Pascal дал высокий прирост. Появление Delphi дало прирост в разы (особенно для специфичных задач). Появление Java-like плаформ тоже дало прирост, но уже довольно небольшой. Увы, все, что появлялось после, улучшало ситуацию очень не значительно.
22 Почему тогда это работает? Новая платформа == драйв == высокая производительность. В этом нет ничего плохого, и эффект надо использовать – он есть. Просто не надо думать, что прирост производительности происходит от того, что вы используете язык X. Если Вы так считаете, то Вы обманываете сами себя.
23 Мифы: работает – не трожь Один из самых живучих мифов, ибо распространяется джуниорами, а джуниорами в той или иной форме были все. На самом деле «не трожь развалится» – это один их первых симптомов плохого кода Хороший код в правильно сделанном проекте от этого только хорошеет Часто существование в проекте таких «черных ящиков» существенно снижает производительность команды
24 Мифы: отладчик «Я тут весь день код дебажил (я крут, сижу за монитором с непонятными закорюками и вообще все девушки мои). Зачем нужен отладчик (для чего его придумали) – Отладка реально сложных алгоритмов/устройств (кто/когда последний раз програмиировал хоть какой-то алгоритм?) – Работа с библиотеками с плохой документацией (а что у нас в регистре R14 после этого вызова)
25 Зачем на самом деле используют отладчик в 99% случаев? – В коде бардак, и вместо того, чтобы переписать по нормальному, некоторые пытаются реанимировать мертвое тело посредством некромантии с отладчиком – Лень почитать доку, и вместо этого человек пытается угадать, как работает метод пользуясь отладчиком – Тупить, глядя в отладчик, всяко легче, чем решать проблемы и вообще работать, при этом совесть чиста. Я код 8 часов отлаживал, и вообще фиг знает когда баг починится. – Т.е. это прекрасный способ прокрастинации
26 Реальный случай «8 часов борьбы с отладчиком vs 5 минут внятно рассказать голосом в чем проблема» aka метод резинового утенка.
27 Вопросы Skype: denis.tsyplakov
28 Спасибо
Еще похожие презентации в нашем архиве:
© 2024 MyShared Inc.
All rights reserved.