Я считаю, что в начале должна следовать простая реализация, и лишь по прошествию времени, когда вы лучше поймете задачу и взаимодействие ее элементов, вы сами сможете увидеть повторяющиеся структуры и выделить правильные абстракции и интерфейсы.
В этом есть доля правды, когда фичу надо сделать быстро, то архитектурный вопрос можно отложить на потом, НО, скорее всего, это выйдет дороже, чем сделать сразу.
Проектирование в UML диаграммах, достаточно бестолковое занятие, так как я не вижу никаких преимуществ перед непосредственным написанием кода, а скорее недостатки, так как код ты можешь запускать и проверять, а работу UML диаграмм можно лишь представлять в голове.
Этот абзац, как и заголовок не отражает истину - надо мыслить абстракциями, тогда интерфейсы придут сами собой, т.е. продумываем какие модули нам нужны, как они будут взаимодействовать друг с другом. Т.е. на диаграммах можно описать абстракции (контракты), на их основании уже будет проверяться рабочая и удобная ли эта схема. Потом уже переходит в реализацию. Т.е. бежать сразу кодить интерфейсы плохо, сначала нужно продумать все реализацию и продумать взаимодействие, после этого все станет на свои места.
Закон о праве на ремонт поставит под угрозу интеллектуальную собственность компаний и приведет к негативным последствиям для потребителей из-за ненадлежаще выполненных работ, уверены в MarketWatch.
Директор по исследованиям Forrester Гленн О'Доннелл считает, что исполнение закона о ремонте затрудняется технической сложностью современных устройств. По его мнению, некоторые компоненты даже не стоит пытаться ремонтировать самостоятельно.
Имхо, это не их ума дело, хочет владелец чинить не у официалов, его право, а не то "вам плохо сделают, потому мы запчасти никому не дадим, чините только у официалов"
@Boomburumпривет, а фичу эту постепенно включаете? Сижу на бета-версии, появилось только плюсование в карму пользователей, для комментов и публикаций нет
Мне всегда было интересно, вот как им дата рождения поможет, паспорт никто не требует, значит вбить левую дату никто не мешает. Как все пользовались, так и будут.
У меня сейчас Ubuntu 20.04 и видеокарта ASUS GeForce GTX 1660 Ti STRIX - проблем нет, на 18 было - по умолчанию не было драйверов под Nvidia, на разрешении 800 на 600 ставил их.
Я конечно могу показаться занудой, но у вас пример в статье - ноутбук и мак, что явно не декстоп. Справедливости ради, вам стоит так же попробовать установить Linux на обычный PC.
Сейчас проблемы редки, но бывают, это скорее я описал опыт последних 2-3 лет, что косяков было много. Стабильнее всего работало совместно с Windows 7, а вот в 18 году переход на Windows 10 стоил огромной боли. Это как раз в то время диски в Ubuntu в целом работали readonly, т.к. Windows для обеспечения какой-то там быстродейственности внутри себя запихивал свои системные конфиги на всех диски (даже если это другие физические диски, не связанные с Ц). Вот это как раз решилось гуглежом на пару часов и отключением в реестре.
С Linux все стабильно, как швейцарские часы и быстрые обновления.
У меня так же, не было ни одной ситуации, чтобы обновление Ubuntu мне что-то сломали, а вот на маке, я уже давно перестал ставить обновления и боюсь их как огня, каждый апдейт что-то ломал и приходилось уйму времени тратить на латание дыр
Последние 8 лет пользуюсь Ubuntu как основной OC на декстопе, начиная с 14 и сейчас на 20.04, не решаемых проблем сходу - не вспомню, иногда приходилось пошаманить, но в целом полет отличный, причем сейчас у меня AMD (Ryzen 5 3600) проц и NVIDIA видяха (GTX 1660 Ti). Причем до этого много пользовался именно радеоноскими картами, с их драйверами больше приколов было (на версии 18 и ниже), в 20 комп из коробки взял и поехал.
У меня скорее больше проблем из-за второй ОСи - Windows 10, которая ой как любит ломать (особенно апдейтами) работу с Ubuntu - то диски в ридонли перейдут, то из-за апдейта винды звук пропадет - обычно все чинится ребутом назад в винду, завершение работы апдейтера и за крайнем случаем что-то поменять в реестре винды.
В ежедневной работе я постоянно пользуюсь macbook pro, и честно, Ubuntu в разы лучше работает, чем то же мак, если сравнивать стабильность в работе с обновлениями, и как часто приходится латать какие-то проблемы, то Ubuntu значительно выигрывает у мака.
PS: Кстати, после долгких лет родителям вместо винды поставил Ubuntu 20.04, за последний год с копейками ни разу не приходилось что-то чинить, а вот в случае работы с виндой, каждые пару месяцев что-то ломалось
Сотрдуники это обычная прислуга которая обязана выполнять задачи которые им дают. Пропала необходимость — уволили и все, никто им ничего не должен и не обязан.
Прислуга? Им никто ничего не должен? А почему они тогда кому-то что-то должны? Вы явно путаете понятия "наемный работник" и "раб"
Тесты пишет другой человек для того чтобы "глаза не были замылены". Не критикую, но обычно так получается если разработчик за собой (до или после - не важно) пишет тесты, то он покрывает только те сценарии в которых уверен :)
Согласен, есть такая проблема, мы ее от части решаем обязательным 100% покрытием всех модулей, которые затрагиваются в рамках задачи, это конечно не гарантирует покрытие всех сценариев, но хотя бы самые тривиальные ошибки закрывает.
QA тесты пишет, но они пишут интеграционные тесты. А Unit-тестирование на плечах разработчиков.
А QA тесты вы запускаете в момент билда в прод или совместно с unit тестами, пока задача еще в разработке? У нас разработчики пишут и интеграционные тесты тоже, которые гоняются на каждый коммит в GitLab, а QA тесты запускаются на реальных данных при сборке релиза.
Бывает на бумаге всё красиво и чино, а начинаешь писать клиентский код (тест) и понимаешь, что не удобно, или непривычно и программист делает неожиданные логические ошибки и т.д.
Тоже с таким сталкивались.
У нас проектирование немного в другой последовательности. Мы документацию сразу не пишем. То, что имеем сразу - это OpenApi сгенерированную спецификацию. Если подход "стреляет" и мы его фиксируем (а это уже итерация стабилизации) - вот тогда пишется полноценная документация.
Мы раньше тоже после реализации писали, но решили поменять подход, во первых чтобы сразу на этапе проектирования можно было увидеть конечный результат и описать, как это работае, а во вторых, чтобы представить описание API его клиента и получить от них фитбек, все ли их устраивает
В моей практике на самом деле и тесты и код решения пишутся одновременно, но разными людьми. В параллель.
А с какой целью вы параллелите тесты и разработку? Ведь это вполне можно делать силами одного разработчика и тогда вы не тратите х2 времени 2-х программистов или у вас тесты пишет QA отдел?
Тесты пишутся быстрее - они становятся каркасом API решения. И на этом моменте они отлично проверяют архитектуру и на то, на сколько этим API будет в итоге удобно пользоваться.
Не хочу показаться занудой, но удобство пользования API лучше проверить на этапе анализа и проектирования самого API, чем в момент написания тестов. Да, бывает такое, что в момент реализации могут обнаружится некоторые тонкости и доработка базовой структуры (если в ходе задачи что-то пришлось переосмыслить).
Все проекты, что делал по такому подходу в итоге вышли в прод и ни с одного не было заведено критичного дефекта в течении года эксплуатации.
Я думаю, большая заслуга не в TDD, а том, что весь функционал покрывается тестами, что покрывает основные сценарии :)
Я в своей практике тоже практикую TDD, но только если это реально уместно для задачи. У нас на проекте проектирование API построено таким образом:
* проводится анализ нужной фичи - метода, доп параметров и тд * пишется документация, где описывается API метод, его параметры и пример ответа * при реализации сразу пишутся тесты, на основании заложенного контракта API метода (когда ожидается, что будет ошибка валидации, успешный ответ и тд) * реализация совмещенная с TDD для некоторых модулей (валидация и тд)
Так нет подтверждения, что было "работать спустя рукава", все что из всей информации видно, что гениальные эффективные менеджеры натянули сову на глобус сделали ML метрики по абсолютно глупым параметрам и выдали это за неэффективность. Ну и кроме этого, то как они объявили это все дело с уведомлением - форма, посыл, грамотность.
Будь это аргументированная и индивидуальная информация - предоставленная каждому сотруднику и там сказано - ну слушай, ты с обязанностями не справляешься и вот почему, то не было такого бума и обсуждения.
И вот представьте что вы осознаете, что просираете 11+ миллионов рублей в месяц в течение года. В том числе потому, что поверили сотрудникам что они могут "так же эффективно" работать на удаленке.
Ну так в этом случае это не значит, что работники плохие, а что процессы работы не готовы к новой схеме работы? Тем более, как я понимаю, тут нет речи про удаленку, а было про офис. Опять же, как по мне - увольнять, это не решение проблемы, если что идет не так, значит процессы выстроены неграмотно, надо их улучшать, надо перепроверять все показатели, все же инженерную работу измерить сложно, метрики по кол-ву тасков это глупо.
Результат согласно отчетности - убыток. Как минимум официально.
Видел в других комментах, что прибыль (2 млрд) все же там есть и те 10 млн это не совсем убыток.
Конечно, первое показывает открытость руководства, что есть проблемы у компании и что с вами общаются можно сказать на равных. А второе, перекладывают вину на тех, кого увольняют (что собственно вообще не адекватно, как говорится, у плохого танцора ноги виноваты).
У меня как-то на одном проекте тоже была похожая история, был плавающий баг, только у заказчика и на старом iphone, мы всей командой поочереди пытались найти баг, несколько месяцев висела эта задача. Потом все же смогли найти, где проблема и починили, но времени убили много
В этом есть доля правды, когда фичу надо сделать быстро, то архитектурный вопрос можно отложить на потом, НО, скорее всего, это выйдет дороже, чем сделать сразу.
Этот абзац, как и заголовок не отражает истину - надо мыслить абстракциями, тогда интерфейсы придут сами собой, т.е. продумываем какие модули нам нужны, как они будут взаимодействовать друг с другом. Т.е. на диаграммах можно описать абстракции (контракты), на их основании уже будет проверяться рабочая и удобная ли эта схема. Потом уже переходит в реализацию. Т.е. бежать сразу кодить интерфейсы плохо, сначала нужно продумать все реализацию и продумать взаимодействие, после этого все станет на свои места.
Имхо, это не их ума дело, хочет владелец чинить не у официалов, его право, а не то "вам плохо сделают, потому мы запчасти никому не дадим, чините только у официалов"
@Boomburumпривет, а фичу эту постепенно включаете? Сижу на бета-версии, появилось только плюсование в карму пользователей, для комментов и публикаций нет
Я пользуюсь uBlock Origin, AdBlocker Ultimate, Adblock Plus, AdBlock (что-то не нашел его сейчас на сайте с аддонами) и еще Neat URL
У меня в FireFox 4 расширения на блокировку + встроенный блокировщик трекинга, как показала практика, Яндекс Метрика тоже не видит такие переходы.
Как по мне, сейчас без блокировщиков страшно в интернет заходить
Мне всегда было интересно, вот как им дата рождения поможет, паспорт никто не требует, значит вбить левую дату никто не мешает. Как все пользовались, так и будут.
У меня сейчас Ubuntu 20.04 и видеокарта ASUS GeForce GTX 1660 Ti STRIX - проблем нет, на 18 было - по умолчанию не было драйверов под Nvidia, на разрешении 800 на 600 ставил их.
А можно поподробнее, о каких дистрибутивах идет речь? В Ubuntu есть утилита для бекапов (сам не пользовался, не было нужды).
Интерфейс дело другое, графическую оболочку всегда можно переустановить при желании.
А вот что касается установки софта и чтобы что-то сломалось, сеть и прочее, ну не знаю, за 8 лет ни разу не сталкивался с подобными проблемами.
Я конечно могу показаться занудой, но у вас пример в статье - ноутбук и мак, что явно не декстоп. Справедливости ради, вам стоит так же попробовать установить Linux на обычный PC.
Сейчас проблемы редки, но бывают, это скорее я описал опыт последних 2-3 лет, что косяков было много. Стабильнее всего работало совместно с Windows 7, а вот в 18 году переход на Windows 10 стоил огромной боли. Это как раз в то время диски в Ubuntu в целом работали readonly, т.к. Windows для обеспечения какой-то там быстродейственности внутри себя запихивал свои системные конфиги на всех диски (даже если это другие физические диски, не связанные с Ц). Вот это как раз решилось гуглежом на пару часов и отключением в реестре.
У меня так же, не было ни одной ситуации, чтобы обновление Ubuntu мне что-то сломали, а вот на маке, я уже давно перестал ставить обновления и боюсь их как огня, каждый апдейт что-то ломал и приходилось уйму времени тратить на латание дыр
Соглашусь, это как меня сейчас забавляет, как Microsoft к себе ядро Linux внедряет, через лет 10 получим новый дистрибутив с этикеткой Microsoft...
Последние 8 лет пользуюсь Ubuntu как основной OC на декстопе, начиная с 14 и сейчас на 20.04, не решаемых проблем сходу - не вспомню, иногда приходилось пошаманить, но в целом полет отличный, причем сейчас у меня AMD (Ryzen 5 3600) проц и NVIDIA видяха (GTX 1660 Ti). Причем до этого много пользовался именно радеоноскими картами, с их драйверами больше приколов было (на версии 18 и ниже), в 20 комп из коробки взял и поехал.
У меня скорее больше проблем из-за второй ОСи - Windows 10, которая ой как любит ломать (особенно апдейтами) работу с Ubuntu - то диски в ридонли перейдут, то из-за апдейта винды звук пропадет - обычно все чинится ребутом назад в винду, завершение работы апдейтера и за крайнем случаем что-то поменять в реестре винды.
В ежедневной работе я постоянно пользуюсь macbook pro, и честно, Ubuntu в разы лучше работает, чем то же мак, если сравнивать стабильность в работе с обновлениями, и как часто приходится латать какие-то проблемы, то Ubuntu значительно выигрывает у мака.
PS: Кстати, после долгких лет родителям вместо винды поставил Ubuntu 20.04, за последний год с копейками ни разу не приходилось что-то чинить, а вот в случае работы с виндой, каждые пару месяцев что-то ломалось
Прислуга? Им никто ничего не должен? А почему они тогда кому-то что-то должны? Вы явно путаете понятия "наемный работник" и "раб"
Согласен, есть такая проблема, мы ее от части решаем обязательным 100% покрытием всех модулей, которые затрагиваются в рамках задачи, это конечно не гарантирует покрытие всех сценариев, но хотя бы самые тривиальные ошибки закрывает.
А QA тесты вы запускаете в момент билда в прод или совместно с unit тестами, пока задача еще в разработке? У нас разработчики пишут и интеграционные тесты тоже, которые гоняются на каждый коммит в GitLab, а QA тесты запускаются на реальных данных при сборке релиза.
Тоже с таким сталкивались.
Мы раньше тоже после реализации писали, но решили поменять подход, во первых чтобы сразу на этапе проектирования можно было увидеть конечный результат и описать, как это работае, а во вторых, чтобы представить описание API его клиента и получить от них фитбек, все ли их устраивает
А с какой целью вы параллелите тесты и разработку? Ведь это вполне можно делать силами одного разработчика и тогда вы не тратите х2 времени 2-х программистов или у вас тесты пишет QA отдел?
Не хочу показаться занудой, но удобство пользования API лучше проверить на этапе анализа и проектирования самого API, чем в момент написания тестов. Да, бывает такое, что в момент реализации могут обнаружится некоторые тонкости и доработка базовой структуры (если в ходе задачи что-то пришлось переосмыслить).
Я думаю, большая заслуга не в TDD, а том, что весь функционал покрывается тестами, что покрывает основные сценарии :)
Я в своей практике тоже практикую TDD, но только если это реально уместно для задачи. У нас на проекте проектирование API построено таким образом:
* проводится анализ нужной фичи - метода, доп параметров и тд
* пишется документация, где описывается API метод, его параметры и пример ответа
* при реализации сразу пишутся тесты, на основании заложенного контракта API метода (когда ожидается, что будет ошибка валидации, успешный ответ и тд)
* реализация совмещенная с TDD для некоторых модулей (валидация и тд)
Это да, вообще в данном случае под отменой, я больше подразумевал, чтобы все дружно отказались от работы в столь замечательной компании.
Так нет подтверждения, что было "работать спустя рукава", все что из всей информации видно, что гениальные эффективные менеджеры
натянули сову на глобуссделали ML метрики по абсолютно глупым параметрам и выдали это за неэффективность. Ну и кроме этого, то как они объявили это все дело с уведомлением - форма, посыл, грамотность.Будь это аргументированная и индивидуальная информация - предоставленная каждому сотруднику и там сказано - ну слушай, ты с обязанностями не справляешься и вот почему, то не было такого бума и обсуждения.
Ну так в этом случае это не значит, что работники плохие, а что процессы работы не готовы к новой схеме работы? Тем более, как я понимаю, тут нет речи про удаленку, а было про офис. Опять же, как по мне - увольнять, это не решение проблемы, если что идет не так, значит процессы выстроены неграмотно, надо их улучшать, надо перепроверять все показатели, все же инженерную работу измерить сложно, метрики по кол-ву тасков это глупо.
Видел в других комментах, что прибыль (2 млрд) все же там есть и те 10 млн это не совсем убыток.
Конечно, первое показывает открытость руководства, что есть проблемы у компании и что с вами общаются можно сказать на равных. А второе, перекладывают вину на тех, кого увольняют (что собственно вообще не адекватно, как говорится, у плохого танцора ноги виноваты).
У меня как-то на одном проекте тоже была похожая история, был плавающий баг, только у заказчика и на старом iphone, мы всей командой поочереди пытались найти баг, несколько месяцев висела эта задача. Потом все же смогли найти, где проблема и починили, но времени убили много