Имхо, это всё слегка надумано… Более 90% программистов не пишут библиотеки, а те, кто пишет, разберутся с публикацией по официальной документации без проблем.
Всякие обучающие статьи и лабораторки на эту тему не нужны от слова "совсем". Они только стимулируют помойку аля npm.
В этом плане vozhd99 правильно отметил, что хоть в названии статьи указана "дистанционная работа", по факту статья про предпринимательскую деятельность.
Со схемой "работаю по трудовому договору из дома" и так всё понятно, там просто фикс.зарплата за вычетом 13%. Отпуск, праздники, больничные и т.д. — всё оплачивается и на net не влияет.
Для предпринимательства всё по другому, и там net = 0.6 * gross, а не 0.87, но зато gross существенно выше.
Есть разные варианты. Если у Вас обычный рабочий день, только дома, то Вы — дистанционный наёмный сотрудник. Так можно работать с российскими компаниями, а зарубежные Вас в штат брать не будут и оплата будет либо попроектная (для мелких типовых заказов), либо почасовая (только время, потраченное на решение задач).
У патентов есть ограничения в зависимости от региона пребывания.
А в целом Ваш расчёт неплох. Единственное, что Вы забыли — это вынужденный простой, допустим когда один проект закончился, а второй ещё не начался… или даже внутри одного проекта такое бывает… или вообще из-за собственной прокрастинации. Это ещё около 10% в минус. Так что диапазон я бы указал 50-70%, а мат.ожидание: net = 0.6 * gross
И поскольку в России принято указывать именно net-зарплату правильно писать так:
"что соответствует рейту от 30 до 50$/час ($3000-5000 в мес.)" ;-)
Клиент понимает сценарий, разработчики понимают сценарий.
Дальше эти блоки встают в таскменеджер и все едет.
Имхо, это не по ТЗ, это BDD называется :-)
Систему сдали, в эксплуатацию ввели, акты подписали, деньги получили. И тут через полгода пользователи такие решили ее использовать и нашли невыловленные баги.
У вас просто какая-то особая специфика.
Ну а вот выделенный человек он разработчик и сидит вкуривает в старые проекты?
Если понимаете, то должны также понимать что все эти параллели — это медвежья услуга новичкам, ну и соответственно вред всему Elixir-сообществу.
Во-первых, пытаться тащить привычки из Ruby в Elixir — это самый сложный путь.
Тем, кто хочет изучить Elixir, эффективнее всего будет отложить все знания, связанные с Ruby, на отдельную полочку и не вспоминать про них пока программируешь на Elixir.
Во-вторых, библиотеки по кальке скопированные с Ruby только привносят проблемы с пониманием того, как работает Elixir и какова его область применения. Этому надо противостоять по мере сил и поддерживать идиоматичные для Elixir библиотеки.
Также повторюсь, что сейчас проводится чёткая параллель между Elixir и Ruby
Это очень хреновая параллель, т.к. языки не имеют ничего общего, кроме отдалённо похожего синтаксиса и частично совпадающих названий функций в stdlib. По факту Elixir имеет в сотни раз больше общего с Erlang и с Lisp, чем с Ruby.
Хуже параллель проводить только между Phoenix и Rails, там вообще принципиально разная идеология в архитектуру заложена.
Эмм ну у меня мини-этапы подписанные делятся от недели до месяца (иногда до двух).
И Вы их прям как ТЗ детально расписываете? Имхо, какая-то излишняя бюрократия, зря время отнимающая. Но если клиенту нравится такой подход, то ok.
И клиент получает что-то работающее по опыту через неделю-две.
Да, в идеале после каждой итерации. Но как Вы умудряетесь это ассоциировать с разработкой по ТЗ, я честно говоря не улавливаю.
При затыках со стороны клиента есть несколько вариантов: временно перебросить на другой проект или на внутренний проект, либо по согласованию с клиентом занять непродуктовыми задачами, типа оптимизаций и горизонтального масштабирования.
С потоком внезапных, срочных, и важных тикетов на суппорт по прошлым проектам
Т.е. есть проект, по которому разработка уже не ведётся, и вдруг оттуда прилетает поток внезапных, срочных, и важных тикетов? это как вообще? У нас такого не было.
А для мелких доработок по старым проектам есть выделенный человек, он же сортирует тикеты в техподдержку по текущим.
Вы утрируете. Полно случаев, когда можно слегка улучшить код по ходу дела, не меняя его поведения и не разбираясь, как можно/нельзя изменить его поведение. И в любом случае, если Вы хоть как-то измените поведение, то это уже будет не рефакторинг. И лучше это делать отдельным коммитом, когда надо.
Притом что они получают мусор?
Почему мусор? undefined — это вполне рабочее значение в JavaScript. Нравится Вам или нет, но факт в том, что это так.
P.S. Слушайте, я тоже не в восторге от JS и вообще фронтом практически не занимаюсь… но там сам JS-мир слегка сумасшедший, Вы конечно можете старательно огораживаться, не принимая их практики, но смысла мало.
В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".
Как делаете вы, при условии, что клиент не согласен выкупить время например 5-ти разработчиков на непредсказуемое количество дней, пока проект не будет сделан?
Не работаем с ним :-)
Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.
Мне попадался: «Мы не можем ничего согласовать, так как это отрежет нам дорогу к изменениям».
Или: «Мы не можем согласовать, т.к. не знаем как должно быть, но начинать надо сейчас»
Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.
"тут для простоты я использую квадратичный алгоритм — значит, надо убедиться, что большие наборы данных сюда не попадут"
Шикарный пример оптимизации xD
А если серьёзно, то проблема действительно есть… мало программистов задумываются о производительности своего кода, хотя в большинстве случаев это упирается в незнание SQL. Ну и да, иногда попадаются на ревью квадратичные алгоритмы там, где можно было бы обойтись линейным, но это гораздо реже.
Реализация — это не API. API — это описание параметров и результатов. Подкреплённое тестами, в идеале.
И что? В данном случае, единственное описание API — это сам код. Так тоже бывает.
Устраивать рефакторинг не имея представления что ваш фрагмент кода делает и когда он используется — кончается слезьми.
Ну так я и пытаюсь эту мысль донести. Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров.
Ну или не плачьте, когда прод упадёт :-)
Но стараться «сохранить жизнь» программе когда она уже «слетела с катушек»
В чём тут "слёт с катушек"? Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean? Не так уж редко именно это и требуется, вне зависимости от входных параметров. Ваши фантазии на тему неопределённых результатов имхо оффтопик.
Я же утверждаю, что данная функция изначально должна была быть написана по-другому.
На основании чего? Это уже исключительно Ваши домыслы.
Мы обсуждаем варианты переписать существующую функцию, не имея никаких явных требований (есть только те, что заложены в код)… Это рефакторинг в чистом виде и ничто больше.
Вы же мотивируете только тем, что "автор — дурак, потому что я так считаю"… Это непрофессионально и все эти сокращения по факту оказываются дешевыми понтами, если не можешь сократить без изменения поведения кода.
Ну, а что такое рефакторинг? Это улучшение кода без изменения его API. Исходный код всегда возвращает либо true, либо false. Требований у нас нет, значит мы при переписывании кода обязаны подразумевать что такое требование было. И результат итоговой функции должен совпадать с результатом исходной на всём множестве значений аргументов. Мы тут не вдаёмся в причины этого требования, может результат надо было запихнуть в JSON и отправить какому-нибудь микросервису на Go (вот он обрадуется, когда получит "undefined" вместо false).
Но причины требования не суть важны в данном примере, важно, что сохранность API — это базовые основы рефакторинга. И куча людей этого не понимает, что уже печально. Получается, хотели показать как они круты, переделав код из статьи, а по факту опозорились. Но не в силах признать ошибку, предпочитают заминусить… Ну ладно, желаю им профессионального роста. Может через пару лет поймут, что признать ошибку не стыдно, стыдно — не признать )))
Это отличный вариант для строго типизированного языка. При динамической же типизации у вас нет контракта какого типа аргументы придут в функцию. hardWork внезапно может оказаться undefined.
Поэтому как не изголяйтесь, а явное приведение к boolean будьте любезны написать, раз функции требуется возвращать именно true/false. Забыть про это приведение — типичная ошибка новичка.
Кол-во минусов к моему исходному комментарию показывает только то, что есть немало людей, которые пишут код на JavaScript ещё хуже, чем автор статьи. При этом они сами пока об этом не догадываются… недостаток опыта он такой, даёт ложную уверенность в своей неправоте :-)
Это более хрупкий вариант… в текущем JS сработает, а в других языках не получится сравнить 0 и boolean. А это тоже допустимый вариант, если допустим hardWork — boolean, a luck — число от 0 до 10. Так что либо !!, либо явное приведение: return Boolean(isPrepared);
Имхо, это всё слегка надумано… Более 90% программистов не пишут библиотеки, а те, кто пишет, разберутся с публикацией по официальной документации без проблем.
Всякие обучающие статьи и лабораторки на эту тему не нужны от слова "совсем". Они только стимулируют помойку аля npm.
В этом плане vozhd99 правильно отметил, что хоть в названии статьи указана "дистанционная работа", по факту статья про предпринимательскую деятельность.
Со схемой "работаю по трудовому договору из дома" и так всё понятно, там просто фикс.зарплата за вычетом 13%. Отпуск, праздники, больничные и т.д. — всё оплачивается и на net не влияет.
Для предпринимательства всё по другому, и там net = 0.6 * gross, а не 0.87, но зато gross существенно выше.
Может быть. Хотя какой юзкейс у песочницы? Всё равно ведь ничто кроме здравого смысла не остановит от публикации в основной репозиторий пакетов.
Зачем Вы "это" запихнули в hex? Не превращайте его в файлопомойку.
Есть разные варианты. Если у Вас обычный рабочий день, только дома, то Вы — дистанционный наёмный сотрудник. Так можно работать с российскими компаниями, а зарубежные Вас в штат брать не будут и оплата будет либо попроектная (для мелких типовых заказов), либо почасовая (только время, потраченное на решение задач).
У патентов есть ограничения в зависимости от региона пребывания.
А в целом Ваш расчёт неплох. Единственное, что Вы забыли — это вынужденный простой, допустим когда один проект закончился, а второй ещё не начался… или даже внутри одного проекта такое бывает… или вообще из-за собственной прокрастинации. Это ещё около 10% в минус. Так что диапазон я бы указал 50-70%, а мат.ожидание: net = 0.6 * gross
И поскольку в России принято указывать именно net-зарплату правильно писать так:
"что соответствует рейту от 30 до 50$/час ($3000-5000 в мес.)" ;-)
Имхо, это не по ТЗ, это BDD называется :-)
У вас просто какая-то особая специфика.
Программист.
Если понимаете, то должны также понимать что все эти параллели — это медвежья услуга новичкам, ну и соответственно вред всему Elixir-сообществу.
Во-первых, пытаться тащить привычки из Ruby в Elixir — это самый сложный путь.
Тем, кто хочет изучить Elixir, эффективнее всего будет отложить все знания, связанные с Ruby, на отдельную полочку и не вспоминать про них пока программируешь на Elixir.
Во-вторых, библиотеки по кальке скопированные с Ruby только привносят проблемы с пониманием того, как работает Elixir и какова его область применения. Этому надо противостоять по мере сил и поддерживать идиоматичные для Elixir библиотеки.
Это очень хреновая параллель, т.к. языки не имеют ничего общего, кроме отдалённо похожего синтаксиса и частично совпадающих названий функций в stdlib. По факту Elixir имеет в сотни раз больше общего с Erlang и с Lisp, чем с Ruby.
Хуже параллель проводить только между Phoenix и Rails, там вообще принципиально разная идеология в архитектуру заложена.
И Вы их прям как ТЗ детально расписываете? Имхо, какая-то излишняя бюрократия, зря время отнимающая. Но если клиенту нравится такой подход, то ok.
Да, в идеале после каждой итерации. Но как Вы умудряетесь это ассоциировать с разработкой по ТЗ, я честно говоря не улавливаю.
При затыках со стороны клиента есть несколько вариантов: временно перебросить на другой проект или на внутренний проект, либо по согласованию с клиентом занять непродуктовыми задачами, типа оптимизаций и горизонтального масштабирования.
Т.е. есть проект, по которому разработка уже не ведётся, и вдруг оттуда прилетает поток внезапных, срочных, и важных тикетов? это как вообще? У нас такого не было.
А для мелких доработок по старым проектам есть выделенный человек, он же сортирует тикеты в техподдержку по текущим.
Вы утрируете. Полно случаев, когда можно слегка улучшить код по ходу дела, не меняя его поведения и не разбираясь, как можно/нельзя изменить его поведение. И в любом случае, если Вы хоть как-то измените поведение, то это уже будет не рефакторинг. И лучше это делать отдельным коммитом, когда надо.
Почему мусор? undefined — это вполне рабочее значение в JavaScript. Нравится Вам или нет, но факт в том, что это так.
P.S. Слушайте, я тоже не в восторге от JS и вообще фронтом практически не занимаюсь… но там сам JS-мир слегка сумасшедший, Вы конечно можете старательно огораживаться, не принимая их практики, но смысла мало.
В моём понимании ТЗ — это официальный документ, подписанный с двух сторон, с описанием в том числе и мелких деталей. План итерации — это скорее неподписанный каркас для "мини-ТЗ".
Не работаем с ним :-)
Тут в принципе выбор: либо вы работаете по водопаду (и сами себе буратино), либо штампуете типовые проектики, либо у вас неизвестный бюджет и сроки. Можно давать клиенту пробный период 2-3 месяца, если он раньше не работал по такой схеме, прежде чем какие-то долгосрочные договора заключать.
Важно, что при Agile вы должны даже за этот короткий срок выдать что-то работающее. Имхо, абсолютная противоположность ТЗ-подходу.
Слова Agile, Scrum, Kanban и т.д. летят из каждого утюга уже лет 7… Как они смогли пролететь мимо Вас?
Это всё именно для таких заказчиков и придумано. Можно конечно условно сказать, что у вас есть некое подобие ТЗ на ближайшие 2 недели, но по факту это явно пункт "работаю без ТЗ", т.к. ТЗ на весь проект не пишется.
Шикарный пример оптимизации xD
А если серьёзно, то проблема действительно есть… мало программистов задумываются о производительности своего кода, хотя в большинстве случаев это упирается в незнание SQL. Ну и да, иногда попадаются на ревью квадратичные алгоритмы там, где можно было бы обойтись линейным, но это гораздо реже.
И что? В данном случае, единственное описание API — это сам код. Так тоже бывает.
Ну так я и пытаюсь эту мысль донести. Если делаете рефакторинг без явных требований, то не меняйте соответствие между входными параметрами и результатом для всего множества входных параметров.
Ну или не плачьте, когда прод упадёт :-)
В чём тут "слёт с катушек"? Вы ни разу в жизни не писали функций, которые должны строго возвращать boolean? Не так уж редко именно это и требуется, вне зависимости от входных параметров. Ваши фантазии на тему неопределённых результатов имхо оффтопик.
На основании чего? Это уже исключительно Ваши домыслы.
Мы обсуждаем варианты переписать существующую функцию, не имея никаких явных требований (есть только те, что заложены в код)… Это рефакторинг в чистом виде и ничто больше.
Вы же мотивируете только тем, что "автор — дурак, потому что я так считаю"… Это непрофессионально и все эти сокращения по факту оказываются дешевыми понтами, если не можешь сократить без изменения поведения кода.
Ну, а что такое рефакторинг? Это улучшение кода без изменения его API. Исходный код всегда возвращает либо true, либо false. Требований у нас нет, значит мы при переписывании кода обязаны подразумевать что такое требование было. И результат итоговой функции должен совпадать с результатом исходной на всём множестве значений аргументов. Мы тут не вдаёмся в причины этого требования, может результат надо было запихнуть в JSON и отправить какому-нибудь микросервису на Go (вот он обрадуется, когда получит "undefined" вместо false).
Но причины требования не суть важны в данном примере, важно, что сохранность API — это базовые основы рефакторинга. И куча людей этого не понимает, что уже печально. Получается, хотели показать как они круты, переделав код из статьи, а по факту опозорились. Но не в силах признать ошибку, предпочитают заминусить… Ну ладно, желаю им профессионального роста. Может через пару лет поймут, что признать ошибку не стыдно, стыдно — не признать )))
Это отличный вариант для строго типизированного языка. При динамической же типизации у вас нет контракта какого типа аргументы придут в функцию. hardWork внезапно может оказаться undefined.
Поэтому как не изголяйтесь, а явное приведение к boolean будьте любезны написать, раз функции требуется возвращать именно true/false. Забыть про это приведение — типичная ошибка новичка.
Кол-во минусов к моему исходному комментарию показывает только то, что есть немало людей, которые пишут код на JavaScript ещё хуже, чем автор статьи. При этом они сами пока об этом не догадываются… недостаток опыта он такой, даёт ложную уверенность в своей неправоте :-)
Это более хрупкий вариант… в текущем JS сработает, а в других языках не получится сравнить 0 и boolean. А это тоже допустимый вариант, если допустим hardWork — boolean, a luck — число от 0 до 10. Так что либо !!, либо явное приведение:
return Boolean(isPrepared);Тогда уж
Только стоит ли сокращать эту запись, если как минимум 6 шутников в комментариях сократили её некорректно? Вопрос далеко неоднозначный.