Для того чтобы кодить условное приложение для атомных электростанций, самолётов МС-21 и даже кодить приложения эксплуотируемые в банке России и прочее - жизненно важно высшее образование и математическая база.
Для того, чтобы кодить исключительно мобильные приложения или фронтенд - можно ограничится только опытом, но высшее образование будет плюсом.
При любом раскладе высшее образование будет плюсом, а набираться опыта после пар никто не запрещает.
Принцип единственной ответственности (single responsibility principle): Модуль должен отвечать за одного и только за одного актора это подметил Р. Мартин в книге «Чистая архитектура. Искусство разработки программного обеспечения», когда описывал эволюцию данного определения.
Каждый класс должен отвечать только за одну зону ответственности (действий), чтобы его было проще дополнять и менять.
Верная трактовка:
The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor."
ИП и ГПХ могут перевести в штат и все дела. В последнее время налоговая ведёт работу с компаниями которые сотрудничают с ИП, ГПХ, СЗ. Дальше будет жёстче.
Есть компании которые работают по классическом Agile. Однако эти компании высокоэффективные, у них заказов на 200 лет вперед и им некогда разговоры разговаривать.
На CodeReview как правило не видно насколько качественна логика решения задачи, только CodeStyle. А если джуны не уступают по коду мидлам, тогда почему они джуны, а не мидлы. Но вы наверное проверили свое решение и верите в него...
Качество оценки срока разработки для задачи, у среднестатистического разработчика, в среднестатистическом проекте, в среднестатистической компании, зависит от того, насколько хорошо было создано описание задачи, от полноты разъяснения всего что необходимо сделать и от понимания кода предметной области в коде проекта. В идеальных условиях эстимэйт точен, если менеджер лукавый и хочет заработать на разработчике лишний миллион - он сделает описание похуже, задачу даст разработчику который в этой части код видит впервые. В таком случае разработчик вероятнее всего ошибется в эстимэйте, а последствия зависят от корпоративной культуры...
Прокачать скил точного эстимэйт невозможно! Только точное, подробное описание задачи и знание кода даст возможность точного эстимэйта.
Подход оценки в абстрактных единицах сложности описанный в книге Чистый Агайл предполагает переход к планированию поставки фич проекта в прод спустя некоторое время необходимое для сбора статистики работы команды. Собрав статистику сколько стори поинтов команда делает за спринт, можно планировать достаточно точно, сколько команда сделает за месяц или квартал. И что стоит отметить, планирование в этом случае будет честным, без нагрева и без срыва сроков.
Каждый сам выбирает что лучше использовать...
Что касается использования гугл докс: намного проще для разработчиков запилить на условном PHP, веб страницу для индивидуальной оценки задач и формирование сводной таблицы за 2 дня и не париться с гугл доком.
Очевидно что эта методология была придумана для масштабирования производства решений и сокращений затрат. Возможно в этих рамках все работает. Единственный вопрос это качество и поддерживаемость кода и поддержка масштабирования приложения ведь основной штат кодеров это джуны или дешёвые stable разработчики.
Мне не понятно почему все права принадлежат компании, а у работника прав кот наплакал. Логично когда и компания и работодатель обладают равными правами, где каждый имеет права сменить работу/работника. Как у компании могут быть ошибки найма, так и у сотрудника могут быть ошибки выбора компании и т.д. Но важно отметить: если в трудовых отношениях синергия не случилась смысла продолжать отношения нет. Разошлись и каждый ищет лучшую жизнь.
В дополнение к прогреву Лида и переводу его в клиента также целесообразно использовать инструменты удержания клиента прогревая его к следующей покупке на новом уровне!
П.С. люди боятся что дельные кометы распространятся по миру и их псевдоуникальность растаит и поэтому минусуют. Видел я все ваши минусы...
В нашей песочнице строителей немного, но идея греть лидов хорошая! Если кто занимается бизнесом серьёзно и намерен играть в долгую - греть лидов будет хорошей идеей.
Но it это не стройка, то что работает в стройке не будет работать в it, для it нужны другие подходы.
КПИ и деньги это про манагеров. Работа с кафка и рэббитом это про программистов. Программистов берут для того, чтобы они написали код скомпилированный в приложение. Этого достаточно. За остальное, а именно как код превратить в деньги - этим занимаются манагеры. Поэтому если вы говорите про КПИ нанимая программиста - вам ред флаг. Говорите про технологии, код и процессы - вам грин флаг. По другому продуктивного сотрудничества не выйдет.
Для того чтобы кодить условное приложение для атомных электростанций, самолётов МС-21 и даже кодить приложения эксплуотируемые в банке России и прочее - жизненно важно высшее образование и математическая база.
Для того, чтобы кодить исключительно мобильные приложения или фронтенд - можно ограничится только опытом, но высшее образование будет плюсом.
При любом раскладе высшее образование будет плюсом, а набираться опыта после пар никто не запрещает.
Принцип единственной ответственности (single responsibility principle): Модуль должен отвечать за одного и только за одного актора это подметил Р. Мартин в книге «Чистая архитектура. Искусство разработки программного обеспечения», когда описывал эволюцию данного определения.
30К на маркетинг как-то тоскливо. Что можно продать при таких расходах?! Сегодня для нормальных продаж 150К+ нужно.
Неверная трактовка:
Верная трактовка:
The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor."
ИП и ГПХ могут перевести в штат и все дела. В последнее время налоговая ведёт работу с компаниями которые сотрудничают с ИП, ГПХ, СЗ. Дальше будет жёстче.
Есть компании которые работают по классическом Agile. Однако эти компании высокоэффективные, у них заказов на 200 лет вперед и им некогда разговоры разговаривать.
Интересно там у вас, в Звук-е!
Для адекватной, точной оценки важно полное описание описание + знание кода проекта.
На CodeReview как правило не видно насколько качественна логика решения задачи, только CodeStyle. А если джуны не уступают по коду мидлам, тогда почему они джуны, а не мидлы. Но вы наверное проверили свое решение и верите в него...
Качество оценки срока разработки для задачи, у среднестатистического разработчика, в среднестатистическом проекте, в среднестатистической компании, зависит от того, насколько хорошо было создано описание задачи, от полноты разъяснения всего что необходимо сделать и от понимания кода предметной области в коде проекта. В идеальных условиях эстимэйт точен, если менеджер лукавый и хочет заработать на разработчике лишний миллион - он сделает описание похуже, задачу даст разработчику который в этой части код видит впервые. В таком случае разработчик вероятнее всего ошибется в эстимэйте, а последствия зависят от корпоративной культуры...
Прокачать скил точного эстимэйт невозможно! Только точное, подробное описание задачи и знание кода даст возможность точного эстимэйта.
Подход оценки в абстрактных единицах сложности описанный в книге Чистый Агайл предполагает переход к планированию поставки фич проекта в прод спустя некоторое время необходимое для сбора статистики работы команды. Собрав статистику сколько стори поинтов команда делает за спринт, можно планировать достаточно точно, сколько команда сделает за месяц или квартал. И что стоит отметить, планирование в этом случае будет честным, без нагрева и без срыва сроков.
Каждый сам выбирает что лучше использовать...
Что касается использования гугл докс: намного проще для разработчиков запилить на условном PHP, веб страницу для индивидуальной оценки задач и формирование сводной таблицы за 2 дня и не париться с гугл доком.
Очевидно что эта методология была придумана для масштабирования производства решений и сокращений затрат. Возможно в этих рамках все работает. Единственный вопрос это качество и поддерживаемость кода и поддержка масштабирования приложения ведь основной штат кодеров это джуны или дешёвые stable разработчики.
Есть интересная книга "Чистый Agile". Рекомендую!
Мне не понятно почему все права принадлежат компании, а у работника прав кот наплакал. Логично когда и компания и работодатель обладают равными правами, где каждый имеет права сменить работу/работника. Как у компании могут быть ошибки найма, так и у сотрудника могут быть ошибки выбора компании и т.д. Но важно отметить: если в трудовых отношениях синергия не случилась смысла продолжать отношения нет. Разошлись и каждый ищет лучшую жизнь.
В дополнение к прогреву Лида и переводу его в клиента также целесообразно использовать инструменты удержания клиента прогревая его к следующей покупке на новом уровне!
П.С. люди боятся что дельные кометы распространятся по миру и их псевдоуникальность растаит и поэтому минусуют. Видел я все ваши минусы...
Турбо Паскаль 7.0 имеет встроенные возможности ООП включая виртуальные функции которых нет во многих яп.
Но я считаю что сегодня Паскаль не самый подходящий яп для начала изучения программирования.
В нашей песочнице строителей немного, но идея греть лидов хорошая! Если кто занимается бизнесом серьёзно и намерен играть в долгую - греть лидов будет хорошей идеей.
Но it это не стройка, то что работает в стройке не будет работать в it, для it нужны другие подходы.
naznachitAvtoraDlyaKnigi (шутка) !!! ?
Если это рабочая идея военного предназначения, почему о ней пишут в открытом доступе в интернете?
КПИ и деньги это про манагеров. Работа с кафка и рэббитом это про программистов. Программистов берут для того, чтобы они написали код скомпилированный в приложение. Этого достаточно. За остальное, а именно как код превратить в деньги - этим занимаются манагеры. Поэтому если вы говорите про КПИ нанимая программиста - вам ред флаг. Говорите про технологии, код и процессы - вам грин флаг. По другому продуктивного сотрудничества не выйдет.
Чем больше корабль, тем сложнее его поворачивать.