В Mass Effect не играл, но наслышан. Боюсь, что захейтили его далеко не только за баги.
Контр-пример: TES. Сколько уж там багов, а люди все равно всем сердцем любят эту серию.
Второй пример - это Cyberpunk. Сколько его критиковали на старте. Но ничего, через пару лет подлатали дыры, и игру любят и покупают.
Но не это главное. Главное, что разработка игр - это всегда огромное количество экспериментов по игровым механикам. Львиная доля этих экспериментов потом выпиливается из релиза. То есть, огромное количество кода просто выбрасывается на помойку. Именно в таких случаях подход "сделал на коленке, потом допилил до удовлетворительного состояния" очень хорошо себя показывает.
Добро пожаловать в реальный мир, где проект может вообще не взлететь, и все потраченные ресурсы будут выброшены.
Добро пожаловать в реальный мир, где проект может измениться до такой степени, что написанный код просто выкинется или станет неузнаваемым.
В такой изменчивой среде делать преждевременные оптимизации - это через чур оптимистично. Если вдруг окажется, что код прижился и такая же логика понадобится в других местах - тогда и реализовывать переиспользуемое решение.
Все деньги заработает тот, кто первый выставит продукт на рынок, а не тот, кто заложит лучшую архитектуру
Ощущение, что прочел статью, сгенерированную нейросетью. Вроде общий смысл улавливается, но предложения как-то слабо связаны друг с другом.
По теме автоматизации: был у меня знакомый, для которого идеальная работа - наматывать проволоку на катушки. Без стремлений, без амбиций, без желания что-то привнести в мир. Вы мне платите копеечку, а я буду проволоку наматывать. Идеальный биоробот. А роботов, случается, заменяют на более совершенные модели.
Автолевелинг там только на случайных монстрах. Но статично прописанные НПЦ там не скейлятся вместе с игроком. Именно поэтому однажды приходит приятное осознание, что теперь, наконец, ты можешь прикончить Умбру или Дивайта Фира)
По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия
Везде засветился тот же Пименов, но это не удивительно, он один из главных евангелистов канбана в России.
Если есть много времени и хочется углубиться больше, то книга создателя канбана Дэвида Андерсена "Альтернативный Путь в Аджайл", хотя она уже довольно устарела.
И, конечно, ссылка от товарища Apathetic.
Тут надо отметить, что информация о канбане от ресурса к ресурсу разнится. Это связано с тем, что канбан очень живой и постоянно эволюционирует. А в русском сегменте это усугубляется часто неправильными переводами и, следовательно, неверным пониманием некоторых моментов
А это, видимо, потому что никто эти процессы не любит соблюдать. Вот и получается либо недоскрам, либо полуканбан, либо вообще канбарам.
Понятия "полуканбан" быть не может. Частичный канбан - это уже канбан (в отличие от скрама, где частичный скрам не является скрамом совсем). Это обусловлено оной из ценностей канбана - эволюционные изменения.
А так, судя по статье, скрам - это когда есть спринты с атомарными фичами и релизами, а канбан - это когда нет спринтов и релизов, а есть постоянные допиливания-улучшения по мере готовности.
Из статьи действительно может сложиться это ложное впечатление. В реальности же, сравнивать канбан и скрам нет смысла, потому что это то же самое, что сравнивать понедельник с Хондой. Скрам - это процессный фреймворк, заданный набор жестких правил. Канбан - это метод эволюционного изменения процессов с набором рекомендаций. Релизы в канбане очень даже могут быть, у канбана даже одна из каденций - Встреча по планированию поставки. Спринты - вопрос терминологии: если по канбану у нас встречи по наполнению очереди раз в две недели, и очередь наполняется на две недели вперед, то как раз получаются те же двухнедельные спринты.
Вообще в статье есть довольно спорные заявления, например
Канбан не заботится о времени
Либо я не так понял посыл, либо это неверное заявление. В канбане есть даже два классических класса обслуживания, намекающих на большой заболе о времени: ускоренный и с фиксированной датой поставки
В Канбане нет конкретных размеров команд или должностей
частично верное заявление. Должностей действительно нет, но есть роли, о чем можно было бы и упомянуть.
Не понимаю, как можно пользоваться Хромом после Вивальди или, хотя бы, Лисы) Хром — это просто просматривалка сайтов, в которой совершенно никакого нужного функционала нет, и плагинами этот функционал набить невозможно
Заставлять на собеседовании писать код — не самый лучший способ протестировать кандидата: сеньора и мидла так за полчаса-час не проверить, а джуниор может просто не справиться с задачей из-за малой компетенции. При этом человек может быть реально очень смышленым.
Насколько разработчик потенциально хорош, можно выяснить в беседе.
А то, что разработчики вставали на плато — так это в основном вопрос качественного наставничества и обучения сотрудника. Берите не знающих, а смышленых, и качественно их обучайте
У меня панель вкладок слева, и сверху тоже есть ненужная плашка с кнопкой меню, заголовком и тремя кнопками управления окном. Было бы здорово, если бы эту панель можно было скрывать.
А как ООО получает деньги от инвестора? Вот например договорились, что инвестор инвестирует 1млн рублей. При этом он вносит 10к рублей в уставный капитал и получает 50% компании. Остальные 990к проводятся каким типом операции? Считается ли приход инвесторских денег доходом и облагается ли налогом на прибыль?
Можно ли тратить уставный капитал, если он внесен в деньгах?
Как лучше вносить деньги в ООО? Например, я единственный учредитель. Фирме нужны финансы, и я, как физ. лицо, хочу внести на счет фирмы свои личные деньги. Как лучше проводить эту операцию? Как дарение, или, может быть, как кредит с неограниченным сроком возврата?
Проект развивается, кодовая база увеличивается. Я про это и говорил, что проект либо умирает, либо растет. Вы писали, что такие инвестиции могут не окупиться. но они всегда окупаются, когда проект дорастает до определенного уровня.
А можно вот тоже пример из вашего опыта, когда это выделение типа исключения на каждый чих дает профит и почему это сложнее было сделать методом рефакторинга существующего кода с общим исключением?
Пример: исключения логируются. Я знаю, что скрипт падает из-за проблем с внешним сервисом, но не знаю, из-за чего конкретно. Все исключения в скрипте базового типа. Я мог бы легко найти в логе все ошибки, связанные с внешним сервисом, если бы у них был отдельный тип, но увы. Приходится эмпирически искать по сообщению исключения.
Кстати, а вы не задумывались, что описанный подход как раз таки уместен в переиспользуемых библиотеках/фреймворках и несколько избыточен для большинства (не говорю про все) конечных проектов?
Он уместен всегда, поскольку практически не требует усилий и работы мозга. При этом профита дает много.
А как же нишевые проекты, коих большинство и которые живут себе припеваючи, покрыты автотестами и вполне себе поддерживаются и развиваются без сферических абстракций в вакууме?
Можно пример?
Вы думаете если вы напишете идеальный код и напичкаете его точками расширений, то проект из интернет-магазинчика вырастет до уровня Яндекса или Гугла ?)
Я не совсем верно выразился. Под крупными проектами я подразумевал проекты с большой кодовой базой, а не большой аудиторией.
Интернет-магазины, обычно, либо на SaaS, либо CMS, и поддержка и расширение лежат, в большинстве своем, на разработчиках ядра.
То есть вы перехватываете исключение общего вида (\PDOException) и вводите свое исключение общего вида DataBaseException. Какой в этом смысл? Чем DataBaseException лучше \PDOException? Даже Query из него не вытащить же.
Смысл в том, что на верхнем уровне нам не интересно, какой драйвер и какая библиотека используется для работы с БД (это может быть PDO или, например, mysqli). Нам важно только, что произошла исключительная ситуация при работе с БД. А чтобы вытащить query, стоит пробрасывать предыдущее исключение в новое.
Эта инвестиция может и не окупиться со временем с большой вероятностью, все зависит от проекта
Обычно либо проект умирает на ранней стадии, либо развивается до очень крупного. Или, третий вариант, проект настолько плохо написан, что его никто не хочет дорабатывать, и он так и остается маленьким и уродливым легаси.
В Mass Effect не играл, но наслышан. Боюсь, что захейтили его далеко не только за баги.
Контр-пример: TES. Сколько уж там багов, а люди все равно всем сердцем любят эту серию.
Второй пример - это Cyberpunk. Сколько его критиковали на старте. Но ничего, через пару лет подлатали дыры, и игру любят и покупают.
Но не это главное. Главное, что разработка игр - это всегда огромное количество экспериментов по игровым механикам. Львиная доля этих экспериментов потом выпиливается из релиза. То есть, огромное количество кода просто выбрасывается на помойку. Именно в таких случаях подход "сделал на коленке, потом допилил до удовлетворительного состояния" очень хорошо себя показывает.
Добро пожаловать в реальный мир, где проект может вообще не взлететь, и все потраченные ресурсы будут выброшены.
Добро пожаловать в реальный мир, где проект может измениться до такой степени, что написанный код просто выкинется или станет неузнаваемым.
В такой изменчивой среде делать преждевременные оптимизации - это через чур оптимистично. Если вдруг окажется, что код прижился и такая же логика понадобится в других местах - тогда и реализовывать переиспользуемое решение.
Все деньги заработает тот, кто первый выставит продукт на рынок, а не тот, кто заложит лучшую архитектуру
Ощущение, что прочел статью, сгенерированную нейросетью. Вроде общий смысл улавливается, но предложения как-то слабо связаны друг с другом.
По теме автоматизации: был у меня знакомый, для которого идеальная работа - наматывать проволоку на катушки. Без стремлений, без амбиций, без желания что-то привнести в мир. Вы мне платите копеечку, а я буду проволоку наматывать. Идеальный биоробот. А роботов, случается, заменяют на более совершенные модели.
Black Mesa вообще отличная. Но ее и делали фанаты HL1, олдскульщики
Автолевелинг там только на случайных монстрах. Но статично прописанные НПЦ там не скейлятся вместе с игроком. Именно поэтому однажды приходит приятное осознание, что теперь, наконец, ты можешь прикончить Умбру или Дивайта Фира)
По мне так это все словоблудие. Разработчик просто более широкое понятие, так как разрабатывать можно не только ПО, но и, например, месторождения полезных ископаемых или прототип автомобиля. Но в IT-среде разработчик и программист - тождественные понятия
У вас интересный опыт, но странные выводы: негативное отношение к Аджайлу, когда в вашей фирме его толком и не было.
Если мошенник продаст вам фейковый Айфон, ругаться из-за низкого качества вы будете на Эппл?
Какая милая наивность)
Алексей Пименов хорошо рассказывает про канбан, можно поискать его материалы.
Несколько хороших статей можно найти на https://scrumtrek.ru/blog/kanban/, можно начать с https://scrumtrek.ru/blog/kanban/1360/chto-takoe-kanban-metod-maksimalno-korotko/, чтобы получить первое представление.
В Яндекс.Музыке есть годный подкаст Kanban Talks.
Везде засветился тот же Пименов, но это не удивительно, он один из главных евангелистов канбана в России.
Если есть много времени и хочется углубиться больше, то книга создателя канбана Дэвида Андерсена "Альтернативный Путь в Аджайл", хотя она уже довольно устарела.
И, конечно, ссылка от товарища Apathetic.
Тут надо отметить, что информация о канбане от ресурса к ресурсу разнится. Это связано с тем, что канбан очень живой и постоянно эволюционирует. А в русском сегменте это усугубляется часто неправильными переводами и, следовательно, неверным пониманием некоторых моментов
Понятия "полуканбан" быть не может. Частичный канбан - это уже канбан (в отличие от скрама, где частичный скрам не является скрамом совсем). Это обусловлено оной из ценностей канбана - эволюционные изменения.
Из статьи действительно может сложиться это ложное впечатление. В реальности же, сравнивать канбан и скрам нет смысла, потому что это то же самое, что сравнивать понедельник с Хондой. Скрам - это процессный фреймворк, заданный набор жестких правил. Канбан - это метод эволюционного изменения процессов с набором рекомендаций. Релизы в канбане очень даже могут быть, у канбана даже одна из каденций - Встреча по планированию поставки. Спринты - вопрос терминологии: если по канбану у нас встречи по наполнению очереди раз в две недели, и очередь наполняется на две недели вперед, то как раз получаются те же двухнедельные спринты.
Вообще в статье есть довольно спорные заявления, например
Либо я не так понял посыл, либо это неверное заявление. В канбане есть даже два классических класса обслуживания, намекающих на большой заболе о времени: ускоренный и с фиксированной датой поставки
частично верное заявление. Должностей действительно нет, но есть роли, о чем можно было бы и упомянуть.
В общем, к статье довольно много вопросов.
Насколько разработчик потенциально хорош, можно выяснить в беседе.
А то, что разработчики вставали на плато — так это в основном вопрос качественного наставничества и обучения сотрудника. Берите не знающих, а смышленых, и качественно их обучайте
У меня панель вкладок слева, и сверху тоже есть ненужная плашка с кнопкой меню, заголовком и тремя кнопками управления окном. Было бы здорово, если бы эту панель можно было скрывать.
Можно ли тратить уставный капитал, если он внесен в деньгах?
Как лучше вносить деньги в ООО? Например, я единственный учредитель. Фирме нужны финансы, и я, как физ. лицо, хочу внести на счет фирмы свои личные деньги. Как лучше проводить эту операцию? Как дарение, или, может быть, как кредит с неограниченным сроком возврата?
Проект развивается, кодовая база увеличивается. Я про это и говорил, что проект либо умирает, либо растет. Вы писали, что такие инвестиции могут не окупиться. но они всегда окупаются, когда проект дорастает до определенного уровня.
Пример: исключения логируются. Я знаю, что скрипт падает из-за проблем с внешним сервисом, но не знаю, из-за чего конкретно. Все исключения в скрипте базового типа. Я мог бы легко найти в логе все ошибки, связанные с внешним сервисом, если бы у них был отдельный тип, но увы. Приходится эмпирически искать по сообщению исключения.
Он уместен всегда, поскольку практически не требует усилий и работы мозга. При этом профита дает много.
Можно пример?
Я не совсем верно выразился. Под крупными проектами я подразумевал проекты с большой кодовой базой, а не большой аудиторией.
Интернет-магазины, обычно, либо на SaaS, либо CMS, и поддержка и расширение лежат, в большинстве своем, на разработчиках ядра.
Смысл в том, что на верхнем уровне нам не интересно, какой драйвер и какая библиотека используется для работы с БД (это может быть PDO или, например, mysqli). Нам важно только, что произошла исключительная ситуация при работе с БД. А чтобы вытащить query, стоит пробрасывать предыдущее исключение в новое.
Обычно либо проект умирает на ранней стадии, либо развивается до очень крупного. Или, третий вариант, проект настолько плохо написан, что его никто не хочет дорабатывать, и он так и остается маленьким и уродливым легаси.