/ фото Alexandre Dulaunoy CC
На прошлой неделе в нашем блоге на Хабре мы обсуждали тему коммуникации в рамках команды. Речь шла о том, какие вещи лучше не говорить разработчикам и тестировщикам. На этот раз мы зайдем с другой стороны и обсудим рабочие моменты, в которых иногда заблуждаются сами девелоперы.
1. Eat, sleep, code, repeat!
Известно, что этой концепции следуют многие разработчики – она стала своеобразной мантрой, которую повторяют наиболее приверженные своему делу трудяги. Однако в ней скрывается опасный подтекст. Если задуматься, то эта фраза пропагандирует нездоровый образ жизни, внушая мысль, что программирование – это всё. Якобы, чтобы преуспеть в этой области, необходимо целиком посвящать себя разработке. Но на деле все совершенно наоборот.
Есть еще множество других увлекательных занятий помимо программирования: чтение, походы, садоводство, прогулки с собакой, катание на горных лыжах, гонки на мотоциклах и так далее. Список можно продолжать бесконечно.
Когда вы отвлекаетесь на другую деятельность, ваш мозг получает возможность «подышать» воздухом вдали от трансляторов и компиляторов. Именно это сделает вас лучшим разработчиком, разовьет гибкость ума и такие качества, как креативное мышление и терпеливость. Их нельзя культивировать, занимаясь лишь написанием кода.
Техническая индустрия любит гиперболизировать, мол, как иначе вам стать гуру программирования, если не посвящать все часы бодрствования разработке приложений? Да, энтузиазм способен вознести вас на вершину успеха, но чтобы там удержаться и стать действительно хорошим программистом, зарезервируйте в своем расписании местечко под развлечения «простых смертных».
2. Митапы не нужны
Среди разработчиков бытует мнение, что приложения доставляются в срок только в том случае, если программисты пишут код, а не просиживают на «разборах полетов». Но нужно понимать, чтобы создать хороший продукт, уделять время этим разговорам необходимо, иначе компания рискует уйти не в ту сторону.
Кто-то считает встречи корпоративным кошмаром. Долгие часы тратятся еженедельно на собрания, во время которых не принимается никаких особо важных решений. Планерки – наиболее популярная их разновидность, когда десяток людей собирается, чтобы поговорить о ситуации и будущих проектах. Многие их участники скучают и не уделяют должного внимания докладам, витая в облаках, спускаясь на землю только тогда, когда нужно ответить на вопрос.
Однако митапы необходимы, чтобы организовать работу. Это дает возможность каждому члену команды ознакомиться со статусом проекта. Как ни странно, в первую очередь это важно для руководства.
Питер Тиль (Peter Thiel), соучредитель компании PayPal, как-то отметил: «Как генеральный директор вы являетесь центром организации, однако иной раз вы знаете меньше всех в компании». Потому даже небольшие доклады длительностью 5-7 минут позволят боссу держать руку на пульсе и не чувствовать себя аутсайдером.
Если вам действительно жалко времени на подобную «групповую терапию», то попробуйте предложить руководству проводить совещания тет-а-тет или отдавать общий отчет на откуп лидеру команды. Это высвободит драгоценное время на разработку.
3. UI можно сделать и самому…
Глубоко внутри каждого разработчика скрывается начинающий дизайнер. Если вы позволите ему вырваться, то вас ждут неприятности. Ну или как минимум проблемы ждут пользователей приложения.
Есть интерфейсы, которые мгновенно вызывают улыбку. Вы можете представить себе поток мыслей, проносившийся в голове разработчика в момент создания сего шедевра. Часто это неказистое диалоговое окно или какое-нибудь утилитарное приложение.
Вот здесь он хотел отобразить некую информацию, потому создал это поле, разумеется, с намерением позднее удалить его. Здесь он решил, что неплохо бы добавить еще пару параметров – так появились несколько новых кнопок и выпадающих списков. Так, а почему этот параметр нигде не выводится? Непорядок. Добавим еще один ползунок. В результате рождается что-нибудь подобное:
Внешний вид создаваемого интерфейса-монстра становится настолько привычным, что команда разработки перестает замечать его «нагроможденность». Позднее, когда это всплывет наружу, привести все в порядок достаточно сложно.
Тем, кто жаждет научиться разрабатывать хорошие интерфейсы, стоит начать с изучения этой темы на Stack Overflow.
4. …и протестировать все самостоятельно
Разработчик не может быть тестировщиком (разумеется, исключения есть всегда). Это связано с тем, что девелопер слишком хорошо знает все тонкости созданного им программного обеспечения, потому ему сложно сделать какие-то выводы о жизнеспособности кода – этот факт хорошо известен тестировщикам.
Разумеется, разработчики могут принимать участие в процессе тестирования, особенно в случае Agile, но необходимо помнить о «слепых пятнах». Вот несколько из них:
1) Родительская любовь к написанному коду
Известный факт: свое творение сложно оценить объективно. Разработчики эмоционально привязаны к написанным ими операторам и функциям.
Наглядный пример – дети. Родители считают своих детей идеальными (не замечают недостатков) и сердятся, если кто-то ругает их чадо.
2) Позитивное мышление
Большинство усилий разработчика направлены на эффективную реализацию функций. В тестировании же необходимо искать «неэффективные» способы их использования (что может пойти не так?) – переключить сознание за короткий период времени достаточно проблематично.
3) Упрощение сложных сценариев
Тестировщики учатся искать сложные сценарии использования функций, например, выполняют множество действий одновременно или повторяют одну и ту же операцию несколько раз, чтобы «сломать» систему и выявить баги. По сути, они ищут способы усложнить простой процесс. Разработчики же, наоборот, разбивают сложные процессы на мелкие компоненты, которые позволяют им найти решение.
4) Слабый «нюх»
Хороший тестер «чует» баги и легко выявляет, что не вписывается в общую картину приложения. Это приходит только с большим опытом.
Большинство разработчиков не имеют четкого представления о том, как пользователи будут обращаться с ПО. Тестировщики же понимают, как именно пользователи добиваются поставленных целей, и умеют «симулировать» их работу с приложением.
5. Быть заказчиком и разработчиком в одном флаконе
Проблема разработчика и заказчика в одном лице заключается в том, что разработчики акцентируют все внимание на решении проблем, а задачей заказчика является их поиск. Бывает сложно переключиться с одного сценария работы на другой.
Разработчик фокусирует внимание на коде и архитектуре продукта. Заказчик думает о бизнес-требованиях. Иногда эти два человека не хотят слышать друг друга.
Также стоит отметить, что, выступая как разработчик, заказчик ограничивает в правах команду разработки, поскольку последнее слово будет всегда оставаться за ним. Делегировать все полномочия девелоперам тоже не удастся. Вы же не сможете писать код и не высказывать свое мнение о проекте?
6. «Стэлс-режим» или «Alone In The Dark»
Код «пахнет» – так говорят, когда в листинге с первого взгляда видны потенциальные проблемы и недоработки. Мартин Фаулер (Martin Fowler), автор ряда книг и статей по архитектуре ПО, называет такой «запах» индикатором проблем, присутствующих в системе. На сегодняшний день написаны сотни статей на тему определения плохого кода (например вот, вот и вот). Зачастую эта проблема связана с излишней сложностью, запутанностью, бездумным копированием и т. д.
Однако код, написанный одним человеком, также будет «издавать неприятный запах». Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат.
Так происходит потому, что, когда вы работаете один, требуется невероятная выдержка, дабы не начать искать легких путей. Документация будет неполной, процессы будут не оптимизированы, о рефакторинге иной раз можно забыть.
С другой стороны, программирование «при свете» дает только положительный результат. В процессе работы вы начинаете задумываться о мелочах, например о названиях переменных, а отзывы других разработчиков помогут вам вырасти как специалисту.
Возможно, это достаточно очевидная вещь, но не каждый девелопер готов отдать свою работу на суд других. Просить о фидбеке непросто – никто не любит слышать, что он был неправ.
Мы в 1cloud считаем, что о разработках нужно рассказывать, делиться опытом со знакомыми и коллегами. Хороший код и сервисы не рождаются из ниоткуда, они становятся такими, закаляясь в огне критики. Для этого отлично подходит Хабр, а нам остается только оперативно реагировать на любую критику и давать максимум информации о своем IaaS-провайдере.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (65)
Terras
11.07.2016 10:49+6Пф. И все эти советы идут в задницу, когда тебе 25 лет, у тебя ипотека и жена с маленьким ребенком, и ты сидишь один ночью и пилишь какое-нибудь приложение, которое поможет тебе заработать дополнительно 10-30к в месяц.
1cloud
11.07.2016 10:59+1Это точно, но с другой стороны можно что-то более существенное сделать, если привлечь к работе дизайнера / проектировщика и часть задач по тестированию делегировать. Вопрос именно в эффективности
SerP1983
11.07.2016 12:13+3И где сейчас winamp? После того, как к его разработке были подключены дизайнеры, проектировщики, тестеры…
Idot
11.07.2016 12:11+3Потому что тебе 25 лет, в 45 такое фиг получится, потому что организм элементарно не будет успевать восстановиться.
PS начинающий программист сразу начинает писать код, опытный программист, прежде чем писать код, сначала тщательно обдумывает, как сделать это так чтобы не пришлось его потом переписывать (избежание ошибок на стадии проектирования).
0xd34df00d
13.07.2016 02:16Завидую. Мне 25, и я ощущаю разницу в реакции организма на ночные бдения сейчас и 10 лет назад.
KirillFormado
13.07.2016 11:51+1«Живу так лет 10 (с точностью до частичной подмены code на учёбу в вузе). Брат жив.»
Возможно дело в этом?0xd34df00d
13.07.2016 16:32В учёбе?
Так это ИМХО сорта одного и того же. Я ведь почти не читаю худлит (к сожалению), не езжу в путешествия, не занимаюсь садоводством, у меня нет лыж и велосипеда, и так далее.KirillFormado
13.07.2016 17:14В образе жизни. Тут можно спорить, но я придерживаюсь мнения, что если не уделять время физической активности, со временем сил и на учебу/работу будет оставаться все меньше и меньше. А так же придерживаюсь мнения, что переключение контекста помогает отдохнуть психологически. Плюс увлечения не сосредоточенные в одной узкой области в конечном итоге расширяют кругозор.
0xd34df00d
14.07.2016 05:32Не могу воспроизвести.
Ну, то есть, ходил я в качалку месяцев 9. Вечер после качалки — выкинутое время, мозги не варят вообще. После переезда, так получилось, в качалку перестал ходить — и мозги снова продуктивны и хорошо работают.
Переключение контекста, безусловно, полезно. Поэтому на работе один проект, а для хобби — другой :)
Расширение кругозора как самоцель я не очень понимаю, но читать статьи и книги не только по программированию, но и по всяким математикам, физикам и прочему подобному нахожу интересным и полезным. Но это, опять же, ИМХО далековато от путешествий-прогулок-собак.michael_vostrikov
14.07.2016 08:54Вы не поняли. Человек написал комментарий по поводу «ощущаю разницу в реакции организма на ночные бдения сейчас и 10 лет назад». Потому и ощущаете, что из-за компьютера не вылазите последние 10 лет.
0xd34df00d
15.07.2016 08:23И правда, не понял.
Тут уже, правда, другой вопрос — а успею ли я больше, если из-за компьютера вылазить? Ведь тогда и бдений-то не будет столько же, как минимум.
ef_end_y
11.07.2016 11:36Бывает в режиме «eat, sleep, code, repeat» делаешь 90% задачи. Главное выделить под это дело адекватное количество времени. Пишу это, потому что как раз в пятницу вечером решил изучить андроид и написать приложение с ассинхронными запросами по API. Включился в работу вечером и завершил в 5 утра, через 5 часов проснулся, несколько часов на кодинг, пару часов сна, doom4 и до 4 часов утра кодить. Устал жутко, зато сделал задел на будущее и в спокойном режиме смогу продумать все части проекта, что успел сделал в таком режиме нонстоп
aquamakc
11.07.2016 12:14+2Есть еще множество других увлекательных занятий помимо программирования: чтение, походы, садоводство, прогулки с собакой, катание на горных лыжах, гонки на мотоциклах и так далее. Список можно продолжать бесконечно.
Меня тут-же на хабре заминусили как-то, когда я посмел высказать эту мысль в подобной теме.Terras
11.07.2016 12:44у меня допустим график такой.
1) Работа 2) Потом пилю свой проект 3) Провожу время с женой. Причем очень часто жена вредничает, что я слишком много работаю и провожу слишком мало времени с женой. В итоге, у меня просто нет времени на какие-то свои дела и хобби. Ну разве, что в тренажерный зал хожу, но это опять же больше необходимость, чем хобби.
Правда раз в 3-4 месяца, забиваю на свой проект и примерно неделю занимаюсь чем-то другим. Но опять же работу и жену никто не отменял, в итоге, просто 4-5 часов, которые я могу куда-то сходить с друзьями и что-то поделать.
Конечно, можно назвать свой проект хобби, где я учусь новым штукам и познаю мир программирования, но это очень спорно.Idot
11.07.2016 12:50А каким ещё хобби Вы мечтали бы заниматься помимо своего проекта, если не секрет? (^_^)
PS например, у меня в качестве Хобби:
— WolfGL-3D основанный на исходниках Wolfenstein 3D (а точнее форк от newWolf)
— мод к King's Bounty
— чтение книг
— просмотр аниме (^_^)
— чтение манги
— игры
— просмотр Игры Престолов
— просмотр фильмов
msdos9
11.07.2016 15:31-1Это и есть Ваши хобби????? Извините, но я Вам сочувствую…
Я так понял, что у многих айтишников даже хобби завязано на мониторе. Но, по опыту знаю, проблема придумывания виртуальных увлечений и «куда себя деть и чем заняться» резко исчезает с появлением семьи и детей.exerrk
11.07.2016 17:32+1Мне кажется хобби — это то, на что приятно тратить время. Разве есть разница к чему оно привязано (монитору, спортивным снарядам, WD-40, людям), если это приносит удовольствие? И, как мне кажется, «проблемы придумывания» у хобби быть не может — либо оно есть, либо его нет.
monah_tuk
12.07.2016 10:03Я так понял,
а на основании чего? Вот у нас в Приморье, если встретишь туриста в тайге, во многих случаях это окажется человек так или иначе связанный с IT.
0xd34df00d
13.07.2016 02:17А, это объясняет, почему я семью-детей заводить не хочу — и так понятно, куда себя девать и чем заняться.
Даже страшно, столько всего умного вокруг, а я такой глупый.monah_tuk
13.07.2016 15:29Да оратор выше что-то сморозил не то. Дети и семья время требуют и его обязательно нужно выделять, но они и больше дисциплинируют, что способствует. Если они мешают… то что-то у человека не то. Скорее всего — с головой. Поэтому если не тянет — то лучше и не нужно.
В любом случае, как это может быть определяющим фактором для хобби — хоть убей, но не пойму.
0xd34df00d
13.07.2016 16:33Эм, почему если мешают, то что-то у человека не то?
Всё ведь зависит от целей человека. А отвлекающие факторы, гм, отвлекают.monah_tuk
13.07.2016 17:02Попробую пояснить.
Если для человека дети — отвлекающий фактор, то они явно не его цель (т.е. он не готов распределить на них часть времени как на другие цели), но если они у него есть… где-то он накосячил :-D
symbix
13.07.2016 18:16Да просто ваше предыдущее сообщение можно понять как «если человек не хочет заводить семью-детей, то у него что-то не то с головой». И это весьма распространенное мнение :)
monah_tuk
14.07.2016 02:00Упс. Вот этого я точно не имел ввиду :)
0xd34df00d
14.07.2016 05:29О, спасибо, что пояснили здесь и чуть выше, а то я ведь вас так и распарсил :( symbix прав, больно распространённое мнение, prior probability высокая.
А так-то да, с учётом вашего пояснения не могу не согласиться!
aquamakc
11.07.2016 13:01+1У меня примерно также, только вместо п.2 у меня 4-х месячная дочь, а через месяц получу ключи от новой квартиры и надо будет ремонт делать. Так-что у меня даже на тренажёрку времени нет. От окончательной потери хоть какой-то физической формы помогает зарядка по утрам, велосипед и пешая доставка себя на работу и обратно.
Но факт в том, что помимо программирования должны быть в жизни и другие вещи.
Serg85
11.07.2016 17:32С одной стороны советы капитанские, но к сожалению все в той или иной мере присутствуют в повседневной работе.
Пока свой проект не начал приносить какую-то прибыль, не представляю как можно избежать этих проблем.
elegorod
12.07.2016 00:50+1> 3. UI можно сделать и самому
Если это внутреннее корпоративное приложение, такой подход вполне работает. Конечно, про юзабилити думать надо, но и нанимать дизайнера нарисовать обычные формы и таблицы — перебор.
> 6. «Стэлс-режим» или «Alone In The Dark»
Мне больше помогли статьи о том, как надо (и не надо) делать, и книги вроде Clean code, чем работа в команде. После прочтения и опыта в команде можно и самому писать хороший код, даже если проект для себя.
fishHook
12.07.2016 08:01>UI можно сделать и самому…
Совершенно не понятно, почему бы это разработчику не быть одновременно немного дизайнером. Автор позиционирует эти две сферы человеческой деятельности как противоположные и несовместимые. Вероятно, все зависит от конкретного разработчика, конкретного проекта, конкретного заказчика. Автор, видимо, сам не сталкивался с реалиями разработки ПО, поэтому берет на себя смелость давать подобные советы.Idot
12.07.2016 08:15При этом, автор приведя пример «плохого» интерфейса, не продемонстрировал пример хорошего. А ссылка которую они привёл — бестолковая и бесполезная, ибо содержит лишь кучу слов и ни одной иллюстрации с примером хорошего интерфейса.
aquamakc
12.07.2016 09:22Я подозреваю, что имело в виду то, что типовой программист делает интерфейс для программы, а дизайнер (хороший) для человека, т.к. ему неважно как программа работает. Хреновый дизайнер делает для красоты.
Но это всё ерунда на самом деле. Небольшая утилита с 3,5 кнопок не нуждается в дополнительных людях, а серьёзное приложение должно разрабатываться с проработки архитектуры программы, и(!) архитектуры пользовательского интерфейса. И только когда эти 2 архитектуры будут определены — надо приступать к написанию кода.fishHook
12.07.2016 09:55Программист обычно хорошо понимает предметную область, поэтому ориентируется в программе не с точки зрения какого-то сферического юзабилити в вакууме, а знает какие функции более востребованы, какие именно задачи они решают и какой подготовкой будет обладать использующий их персонал. Программист проводит за отладкой программы кучу времени, поэтому имеет представление об удобстве интерфейса именно как конечный пользователь. А вообще, фронтенд это такая штука, где прийти к более-менее оптимальному решению обычно удается только в процессе работы. Автор описал нам полного дебила, который накидал на форму кучу контролов и инфантильно радуется. С другой стороны где-то есть мудрые дизайнеры интерфейсов, которые не зная как работает программа и какие задачи она решает с первого раза безошибочно продумывают интерфейс не смотря на все правки которые обычно возникают в процессе разработки любого продукта, даже серьезного приложения. Это какой-то мир единорогов и розовых пони, где заказчик не вмешивается в процесс разработки, ТЗ не меняются по десять раз, менеджеры не подписывают кучи допсоглашений, все делается в срок и в продакшен не попадают плохо протестированные модули. Для кого эта статья? ИМХО для того, кто видел работу программерской конторы только по телевизору.
Idot
12.07.2016 10:16Зависит от организации работы. Например, однажды работал в месте, где IT Бизнес Аналитик, неделями согласует с заказчиком и с разработчиками документ с полным и подробным описанием того что хочет заказчик, а затем на финальном документе ставят подписи и печати.
aquamakc
12.07.2016 13:18В сфечиреской разработке в вакууме дизайнер интерфейсов не должен знать, как работает программа. Ему ставится задача создать максимально удобный для пользователя интерфейс, с помощью которого он может решать конкретные задачи. Предполагается, что программа эти задачи решать может, в ней нет костылей, накладывающих какие-то ограничения и/или условия. Опять-же в грамотно построенном приложении интерфейс никак не влияет на функционирование, что развязывает дизайнеру руки. Хочет — консоль, хочет — веб страничка, хочет — формочка с одной кнопкой «Сделать мне хорошо».
Мы все понимаем, что реальность имеет отличия и не в лучшую сторону, особенно в наших краях, где для экономии бюджета руководители оплачивают труд одного программиста считая, что он и разработчик, и тестировщик и дизайнер, а иногда ещё и маркетолог.fishHook
12.07.2016 13:34>В сфечиреской разработке в вакууме дизайнер интерфейсов не должен знать, как работает программа. Ему ставится задача создать >максимально удобный для пользователя интерфейс, с помощью которого он может решать конкретные задачи
Какие конкретные задачи? Дизайнер в этих задачах ничего не понимает и не разбирается. Вы понимаете, что задачи бывают сложнее, чем скроллить мышкой странички в браузере? Дизайн приложения вырабатывается годами, а у некоторых десятилетиями. Чтобы дизайнер выработал тот же опыт общения с программой, что и программист с тестировщиком, его надо погрузить в предметную область и посадить
на место диспетчера/бухгалтера/какого-то работника.aquamakc
12.07.2016 14:12Какие конкретные задачи? Дизайнер в этих задачах ничего не понимает и не разбирается.
Вот в этом основная проблема. Программист решает задачу разработки, а для дизайнер должен решить проблему пользователя, это разные задачи.
Дизайнеры приборной панели авто могут понятия не иметь о конструктиве двигателя, объёме багажника и расположении генератора под капотом. Они решают где разместить отверстия вентиляции, ручки управления мультмедиа-системой, какой формы будет руль и каким цветом подсвечиваются приборы.fishHook
12.07.2016 14:33Вы смеётесь? Вы поищите в интернете примеры дизайнерских решений в автомобилестроении. Эти прототипы доживают только до выставки, в серию идут решения инженеров. Чтобы дизайнер смог спроектировать рабочее место водителя грузовика, он должен сам уметь управлять грузовиком и иметь в этом солидный опыт. А чтобы размышлять о решетках вентиляции, нужно иметь представление об аэродинамике, понимать как прокладываются жгуты проводов, как лишнее отверстие в панели приборов влияет на её прочность
и безопасность. «Решить проблему пользователя» без подобного багажа знаний невозможно, и разумеется инженер решает её успешнее художника-декоратора.
pan_KOST
12.07.2016 16:39В качестве дополнения, замечу, что есть промышленный дизайн и есть просто дизайн.
Прототипы на выставках сделаны в первую очередь дизайнерами, а промышленный дизайн — это несколько иная предметная область, где дизайнер знает теормех и, возможно, сопромат.
С точки зрения ПО — дизайнер это плохой человек, правильный человек -UI/UX -который рисует не кнопочки, а сценарии работы с программой и подтягивает под эти сценарии кнопки.
А сами сценарии — воплощение работы с предметной областью, как раз
monah_tuk
12.07.2016 09:58Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат
эх, самое хреновое, когда сам себя не сильно относишь к экспертам, в результате заводишь ревью, никто ничего не находит, а ты сам себе заводишь пачку замечаний… Печально становится: или лучше тебя нет, или на ревью забили.
А вот сейчас проект, на котором я один разработчик… Из-а вынужденных простоев (зависимости по железу, FPGA) приходилось адски себя удерживать от перфекционизма. В результате получилась достаточно стройная система, на основании которой вышло уже три продукта, только, фактически, с эволюционными изменениями ядра.
fishHook
12.07.2016 10:15>Это не означает, что он плохой, просто, если показать его другим экспертам, со 100% вероятностью они его улучшат
Да щас прям. С 50% вероятностью его ухудшат. Ну а то, что ж я за эксперт, если не найду в чужом коде косяков? Каждому охота повыпендриваться, «а вот я бы тут сделал фабрику фабрик, а вот эти методы можно сделать статичными» и в таком духе. Такие советы не делают код лучше, они делают видимость участия и высокого профессионализма советчиков.
dmitry_ch
12.07.2016 14:17> 3. UI можно сделать и самому…
Ну, Gmail который год живет с UI, который иначе как написанным программистами не назовешь )
Crazy_as
12.07.2016 23:39Как подметили выше, не факт, что другой разработчик как-то улучшит ваш код.
Был подобный случай: нужно было написать один достаточно сложный проект. Буквально за день до защиты было решено показать его одному программисту, который в моем кругу общения считается достаточно продвинутым. И что в итоге? «Зачем ты в public классе ты передаешь значение private полю через метод, можно же сделать его public и обращаться напрямую...», «Зачем ты сделала то-то так-то так-то, можно же было проще....» etc. В итоге, после его «набега», в исходниках явно «запахло»(и не горной лавандой) пришлось экстренно откатывать версию.
К чему все это? Да просто этой реальной историей я хотел показать, что вероятность улучшения вашего когда другим разработчиком явно не 100%.
0xd34df00d
13.07.2016 02:26Eat, sleep, code, repeat — это отлично.
Я не помню ни разу, когда мне приходило бы решение сложной проблемы, когда я занимаюсь чем-то другим, вроде чтения худлита, игры на гитаре (когда я ещё этим занимался) или полуторачасовой поездки в вуз. Надо много и долго работать и думать, погрузиться в задачу. Я понял, как переписать хитрый алгоритм с матрицами на высоком уровне, чтобы добиться параллелизма, не когда гулял, а когда третий час смотрел на коллстек в профайлере. Я понял, как красиво вывести одну умную формулу не когда читал художественную книгу, а когда почти весь день провёл с ручкой и бумажкой, пытаясь вывести её из совсем других соображений. Ну и так далее.symbix
13.07.2016 16:59У меня иногда бывает, что, когда отвлечешься, приходит неожиданное решение. Думаешь вроде бы вообще о другом, срабатывает какая-то странная ассоциация, и вот оно. Но это, конечно, случайности.
michael_vostrikov
13.07.2016 18:43У меня тоже так бывает, да и думаю у многих. У меня даже есть теория, почему так происходит.
Когда занимаешься задачей, новые данные находятся в оперативной памяти, весь фокус внимания направлен на их восприятие и на текущий вариант решения (обычно на понимание того, как оно работает, или на поиск причины, почему не работает). А когда отвлекся (пошел прогуляться, или просто чай поставить и в окно посмотреть), то информация начинает переходить из оперативной памяти в долговременную, и появляются ассоциативные связи с уже известными понятиями и между новыми.
Ассоциативные сигналы, кончено, возникают постоянно, но когда внимание направлено на новую информацию, воспринимаются только наиболее сильные. Поэтому когда появляется знакомая задача, то и решение можно найти быстро.
0xd34df00d
14.07.2016 05:32Да, я про это наслышан, но у меня оно, похоже, к сожалению, так не работает.
Actee
Как по мне: eat, sleep, code, repeat! – самое зло. Хватит на пару месяцев, потом еще столько же придется приходить в нормальное состояние. Но для некоторых только такой подход и работает, кстати
1cloud
Тут главное грамотно подойти к планированию рабочего графика (в том числе и для всей команды).
Тогда необходимость работы 24/7 отпадет, и переживать за возможные недоработки не придется :)
adeptoleg
Да, но ИМХО труднореализуемый вариант если критерием выступает производительность. К примеру сложно предвидеть что завтра там будет плохая погода и все будут сидеть вялые, и тут планируй не планируй работа практически стоит. Человек не робот втиснуть его в какие то рамки можно только на короткий срок и не всегда.
1cloud
Плохая погода – это уже единичный случай. Ну и тут вкусовщина играет роль. Мы скорее про общий подход :)
mamkaololosha
Тогда уж: eat, sleep, solve problem, relax, solve problem, relax, repeate!
Проблема должна быть решена, а не «закодирована».
symbix
Зло, если так все время делать.
А иногда (разок в месяц) 2-3 дня нормально, причем за такие 2-3 дня можно запросто сделать недельную работу целого отдела. :-) После такого уже можно спокойно и размеренно наводить красоту в написанном.
0xd34df00d
Живу так лет 10 (с точностью до частичной подмены code на учёбу в вузе). Брат жив.
Просто надо заниматься тем, что интересно.