Важно сначала сформулировать задачу, а потом искать способ её решения.
Классическая последовательность: «Зачем? --> Что? --> Как?»
У автора статьи идёт прямая проекция: Зачем? — это цель; Что? — это структура данных; Как? — это реализация, то есть алгоритм или код.
Но некоторые люди могут действовать только на уровне абстракции «Как?», поэтому для них алгоритм первичен, а структуры данных (не говоря уже о целях) околачиваются где-то на задворках сознания. Может быть, в итоге и получается «некривой» код (по субъективному мнению авторов), но почти всегда он приводит к кривому решению бизнес-задачи. Если вообще что-то решает.
ООП плохой, потому что не является прагматичным инструментом для решения практических задач. Он не помогает концентрироваться на кратчайшем пути, а постоянно уводит в сторону. Вместо лаконичного функционального кода приходится писать тонны сервисного кода, не дающего заметного эффекта. Чтобы это понять, надо не только достаточно хорошо овладеть ООП, но и иметь представление о том, что существует за его пределами.
Если язык популярный, это не всегда значит, что он — практичный, то есть оптимальный для решения практических задач. Как по мне так Дейкстра видел перспективу на десятилетия вперёд, а любители «практического программирования» иногда не видят и на десятилетия назад)
Я считаю, что эксперимент сделан в правильном направлении, но фокус сильно рамазан. Можно взять, например, research или r&d отдел технологической компании, где уровень влияния творчества на качество работы достаточно высокий. И срезать рабочий день не на проценты, а в разы. Например, работать 4 дня в неделю, 4 часа в день и с двойной зарплатой. Вот тогда реально можно почувствовать эффект квантового перехода)
Я бы вот даже заморочился, лично открыл контору и поработал в ней так годик-два.
Я думаю, тут важно не сделать шедевр со второй попытки, а каждый раз пытаться сделать шедевр. Кармаку понадобилось 23 попытки, чтобы дойти до Дума. Но если бы он каждый раз хотел сделать что-то заурядное и посредственное, то Дум мы бы не увидели никогда.
Есть такие люди — начинающие геймдизайнеры. Они обычно много всего придумывают, но реализовать не могут, потому что программировать — это не их специализация. Обычно хорошие игры делаются в содружества геймдизайнеры и программиста-разработчика.
Можно попробовать найти человека с уже готовой идеей и сделать игру для него. Конечно, если самому эта идея нравится. Может быть, в процессе и своя идея появится)
Мне кажется, автору стоит обратить внимание на режим дня. В разработке игр сложно то, что процесс увлекательный и творческий одновременно. Если делать игру высокого класса, то это ещё и долго. Например, я свою первую коммерческую игру делал 9 месяцев. Если срываться каждый день в авралы и не спать ночами, то за месяц-два можно прийти к невменяемому состоянию, в котором никакого творчества уже невозможно. А если нет творчества, нет элемента искусства, то зачем вообще нужна такая игра?)
Даже взрослых опытных разработчиков часто подводит неумение выдерживать режим дня и режим недели. Я думаю, это первое, чему надо учиться. И чем раньше, тем лучше. Это гораздо проще, чем Java и C#, Unity и UDK, но при этом намного важнее в реальной жизни.
В долгосрочной перспективе очень полезно уметь сдерживать свои творческие порывы — благодаря этому растёт творческий потенциал. И в итоге вместо 20 поделок-однодневок за то же время можно сделать 1-2 шедевра мирового уровня на века)
Я работаю удалённо 7 лет, из них 5 лет непрерывно путешествовал, в основном по Азии. По началу была романтика, постоянно новые места, новые люди, возможность не ограничивать себя местом и временем. Опять же зима без снега) Или наоборот — зима на горнолыжном курорте. Но в итоге новизна прошла и это стало ощущаться как неинтересная рутина. Планирование путешествий — это тоже в итоге весьма непростая работа, которая которая генерирует стресс и имеет свои риски. Оказалось, что я работаю сразу на двух работах, и это напряжно) Я осел в одном месте и оставил себе только одну работу. Жить стало в 2 раза проще.
Я не жалею о времени и силах, потраченных на путешествия. В своё время это было здорово и интересно. Но в какой-то момент это надоедает и игра перестаёт стоить свеч.
Из новых планов — хочу попробовать попутешествовать без параллельной работы — взять большой отпуск на 2-3 месяца и погрузиться целиком в исследование окружающего мира, а не держать постоянно на фоне релизы и дедлайны.
Хорошая статья, но на мой взгляд тут только половина правды.
Очень точно замечено, что в нашей жизни есть механизм выгорания и он является реальной проблемой для многих, особенно кто работает в сфере интеллектуального труда. Но не раскрыто как работает механизм выгорания, кто и зачем его запускает, и почему для человека так важно сохранять определённый запас внутренней энергии, а не распылять его во внешний мир.
У кого какие мысли по этому поводу?)
Мне тоже Monaco Editor гораздо больше нравится. Недавно перешёл на него с Ace'а в своих проектах, весьма доволен. Но он не настолько популярен пока что как более пожилые CodeMirror и Ace — меньше ссылок и материалов на него. Поэтому многие о нём элементарно могут и не знать)
Интересная разработка с концептуальной точки зрения — получается, что веб-страница может изменять сама себя в реальном времени. Мне нравится) Ещё порадовал многопользовательский режим.
Единственное, на мой взгляд для полноты функционала не хватает функции «Экспортировать», которая собирает 3 куска кода в единую рабочую хтмл-страницу и сохраняет её на диск в работоспособном состоянии. Тогда можно будет поработать над веб-страничкой с коллегами (например, художником и верстальщиком), сэкспортировать её в файл и выложить на свой хостинг без каких-либо промежуточных правок вне редактора правок.
Сейчас если сохранить по отдельности файлы html, css и js, то html в браузере работать не будет — надо будет прописывать ему линки на стили и скрипты. Это не очень удобно.
Классическая последовательность: «Зачем? --> Что? --> Как?»
У автора статьи идёт прямая проекция: Зачем? — это цель; Что? — это структура данных; Как? — это реализация, то есть алгоритм или код.
Но некоторые люди могут действовать только на уровне абстракции «Как?», поэтому для них алгоритм первичен, а структуры данных (не говоря уже о целях) околачиваются где-то на задворках сознания. Может быть, в итоге и получается «некривой» код (по субъективному мнению авторов), но почти всегда он приводит к кривому решению бизнес-задачи. Если вообще что-то решает.
Никто не думает, что хранить информацию в файлах — не лучшая идея? Может отсюда и происходят по факту нерешаемые проблемы с файловыми менеджерами?
Я считаю, что эксперимент сделан в правильном направлении, но фокус сильно рамазан. Можно взять, например, research или r&d отдел технологической компании, где уровень влияния творчества на качество работы достаточно высокий. И срезать рабочий день не на проценты, а в разы. Например, работать 4 дня в неделю, 4 часа в день и с двойной зарплатой. Вот тогда реально можно почувствовать эффект квантового перехода)
Я бы вот даже заморочился, лично открыл контору и поработал в ней так годик-два.
Я думаю, тут важно не сделать шедевр со второй попытки, а каждый раз пытаться сделать шедевр. Кармаку понадобилось 23 попытки, чтобы дойти до Дума. Но если бы он каждый раз хотел сделать что-то заурядное и посредственное, то Дум мы бы не увидели никогда.
Уважаемый, зачем сразу крылья рубить?) Пусть человек попробует сделать шедевр. Мы же не знаем, может быть перед нами новый Кармак рождается.
Есть такие люди — начинающие геймдизайнеры. Они обычно много всего придумывают, но реализовать не могут, потому что программировать — это не их специализация. Обычно хорошие игры делаются в содружества геймдизайнеры и программиста-разработчика.
Можно попробовать найти человека с уже готовой идеей и сделать игру для него. Конечно, если самому эта идея нравится. Может быть, в процессе и своя идея появится)
Мне кажется, автору стоит обратить внимание на режим дня. В разработке игр сложно то, что процесс увлекательный и творческий одновременно. Если делать игру высокого класса, то это ещё и долго. Например, я свою первую коммерческую игру делал 9 месяцев. Если срываться каждый день в авралы и не спать ночами, то за месяц-два можно прийти к невменяемому состоянию, в котором никакого творчества уже невозможно. А если нет творчества, нет элемента искусства, то зачем вообще нужна такая игра?)
Даже взрослых опытных разработчиков часто подводит неумение выдерживать режим дня и режим недели. Я думаю, это первое, чему надо учиться. И чем раньше, тем лучше. Это гораздо проще, чем Java и C#, Unity и UDK, но при этом намного важнее в реальной жизни.
В долгосрочной перспективе очень полезно уметь сдерживать свои творческие порывы — благодаря этому растёт творческий потенциал. И в итоге вместо 20 поделок-однодневок за то же время можно сделать 1-2 шедевра мирового уровня на века)
Я работаю удалённо 7 лет, из них 5 лет непрерывно путешествовал, в основном по Азии. По началу была романтика, постоянно новые места, новые люди, возможность не ограничивать себя местом и временем. Опять же зима без снега) Или наоборот — зима на горнолыжном курорте. Но в итоге новизна прошла и это стало ощущаться как неинтересная рутина. Планирование путешествий — это тоже в итоге весьма непростая работа, которая которая генерирует стресс и имеет свои риски. Оказалось, что я работаю сразу на двух работах, и это напряжно) Я осел в одном месте и оставил себе только одну работу. Жить стало в 2 раза проще.
Я не жалею о времени и силах, потраченных на путешествия. В своё время это было здорово и интересно. Но в какой-то момент это надоедает и игра перестаёт стоить свеч.
Из новых планов — хочу попробовать попутешествовать без параллельной работы — взять большой отпуск на 2-3 месяца и погрузиться целиком в исследование окружающего мира, а не держать постоянно на фоне релизы и дедлайны.
Очень точно замечено, что в нашей жизни есть механизм выгорания и он является реальной проблемой для многих, особенно кто работает в сфере интеллектуального труда. Но не раскрыто как работает механизм выгорания, кто и зачем его запускает, и почему для человека так важно сохранять определённый запас внутренней энергии, а не распылять его во внешний мир.
У кого какие мысли по этому поводу?)
Единственное, на мой взгляд для полноты функционала не хватает функции «Экспортировать», которая собирает 3 куска кода в единую рабочую хтмл-страницу и сохраняет её на диск в работоспособном состоянии. Тогда можно будет поработать над веб-страничкой с коллегами (например, художником и верстальщиком), сэкспортировать её в файл и выложить на свой хостинг без каких-либо промежуточных правок вне редактора правок.
Сейчас если сохранить по отдельности файлы html, css и js, то html в браузере работать не будет — надо будет прописывать ему линки на стили и скрипты. Это не очень удобно.