Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 130
Использую технологию pomodoro, отлично решает данную проблему
< offtop
Тьфу ты, прочитал как poRNodoro и задумался…
</ offtop
Тьфу ты, прочитал как poRNodoro и задумался…
</ offtop
Можно поподробней?
25 минут работаем, 5 отдыхаем. Получается 30 минут — это одна помидора. :) Перед работой составляем план со списком заданий, каждое задание оцениваем в помидорах — сколько помидоров требует это задание. Потом ставим таймер на 25 минут — делаем задание, потом 5 минут отдыхаем, 25 минут работаем, 5 отдыхаем, таким образом выполняя задания, один за одним. В процессе отмечаем сколько нам потребовалось помидор для выполнения задания, и сколько мы планировали.
Это в кратце. Подробнее тут — http://www.pomodorotechnique.com
Это в кратце. Подробнее тут — http://www.pomodorotechnique.com
А, и самое главное — ни на что не отвлекаемся в течение 25 минут. Вообще. Если даже телефон звонит — берем трубку, обещаем перезвонить, ставим напоминание позвонить в течение 5 минут перерыва. Если пришлось вдруг надолго прерваться — этот помидор не учитываем, ставим опять таймер на 25 минут и начинаем сначала.
Очень хорошо эта техника работает во время приближающихся дедлайнов — очень высокая производительность. Но лично для меня так работать все время тяжело.
Очень хорошо эта техника работает во время приближающихся дедлайнов — очень высокая производительность. Но лично для меня так работать все время тяжело.
Потому что это работа на износ. Через полтора часа колбасива нужно делать перерыв на пол часа, а то и час.
берем трубку, обещаем перезвонить
Имхо, после этого помидору уже можно не засчитывать.
> Но лично для меня так работать все время тяжело.
А что тяжелого?
А что тяжелого?
ого, спасибо за ценный совет — хорошая система мерить время в помидорках :)
да, а то минуту это несовременно… не вебдванольно как-то )))) да?
PS а для себя я нашел через хабр прогу EyeRelax (бесплатная и на русском) которая просто делает перерывы, чтобы глаза отдыхали. Там есть много настроек, я для себя выбрал: 1) нужную мне заставку со скриншотом рабочей среды, 2) перерыв нельзя прервать, если не набрать комбинацию (чтобы самому не жульничать и не отменять перерывы) и поставил каждые 15 минут перерыв на минут, каждый час — на 5 минут. В перерывах зарядка для глаз.
Я делаю это чтобы зрение сохранить, но прочитав эту статью — буду пожалуй следовать методике автора. Тем более я к подобному методу сам подошел уже.
PS а для себя я нашел через хабр прогу EyeRelax (бесплатная и на русском) которая просто делает перерывы, чтобы глаза отдыхали. Там есть много настроек, я для себя выбрал: 1) нужную мне заставку со скриншотом рабочей среды, 2) перерыв нельзя прервать, если не набрать комбинацию (чтобы самому не жульничать и не отменять перерывы) и поставил каждые 15 минут перерыв на минут, каждый час — на 5 минут. В перерывах зарядка для глаз.
Я делаю это чтобы зрение сохранить, но прочитав эту статью — буду пожалуй следовать методике автора. Тем более я к подобному методу сам подошел уже.
Забыли сказать, что после каждого 4-ого помидора идет большой перерыв, 15 минут например
Работа не волк — в лес не убежит
Мне кажется очень плохо, если у Вас такой код, отвлекшись от которого очень тяжело «восстановить картину». А если нужно к нему вернуться через месяц?! Как картину восстанавливать? Пишите так, чтобы хотя бы Вам становилось все ясно сразу.
Если код уже написан — это одно. А если вас отвлекают на фазе «вот здесь я напишу вот так, а потом полезу в другой модуль и допишу вот эдак», когда готового кода еще нет?
А если код не ваш, а вы его реверсите и допиливаете? А если это сложная оптимизация, где вопрос красоты кода совершенно не стоит? Или вы экспериментируете с кодом, например в ГА играетесь с фитнесс функцией?
Код написанный месяц назад даже самый изящный потребует пару часов на заполнение оперативной памяти мозга его контекстом.
Спасибо за перевод!
Особенно мне понравилась мысль — не отвлекаться на проблемы, возникающие по ходу, но не относящиеся к текущей задаче. Действительно, иногда ловлю себя на мысли, что продолжаю спускаться по «дереву проблем» всё ниже и ниже, в итоге к концу дня дай бог наполовину вернулся к своей исходной задаче.
Записал — забыл. А потом вернулся, когда будет время и внимание для этого…
Особенно мне понравилась мысль — не отвлекаться на проблемы, возникающие по ходу, но не относящиеся к текущей задаче. Действительно, иногда ловлю себя на мысли, что продолжаю спускаться по «дереву проблем» всё ниже и ниже, в итоге к концу дня дай бог наполовину вернулся к своей исходной задаче.
Записал — забыл. А потом вернулся, когда будет время и внимание для этого…
Где-то наоборот читал, что никаких комментариев, это твой код и ты должен знать его как никто другой.
И помнить каждую написанную строчку через несколько лет, когда в него внезапно придется внести две-три правки?
комментарии не только (и не столько) для себя пишутся, но и для других. Вот пришел я в проект. Хорошо тут есть те, кто писал то, с чем мне предстоит работать. А если бы меня взяли на место единственного уволившегося? Прочитать код без комментариев >100 строк ~ написать его заново. особенно на перле
Единственное, комментарии нужно сразу писать так, как будто их сразу увидят тысячи человек. А то сотни раз уже встречались истории, как кто-то писал какие-то дурацкие комменты типа «не знаю, как оно работает, но не трожь», или «мой босс дурак, заставил меня сделать так» :-)
Хотя, чтобы избежать таких проблем, мы, например, полностью вырезаем все комментарии из production code…
Хотя, чтобы избежать таких проблем, мы, например, полностью вырезаем все комментарии из production code…
Если кто-то не может прочитать ваш код без комментариев, значит вы написали плохой код и его стоит переписать.
вариант того, что он написан на перле или ассемблере (да-да, и то и другое еще используют) вы не рассматриваете?
Вы не умеете читать между строк, и это плохо. Искусство написания кода без комментариев потребует от вас создания ряда техник, которые будут облегчать понимание. Именование переменных, функций, зонирование данных, файловая структура, да много всего, потребует пересмотра. Если вы не будете вообще задумываться над качеством кода, то вам не помогут даже комментарии.
Когда я впервые прочитал приведенное мной предложение, я тоже возмутился, как же так! Но потом сел и задумался, почему люди говорят именно это. И когда я подумал, то понял, что они борятся против бестолковых комментариев и против идиотского отношения к названию переменных. Они борятся против усложнения кода и попытку сотворить пепелац там, где нужен всего лишь самокат. Предсказуемость и легкочитаемость кода не миф, это всего лишь техника, и ее нужно развивать.
я вот согласен с вами.
Когда пишешь комментарии, то надо писать не КАК работает код, а ЧТО он делает. Это написано во многих книгах.
Так вот, обычно приходится просто дублировать названия методов. Если один метод длинной не больше десяти строк, еще и нормально оформлен и с нормальным названием, то нету смысла его комментировать. Вот что тут комментировать?
Когда пишешь комментарии, то надо писать не КАК работает код, а ЧТО он делает. Это написано во многих книгах.
Так вот, обычно приходится просто дублировать названия методов. Если один метод длинной не больше десяти строк, еще и нормально оформлен и с нормальным названием, то нету смысла его комментировать. Вот что тут комментировать?
Вот что тут комментировать?
class Controller_Articles extends Controller_Overall {
public function action_list ($args = array()) {
$form = Arr::extract($_REQUEST, array('title', 'content'));
$errors = isset($form['title']) ? $this->try_add_article($form) : null;
$view = new View('articles_list');
$view->articles = ORM::factory('article')->order_by('id', 'DESC')->find_all();
$view->form = $form;
$view->errors = $errors ? new Helper_View_Notification(__('Adding article failed'), $errors) : '';
$view->user = $this->user;
$this
->set_title(__('Articles list'))
->set_content($view);
}
protected function try_add_article (array $form) {
if ($this->user) {
$article = Model::factory('article')->values($form);
if ($article->check()) {
$article->author = $this->user;
$article->save();
$this->request->redirect('/'); // exit here;
}
return $article->validate()->errors('article');
}
}
public function action_get ($id = null) {
if (!$id) $this->request->redirect('/');
$view = new View('article');
$view->article = ORM::factory('article', (int) $id);
$this
->set_title($view->article->title)
->set_content($view);
}
}
На редкость хороший код. Понял и без комментов.
Можно дать ссылки на литературу, которая была использована для воспитания хорошего стиля кода :)
в комментариях к коду? точно) а еще перед каждой строчкой — цитату из мануала php, а в начале класса — урывок мануала любой команды линукса.
Советую найти и прочитать «Чистый код» Роберта Мартина. Ещё он в блог интересные мысли пишет: thecleancoder.blogspot.com
Приведенный фрагмент кода не содержит никакой сложной логики, поэтому комментировать тут действительно нечего.
лбьой фрагмент кода не должен содержать ничего сложного
это исключение, а мы говорим про программирование впринципе.
Программирование в принципе не всегда сводится к перекладыванию чего-то куда-то. Интеллектоемкие фрагменты кода достаточно часто встречаются, чтобы не быть исключением.
Ну вот, вы смешали борщ с мороженым.
Интеллектоемкие фаргменты и сверхоптимизированные — это вещи совершенно из разной области, а не одно и то же.
Ителлектоемкие фрагменты встречаются очень часто по всему коду. И с оптимизацией они связны в небольшом количестве случаев.
Сверхоптимизированные — крайне редко в узких местах.
Не надо делать подмену понятий.
Интеллектоемкие фаргменты и сверхоптимизированные — это вещи совершенно из разной области, а не одно и то же.
Ителлектоемкие фрагменты встречаются очень часто по всему коду. И с оптимизацией они связны в небольшом количестве случаев.
Сверхоптимизированные — крайне редко в узких местах.
Не надо делать подмену понятий.
А я и не делаю — про сверхоптимизацию говорил вообще другой человек. Просто не любой код тривиален настолько, чтобы любой фрагмент не содержал ничего сложного. Да даже в выборках иногда нужно комментировать отдельные условия, потому что через месяц вернешься к коду и обнаружишь, что понятия не имеешь, что имел в виду!
превратить коммент в название метода и вынести непонятный код. это ведь очевидно.
почитайте Фаулера)
почитайте Фаулера)
Ага, особенно хорошо непонятный код выносится из выборки, сиречь select statement :-)
Знаете, давайте прекращать этот холивар. Я работала с такими «идейными», которые не пишут комментарии, зато на каждый чих плодят новый метод (с достойно и подобающе названными переменными, да-да) — так вот в среднем на 10-15 вложенном методе, делающем все то же непонятно что, читатель кода теряет человеческий облик и с рыком мчится убивать автора кода. Мне — лично мне — такой подход (равно как и его апологеты) не нравится. Dixi.
Знаете, давайте прекращать этот холивар. Я работала с такими «идейными», которые не пишут комментарии, зато на каждый чих плодят новый метод (с достойно и подобающе названными переменными, да-да) — так вот в среднем на 10-15 вложенном методе, делающем все то же непонятно что, читатель кода теряет человеческий облик и с рыком мчится убивать автора кода. Мне — лично мне — такой подход (равно как и его апологеты) не нравится. Dixi.
Пример покажите, ато я не понимаю о чём вы.
Вы сами предложили закончить холивар, а потом его продолжили. Как по-женски.
Я не виноват, что у вас были неопытные сотрудники, которые неправильно поняли философию выноса кода в методы.
В большинстве случаев, что я видел комменты только усложняют чтение кода.
Вы сами предложили закончить холивар, а потом его продолжили. Как по-женски.
Я не виноват, что у вас были неопытные сотрудники, которые неправильно поняли философию выноса кода в методы.
В большинстве случаев, что я видел комменты только усложняют чтение кода.
видимо, тут уже личное у каждого.
я вот терпеть не могу комменты в чужом коде. когда я его читаю — я мыслю не на русском или английском языке, а на PHP, Javascript или чем-то другом и комменты воспринимаются просто как шум.
я вот терпеть не могу комменты в чужом коде. когда я его читаю — я мыслю не на русском или английском языке, а на PHP, Javascript или чем-то другом и комменты воспринимаются просто как шум.
еще часто комменты не только очевидные, но не в тему (автор будто на своей волне) и ложные (код исправили, коммент забыли). Плюс — занимают место. Так я могу взглядом окинуть два-три метода на экране, а с комментами — иногда и один не влазит. И еще — когда пролистываешь класс, приходится скроллить намного больше, чем без комментов.
Вы читали ветку комментариев с kit? Интересно просто.
Комменты должны быть крайне редко. И если комменты объясняют код — с кодом чего-то не так. Всякие TODO и тому подобное — бывает.
Когда же я вижу прокомметированы в коде каждые две строчки… Большинство комментов, что я видел выглядят так, словно автор не хотел комментировать, но комментировал, словно нужно. Проблема не в том, что это плохой прогер, а в том, что на него давит общество под предлогом: «Комментарии. Обязательно нуужно комментировать». И многие хорошие прогеры страдают от этого стереотипа, придумывая комментарии.
Вот, посмотрите, серьезный проект. Вот нахрен тут комментарии впринципе? Я читаю и, как человек, который работал с Коханой понимаю все и почему.
github.com/bluehawk/kohanut-core/blob/master/classes/kohanut/core.php
Именно такие комментарии встречаются чаще всего. Если автор — опытный, то ему практически не нужно комментировать свой код. Если автор — неопытный, то его комментарии будут еще хуже, чем код. Так зачем эти стереотипы, чтобы люди с хорошим кодом стеснялись из-за того, что не прокомментировали его?
Комменты должны быть крайне редко. И если комменты объясняют код — с кодом чего-то не так. Всякие TODO и тому подобное — бывает.
Когда же я вижу прокомметированы в коде каждые две строчки… Большинство комментов, что я видел выглядят так, словно автор не хотел комментировать, но комментировал, словно нужно. Проблема не в том, что это плохой прогер, а в том, что на него давит общество под предлогом: «Комментарии. Обязательно нуужно комментировать». И многие хорошие прогеры страдают от этого стереотипа, придумывая комментарии.
Вот, посмотрите, серьезный проект. Вот нахрен тут комментарии впринципе? Я читаю и, как человек, который работал с Коханой понимаю все и почему.
github.com/bluehawk/kohanut-core/blob/master/classes/kohanut/core.php
if (Kohana::$profiling === TRUE)
{
// Start a new benchmark
$benchmark = Profiler::start('Kohanut', __FUNCTION__);
}
// Make sure $page is set and loaded
if (!is_object(self::$page) || !self::$page->loaded())
{
return "Kohanut::main_nav failed because page is not loaded";
}
Именно такие комментарии встречаются чаще всего. Если автор — опытный, то ему практически не нужно комментировать свой код. Если автор — неопытный, то его комментарии будут еще хуже, чем код. Так зачем эти стереотипы, чтобы люди с хорошим кодом стеснялись из-за того, что не прокомментировали его?
Ну, например, мне лично непонятно:
— почему редирект на главную, а не на страницу ошибки, например;
— почему вызывается check(), а не validate() (и зачем это разные функции);
— почему вообще проверка $article->check() может не сработать;
— почему в action_get() есть проверка на пустой id, но нет на несуществующий id.
Т.е. комментарии не помешали бы.
— почему редирект на главную, а не на страницу ошибки, например;
— почему вызывается check(), а не validate() (и зачем это разные функции);
— почему вообще проверка $article->check() может не сработать;
— почему в action_get() есть проверка на пустой id, но нет на несуществующий id.
Т.е. комментарии не помешали бы.
2.3. — это Кохана, у неё такой Апи.
4. Согласен, но это недоработка
1. Не согласен, что значит «почему»? какой коммент там можно написать? «Редиректим на главную, если адрес url/article/»? Это очевидно из кода.
Вы ищите, к чему придратся. В таком коде комменты только мешают.
4. Согласен, но это недоработка
1. Не согласен, что значит «почему»? какой коммент там можно написать? «Редиректим на главную, если адрес url/article/»? Это очевидно из кода.
Вы ищите, к чему придратся. В таком коде комменты только мешают.
Ну про 3 написать, например, «может не пройти, если маты в тексте».
Про 1: коммент, например, такой: «TODO: возвращать корректный HTTP код ошибки» ;-)
Вообще да, ищу :-D
Там еще можно много к чему придраться, есть задаться целью.
Но насчет «В таком коде комменты только мешают» не согласен — пара неочевидных моментов есть, плюс те же TODO. Толку от комментариев в таком коде немного, но явно не только мешают (если без фанатизма, естественно).
Про 1: коммент, например, такой: «TODO: возвращать корректный HTTP код ошибки» ;-)
Вообще да, ищу :-D
Там еще можно много к чему придраться, есть задаться целью.
Но насчет «В таком коде комменты только мешают» не согласен — пара неочевидных моментов есть, плюс те же TODO. Толку от комментариев в таком коде немного, но явно не только мешают (если без фанатизма, естественно).
Условия метода check описаны в модели. и сейчас там может обломится из-за цензуры, а через полгода заказчики разочаруются в цензуре и скажут, чтобы я проверял, не написано ли капсом. так и будет — в модели проверка на то, не написано ли капсом, а в комменте на то — прошло ли цензуру. В том числе потому я не люблю комменты.
более того, в данном случае вы предлагаете мне описать метод check. вас бы сконфузило от предложения прокомментировать строку «ORM::factory('article', (int) $id)» так: «При помощи базы данных MySQL осуществится поиск в таблице prefix_articles»?
Имеем ту же самую ситуацию — нам сообщают детали реализации метода, которые нам совершенно не нужны здесь и, при этом, еще и могут стать ложными в случае смены движка бд на другой.
Не удивительно, понятно, кто вас попросил о помощи:
Зачем? У меня есть сайт example.com/, список статтей в нем на главной, а каждая отдельная статья на example.com/article/ и я хочу, чтобы, если человек удалил — его редиректнуло на главную, в списоку статтей. ситуация редкая, но пользователь получит то что хотел — список статтей, а не 404 ошибку. что делает этот код — это очевидно. и если не придираться ради подружки, то все легко понять, как людям выше.
с TODO — согласен. как на меня — один из немногих случаев, когда комменты оправданы.
более того, в данном случае вы предлагаете мне описать метод check. вас бы сконфузило от предложения прокомментировать строку «ORM::factory('article', (int) $id)» так: «При помощи базы данных MySQL осуществится поиск в таблице prefix_articles»?
Имеем ту же самую ситуацию — нам сообщают детали реализации метода, которые нам совершенно не нужны здесь и, при этом, еще и могут стать ложными в случае смены движка бд на другой.
Вообще да, ищу :-D
Не удивительно, понятно, кто вас попросил о помощи:
Друзья: Nicolette
Про 1: коммент, например, такой: «TODO: возвращать корректный HTTP код ошибки»
Зачем? У меня есть сайт example.com/, список статтей в нем на главной, а каждая отдельная статья на example.com/article/ и я хочу, чтобы, если человек удалил — его редиректнуло на главную, в списоку статтей. ситуация редкая, но пользователь получит то что хотел — список статтей, а не 404 ошибку. что делает этот код — это очевидно. и если не придираться ради подружки, то все легко понять, как людям выше.
с TODO — согласен. как на меня — один из немногих случаев, когда комменты оправданы.
Придираться к коду меня никто не просил, честно.
Это у меня такая форма прокрастинации :-D
Про 404 ошибку — на главную будет ведь редиректить не только с удаленных URL, а и с никогда не существовавших. Каким-нибудь поисковикам это может не понравиться, например. А по вашей логике вообще 404 страниц на сайтах быть не должно, получается — все редиректим на главную. Это неправильно.
Вообще, я начал к тому, что не такой уж и простой код вы привели (особенно для другого человека). И, вероятно, простор для полезных комментариев там есть.
Это у меня такая форма прокрастинации :-D
Про 404 ошибку — на главную будет ведь редиректить не только с удаленных URL, а и с никогда не существовавших. Каким-нибудь поисковикам это может не понравиться, например. А по вашей логике вообще 404 страниц на сайтах быть не должно, получается — все редиректим на главную. Это неправильно.
Вообще, я начал к тому, что не такой уж и простой код вы привели (особенно для другого человека). И, вероятно, простор для полезных комментариев там есть.
не. я не говорю, что 404 ошибки быть не должно.
когда человек вводит адрес example.com/articles/ — он ожидает увидеть список статтей, который у нас на главной. потому его и редиректим на главную. и хотя эту фразу можно было бы добавить комментарием в код, но плюсов по моему мнению намного меньше, чем минусов
когда человек вводит адрес example.com/articles/ — он ожидает увидеть список статтей, который у нас на главной. потому его и редиректим на главную. и хотя эту фразу можно было бы добавить комментарием в код, но плюсов по моему мнению намного меньше, чем минусов
Это да, верно.
А при ошибке в добавлении статьи у вас ведь тоже так.
И example.com/articles/0/ тоже (ну или как там параметры передаются в URL).
А при ошибке в добавлении статьи у вас ведь тоже так.
И example.com/articles/0/ тоже (ну или как там параметры передаются в URL).
А при ошибке в добавлении статьи у вас ведь тоже так.
Вы специально делаете вид, что не поняли или просто код не читали?)
if ($article->check()) {
$article->save();
$this->request->redirect('/'); // exit here;
}
return $article->validate()->errors('article');
Если прошло проверку — сохранить и выйти, иначе — вернуть список ошибок.
Написано в книжках по XP. (не операционка от МС, а экстремальное программирование)
Но там не по этой причине. Ты должен написать такой код, который при прочтении тобой же через три месяца или другим человеком, не вызывал бурю негативных эмоций. И я скажу, что это реально работает. Я могу спокойно читать свой код, который был написан 3 года назад без особых проблем. И я мальчик с феноменальной памятью
Но там не по этой причине. Ты должен написать такой код, который при прочтении тобой же через три месяца или другим человеком, не вызывал бурю негативных эмоций. И я скажу, что это реально работает. Я могу спокойно читать свой код, который был написан 3 года назад без особых проблем. И я мальчик с феноменальной памятью
сразу видно что новичОк
Хотелось бы подробнее о сохранении контекста во внешней памяти, не могу придумать эффективный способ не отбирающий большого количества времени. Желательно с примерами.
Из жизни патчера — ведете заметки что куда откуда переходит и как ветвится
Из жизни кодера — делаете комментарии для себя, хорошо называете фенкции и классы и прочее
Прицип простой — чем меньше держится в памяти тем легче поднять контекст.
Из жизни кодера — делаете комментарии для себя, хорошо называете фенкции и классы и прочее
Прицип простой — чем меньше держится в памяти тем легче поднять контекст.
Я просто использую мелкие квадратные бумажки, которые продаются пачками по нескольку десятков штук.
На бумажку записывается набор целей, которые надо сделать, плюс краткие комментарии по реализации. Так как пишу только для себя, то можно использовать любые аббревиатуры, добавлять какие-то рисунки… Стараюсь обходиться не более, чем десятком слов на всю бумажку.
В итоге получается своеобразный якорь для контекста. Он кладётся на видное место, и в любой момент можно восстановить контекст. Сделанные цели зачёркиваются. Если вся бумажка зачёркнута, её можно отправить в ведро. И завести новую.
На бумажку записывается набор целей, которые надо сделать, плюс краткие комментарии по реализации. Так как пишу только для себя, то можно использовать любые аббревиатуры, добавлять какие-то рисунки… Стараюсь обходиться не более, чем десятком слов на всю бумажку.
В итоге получается своеобразный якорь для контекста. Он кладётся на видное место, и в любой момент можно восстановить контекст. Сделанные цели зачёркиваются. Если вся бумажка зачёркнута, её можно отправить в ведро. И завести новую.
Курящие программисты, уверен, уже давно в совершенстве освоили технику под номером 1. :)
Освоили и применяют.
Кстати, перекуры (или просто перерывы для тех, кто не курит), действительно благотворно влияют на трудоспособность.
Замечено по себе и по коллегам.
С другой стороны — многое зависит от человека. Если он по природе несколько рассеянный и возвращение в «поток» ему даётся тяжело, то частые перерывы (раз в один-два часа) ему скорее навредят, чем помогут.
Кстати, перекуры (или просто перерывы для тех, кто не курит), действительно благотворно влияют на трудоспособность.
Замечено по себе и по коллегам.
С другой стороны — многое зависит от человека. Если он по природе несколько рассеянный и возвращение в «поток» ему даётся тяжело, то частые перерывы (раз в один-два часа) ему скорее навредят, чем помогут.
У меня как у программиста вызывает большое сомнение один нюанс: внешняя память имеет большую латентность, и хранить там оперативную информацию означает огромные накладные расходы на обращения к ней.
Ни я, ни автор статьи тоже вроде не комбайнеры… :-)
В данном случае накладные расходы на восстановление этой информации с нуля выше, чем на ее запись и последующее чтение. Вы никогда не записывали в файл/в таблицу/с-чем-там-вы-работаете какую-нибудь информацию, которую можно было бы вычислять заново при каждом обращении, но перечитывать оттуда получается дешевле?
В данном случае накладные расходы на восстановление этой информации с нуля выше, чем на ее запись и последующее чтение. Вы никогда не записывали в файл/в таблицу/с-чем-там-вы-работаете какую-нибудь информацию, которую можно было бы вычислять заново при каждом обращении, но перечитывать оттуда получается дешевле?
Ничерта не понял второй пункт. Что значит выносить наружу как можно большее число деталей, на как можно большее число уровней? Использовать многослойную архитектуру что ли?
да, частенько ловлю себя на мысле что вместо того чтобы что то полезное сделать (не только кодирование, любая работа) я лазию в интернете по впринципе в данный момент не срочным ресурсам. Вообще считаю если надо что то сделать, надо отключаться от интернета в первую очередь. Кпримеру как назло когда надо что нибудь сделать начинает весь контакт лист в асе писать :)
Хорошо написано, верится, что это будет работать.
С багтрекером (у нас багзилла) меня долго смущало, что создание бага занимает существенное время: нужно тыкать мышкой, выбирая разные категории и заполняя несколько полей в соответствии с формальными требованиями. Поэтому для «быстрых заметок» использую текстовый файлик, который у меня всегда открыт в одном из Far'ов. Одна строчка = один баг/фичареквест в формате:
Компонент берётся из ранее использованных или придумывается новый на ходу; по сути минимальная каталогизация. С таким подходом замеченный между делом баг обычно отнимает 5-10 секунд на фиксацию. Если есть проблемы с воспроизводимостью, то больше, но всё равно всегда можно дописать типа «возникает иногда». После завершения текущей задачи свежие записи из этого списка можно неспеша закинуть в багтрекер, оформив как полагается, или быстро пофиксать, если проблемы небольшие. Здесь же спокойно разобраться с «возникает иногда» и понять, когда именно.
Иногда возникает некоторое чувство отчаяния, когда, отлаживая код, над которым работаешь непосредственно, напарываешься подряд на несколько других ранее неизвестных багов. Возникают депрессивные мысли типа «всё сломалось, мы все умрём». Подобная система «заметил-записал-забыл» эффективно помогает не допускать такого отчаяния.
С багтрекером (у нас багзилла) меня долго смущало, что создание бага занимает существенное время: нужно тыкать мышкой, выбирая разные категории и заполняя несколько полей в соответствии с формальными требованиями. Поэтому для «быстрых заметок» использую текстовый файлик, который у меня всегда открыт в одном из Far'ов. Одна строчка = один баг/фичареквест в формате:
<компонент> <табуляция> <описание проблемы в произвольном стиле в объёме достаточном для того, чтобы я сам вспомнил, прочитав это позднее>Компонент берётся из ранее использованных или придумывается новый на ходу; по сути минимальная каталогизация. С таким подходом замеченный между делом баг обычно отнимает 5-10 секунд на фиксацию. Если есть проблемы с воспроизводимостью, то больше, но всё равно всегда можно дописать типа «возникает иногда». После завершения текущей задачи свежие записи из этого списка можно неспеша закинуть в багтрекер, оформив как полагается, или быстро пофиксать, если проблемы небольшие. Здесь же спокойно разобраться с «возникает иногда» и понять, когда именно.
Иногда возникает некоторое чувство отчаяния, когда, отлаживая код, над которым работаешь непосредственно, напарываешься подряд на несколько других ранее неизвестных багов. Возникают депрессивные мысли типа «всё сломалось, мы все умрём». Подобная система «заметил-записал-забыл» эффективно помогает не допускать такого отчаяния.
stevelosh.com/projects/t/ — классная утилитка командной строки для похожего. тоже простая до одури (:
Баги по тексту пишу коментами типа fixme и todo, а уж потом завожу, если надо в трекере
Еще в браузере есть task-и из google. F4 — вписал/поправил, закрыл
Еще в браузере есть task-и из google. F4 — вписал/поправил, закрыл
> где-нибудь в душе или в дороге
Как-то не по-русски звучит. Может стоит переправить? :)
Как-то не по-русски звучит. Может стоит переправить? :)
Давно уже использую технику сохранения контекста в конце рабочего дня, если не успел решить задачу. Еще действительно полезно сосредотачиваться на одном текущем деле, а на остальные не обращать внимания. Та же мысль была недавно в топике про тестирование, в примере с директором какой-то промышленной фабрики.
Последний абзац давно осознал, поэтому как только вечером затыкаюсь на решении задачи более, чем на пол-часа, и при этом понимаю, что смотрю совсем не в том направлении (а в каком надо — не знаю) — иду спать :)
Даешь статью: тестировщик, который отвлекается!
Самый лучший кеш для контекста — тетрадка. Записывайте все мелкие задачи, на которые нужно разбить крупную. Если возникает ситуация, когда нужно отвлечься на проверку какой-то теории, или поправить код в другом месте, делайте это сразу, а не потом, и, естественно, запишите это в тетрадку.
Если не нравится тетрадка — используйте программы для создания заметок. Быстро, эффективно. В win7, ubuntu такие программы есть сразу по умолчанию. Мой десктоп «обклеен» заметками. Очень удобно.
Отвлекаться надо раз в 20-30 минут. Например, можно почитать новости, или походить по офису. Некоторые решения должны созреть как личинка, и мозг может выдать лучший вариант, чем вы уже придумали.
Если не нравится тетрадка — используйте программы для создания заметок. Быстро, эффективно. В win7, ubuntu такие программы есть сразу по умолчанию. Мой десктоп «обклеен» заметками. Очень удобно.
Отвлекаться надо раз в 20-30 минут. Например, можно почитать новости, или походить по офису. Некоторые решения должны созреть как личинка, и мозг может выдать лучший вариант, чем вы уже придумали.
Спасибо за перевод!
Действительно, подобный подход может работать и работает. Причем, совершенно не обязательно бросаться из одной крайности в другую — оба варианта можно совмещать «в одном флаконе».
Исходя из собственного опыта, могу отметить следующее:
• Если поток пойман, то действительно, имеет смысл использовать его по максимуму. В этом состоянии лучше всего решаются рутиные задачи, требующие среднего уровня концентрации. Там где надо много думать — поток словить сложно. Опять же, там где нет быстрой возможности применять творческие порывы тоже.
Однако, если поток не приходит, не стоит всеми силами стараться его поймать (это все равно что заставлять себя заснуть). Когда состояние подходящее, он возникнет сам.
• После перерыва на выходные бывает сложно загрузить контекст. Лучшее средство, которое безотказно работает для меня — это комментирование кода. В идеале, не комментированного кода лучше не оставлять, но часто бывает, что второстепенные функции оказываются написанными как раз в потоке, когда «мысль прет» и вдумчивое/размеренное комментирование может ее сбить.
Как правило, каждый понедельник у меня начинается с ревью кода, написанного за предыдущую неделю. Я просто начинаю листать код и комментировать участки кода, не получившие должного внимания в прошлый раз. Это помогает гораздо быстрее вспомнить контекст, нежели пустое «втыкание» в код. Одновременно, на этом этапе ловятся многие баги, связанные с замыливанием внимания в потоке, либо обнаруживается другой, более элегантный способ решения проблемы. В-третьих, перерыв на выходные позволяет избавиться от комплекса «мой код — моя прелесть». В смысле, что бывает психологически сложно затереть сотню-другую строк которые только-что написал. А после перерыва это сделать легче :)
Однако я отвлекся :)
• При необходимости сделать перерыв (на чай или обед) — следует в уме отметить пару-тройку пунктов текущей работы и текущего контекста. А после перерыва первым делом вспомнить их.
Однако, гораздо лучше для этих целей использовать бумажку и карандаш. Очень многие программисты недооценивают мощь этого инструмента :) Одни считают что неумение думать без бумажки — это недостаток. Другие стараются делать все по фен шую, но в электронном виде.
У меня бумага выполняет роль эдакого своп файла для мыслей. Любая мимолетная мысль может быть сброшена в своп и непременно попадется на глаза позже. Причем, сам своп файл (подобно настоящему свопу) выглядит как нагромождение raw данных. Кружочки, картинки, отрывки текста. Я очень часто рисую всякую абстрактную хрень на этом же листке. Причем абстракция эта оказывается промодулированной текущими мыслями. Это чем-то похоже на mind map-ы, но осуществляется практически бессознательно.
К концу недели, лист А4 оказывается полностью изрисованным. Эдакое произведение абстрактного искусства :) И тем не менее, изучая его впоследствии, можно легко восстановить ход мыслей и те самые идеи. Бывает очень интересно рассматривать картинки, потому что рисовались они сами собой :)
В общем как-то так. Надеюсь, что эта информация может быть полезна.
Действительно, подобный подход может работать и работает. Причем, совершенно не обязательно бросаться из одной крайности в другую — оба варианта можно совмещать «в одном флаконе».
Исходя из собственного опыта, могу отметить следующее:
• Если поток пойман, то действительно, имеет смысл использовать его по максимуму. В этом состоянии лучше всего решаются рутиные задачи, требующие среднего уровня концентрации. Там где надо много думать — поток словить сложно. Опять же, там где нет быстрой возможности применять творческие порывы тоже.
Однако, если поток не приходит, не стоит всеми силами стараться его поймать (это все равно что заставлять себя заснуть). Когда состояние подходящее, он возникнет сам.
• После перерыва на выходные бывает сложно загрузить контекст. Лучшее средство, которое безотказно работает для меня — это комментирование кода. В идеале, не комментированного кода лучше не оставлять, но часто бывает, что второстепенные функции оказываются написанными как раз в потоке, когда «мысль прет» и вдумчивое/размеренное комментирование может ее сбить.
Как правило, каждый понедельник у меня начинается с ревью кода, написанного за предыдущую неделю. Я просто начинаю листать код и комментировать участки кода, не получившие должного внимания в прошлый раз. Это помогает гораздо быстрее вспомнить контекст, нежели пустое «втыкание» в код. Одновременно, на этом этапе ловятся многие баги, связанные с замыливанием внимания в потоке, либо обнаруживается другой, более элегантный способ решения проблемы. В-третьих, перерыв на выходные позволяет избавиться от комплекса «мой код — моя прелесть». В смысле, что бывает психологически сложно затереть сотню-другую строк которые только-что написал. А после перерыва это сделать легче :)
Однако я отвлекся :)
• При необходимости сделать перерыв (на чай или обед) — следует в уме отметить пару-тройку пунктов текущей работы и текущего контекста. А после перерыва первым делом вспомнить их.
Однако, гораздо лучше для этих целей использовать бумажку и карандаш. Очень многие программисты недооценивают мощь этого инструмента :) Одни считают что неумение думать без бумажки — это недостаток. Другие стараются делать все по фен шую, но в электронном виде.
У меня бумага выполняет роль эдакого своп файла для мыслей. Любая мимолетная мысль может быть сброшена в своп и непременно попадется на глаза позже. Причем, сам своп файл (подобно настоящему свопу) выглядит как нагромождение raw данных. Кружочки, картинки, отрывки текста. Я очень часто рисую всякую абстрактную хрень на этом же листке. Причем абстракция эта оказывается промодулированной текущими мыслями. Это чем-то похоже на mind map-ы, но осуществляется практически бессознательно.
К концу недели, лист А4 оказывается полностью изрисованным. Эдакое произведение абстрактного искусства :) И тем не менее, изучая его впоследствии, можно легко восстановить ход мыслей и те самые идеи. Бывает очень интересно рассматривать картинки, потому что рисовались они сами собой :)
В общем как-то так. Надеюсь, что эта информация может быть полезна.
Интересные методики. Я привык уже делать полный review своего кода перед коммитом и просматривать код коллег после апдейта, но недельный review — это новая идея. Обязательно попробую в следующий понедельник!
Попробуйте и отпишитесь о результатах :) Еще могу сказать, что у меня получается своеобразная мини итерация на неделю. Сам коллектив работает по Scrum-у с итерацией в три неделеи. Но у меня так получается, что единичный кусок работы укладывается в неделю. Примерный сценарий работы такой:
• Понедельник: ревью кода, комментирование, вспоминание предыдущих идей, их реализаций; причесывание кода, рефакторинг. В общем, в основном созерцательная деятельность. Заодно — втягивание в работу, разгон и настрой. Так что никакого «понедельник — день тяжелый».
• Вторник: планирование работы на неделю, оценка трудоемкости и необходимой «средней скорости выполнения». Начальные наброски в коде. Начинает что-то появляться на бумажке :)
• Среда: первые ощутимые изменения в коде. Вхождение в проблему, реализация основы, кодинг кодинг…
• Четверг: обычно менее «скоростной» чем среда, но более мозголомный. Основной мотив «я на верном пути? надо ли все это?». Если таких вопросов не возникает и код «льется рекой», то бывает, что четверг проходит так же как и среда.
• Пятница: часто такой же производительный день, как и среда. Обычно наибольший объем коммита. Стараюсь сделать так, чтобы можно было уже подвести итоги работы за неделю. В идеале — уже имеющиеся результаты работы, с которыми можно поиграться. Если работа выполнена заранее — опять же комментирование сложных или нетривиальных алгоритмов, общей идеи и т. д. Рефакторинг в пятницу нежелателен, лучше оставить до понедельника.
• Суббота Отдых :)
P.S.: Разумеется, это все усреднено и сглажено. Когда-то лучше, когда-то хуже. Но одно могу сказать точно — уже заранее можно представить, чем ты будешь заниматься в каждый из дней. И это помогает не гнаться сломя голову, ну и в то же время не зевать. Как раз против зевания организован такой подход.
P.P.S: Я не живу по графику и терпеть не могу жестких правил, расписаний и прочего. Эта методика — сугубо для задач самомотивации.
• Понедельник: ревью кода, комментирование, вспоминание предыдущих идей, их реализаций; причесывание кода, рефакторинг. В общем, в основном созерцательная деятельность. Заодно — втягивание в работу, разгон и настрой. Так что никакого «понедельник — день тяжелый».
• Вторник: планирование работы на неделю, оценка трудоемкости и необходимой «средней скорости выполнения». Начальные наброски в коде. Начинает что-то появляться на бумажке :)
• Среда: первые ощутимые изменения в коде. Вхождение в проблему, реализация основы, кодинг кодинг…
• Четверг: обычно менее «скоростной» чем среда, но более мозголомный. Основной мотив «я на верном пути? надо ли все это?». Если таких вопросов не возникает и код «льется рекой», то бывает, что четверг проходит так же как и среда.
• Пятница: часто такой же производительный день, как и среда. Обычно наибольший объем коммита. Стараюсь сделать так, чтобы можно было уже подвести итоги работы за неделю. В идеале — уже имеющиеся результаты работы, с которыми можно поиграться. Если работа выполнена заранее — опять же комментирование сложных или нетривиальных алгоритмов, общей идеи и т. д. Рефакторинг в пятницу нежелателен, лучше оставить до понедельника.
P.S.: Разумеется, это все усреднено и сглажено. Когда-то лучше, когда-то хуже. Но одно могу сказать точно — уже заранее можно представить, чем ты будешь заниматься в каждый из дней. И это помогает не гнаться сломя голову, ну и в то же время не зевать. Как раз против зевания организован такой подход.
P.P.S: Я не живу по графику и терпеть не могу жестких правил, расписаний и прочего. Эта методика — сугубо для задач самомотивации.
Удалось провести review?
Только к среде. Подозрительно много нафлудил за прошедшую неделю!
Отсутствие поставленного workflow на проекте (не то что у Halt!) порой сбивает с ритма, если честно.
Отсутствие поставленного workflow на проекте (не то что у Halt!) порой сбивает с ритма, если честно.
Согласен по поводу блокнота и карандаша. Передо мной всегда лежит блокнот, на котором начиркано много всего, понятного только мне, но помогающего логировать собственные мысли. Как только перехожу к новой задаче, открываю новый лист.
Насчет записи контекста вспомнился фильм «Memento» — там запись так запись была :)
А вообще перерывы делать полезно даже для того, чтобы не получить букет хронических заболеваний программиста.
А вообще перерывы делать полезно даже для того, чтобы не получить букет хронических заболеваний программиста.
Хорошие и действенные советы!
Некоторые использую в работе сам, но не все. Теперь буду знать.
В дополнении могу написать…
Всегда, когда много маленьких сволочных заданий отвлекаешься и непременно надо записывать, что ты делаешь. А иногда даже писать самому себе записки во времени.
«Сделай это завтра»
«Привет, а как ты думаешь стоит ли...»
Когда отвлекаешься на чай или еще что-то (другой проект, выходные, беспробудный сон на книжках, поход к бизнес-пользователям) потом сложно вспомнить, что ты хотел сделать, а такие записки часто дают возможность вспомнить или даже поспорить с самим собой.
Чуть выше был комент про рисование на листке. Я выбил у начальства доску для рисований и фломастер))) Чего только не было нарисовано и написано на ней. Часто рисуются задачи, которые передо мной стоят (mind mapping) и это иногда здорово помогает объяснить самому себе, что я хочу сделать. Ну и просто порисовать и отвлечься…
А самое главное это что бы перерывы не слились в один большой перерыв на весь день)
Некоторые использую в работе сам, но не все. Теперь буду знать.
В дополнении могу написать…
Всегда, когда много маленьких сволочных заданий отвлекаешься и непременно надо записывать, что ты делаешь. А иногда даже писать самому себе записки во времени.
«Сделай это завтра»
«Привет, а как ты думаешь стоит ли...»
Когда отвлекаешься на чай или еще что-то (другой проект, выходные, беспробудный сон на книжках, поход к бизнес-пользователям) потом сложно вспомнить, что ты хотел сделать, а такие записки часто дают возможность вспомнить или даже поспорить с самим собой.
Чуть выше был комент про рисование на листке. Я выбил у начальства доску для рисований и фломастер))) Чего только не было нарисовано и написано на ней. Часто рисуются задачи, которые передо мной стоят (mind mapping) и это иногда здорово помогает объяснить самому себе, что я хочу сделать. Ну и просто порисовать и отвлечься…
А самое главное это что бы перерывы не слились в один большой перерыв на весь день)
По поводу «одной задачи, а всё остальное — отвлекающие факторы» — у меня именно «текущие задачи». Ибо их всегда несколько. И не всегда они быстро решаются. Начинаю делать первую, делаю пока делается. Если упираюсь в затык и не могу быстро найти решение — переключаюсь на вторую задачу и т.д. Пока делаю вторую — обычно возникает решение затыка первой задачи. При затыке на второй задаче переключаюсь на первую и т.д.
а я когда отвлекаюсь — нарочно делаю ошибки в коде, чтоб знать где остановился =)
Ага, самый мой главный принцип — что бы не забыть — надо записать и забыть :)
Ну я к этому пришел за 3 года работы в офисе.
А всего работаю уже 10 лет.
Итого все просто
— каждый час на 10 минут в убунту блокируется экран
— все мысли выписываются в блокнот для освобождения мозга
— перед глазами всегда задачи на день — ясно, что делать дальше
— на ЛЮБУЮ задачу смотреть, как на ту, от которой надо избавиться, забить на нее. ради того весь тайм-менеджмент, ИМХО. эффективно направлять время туда, куда требуется -а таких вещей всего 20%, по Парето.
— весь день это 8 итераций. когда 10 минут пауза, я иду бродить по коридору. за это время подсознание думает над задачами. идет творческий процесс.
все это я уже писал в своих постах. значит, не одному мне приходят такие мысли и идеи в процессе работы над собой.
всем удачи в саморазвитии.
А всего работаю уже 10 лет.
Итого все просто
— каждый час на 10 минут в убунту блокируется экран
— все мысли выписываются в блокнот для освобождения мозга
— перед глазами всегда задачи на день — ясно, что делать дальше
— на ЛЮБУЮ задачу смотреть, как на ту, от которой надо избавиться, забить на нее. ради того весь тайм-менеджмент, ИМХО. эффективно направлять время туда, куда требуется -а таких вещей всего 20%, по Парето.
— весь день это 8 итераций. когда 10 минут пауза, я иду бродить по коридору. за это время подсознание думает над задачами. идет творческий процесс.
все это я уже писал в своих постах. значит, не одному мне приходят такие мысли и идеи в процессе работы над собой.
всем удачи в саморазвитии.
Тоже в этом месяце перевёл данную статью: kornerr.blogspot.com/2010/10/20.html
Причём переводил её как раз небольшими порциями (см. примечание).
Взял у вас заголовок.
Подобные переводы-изложения лично не люблю, т.к. отбрасывается ненужная, по мнению переводчика, информация. Мне ближе стиль второго переводчика.
В остальном — спасибо за другую точку зрения на перевод :)
Причём переводил её как раз небольшими порциями (см. примечание).
Взял у вас заголовок.
Подобные переводы-изложения лично не люблю, т.к. отбрасывается ненужная, по мнению переводчика, информация. Мне ближе стиль второго переводчика.
В остальном — спасибо за другую точку зрения на перевод :)
В небезысветсной книге «Rework» (написанной программистами), есть данный раздел:
Перерывы – Враги Продуктивности
Что скажете на этот счет?
Перерывы – Враги Продуктивности
Перерывы дробят ваш рабочий день. 45 минут работы – и затем вы разговариваете по телефону. Еще 15 минут – и вам пора на обед. Спустя еще час вы спешите на послеобеденное совещание. В результате на часах уже шесть вечера, и у вас была всего пара часов без перерывов, чтобы делать свое дело. Вы не можете вершить важные дела в режиме «старт – остановка, старт – остановка».
Что скажете на этот счет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программист, который отвлекается