Т.е. улучшение поддержки стандартов (html5, css3), усовершенствование javascript, ускорение скорости интернета — ничто из этого не повлияло на смерть Flash, все сделало Apple?
Во время собрания сотрудники не выполняют своих рабочих обязанностей и, следовательно, не приносят компании прибыль.
Не совсем согласен с подобной постановкой предложения. Таким же образом можно сказать, что прибыль компании приносят конкретно продажи (либо, для абсурдности конкретный момент передачи денег), но никак не разработка сама по себе.
Это какой такой баг на проде, который требует незамедлительного решения, который каким-то образом прошел все тесты на всех предварительных средах, дошел до прода и все сломал?
За все время работы в enterprise все баги, возникающие на проде, не лечатся за один день. В спринт берется задача с багом на проде и в течение спринта решается. А потом еще только через какое-то время деплоится на прод, потому что также должна пройти через все стандартные процедуры. Т.е. это в принципе небыстрый процесс.
Выкатывать сырое решение, править продакшн базу наживую и другие подобные действия (плюс делать это все силами уставшей команды поздно вечером) зачастую более опасное мероприятие, чем наличие прод бага. Так что решение отправить всех домой вовремя и на следующий день побрейнштормить как это лечить, возможно, самое лучшее что можно сделать.
На мой взгляд вы просто не хотите подбирать более-менее подходящие слова.
Читал я как-то статью, в которой вместо устоявшихся в индустрии англицизмов использовались «более-менее подходящие слова». Статья была практически нечитаемой и непонятной.
Это происходит от того, что английский язык более примитивен, чем русский.
Если начать работать, например, в сфере финансов, то в 30 лет вы почти наверняка будете руководителем.
Т.е. если у нас на рынке сейчас есть, условно, 10 тысяч молодых сотрудников в сфере финансов, то через 10 лет у нас будет 10 тысяч руководителей в сфере финансов? Что-то очень сильно сомневаюсь.
На самом деле, правильных ответов в таком случае нет — есть правильный вектор
В данном контексте абсолютно тождественно.
— Нет-нет-нет, мы не считаем капусту правильным овощем, мы просто считаем голубцы единственно правильным блюдом. А из чего вы их приготовите — это ваше дело.
Хороший знак, когда кандидат говорит «я постараюсь помочь найти кого-то на замену».
Ему дадут доступ к профилю компании на hh.ru? На две недели он займет должность hr? Как он должен помочь найти кого-то на замену?
Все, что может сделать большинство сотрудников — это пустить слухи по сарафанному радио и спросить у друзей есть ли кто на примете. Практика показывает, что это дает достаточно слабый приток кандидатов. По большей части фраза абсолютно шаблонная. Но раз такой правильный «вектор» работает при интервью, то, естественно, все ее будут произносить.
Чаще всего при выборе этого языка ожидается, что разработка одного приложения под две платформы займёт в два раза меньше времени, чем разработка двух приложений.
Я могу ошибаться, но чаще всего фреймворк для создания гибридного мобильного приложения выбирают для того, чтобы не содержать две разных команды. И вот с этой задачей эти фреймворки как раз таки отлично справляются. А недостатки и подводные камни, как уже заметили выше, есть везде.
Площадь это вычисляемое свойство. Следует из контракта самого класса.
Как бы вы отнеслись к коллекции, у которой метод sort вместо сортировки всех данных, удалял бы все содержимое? Не посчитали ли бы вы naming convention такой библиотеки, как минимум, странным? Или если бы коллекция ImmutableItems на самом деле была бы мутабельной? Если вы будете игнорировать naming convention во время составления контракта, то вы потеряете очень важную составляющую.
Без понятия, я не знаю что мне обещает документация к Rectangle.
Учебник геометрии за пятый класс достаточно точно дает определение тому, что есть прямоугольник. Обсуждается как раз таки классический случай из геометрии. Контекст обсуждения предельно ясен и прозрачен. Вы можете, конечно, его пытаться искусственно усложнить в угоду своей позиции, но боюсь на этом дальнейшее обсуждение скатится к софистике.
Вы на основании чего-то считаете что после вызова setWidth метод getHeight будет возвращать то же, что и до вызова.
Не знаю даже. Может быть вот en.wikipedia.org/wiki/Rectangle
На основании того, что стороны прямоугольника являются не связанными друг с другом величинами, но в совокупности придающими прямоугольнику дополнительные свойства. Например, периметр, выведение которого производится общеизвестным методом.
Что вы подразумеваете под контрактом? Можем создать класс Weirdtangle, который будет иметь setWidth/setHeight, но имплицитно второе свойство будет устанавливать в ноль. Мы нарушили контракт ожидаемого поведения Rectangle? Сигнатуры в норме, проект собирается, вот только вся логика написанная для работы с Rectangle с этим классом летит как фанера.
Контракт Rectangle подразумевает изменение только одной стороны одной функцией. Если будет логика, которая полагается на независимое изменение сторон, то Square автоматически становится невалидным для этой функции.
А теперь предположим есть отверстие с прямоугольными углами, которое принимает Rectangle, и чтобы наш класс туда поместился необходимо задать ему нужную ширину и высоту и тогда все туда пролезет. Square же попадает под условие сигнатуры, но когда мы попытаемся присвоить ему setWidth(1) и setHeight(2) (что является достаточным условием для метода отверстия), он почему-то туда все равно не пролезет. Налицо нарушение принципа Барбары Лисков. Вызывая один из методов setWidth или setHeight у класса Rectangle, мы ожидаем, что изменим каждую из сторон независимо, но тут внезапно врывается Square, который меняет стороны имплицитно.
На самом деле, наш подход принципиально не так уж сильно отличается от того, что описано в руководствах по архитектуре.
Потому что вы его уже знали. Это часть профессиональной деградации, когда тебе кажется, что все и так очевидно и просто, зачем об этом везде пишут.
Правила нарушают новички и эксперты, только результат у них разный, потому что нарушать правила можно по-разному. Правила это не концепции, которые являются единственно верными, это концепции, которые проверены временем и работают, но это не значит, что все остальное не работает. Проблема в том, что всего остального очень много и выбрать что-то не очень хорошо работающее из него при отсутствии компетенции вероятность крайне высокая.
в Skype/Mircrosoft нет штатных позиций для архитекторов ПО
Я частично согласен с мнением, что роль архитекторов переоценена, и достаточно тепло отношусь к компании Microsoft в целом, но не приводил бы в пример продукт под названием Skype в его нынешней инкарнации.
Программисты, кажется, забыли реальную цель программного обеспечения — это решать реальные проблемы.
Программисты ничего не забыли. Просто существует очень сильная корреляция между хорошим кодом, лучшим практикам, современным технологиям, продуманным решениям с одной стороны и качеством ПО, стабильностью работы, стоимостью разработки и поддержки с другой. И если аналитик, менеджер, либо кто-то еще этого не понимает, то, вполне возможно, проблемным звеном в цепи разработки являются не программисты.
Программисты осознают, что их первостепенная задача решить проблему. Вот только проблема не бывает в отрыве от контекста. У проблемы есть некий бекграунд, у проблемы есть причина, у проблемы может быть классификация. А еще иногда проблема на самом деле не является проблемой, а это просто наша собственная интерпретация ее как проблемы.
Не совсем согласен с подобной постановкой предложения. Таким же образом можно сказать, что прибыль компании приносят конкретно продажи (либо, для абсурдности конкретный момент передачи денег), но никак не разработка сама по себе.
За все время работы в enterprise все баги, возникающие на проде, не лечатся за один день. В спринт берется задача с багом на проде и в течение спринта решается. А потом еще только через какое-то время деплоится на прод, потому что также должна пройти через все стандартные процедуры. Т.е. это в принципе небыстрый процесс.
Выкатывать сырое решение, править продакшн базу наживую и другие подобные действия (плюс делать это все силами уставшей команды поздно вечером) зачастую более опасное мероприятие, чем наличие прод бага. Так что решение отправить всех домой вовремя и на следующий день побрейнштормить как это лечить, возможно, самое лучшее что можно сделать.
Читал я как-то статью, в которой вместо устоявшихся в индустрии англицизмов использовались «более-менее подходящие слова». Статья была практически нечитаемой и непонятной.
Вы серьезно?
Т.е. если у нас на рынке сейчас есть, условно, 10 тысяч молодых сотрудников в сфере финансов, то через 10 лет у нас будет 10 тысяч руководителей в сфере финансов? Что-то очень сильно сомневаюсь.
В данном контексте абсолютно тождественно.
— Нет-нет-нет, мы не считаем капусту правильным овощем, мы просто считаем голубцы единственно правильным блюдом. А из чего вы их приготовите — это ваше дело.
Ему дадут доступ к профилю компании на hh.ru? На две недели он займет должность hr? Как он должен помочь найти кого-то на замену?
Все, что может сделать большинство сотрудников — это пустить слухи по сарафанному радио и спросить у друзей есть ли кто на примете. Практика показывает, что это дает достаточно слабый приток кандидатов. По большей части фраза абсолютно шаблонная. Но раз такой правильный «вектор» работает при интервью, то, естественно, все ее будут произносить.
Вы только что С++.
Я могу ошибаться, но чаще всего фреймворк для создания гибридного мобильного приложения выбирают для того, чтобы не содержать две разных команды. И вот с этой задачей эти фреймворки как раз таки отлично справляются. А недостатки и подводные камни, как уже заметили выше, есть везде.
Как бы вы отнеслись к коллекции, у которой метод sort вместо сортировки всех данных, удалял бы все содержимое? Не посчитали ли бы вы naming convention такой библиотеки, как минимум, странным? Или если бы коллекция ImmutableItems на самом деле была бы мутабельной? Если вы будете игнорировать naming convention во время составления контракта, то вы потеряете очень важную составляющую.
Учебник геометрии за пятый класс достаточно точно дает определение тому, что есть прямоугольник. Обсуждается как раз таки классический случай из геометрии. Контекст обсуждения предельно ясен и прозрачен. Вы можете, конечно, его пытаться искусственно усложнить в угоду своей позиции, но боюсь на этом дальнейшее обсуждение скатится к софистике.
Не знаю даже. Может быть вот en.wikipedia.org/wiki/Rectangle
На основании того, что стороны прямоугольника являются не связанными друг с другом величинами, но в совокупности придающими прямоугольнику дополнительные свойства. Например, периметр, выведение которого производится общеизвестным методом.
Потому что вы его уже знали. Это часть профессиональной деградации, когда тебе кажется, что все и так очевидно и просто, зачем об этом везде пишут.
Правила нарушают новички и эксперты, только результат у них разный, потому что нарушать правила можно по-разному. Правила это не концепции, которые являются единственно верными, это концепции, которые проверены временем и работают, но это не значит, что все остальное не работает. Проблема в том, что всего остального очень много и выбрать что-то не очень хорошо работающее из него при отсутствии компетенции вероятность крайне высокая.
Я частично согласен с мнением, что роль архитекторов переоценена, и достаточно тепло отношусь к компании Microsoft в целом, но не приводил бы в пример продукт под названием Skype в его нынешней инкарнации.
© Code complete, Steve McConnell
Программисты ничего не забыли. Просто существует очень сильная корреляция между хорошим кодом, лучшим практикам, современным технологиям, продуманным решениям с одной стороны и качеством ПО, стабильностью работы, стоимостью разработки и поддержки с другой. И если аналитик, менеджер, либо кто-то еще этого не понимает, то, вполне возможно, проблемным звеном в цепи разработки являются не программисты.
Программисты осознают, что их первостепенная задача решить проблему. Вот только проблема не бывает в отрыве от контекста. У проблемы есть некий бекграунд, у проблемы есть причина, у проблемы может быть классификация. А еще иногда проблема на самом деле не является проблемой, а это просто наша собственная интерпретация ее как проблемы.