Комментарии 200
Нередко можно столкнуться с тем, что данные не защищены или плохо зашифрованы:
Просто не включаются в план менеджерами. Без учета обсуждений, зачем вообще шифрование везде.
Или разрабы должны это овертаймом делать?
Как-то раз я гуглил одну проблему для своего друга и наткнулся в выдаче на страницу сайта ASUS, описание которой идеально подходило под описание проблемы. Однако, когда я перешел на нее, я получил пустую страницу с формой, в которой меня просили указать, была ли решена моя проблема:
Это задача разработчика писать этот документ?
Как-то мне пришло письмо от IKEA, в котором напоминалось, что я не закончил свою сессию опроса (обзора) и предлагалось пройти по ссылке, чтобы сохранить результат. Когда я перешел по ней, мне вернулось окно, в котором говорилось, что я-то уже все закончил:
Не понятно, то ли и правда баг, то ли такой бизнес процесс.
Сегодня я получил письмо от Coursera с не замененным заголовком:
Мало времени на тестирование?
Антивирус, которым мы пользуемся на работе, уже второй раз за месяц заблокировал нам доступ к большей части Интернета. В твиттере бурлило обсуждение на эту тему и у всех была одна и та же проблема. Я считаю это просто поразительным: неужели нельзя все протестировать перед тем, как выкатывать обновление в свет? Причем, были заблокированы многие крупные ресурсы, например, Google и сайт BBC!
Опять же. Менеджер ставит n часов. Тестировать овертаймом?
И я не совсем понимаю, что вообще значит это сообщение при выключении моей Raspberry Pi!
И виноваты разрабы, ага. Прохладная история.
Тут я попытался посетить сайт HTC Vive, но получил ошибку соединения MongoDB, которая вывалилась, ко всему прочему, на весь экран. Я быстро отписал об этом через твиттер, так же быстро получил остроумненький ответ, но ошибку выбивало вплоть до следующего дня:
Пустили фигню в продакшен.
Еще я попытался поднять Ubuntu MATE на моей Pi. Я записал совместимый с Pi образ на SD-карту, а в итоге получил вот это при первой загрузке. И я не уверен, что понимаю, в чем проблема:
Ubuntu open-source. Иди и помоги им.
Сегодня я пытался скачать ISS Log Parser, но не похоже, чтобы он качался. Открыв Dev-панель я увидел ошибку “jQuery not defined”, повторяющуюся с завидным упорством:
Через ИЕ. Мсье знает толк.
Я попытался связаться с моей коммунальной компанией NPower (занимаются газом и электричеством).
Опять таки — это разрабы игнорировали? Нет. Менеджеры.
Дальшле мне надоело, бла бла бла "А вот этот веб-сайт обвинил меня в использовании блокировщика рекламы" — виноваты разработчики, ага. Конечно.
Багованная всплывающая реклама… Это разработчик решил её туда поместить? Или спланировать тестирование без нее?
В общем автора в биореактор, типичный подход "тыж программист, тыж во всем виноват"
Меня аж в жар кинуло.
Ок, ок, всё, был не прав, не сливайте совсем :(
Он имел ввиду, что иногда менеджмент не понимает что и как нужно тестировать и отводят на тестирование и доведение до хорошего результата мало времени. Это на самом деле проблема менеджмента / бизнеса, хотя скорей всего идеальный и дорогой результат бизнесу просто будет обходится дорого и не нужен на текущем этапе, поэтому обычно достаточно среднего, но который имеет свойство крашиться и удивлять.
Проблема еще круче. Как себя позиционирует автор статьи?
> Я разработчик программного обеспечения и я создаю баги и ошибки.
Ладно, вторую часть откинем и оставим на его совести. Но по первой части — он, вроде бы, разработчик. При этом в самой статье лажается и путает баги программы с:
— недостачей контента;
— проблемой инфраструктуры;
— своим низким скиллом, когда ему не хватает квалификации понять смысл диагностической ошибки;
— завышенными требованиями к free software;
— закидонами маркетологов, которые заставили сделать галочку неотключаемой;
— ошибками в стороннем ПО, а не в системе;
— проблемами с локальной конфигурацией;
— итд, итп
Так же он пытается оценить качество ПО В ЦЕЛОМ по своим локальным глюкам — т.е. очень вольно обращается с кванторами общности: «Если у меня ПО не работает — значит ПО плохое в принципе».
В общем — типичнейший наброс на вентилятор.
> Я разработчик программного обеспечения и я создаю баги и ошибки.
Ладно, вторую часть откинем и оставим на его совести. Но по первой части — он, вроде бы, разработчик. При этом в самой статье лажается и путает баги программы с:
— недостачей контента;
— проблемой инфраструктуры;
— своим низким скиллом, когда ему не хватает квалификации понять смысл диагностической ошибки;
— завышенными требованиями к free software;
— закидонами маркетологов, которые заставили сделать галочку неотключаемой;
— ошибками в стороннем ПО, а не в системе;
— проблемами с локальной конфигурацией;
— итд, итп
Так же он пытается оценить качество ПО В ЦЕЛОМ по своим локальным глюкам — т.е. очень вольно обращается с кванторами общности: «Если у меня ПО не работает — значит ПО плохое в принципе».
В общем — типичнейший наброс на вентилятор.
>Так же он пытается оценить качество ПО В ЦЕЛОМ по своим локальным глюкам — т.е. очень вольно обращается с кванторами общности: «Если у меня ПО не работает — значит ПО плохое в принципе».
вы не поверите, но именно так оценивает ПО обыватель — что-то ему критичное не работает -> не работает ничего вообще
как утрированный пример приведу gmail — пользователь набирает и отсылает почту, и тут у него вместо кнопки отправить появляется текст
nbspa href=awdawdawd>отправить и он не может отправить почту — пользователь закрывает окно браузера и решает, что почтовый клиент не работает вообще
хотя, например, функции фильтрации, приёма и так далее работают хорошо
вы не поверите, но именно так оценивает ПО обыватель — что-то ему критичное не работает -> не работает ничего вообще
как утрированный пример приведу gmail — пользователь набирает и отсылает почту, и тут у него вместо кнопки отправить появляется текст
nbspa href=awdawdawd>отправить и он не может отправить почту — пользователь закрывает окно браузера и решает, что почтовый клиент не работает вообще
хотя, например, функции фильтрации, приёма и так далее работают хорошо
Обыватель может считать о себе что угодно и как угодно, но разработчик не должен забывать что пользователь — это «это не только ценный мех, но и 3–4 килограмма легкоусвояемого мяса», а если точнее — доход (не прибыль!) в районе $10 в год (ну или если учесть эффект «один выведенный из себя потребитель уведёт в среднем ещё 10 друзей», то $100 в год) — и это, напомню, самый-самый ужасный случай, когда ошибка настолько кошмарная, что пользователь «развернулся и убёг».
Еще раз — автор статьи позиционирует себя как девелопера. Т.е. он должен быть в курсе разницы между контентом и кодом, а так же между «девелоперы сдались» и «менеджеры закусили удила».
А если он не в курсе всего этого — значит он не имеет морального права наезжать на других девелоперов.
Да, я в курсе, что не нужно быть поваром, что бы оценить качество блюда.
Но я так же в курсе, что если тебе дали тухлые яйца и приказали приготовить омлет — то что ты с этим не делай, то получится говно. И да — при этом маркетинг может преподнести это как «изысканное исключительное кушанье для гурманов, сделанное из столетних яиц». Но это — уже маркетинг. По факту — это будет говённый омлет из протухших яиц.
А если он не в курсе всего этого — значит он не имеет морального права наезжать на других девелоперов.
Да, я в курсе, что не нужно быть поваром, что бы оценить качество блюда.
Но я так же в курсе, что если тебе дали тухлые яйца и приказали приготовить омлет — то что ты с этим не делай, то получится говно. И да — при этом маркетинг может преподнести это как «изысканное исключительное кушанье для гурманов, сделанное из столетних яиц». Но это — уже маркетинг. По факту — это будет говённый омлет из протухших яиц.
Так речь и идет о сфере разработки ПО в целом:
Нигде и не утверждается что «кодеры во всем виноваты». И здесь я согласен с автором: качество ПО, по моим личным субъективным ощущением, все больше и больше ухудшается. Взять те же игры — идешь в стим, платишь ощутимую сумму денег за какую-ниубудь новинку, которую все ждали несколько лет — и получаешь зависания и вылеты чуть ли не со старта. Или релизят игру, котрая несколько лет была в бете или раннем доступе — а там откуда-то багов и глюков больше, чем было в бете, а половина функционала урезана. С неигровыми приложениями в том же эпл аппсторе, например, — та же беда. Новые версии выпускаются с неимоверным количеством багов, с урезанным или перекроенным до неузнаваемости функционалом, и часто — без возможности откатиться к старой версии. Просто современный менеджмент где-то в своих учебниках прочитал, что релизнуть бажную версию в установленный срок — это гораздо лучше для бизнеса, чем подождать фиксов хотя бы критических багов и релизнуться попозже. А в результате можно с удивлением наткнуться на свежий баг и получить в ответ что-то вроде «мы уже в курсе этой проблемы, наша команда уже работает над ее устранением», хотя версия вышла буквально пару минут назад, и в предыдущей версии проблемы не было. То есть, про баги известно еще до релиза, но никого это не волнует, кроме страдающих в результате конечных пользователей.
Я считаю, что у нашей сферы есть серьезные проблемы с качеством выполняемых работ и я не вижу этому конца.
Нигде и не утверждается что «кодеры во всем виноваты». И здесь я согласен с автором: качество ПО, по моим личным субъективным ощущением, все больше и больше ухудшается. Взять те же игры — идешь в стим, платишь ощутимую сумму денег за какую-ниубудь новинку, которую все ждали несколько лет — и получаешь зависания и вылеты чуть ли не со старта. Или релизят игру, котрая несколько лет была в бете или раннем доступе — а там откуда-то багов и глюков больше, чем было в бете, а половина функционала урезана. С неигровыми приложениями в том же эпл аппсторе, например, — та же беда. Новые версии выпускаются с неимоверным количеством багов, с урезанным или перекроенным до неузнаваемости функционалом, и часто — без возможности откатиться к старой версии. Просто современный менеджмент где-то в своих учебниках прочитал, что релизнуть бажную версию в установленный срок — это гораздо лучше для бизнеса, чем подождать фиксов хотя бы критических багов и релизнуться попозже. А в результате можно с удивлением наткнуться на свежий баг и получить в ответ что-то вроде «мы уже в курсе этой проблемы, наша команда уже работает над ее устранением», хотя версия вышла буквально пару минут назад, и в предыдущей версии проблемы не было. То есть, про баги известно еще до релиза, но никого это не волнует, кроме страдающих в результате конечных пользователей.
При чём тут девелоперы — хочется спросить?
Заходим еще на один круг?
«Девелопер» здесь — это обобщенное понятие. Можно читать как «компания-разработчик программного обеспечения». Девелопер — не единичный персонаж, не один человек, который сидит и занимается софтом, начиная с изучения спроса на рынке, и заканчивая продвижением и рекламой. Более-менее сложный софт уже давно не разрабатывается программистами-одиночками, чаще всего это как минимум команда, состоящая из специалистов в различных областях. Это как о строительной отрасли можно обобщенно сказать «строители» — туда относятся все: и менеджмент, и проектировщики, и конструкторы, и архитекторы, и укладчики кирпича, и разнорабочие на стройке, и даже инвесторы и держатели акций строительных компаний. Просто автор оригинальной статьи — сам «девелопер», то есть один из винтиков, принимающих участие в сложном процессе создания программного обеспечения, поэтому возникает ложное ощущение, что речь идет о профессии «программист». А тут скорее о падении качества софта в целом, а не о том, что именно программер на фирме виноват в этом.
речь и идет о сфере разработки ПО в целом:
«Девелопер» здесь — это обобщенное понятие. Можно читать как «компания-разработчик программного обеспечения». Девелопер — не единичный персонаж, не один человек, который сидит и занимается софтом, начиная с изучения спроса на рынке, и заканчивая продвижением и рекламой. Более-менее сложный софт уже давно не разрабатывается программистами-одиночками, чаще всего это как минимум команда, состоящая из специалистов в различных областях. Это как о строительной отрасли можно обобщенно сказать «строители» — туда относятся все: и менеджмент, и проектировщики, и конструкторы, и архитекторы, и укладчики кирпича, и разнорабочие на стройке, и даже инвесторы и держатели акций строительных компаний. Просто автор оригинальной статьи — сам «девелопер», то есть один из винтиков, принимающих участие в сложном процессе создания программного обеспечения, поэтому возникает ложное ощущение, что речь идет о профессии «программист». А тут скорее о падении качества софта в целом, а не о том, что именно программер на фирме виноват в этом.
Вот не надо, пожалуйста, обобщенных понятий. Автор себя отпозиционировал как «Девелопера». Не как сисадмина. Не как техсуппорта. Не как девопса. Не как менеджера ИТ-компании. Как «Девелопера». Соответственно — и спрос с него, как с девелопера. Т.е. он как минимум должен понимать разницу между «девелопером» — сиречь «программистом» — и остальными звеньями цепочки.
Иначе в угаре обощений можно докатиться до того, что «Сгорел утюг? Так эта Ванятка из второго подъезда виноват — вечно он чё-то с компутерами мутит!».
Соответственно тогда и накал статьи… того — поутухнет. Потому что ВДРУГ окажется, что виноваты-то по большей части не девелоперы, а… см. https://habrahabr.ru/company/ua-hosting/blog/283022/#comment_8882704
А про ложное ощущение вины Ванятки из второго подъезда — это, пожалуйста, к бабкам у подъезда (при чем — не второго).
Иначе в угаре обощений можно докатиться до того, что «Сгорел утюг? Так эта Ванятка из второго подъезда виноват — вечно он чё-то с компутерами мутит!».
Соответственно тогда и накал статьи… того — поутухнет. Потому что ВДРУГ окажется, что виноваты-то по большей части не девелоперы, а… см. https://habrahabr.ru/company/ua-hosting/blog/283022/#comment_8882704
А про ложное ощущение вины Ванятки из второго подъезда — это, пожалуйста, к бабкам у подъезда (при чем — не второго).
Какая разница, как он себя отпозиционировал? Рассуждает он вообще с точки зрения пользователя, он же не критикует собственный софт, который сам, как девелопер, разработал. Он позиционирует себя как девелопера, чтобы стало понятно, что он разбирается в вещах, о которых пишет. Он вроде и «по эту сторону баррикад», но «вышел прогуляться на ту», окинуть взглядом общую картину. А обобщение про Ванятку как раз и получилось: раз ты, чувак, девелопер, — то значит винишь во всем девелоперов, поэтому виноваты программисты. Странный вывод. Еще раз аналогия про строителей: если бы кирпичеукладчик Ваня написал статью, что здания нынче не те пошли — это бы не значило автоматом, что Ваня обвиняет в этом всех кирпичеукладчиков.
В целом согласен со статьей и сам принадлежу к тем разработчикам кто выкатывает не протестированные и баженные решения. И я вижу две причины почему это происходит:
1. Низкий порог вхождения в программирование. Сейчас стало очень много программистов, научится программированию по курсам (с++ за 21 день) и пойти работать за копейки. Рынок сейчас такой, что есть много программистов у которых мало опыта, но стоят они дешево.
2. Заказчика не волнует качество, важно быстрее чем конкурент и скорее начать грести деньги. Началась эра стартапов, а в стартапе делается MVP выкатывается, собираются фидбэки и дальше делается. Либо стартап сразу продается. Короче как можно грести деньги.
Реалии такие, что даже компании сейчас работают по принципу как всегда работал фриланс. Решение нужно вчера. А ещё достаточно часто встречается, что на вчера нужно не один, а два или три проекта. И разработчик уже начинает разрыватся между ними, потому как вроде и домой хочется (да можно было бы уволится с такой работы, но эта проблема возникает во многих фирмах). Ну и бонусом ко всему этому стало не модно держать отдел разработки в штате. Зачем? На саппорт можно посадить индусов, а разработчиков тоже можно взять где нибудь по дешевле в удаленной фирме. Тот же HipChat для Atlassian разрабатывают на Украине аутсорс компания.
UPD: Да и стоит признать, что работа программиста перестала быть фаном когда хотели сделать как можно лучше и круче. Теперь это просто работа от звонка до звонка. Поработать дольше? Мне за это не платят. Так что не буду. В этом проблема.
1. Низкий порог вхождения в программирование. Сейчас стало очень много программистов, научится программированию по курсам (с++ за 21 день) и пойти работать за копейки. Рынок сейчас такой, что есть много программистов у которых мало опыта, но стоят они дешево.
2. Заказчика не волнует качество, важно быстрее чем конкурент и скорее начать грести деньги. Началась эра стартапов, а в стартапе делается MVP выкатывается, собираются фидбэки и дальше делается. Либо стартап сразу продается. Короче как можно грести деньги.
Реалии такие, что даже компании сейчас работают по принципу как всегда работал фриланс. Решение нужно вчера. А ещё достаточно часто встречается, что на вчера нужно не один, а два или три проекта. И разработчик уже начинает разрыватся между ними, потому как вроде и домой хочется (да можно было бы уволится с такой работы, но эта проблема возникает во многих фирмах). Ну и бонусом ко всему этому стало не модно держать отдел разработки в штате. Зачем? На саппорт можно посадить индусов, а разработчиков тоже можно взять где нибудь по дешевле в удаленной фирме. Тот же HipChat для Atlassian разрабатывают на Украине аутсорс компания.
UPD: Да и стоит признать, что работа программиста перестала быть фаном когда хотели сделать как можно лучше и круче. Теперь это просто работа от звонка до звонка. Поработать дольше? Мне за это не платят. Так что не буду. В этом проблема.
Еще одна из причин — время на разработку. Обычно все скатывается в
Ага… щас…
Или когда вы работаете в команде с человеком, который за многие годы привык использовать какой-нибудь устаревший инструмент или подход и не собирается его менять.
Например вместо того, чтобы использовать миграции — продолжает по старинке писать вручную sql файлики. И конечно же в самый неподходящий момент поле которое было такое малюсенькое, незаметненькое, пропадает и бац — то что видит автор.
Или человеку лень потратить 5 минут на настройку дебаггера, только потому что просто привык делать var_dump, console.log, print, println по всему проекту…
Ну а че, чего так много часов. Тут же работы на 5 минут. Ты ж опытный программист. Здесь не должно возникнуть никаких проблем.
Ага… щас…
Или когда вы работаете в команде с человеком, который за многие годы привык использовать какой-нибудь устаревший инструмент или подход и не собирается его менять.
Например вместо того, чтобы использовать миграции — продолжает по старинке писать вручную sql файлики. И конечно же в самый неподходящий момент поле которое было такое малюсенькое, незаметненькое, пропадает и бац — то что видит автор.
Или человеку лень потратить 5 минут на настройку дебаггера, только потому что просто привык делать var_dump, console.log, print, println по всему проекту…
чтобы использовать миграции — продолжает по старинке писать вручную sql файлики
Вы имеете ввиду миграции в рамках EF? Или какие-то другие?
Можно использовать любую систему управления схемой БД. Тот же FluentMigrator, если стандартные миграции EF не нравятся. Или что-нибудь самописное, если в используемом языке нет подобного инструмента.
Суть в том, что должен быть способ убедиться, что используемая БД — «свежая» не дожидаясь пока ошибка вывалится в самом неожиданном месте.
Суть в том, что должен быть способ убедиться, что используемая БД — «свежая» не дожидаясь пока ошибка вывалится в самом неожиданном месте.
В точку!
со временем менеджеры поймут, что как девять женщин не родят ребенка за месяц, так и не получится сэкономить на программистах, «освоивших с++ за 21 день». Что рефакторинг может быть экономически обоснован, и чтобы «добавить фичу А» может потребоваться в 20 раз больше времени, чем на «добавить фичу Б», даже если они формулируются похожим образом.
Я понимаю, что мы принадлежим к молодой и еще неопытной сфере производства, что нам не хватает квалифицированных разработчиков для того, чтобы все делать правильно, но в последнее время возникает чувство, что мы даже и не пытаемся.К сожалению, это проблема существует не только в «нашей» сфере.
- Я вот в прошлом году сделал капитальный ремонт двигателя, и поехал отдыхать на Горный Алтай. На обратном пути прожгло один из клапанов, из-за того, что его плохо притерли, в итоге возвращался домой с «троящим» двигателем.
- Кто-то менял трубы отопления, плохо проварили и при нормальной подаче отопления затопили соседей.
- На Автовазе двери для «классики» делают разных размеров. Покупаешь новую дверь, а она на сантиметр длиннее/короче.
«Не мы такие — жизнь такая...»
«Кремниевая долина», сезон 3 серия 2 — как раз про маркетологов, бегущих вперёд разработки, и об экономическом пузыре, который заставляет их это делать.
Ошибки были есть и будут всегда. В современном мире, все ускоряется и неудивительно, что не все справляются с таким ритмом. И тут проблема не только в том, что разработчики обленились, но и в том, какие им ставят задачи. Если ставится задача «выпустить завтра во что бы то ни стало», то с большой вероятностью, получим один из примеров в посте. В любом случае, стоит рассматривать проблему более комплексно.
Да, «сделать „хоть что-то“ за 3 дня вместо 2х недель, иначе конкурентысожрутпаникапаника», а потом вместо 2х недель тратится месяц чтобы это работало более-менее и было совместимо с тем, что сделано за 3 дня и уже запущено.
Я тоже хочу жить в стране Программии! Где у программистов есть ровно столько времени, сколько нужно, что бы написать красивый, быстрый, логичный, рабочий код да еще и покрыть его юнит-тестами. И где за всё это программистам платят такую зарплату, что им хватает на всё, чего бы они не захотели.
Но, увы — я живу в реальном, жестоком мире, где у меня есть сроки и ТММ надо мной. Я стараюсь изо всех своих программерских сил, что бы у меня получался красивый, быстрый, читабельный и безбажный код. Но если не успеваю — пишу так, что бы код как минимум не глючил. Всё остальное — опции.
В противном случае я, конечно, могу писать код любой красоты и охрененности — но платить мне за это не будут. И как-то на горизонте не видеать миграционных агентов из страны Программляндии…
Но, увы — я живу в реальном, жестоком мире, где у меня есть сроки и ТММ надо мной. Я стараюсь изо всех своих программерских сил, что бы у меня получался красивый, быстрый, читабельный и безбажный код. Но если не успеваю — пишу так, что бы код как минимум не глючил. Всё остальное — опции.
В противном случае я, конечно, могу писать код любой красоты и охрененности — но платить мне за это не будут. И как-то на горизонте не видеать миграционных агентов из страны Программляндии…
Ошибки в системах типа «Периметр»…
Сразу вспомнилась целая книга — "Софт — отстой! И что с этим делать?".
И как я в процессе написании рецензии на эту книгу увидел чудное сообщение 7-zipa:
А хотел всего лишь сохранить настройки.
И как я в процессе написании рецензии на эту книгу увидел чудное сообщение 7-zipa:
Посмотреть картинку
А хотел всего лишь сохранить настройки.
Автору-то, прямая дорога в тестировщики.
Автор уже тестер. Причем приличный. Карма у тестеров такая — есть ли в тексте размером на страницу есть опечатка — то глаз прежде всего зацепится зап неё. И в реальной жизни тестеры чаше в разные ситуации попадают. Особенно гадостно это с банкоматами — то карту съедят, то деньги… :-)) Ну что поделать, скил такой — вляпываться в ошибки.
Первым кандидатом оказалась симпатичная девушка в джинсах и свитере. Я пропустил мимо ушей ее резюме, обратив внимание лишь на упоминание какого-то сертификата Quality Assurance Engineer. Во время собеседования девушка вела себя довольно-таки уверенно, то и дело поминала Transition Phase, CMM, ISO9000 и трехлетний опыт работы. Все это время я смотрел в окно и думал о том, что сидеть она будет в комнате через коридор, и что я не смогу использовать обычный лексикон при объяснении тонких моментов тест-плана.
Вторым был парень-студент, во взгляде которого читалась острейшая нужда в денежных средствах. На этот раз я принял участие в собеседовании и узнал, что он – гениальный программист и веб-дизайнер, что у него даже есть свой сайт, и что он сейчас пишет IDE для PHP на MAC. Я бы выяснил, почему он предпочитает MAC, но поймал взгляд технического директора и свернул беседу.
После ухода кандидатов мы несколько минут поспорили о проблемах девушек в чисто мужских коллективах и проблемах излишней амбициозности читателей журнала ксакеп, и сошлись на том, что «теперь хоть матов будет меньше», — девушка была очевидным выбором. Мы уже направились к выходу, когда у технического зазвонил мобильник. Обменявшись парой реплик со своим собеседником, технический зажал микрофон рукой и шепотом известил нас о том, что у входа в офис ждет еще один кандидат. Мы переглянулись. Решение было уже принято, но как-то неудобно было давать от ворот поворот человеку, не поленившемуся притащиться к нам на окраину. Технический велел охране впустить, и мы вернулись в конференц-зал.
Третий кандидат выглядел немного моложе моих лет. Улыбнувшись, он представился и сел в кресло, бросив папку на стол. Маркетинговый директор порылся у себя в бумагах и спросил:
— Извините, я что-то не вижу вашего резюме. Вы не присылали его нам?
— Присылал, — ответил кандидат, с интересом оглядываясь вокруг, — Но у вас почтовый сервер глючит.
Это было не очень хорошее начало. Мы все-таки IT-компания, и достаточно тщательно следим за тем, чтобы у нас все работало. Если у него нет резюме – пусть так и скажет и не тратит наше время. Технический директор с некоторой даже обидой спросил:
— Может быть, проблема все же не в сервере? Со связью что-нибудь, или почтовый клиент не сработал? Вы, кстати, не с мейл.ру отправляли?
— Нет, — ответил кандидат, продолжая оглядываться. Его внимание привлекла настольная лампа. Щелкнув пару раз выключателем, он сказал: «Смотрите-ка!» – и полез под стол. Лампа вспыхнула и перегорела. Кандидат вылез из-под стола и продолжил:
— Если оставить выключатель в промежуточном положении, а потом включить шнур в розетку, лампа перегорит!
— Спасибо. Может быть, вы принесли резюме с собой? — поинтересовался я.
— Да, конечно, вот оно, — он подал лист А4, — а вот это — распечатка ответа вашего почтового сервера, — он подал еще один лист.
Сисадмин с интересом взял его из моих рук и пробежал глазами:
— Но!.. А как?.. Странно… Я сейчас! — с этими словами он почти выбежал из комнаты.
Директора тем временем изучали резюме. Я смотрел на кандидата. Он повернулся назад, и что-то настраивал в кресле. Это было обычное пятилапое офисное чудовище на колесиках, распространитель сколиоза и отложения солей. Наконец в кресле что-то щелкнуло, и потенциальный тестер оказался на полу. Это, казалось, ничуть его не расстроило:
— Я так и знал! Дефект в системе регулировки пневматического амортизатора. Если отогнуть ручку вверх, а потом вбок…
— Принеси ему стул, — попросил меня технический директор, и я вышел из комнаты.
В коридоре я встретил сисадмина. На его лице было такое выражение, как если бы он обнаружил пиво в одной из бутылей для кулера.
— Что там с почтовиком? — спросил я.
— Ты будешь смеяться. В его письме MIME-boundary нарушает RFC 2046. Ничего страшного, но наш сервер падает при приеме такого текста! Измени хотя бы один символ – все пройдет нормально. Я посмотрел в логи – сервер падал четыре раза в понедельник. Судя по всему, именно из-за этого товарища.
Вернувшись, мы застали технического директора за попытками задвинуть жалюзи. Кандидат увлеченно объяснял, каким именно способом он сумел их заклинить. Маркетинговый директор смотрел на него уже почти с ненавистью. За какие-то пять минут это чудо сумело сломать лампу, кресло, жалюзи и продемонстировать багу в нашем почтовике.
— А вот стол у вас хороший, основательный! — сказал кандидат. Как говорил Оззи Осборн, «я начал понимать, что приходит время прощаться».
— Мы с вами свяжемся, до свидания.
— Можно, я от вас позвоню? — спросил этот демон разрушения.
— НЕТ! — ответил технический директор таким голосом, что кандидат мгновенно исчез.
Налив себе еще немного кофе, мы обсудили результаты собеседования. Увы, девушка не прошла.
Сертификат QA Engineer не заменит природного таланта — с таким парнем в команде нам просто не удастся сдать софт, если в нем будет хотя бы один баг.
Завтра пятница, значит – знакомство с новым членом коллектива. Пиво и бильярд в Потерянном Кластере. Пожалуй, я лучше пойду в Пива.NET — пусть попса, но мало ли что он захочет протестировать в баре...
Статья конечно подборка мелких багов из серии — «Гавно случается» и реагировать как автор наверно глупо. Сказать, что тут всегда виноваты разработчики нельзя, как нельзя сказать и обратное, что они тут не при чем. Наверно 50 на 50. Проблемы точно есть, но когда их не было? Это просто старческое брюзжание «Вот все стало хуже, вот в наше время!!!»
С другой стороны, когда «говно случается» на каждом шагу, при выполнении почти любого действия (причем в рамках нормального потока работы с системой), невольно начинают появляться мысли о том, что в консерватории все-таки что-то не так.
Но в статье речь не об этом. В статье придирки к каждой мелочи, было бы если так: Зашел на сайт асус — тут баг, нажал сюда — ошибка 500, запросил пароль — не пришло письмо, то есть на каждом шагу и везде, в рамках определенного проекта, это был бы разговор. А так… вокруг автора каждую секунду выполняются миллионы строк иногда очень сложного кода и вот он поймал несколько багов в разное время, в разных проектах, о да бида, бида мы все умрем, какой кошмар. Но самая прелесть, что начинается все со слов, «да я тоже делаю ошибки». Видимо те ошибки на которые он напоролся у других разработчиков от лени, а его ошибки это совершенно другой случай и поэтому его не бесят.
Автор в целом не понимает разницу между сисадминами, разработчиками и product owner's, потому что вышеописанные проблемы — это смесь ошибок из всех трёх областей (а на первом скриншоте — «перебдели» + контент-менеджер был не в курсе экранирования заголовков, т.е. тут вообще комплексная проблема)
Вот как раз там системная проблема именно у разработчиков — нет правильного подхода к экранированию, экранирование делается по принципу «на всякий случай, чтобы ничего не случилось».
Для сравнения: в движке Razor из ASP.NET MVC экранирование делается при вставке строк в текст. Любая строка будет экранирована автоматически — и ровно один раз. Поэтому на ASP.NET MVC никто не занимается экранированием входных строк «на всякий случай».
Нормальные библиотеки для клиентской шаблонизации вообще работают напрямую с DOM, пропуская фазы формирования разметки и последующего разбора этой разметки браузером. Там тоже не надо ничего экранировать.
Или, скажем, json-сериализация: формально там тоже присутствует экранирование спецсимволов в строковых константах. Но все нормальные сериализаторы делают его самостоятельно.
Для сравнения: в движке Razor из ASP.NET MVC экранирование делается при вставке строк в текст. Любая строка будет экранирована автоматически — и ровно один раз. Поэтому на ASP.NET MVC никто не занимается экранированием входных строк «на всякий случай».
Нормальные библиотеки для клиентской шаблонизации вообще работают напрямую с DOM, пропуская фазы формирования разметки и последующего разбора этой разметки браузером. Там тоже не надо ничего экранировать.
Или, скажем, json-сериализация: формально там тоже присутствует экранирование спецсимволов в строковых константах. Но все нормальные сериализаторы делают его самостоятельно.
В нашей отрасли стало слишком много «индусов» (в прямом и переносном смысле, но больше — в прямом). Двухнедельные курсы «С++ для идиотов» уже повод писать о себе «сеньор» (высшая квалификация программиста). Отдел кадров занимается наймом программистов, при этом не отличая IE от Интернета. Компании не только выкатывают нетестированный софт, но даже самих тестеров не имеют в штате. Так чему удивляться-то?
Тут в пору создавать стартап «пенсионер Козлов», занимающийся тем, что заваливает саппорты нерадивых компаний сообщениями. Штук так по тысяче в день. Глядишь — уволят пару клоунов из менеджмента и начнут думать о качестве!
Тут в пору создавать стартап «пенсионер Козлов», занимающийся тем, что заваливает саппорты нерадивых компаний сообщениями. Штук так по тысяче в день. Глядишь — уволят пару клоунов из менеджмента и начнут думать о качестве!
Да у нас и рынка тестеров нет по большему счёту (если откинуть ручных, с которыми ситуация чуть лучше)
Да какие там тестировщики. У нас сайт администрации весь сплошником в багах. Там буквально ничего не работает… Работают по-моему только ссылки на другие сайты ))… С 2014 года на него вообще забили… Почту никто не читает, а форма «обратиться к главе» при посте также выкидывает ошибку :) Зато доменов 3 штуки и уверен денег было с бюджета смыто не мало…
http://admnkz.info/
Уж думал было пройтись вручную по ошибочкам, но только непонятно куда их дальше девать… Больше всего печалит, что реально нужна некоторая информация с данного сайта ((…
http://admnkz.info/
Уж думал было пройтись вручную по ошибочкам, но только непонятно куда их дальше девать… Больше всего печалит, что реально нужна некоторая информация с данного сайта ((…
слишком много «индусов» (в прямом и переносном смысле, но больше — в прямом).
А можно раскрыть суть обоих смыслов? Ибо лично у меня складывается впечатление, что после событий с курсом рубля, как минимум Россияне и есть те самые «индусы», тогда, как те же Индусы уже давно отдают кучу софта (и не только) на аутсорс.
Как минимум, я наблюдал не кислый приток проектов (сам работаю в аутсорсинговой конторе), после вышеозначенных изменений на мировом валютном рынке.
Я уже молчу про то, что свежие выпускники, довольно крутых ранее, факультетов самых крутых заведений в моём городе, унылые клоуны по сравнению с американской и японской школотой тусующейся на гитхабе. Не все конечно, но субьективно и смотря на инженеров урождённых в ссср, инженерией во многих случаях даже и не пахнет люди «что то делают и оно как то работает». Метод научного тыка через гугл и so.
Вы хотите сказать что нет тех самых американских индусов и все сразу кодят правильно и на гитхабе сидят? дело в том что вы видите только их. Тех кто обладает плохой квалификацией как правило на том гитхабе и нет, от чего у вас и создается ложное впечатление. На том же SO часто как раз пишут ПОЧЕМУ это не работает и как поправить.
Проблема не в том, что в отрасли много индусов и идиотов, а то, что и с индусами и с идиотами кадров все равно мало.
Есть проекты, которые стабильны и достаточно надежны и это является их мощным преимуществом, которое позволяет им зарабатывать хорошие деньги. Один из таких примеров — Sqlite. На мой взгляд достаточно интересный случай, когда без привлечения маркетологов, пиарщиков и рекламы(возможно и была, не находил), проект приносит хорошие и стабильные деньги.
Многие в свое ПО засовывают кучу того, чего вам не нужно(кто помнит древние версии Nero, а?). А сейчас, чуть ли не в блокнот засунут вебкит, чтобы в случае чего, показать вам, как будет выглядеть ваш текст в блокноте в записи на вашей страничке социальной сети, доступ к которой потребуется вам для нормальной работы блокнота…
К сожалению многие забывают принцип, что «программа должна делать что-то одно, но делать хорошо». И еще к большему сожалению, это не нужно широкой массе потребителей.
Многие в свое ПО засовывают кучу того, чего вам не нужно(кто помнит древние версии Nero, а?). А сейчас, чуть ли не в блокнот засунут вебкит, чтобы в случае чего, показать вам, как будет выглядеть ваш текст в блокноте в записи на вашей страничке социальной сети, доступ к которой потребуется вам для нормальной работы блокнота…
К сожалению многие забывают принцип, что «программа должна делать что-то одно, но делать хорошо». И еще к большему сожалению, это не нужно широкой массе потребителей.
>проект приносит хорошие и стабильные деньги.
Он же бесплатен. Каким образом его монетизируют?
Он же бесплатен. Каким образом его монетизируют?
1. На поддержке. И клиентов у них немало.
Sqlite параноидально покрыт тестами. На разных платформах, системах, архитектурах, причем даже экзотических. В промышленном оборудовании. Банальный список https://www.sqlite.org/famous.html — клиенты из этого списка не обломаются заплатить большие деньги за надежность. Особенно если sqlite используется в критически важных местах. Понятно что тут немного клиентов, а самые «на слуху» у всех.
Не забываем, что sqlite — это хранилище информации. И потеря этой информации может иметь очень серьезные последствия. Это и объясняет, почему они так парятся за надежность. Да и цены не такие страшные для такого уровня ответственности — http://www.hwaci.com/sw/sqlite/prosupport.html
2. на спонсорстве с участием в консоциуме. https://www.sqlite.org/consortium.html
3. «крипторешения». http://www.hwaci.com/sw/sqlite/prosupport.html
Для всего этого, разработчиками(а конкретно Ричардом Хиппом) была создана компания Hwaci.
Вообще достаточно зайти на sqlite.org — там полно информации.
Sqlite параноидально покрыт тестами. На разных платформах, системах, архитектурах, причем даже экзотических. В промышленном оборудовании. Банальный список https://www.sqlite.org/famous.html — клиенты из этого списка не обломаются заплатить большие деньги за надежность. Особенно если sqlite используется в критически важных местах. Понятно что тут немного клиентов, а самые «на слуху» у всех.
Не забываем, что sqlite — это хранилище информации. И потеря этой информации может иметь очень серьезные последствия. Это и объясняет, почему они так парятся за надежность. Да и цены не такие страшные для такого уровня ответственности — http://www.hwaci.com/sw/sqlite/prosupport.html
2. на спонсорстве с участием в консоциуме. https://www.sqlite.org/consortium.html
3. «крипторешения». http://www.hwaci.com/sw/sqlite/prosupport.html
Для всего этого, разработчиками(а конкретно Ричардом Хиппом) была создана компания Hwaci.
Вообще достаточно зайти на sqlite.org — там полно информации.
Chrome тоже использует sqlite, но вот только иногда при выключении/перезагрузки компьютера без предварительного закрытия браузера, исчезают все открытые страницы, что даже кнопка restore не появляется. И как пользователь я не хочу думать, то ли это таблица в sqlite повредилась, то ли браузер не отдаёт Windows сигнал «подожди ещё чуть чуть, я тут страницы в sqlite сохраняю». Ну и сам факт того, что сохранение 50 страниц может достигать полминуты тоже как-то удивляет, там ведь не сохраняется содержимое страниц.
А сейчас, чуть ли не в блокнот засунут вебкит
atom.io, лол.
Komodo IDE/Edit работает на движке фаерфокса (
Меня к сожалению не правильно поняли. То что используется монструозный движок — еще ладно, обосновать это вполне возможно.
Представим ситуацию(далее Р — разработчики, М — оказывающий влияние на разработчика менеджер)
Разработчики пилят свой блокнотик, вроде бы всем все нравится, везде пони и ромашки.
М: Нужно вчера добавить в нашу незаменимую программу новый функционал, чтобы во вконтакте на стене отображался текст с блокнотика.
Р: Нафиг?
М: Премия лишняя?
Р: Ясно.
…
Р: Добавляется работа с сокетами, криптографией(https ведь). Ну и т.к. времени немного, для работы с json, поставим библиотеку libsuperjson. Правда она работает на регулярниках, поэтому поставим еще libultrapcre.
М: Ничего страшного, компы дешевые, для нашего незаменимого блокнотика доступно много ядер. Видеокарты вон все стали использовать.
Прошло пару дней.
М: Ребята, жизненно необходим для моей прем… для нас, чтобы можно было наблюдать за комментариями на наш текст из блокнотика, модерировать их, ну и отвечать.
Р: Нафиг?
М: Летний отпуск лишний?
Р: Ясно.
…
Р: Добавили в наш проект bhromium. Прошлые библиотеки приходится оставить, т.к. добавляли в спешке и никто не понимает, что там за бурда.
М: Замечательно! Можно считать, мы в продукте используем проверенные решения! Отличная реклама.
Прошло еще немного дней.
М: Ребята, спасибо вам искреннее за ваши старания. Благодаря им я получил свой процент с продаж. Жаль, что вы премию не заслужили. Но у вас выпал шанс! Крайне нужно добавить в наш блокнотик, чтобы рядом с текстом отображался аватар пользователя, причем в 3Д. Ну а т.к. наш клиент хочет играться с ним, надо добавить возможность катать этот аватар на виртуальной гоночной машинке по трассам, с чемпионатами и статистикой.
Р: Что за #$^&^% !?
М: Так требуют наши потенциальные будущие, в большом количестве, покупатели.
Р: Какие-какие покупатели?
М: Те, которые нам гарантирует инновационная Нигорийская система продаж, методологии которой непобедимы и в семинары которой мы уже вложили ваши премии и разумеется ждем от вас результата.
Р: Какого конкретного результата?
М: Денег конечно. И вообще у вас ипотеки, блестящие карьеры технического директора нашей будущей наверное корпорации, не портите её. Да и нашим инвесторам я обещал показать через три часа.
Р: А Тех. задание, письменное согласование?
М: О да, спасибо. В туалете бумаги нет, пригодилось. Короче жду через два часа.
Р: #:?*%?%#
Р: Интегрировали Ubity3D, систему обновлений, интеграцию с 1Ж(на всякий случай). Правда не знаем, работает это или нет.
М: Отлично? Вы суперспециалисты. И продукт супер. Осталось всего ничего до идеала. Мы уже пустили пару миллионов рекламу, где предупредили о релизе аналогичной мобильной версии.
Р: А нас почему не предупредили?
М: А вы сами почему не догадались? Утром будем презентовать… Ребята, в общем времени у вас полно… ребята… ребята вы куда? Эх жаль… Ладно наймем новых. Напишем как у всех, что мы супер блокнотико-стартап, перспективы развития, крайне адекватные сроки и большая зарплата. В общем РАЙ.
Представим ситуацию(далее Р — разработчики, М — оказывающий влияние на разработчика менеджер)
Разработчики пилят свой блокнотик, вроде бы всем все нравится, везде пони и ромашки.
М: Нужно вчера добавить в нашу незаменимую программу новый функционал, чтобы во вконтакте на стене отображался текст с блокнотика.
Р: Нафиг?
М: Премия лишняя?
Р: Ясно.
…
Р: Добавляется работа с сокетами, криптографией(https ведь). Ну и т.к. времени немного, для работы с json, поставим библиотеку libsuperjson. Правда она работает на регулярниках, поэтому поставим еще libultrapcre.
М: Ничего страшного, компы дешевые, для нашего незаменимого блокнотика доступно много ядер. Видеокарты вон все стали использовать.
Прошло пару дней.
М: Ребята, жизненно необходим для моей прем… для нас, чтобы можно было наблюдать за комментариями на наш текст из блокнотика, модерировать их, ну и отвечать.
Р: Нафиг?
М: Летний отпуск лишний?
Р: Ясно.
…
Р: Добавили в наш проект bhromium. Прошлые библиотеки приходится оставить, т.к. добавляли в спешке и никто не понимает, что там за бурда.
М: Замечательно! Можно считать, мы в продукте используем проверенные решения! Отличная реклама.
Прошло еще немного дней.
М: Ребята, спасибо вам искреннее за ваши старания. Благодаря им я получил свой процент с продаж. Жаль, что вы премию не заслужили. Но у вас выпал шанс! Крайне нужно добавить в наш блокнотик, чтобы рядом с текстом отображался аватар пользователя, причем в 3Д. Ну а т.к. наш клиент хочет играться с ним, надо добавить возможность катать этот аватар на виртуальной гоночной машинке по трассам, с чемпионатами и статистикой.
Р: Что за #$^&^% !?
М: Так требуют наши потенциальные будущие, в большом количестве, покупатели.
Р: Какие-какие покупатели?
М: Те, которые нам гарантирует инновационная Нигорийская система продаж, методологии которой непобедимы и в семинары которой мы уже вложили ваши премии и разумеется ждем от вас результата.
Р: Какого конкретного результата?
М: Денег конечно. И вообще у вас ипотеки, блестящие карьеры технического директора нашей будущей наверное корпорации, не портите её. Да и нашим инвесторам я обещал показать через три часа.
Р: А Тех. задание, письменное согласование?
М: О да, спасибо. В туалете бумаги нет, пригодилось. Короче жду через два часа.
Р: #:?*%?%#
Р: Интегрировали Ubity3D, систему обновлений, интеграцию с 1Ж(на всякий случай). Правда не знаем, работает это или нет.
М: Отлично? Вы суперспециалисты. И продукт супер. Осталось всего ничего до идеала. Мы уже пустили пару миллионов рекламу, где предупредили о релизе аналогичной мобильной версии.
Р: А нас почему не предупредили?
М: А вы сами почему не догадались? Утром будем презентовать… Ребята, в общем времени у вас полно… ребята… ребята вы куда? Эх жаль… Ладно наймем новых. Напишем как у всех, что мы супер блокнотико-стартап, перспективы развития, крайне адекватные сроки и большая зарплата. В общем РАЙ.
Основная причина — отсутствие ответственности. Прочитайте любое лицензионное соглашение к софту, половина его будет посвящена тому, что компания не несет ответственности за глюки. Когда такое заявляется в бесплатной программе, это понятно «Делал для себя, но решил поделиться с народом. Осторожно могут быть глюки». Но когда за программу требуют деньги, а в соглашении написано «вроде работает, но мы ничего не гарантируем», это напрягает.
Рынок же.
Софт, обложенный слоями сертификаций тоже существует.
В медицине, авиации и пр. Порядки цен совсем другие.
Софт, обложенный слоями сертификаций тоже существует.
В медицине, авиации и пр. Порядки цен совсем другие.
Сертификация сертификации рознь. В банковской сфере сертификация может еще ничего не значить. Будут треш и угар и глупые ошибки, но и бумажка о сертификации тоже будет. Ровно как и ответ — мы сертифицированы имя_бумажки, значит у нас все хорошо. Ваше обращение автоматически закрыто.
Тоже самое встречалось и в промышленности. Бумажки есть — качества нет.
Тоже самое встречалось и в промышленности. Бумажки есть — качества нет.
Если сертифицированная программа не удовлетворяет неким критериям качества — это почти ничего не говорит о качестве программы, а говорит лишь о низком качестве процесса сертификации, который не включает основные критерии качества.
Проблема в том, что когда есть некая сертификация, то у некоторых очень велик соблазн делать "под сертификацию", на не "делать хорошо". А дальше гори всё хоть огнём. И тут даже вопрос не в том, что сертификация на включает всех необходимых критериев качества, а в том что меняется подход и психология разработки.
Интересное замечание про отказ от отвественности в лицензионных соглашениях.
Но куда деваться?
У каждого пользователя совершенно непредсказуемое сочетание железа, драйверов и стороннего софта.
Например у одного пользователя почему-то отсуствует один драйвер, который как правило в Windows сразу есть.
Или еще пример. Мы купили в офис новый компьютер, запускаем свою программу, и она сразуже падает со странным сообщением про Windows Clipboard.
8-(
Как оказалось — на новом компьютере был предустановлен словарь, который пытался нестандартным образом посылать команды нашей программе копировать что-то там в буфер обмена при перемещении мыши.
Но куда деваться?
У каждого пользователя совершенно непредсказуемое сочетание железа, драйверов и стороннего софта.
Например у одного пользователя почему-то отсуствует один драйвер, который как правило в Windows сразу есть.
Или еще пример. Мы купили в офис новый компьютер, запускаем свою программу, и она сразуже падает со странным сообщением про Windows Clipboard.
8-(
Как оказалось — на новом компьютере был предустановлен словарь, который пытался нестандартным образом посылать команды нашей программе копировать что-то там в буфер обмена при перемещении мыши.
Я наверное вновь буду «белой вороной», но все же выскажу мнение, что между скоростью и качеством выбирать лучше все-таки первое. Мир ускоряется, и сейчас реалии таковы, что основным фактором является вовсе не качество, и даже не стоимость, а именно время разработки.
Для заказчика лучше иметь хоть какую-нибудь, пусть сырую и с багами, но работающую систему/проект сегодня, нежели красивенькую и стабильную, но не пойми когда в будущем. Особенно это характерно для стартапов, когда еще совершенно неясно «работающая» у вас идея или ерунда полнейшая.
Хотя, признаюсь честно, когда в штате есть свой тестировщик работать одно удовольствие.
Для заказчика лучше иметь хоть какую-нибудь, пусть сырую и с багами, но работающую систему/проект сегодня, нежели красивенькую и стабильную, но не пойми когда в будущем. Особенно это характерно для стартапов, когда еще совершенно неясно «работающая» у вас идея или ерунда полнейшая.
Хотя, признаюсь честно, когда в штате есть свой тестировщик работать одно удовольствие.
Очень и очень неоднозначный выбор. Если компания работает в условиях конкуренции, то лучше ставить на качество потому что все фичи, которые вы пытаетесь так быстро запилить уже есть у кого-то. Возможно, эти фичи уже даже работают лучше(или просто работают).
Если компания — стартап, то ставить на быстрый выпуск дешевого и не очень качественного продука тоже не очень: подтянутся конкуренты, потратят чуть больше времени и отобьют у вас людей. К тому же, что делать после спада «хайпа»? Продукт-то кривой.
Если компания — стартап, то ставить на быстрый выпуск дешевого и не очень качественного продука тоже не очень: подтянутся конкуренты, потратят чуть больше времени и отобьют у вас людей. К тому же, что делать после спада «хайпа»? Продукт-то кривой.
Это можно несколько перефразировать. Разрабатывать бажный и сырой софт легально? Легально. Есть люди, готовые разрабатывать такой софт? Есть. А есть люди готовые за это заплатить? Тоже есть. Добавим сюда тенденцию к ухудшению качества. Можно делать смелое заявление, что сейчас как никогда востребованы проекты написанные быстро и некачественно, и этот спрос продолжает расти. Потребителей устраивает такое качество и они готовы за это платить. То есть всех всё устраивает, отрасль развивается, всё хорошо.
Делать быстро (выпускать раньше) и делать говно — это о разном.
между скоростью и качеством выбирать лучше все-таки первоеЭто ко всему относится? Ремень безопасности? Автомобиль? Самолёт? А если не ко всему, то с чего б для ПО такие привилегии? AutoCAD'у или SolidWorks'у тоже можно делать ошибки?
Можно. Главное посчитать ожидаемый ущерб и затраты чтобы ущерба избежать и сравнить.
Это ко всему относится?Да, разумеется.
Ремень безопасности?Изобретён в XIX веке, начал появляться в автомобилях в 60е, обязателен к применению с 70х-80х годов прошлого века.
Автомобиль? Самолёт?Что конкретно вы имеете в виду? Первые автомобили и самолёты таки напоминали по многим показателям современные сайты — и по степени удобства и по надёжности. Или вы о чём-то другом?
AutoCAD'у или SolidWorks'у тоже можно делать ошибки?Нельзя — но ведь они их делают. Историю о CATIA слышали? Имею в виду одну попытку перейти версии 4 на версию 5…
Вопрос был про что выбираем, быстро (выбирать лучше всё-таки первое) сделанный ремень (автомобиль, самолёт) или качественный.
А стоит ли так вопрос? Обычно вопрос стоит: выбираем ли мы уже продающийся самолёт — или ждём пока доделают «самолёт мечты».
И выбор — весьма часто оказывается в пользу уже существующего самолёта. А вот когда у вас уже есть куча заказчиков и нормальное поступление денег от них — можно и на Dreamliner замахнуться.
И выбор — весьма часто оказывается в пользу уже существующего самолёта. А вот когда у вас уже есть куча заказчиков и нормальное поступление денег от них — можно и на Dreamliner замахнуться.
«Билл, перелогинся».
В свое время в книжном, проходя в компьютерный отдел мимо полок «мысли выдающихся людей», зацепился за фейс Билла Гейтса на обложке.
Книжка оказалась его, не помню точно названия но что-то про «как развить свой бизнес». Открыв наугад попал на его слова: «если у вас стоит выбор доработать продукт до отличного качества или выпустить сырую версию с ошибками, выбирайте второе, это позволит вам начать завоевывать клиента пока на рынке еще нет других предложений, а в процессе вы доработаете свой продукт заодно получая деньги» (цитирую на память, особо не зубрил но смыл примерно передан, у кого есть книжка в наличии исправьте меня).
Так вот, беда в том, что некоторые не занимаются особо доработкой и исправлениями, ведь «поток» уже пошел, и уж если тендер «выигран» то конкурентов не будет.
В свое время в книжном, проходя в компьютерный отдел мимо полок «мысли выдающихся людей», зацепился за фейс Билла Гейтса на обложке.
Книжка оказалась его, не помню точно названия но что-то про «как развить свой бизнес». Открыв наугад попал на его слова: «если у вас стоит выбор доработать продукт до отличного качества или выпустить сырую версию с ошибками, выбирайте второе, это позволит вам начать завоевывать клиента пока на рынке еще нет других предложений, а в процессе вы доработаете свой продукт заодно получая деньги» (цитирую на память, особо не зубрил но смыл примерно передан, у кого есть книжка в наличии исправьте меня).
Так вот, беда в том, что некоторые не занимаются особо доработкой и исправлениями, ведь «поток» уже пошел, и уж если тендер «выигран» то конкурентов не будет.
Так БГ — не программист. БГ — менеджер. И даёт советы с точки зрения менеджера.
Билл — таки именно программист. И программы он писал, по слухам, чуть не до самого ухода.
Вот когда во главе стал менеджер — Microsoft полетел под откос (сатья этот процесс приостановил, и, похоже, сможет и весь Microsoft развернуть).
Это, кстати, типичная история: приход менеджеров, как правило, обозначает что «скоро у компании будут проблемы».
Не всегда, впрочем: классический пример — Лу Герстнер, «человек, который спас IBM» — при этом мало что понимая в IT.
Вот когда во главе стал менеджер — Microsoft полетел под откос (сатья этот процесс приостановил, и, похоже, сможет и весь Microsoft развернуть).
Это, кстати, типичная история: приход менеджеров, как правило, обозначает что «скоро у компании будут проблемы».
Не всегда, впрочем: классический пример — Лу Герстнер, «человек, который спас IBM» — при этом мало что понимая в IT.
Есть другой взгляд на проблему.
Посмотрим на рынок одежды. Есть ширпотреб, он покрывает 99% потребностей. Ширпотреб дешёвый, качество низкое но населению хватает.
Есть просто качественная одежда, цена в разы выше. Вроде разница небольшая — ткань покрепче, швы поровнее… Но цена не на 10% поднимается а в разы.
Почему же в программировании должно быть иначе? Мы и видим результат.
Чтобы улучшить продукт, надо нанять тестера. Чтобы этот тестер нашёл проблемы, он должен быть и программистом, и администратором, и пользователем высокого уровня. Таких мало и они дорогие. Но такой найдёт 1% ошибок. Зачем тратить в разы больше на поиск одного процента, чем остальных 99%? Чтобы работало оборудование, анализировались логи, надо нанять штат администраторов, которые круглые сутки следят и готовы исправлять. Чтобы исправлять программистские ошибки, нужны круглосуточно работающие программисты. И так далее. Идёт гонка за удешевлением.
Не при чём ни ответственность, ни квалификация программистов. Дело в деньгах. Если делать качественно, это будет неконкурентно, так как 99% заказчикам нужен именно ширпотреб.
Посмотрим на рынок одежды. Есть ширпотреб, он покрывает 99% потребностей. Ширпотреб дешёвый, качество низкое но населению хватает.
Есть просто качественная одежда, цена в разы выше. Вроде разница небольшая — ткань покрепче, швы поровнее… Но цена не на 10% поднимается а в разы.
Почему же в программировании должно быть иначе? Мы и видим результат.
Чтобы улучшить продукт, надо нанять тестера. Чтобы этот тестер нашёл проблемы, он должен быть и программистом, и администратором, и пользователем высокого уровня. Таких мало и они дорогие. Но такой найдёт 1% ошибок. Зачем тратить в разы больше на поиск одного процента, чем остальных 99%? Чтобы работало оборудование, анализировались логи, надо нанять штат администраторов, которые круглые сутки следят и готовы исправлять. Чтобы исправлять программистские ошибки, нужны круглосуточно работающие программисты. И так далее. Идёт гонка за удешевлением.
Не при чём ни ответственность, ни квалификация программистов. Дело в деньгах. Если делать качественно, это будет неконкурентно, так как 99% заказчикам нужен именно ширпотреб.
Забавно. Когда айтишники приводят аргументы в защиту «пиратства» они аппелируют к тому что это не кража, так как происходит копирование и оригинал никуда не исчезает (как было бы в случае с булкой хлеба или одеждой).
Так вот тут те же яйца, только в профиль. Произвести одежду (пусть даже ширпотреб) трудозатратно и ресурсоёмко, а вот писать софт — нет (программисту же не нужно создать миллион экземпляров приложения, достаточно всего одной). Про дорогое оборудование речи вообще нет — достаточно ноутбука). Готовых фреймворков и библиотек — тьма тьмущая на все случаи жизни (это не большое преувеличение).
Казалось бы, бери готовые решения и делай качественный продукт? Ан нет, не выходит каменный цветок.
Если Дядюшка Ляо шьёт «абибас» в подвале, то он просто дядюшка Ляо который шъёт ширпотреб, а вот если «Рога и Копыта Soft» делают ширпотреб, то они почему-то IT-компания с CEO, менеджерами, сеньёрами-программистами, тестировщиками и наполеоновскими планами потеснить Google.
Очнитесь, вы не интеллектуальная элита и надежда человечества. Просто наёмные рабочие в модной нынче сфере (схорошей раздутой зарплатой) которые пытаются оправдать низкое качество продукта любыми средствами.
Проблема именно в некомпетентных ленивых погроммистах и «эффективных» менеджерах которых по хорошему нужно ссаными тряпками гнать из профессии. Есть ведь множество примеров великолепных приложений которые создаются на энтузиазме (без сотен денег) и своими силами (без толпы страхующих).
Так вот тут те же яйца, только в профиль. Произвести одежду (пусть даже ширпотреб) трудозатратно и ресурсоёмко, а вот писать софт — нет (программисту же не нужно создать миллион экземпляров приложения, достаточно всего одной). Про дорогое оборудование речи вообще нет — достаточно ноутбука). Готовых фреймворков и библиотек — тьма тьмущая на все случаи жизни (это не большое преувеличение).
Казалось бы, бери готовые решения и делай качественный продукт? Ан нет, не выходит каменный цветок.
Если Дядюшка Ляо шьёт «абибас» в подвале, то он просто дядюшка Ляо который шъёт ширпотреб, а вот если «Рога и Копыта Soft» делают ширпотреб, то они почему-то IT-компания с CEO, менеджерами, сеньёрами-программистами, тестировщиками и наполеоновскими планами потеснить Google.
Очнитесь, вы не интеллектуальная элита и надежда человечества. Просто наёмные рабочие в модной нынче сфере (с
Проблема именно в некомпетентных ленивых погроммистах и «эффективных» менеджерах которых по хорошему нужно ссаными тряпками гнать из профессии. Есть ведь множество примеров великолепных приложений которые создаются на энтузиазме (без сотен денег) и своими силами (без толпы страхующих).
А есть еще больше множество приложений которые не создаются, проваливают процесс разработки, бросаются и т.д. и т.п.
Я вполне уверен что для написания этого кода ядер так 20-40 и памяти под сто гагабайт не требуется (несмотря на всё растущие аппетиты софта), так что любого ноутбука будет достаточно (в теории), ну или средненького для вполне комфортной разработки, ну или любого согласно Вашим представлениям об удобстве и доступным средствам.
Где этот софт будет выполняться — другой вопрос.
>> это не большое преувеличение
> Какие библиотеки и фреймворки мне использовать?
Я надеялся обойтись без явных уточнений, так как из контекста следовало что речь идёт о решении типовых задач. Вы ведь не будете спорить с тем что для решения типовых задач библиотек и фреймворков хватает с избытком?
Разумеется, может статься так что готовых библиотек нет, но в таком случае речь, наверняка, идёт не о типовой задаче.
> И рынок решает, сколько зарплаты платить.
Рынок ничего не решает, это скорее крайне неточная оценка склонная к изменениям. Позавчера доткомы стоили миллионы и миллионы, а вчера обесценились. Изменилось ли что-нибудь качественно за ночь? Нет.
Быть программистом стало стильно-модно-молодёжно и зарплаты начали пухнуть без веских причин (зато как в лучших домахЕвропы США. Вот уж где культ карго благоденствует). Если бы рабочие на заводе делали гвозди столь же качественные сколь надёжен средний софт в наши дни цивилизация бы уже развалилась. Ну или рабочих бы выгнали (что более вероятно).
Где этот софт будет выполняться — другой вопрос.
>> это не большое преувеличение
> Какие библиотеки и фреймворки мне использовать?
Я надеялся обойтись без явных уточнений, так как из контекста следовало что речь идёт о решении типовых задач. Вы ведь не будете спорить с тем что для решения типовых задач библиотек и фреймворков хватает с избытком?
Разумеется, может статься так что готовых библиотек нет, но в таком случае речь, наверняка, идёт не о типовой задаче.
> И рынок решает, сколько зарплаты платить.
Рынок ничего не решает, это скорее крайне неточная оценка склонная к изменениям. Позавчера доткомы стоили миллионы и миллионы, а вчера обесценились. Изменилось ли что-нибудь качественно за ночь? Нет.
Быть программистом стало стильно-модно-молодёжно и зарплаты начали пухнуть без веских причин (зато как в лучших домах
Рабочий на заводе не сталкивается с постоянными изменениями спецификаций и требований. Рабочий на заводе не должен придумывать как сделать что-то новое соответствующее текущим требованиям каждый день. Это скорее как строить летящий самолет.
И программисты просто нужны всем в огромном количестве, поэтому и получают хорошие деньги. И те, что получают действительно хорошие деньги чем-то отличаются от остальных. Иначе бы у нас каждый стал программистом. Весь мир на всех уровнях (от простых пользователей, то гигантских корпораций) пользуется кучей информационных систем огромной (и растущей, потому что они все зависят друг от друга а систем больше и каждая сложнее) сложности с все растущими темпами развития.
И программисты просто нужны всем в огромном количестве, поэтому и получают хорошие деньги. И те, что получают действительно хорошие деньги чем-то отличаются от остальных. Иначе бы у нас каждый стал программистом. Весь мир на всех уровнях (от простых пользователей, то гигантских корпораций) пользуется кучей информационных систем огромной (и растущей, потому что они все зависят друг от друга а систем больше и каждая сложнее) сложности с все растущими темпами развития.
Рабочий на заводе не сталкивается с постоянными изменениями спецификаций и требований.
Это скорее как строить летящий самолет.
Забавно, что Вы не первый, кто эксплуатирует эту аналогию:
Ну я ее с этого ролика и стянул. Как и все аналогии из реального мира она не соответствует действительности, но все же лучше чем аналогия с рабочим с завода.
А насчет полетов в космос — я скорее не про создание универсального решения всего, а про возможность поменять метод решения/детали реализации быстро и с наименьшей болью (не выкидывая все на свалку), когда поменяются условия окружения, вскроются какие-то еще особенности работы или обнаружат фатальные недостатки в изначальном решении.
А насчет полетов в космос — я скорее не про создание универсального решения всего, а про возможность поменять метод решения/детали реализации быстро и с наименьшей болью (не выкидывая все на свалку), когда поменяются условия окружения, вскроются какие-то еще особенности работы или обнаружат фатальные недостатки в изначальном решении.
Готовых фреймворков и библиотек — тьма тьмущая на все случаи жизни (это не большое преувеличение).
Как раз таки, на готовых фремворках и библиотеках «на все случаи жизни» и пишется ширпотреб. И проблема даже не в самих фреймворках…
Недавно потребовался в команду фронтенд разработчик, больше половины собеседуемых, позиционировавших себя middle-разработчиками не могут что-то сделать за пределами ангуляра, очень многие не в состоянии сделать ajax запрос на нативном апи браузера (а зачем, подтянем jquery ради одного только ajax), многие не в состоянии написать deapClone (а зачем, есть underscore/lodash), с заданием напишите простейший переключатель как в примере без использования js не справился вообще никто.
И это middle разработчики с опытом в фронтенде от 2х лет… Что они смогут написать?
Крик души: пожалуйста, не мучайте пользователя такими переключателями. С ними не понятно в каком они сейчас состоянии. К тому же не понятно как ими управлять. На днях наблюдал как мама не могла переключить такой переключатель свайпом, так как он реагировал только на клики.
Иногда заказчик хочет именно подобную фигню, и ему до лампочки на юзабилити, если возвращаться к теме статьи — то это еще одна проблема, которая есть…
Ну а насчет задания, нужно было что-то, что можно было бы сделать быстро с одной стороны, с другой увидеть владеет ли кандидат css.
А так согласен с Вами, неудобно
Ну а насчет задания, нужно было что-то, что можно было бы сделать быстро с одной стороны, с другой увидеть владеет ли кандидат css.
А так согласен с Вами, неудобно
В статье не хватает второго параметра для оценки приемлемого качества — денег.
В защиту первоисточника хочется сказать, что у ESET и Microsoft уж точно есть деньги на тестировщиков, например.
У них есть деньги потому, что они экономят время. «Копроэкономика» требует «лучше хуже, но раньше». Продают не продукты, продают акции компаний, которые «вот-вот сделают что-то грандиозное и качественное раньше других, поверь».
Многие говорят, что сериал совсем не про айти, но там действительно дельные вещи показывают ;)
Не на тот комментарий ответ, но да, согласен, «Силиконовая долина» — самая документальная комедия про IT-бизнес, гротескное описание «инновационной экономики», рынка венчурных инвестиций и стартапов. А учитывая, что это американское состояние дел, и на нас оно проецируется через ещё более ужасные призмы карго-культа и коррупционных схем, становится совсем грустно, а не смешно. «У нас очень много денег. Их просто вот совсем много. И именно поэтому у нас появилась возможность не просто ворочать большими деньгами, а еще и вложить их в нашу долгосрочную стратегию.»
О, было бы здорово глянуть на бюждеты отделов тестирования различных продуктов этих компаний. Ну… раз Вы точно знаете.
На первоистчник никто не нападал, статья — точка зрения инженера, а не бизнесмена, на которого он работает.
На первоистчник никто не нападал, статья — точка зрения инженера, а не бизнесмена, на которого он работает.
И я более чем уверен, что у них огромные QA отделы.
/shrug
/shrug
Вестимо, это должно заставлять ESET и Microsoft тестировать свои продукты на конфигурациях, которые составляют 0,0001% от их базы.
И обязательно — включать всё возможное установленное ПО всех версий во всех конфигурациях, все возможные варианты поврежденной системы (понятно — всех версий со всеми возможными повреждениями всего существующего ПО во всех возможных конфигурациях).
Фигли — деньги-то есть?
И обязательно — включать всё возможное установленное ПО всех версий во всех конфигурациях, все возможные варианты поврежденной системы (понятно — всех версий со всеми возможными повреждениями всего существующего ПО во всех возможных конфигурациях).
Фигли — деньги-то есть?
Могу судить за последние 10 лет — субъективно качество улучшилось. Повсеместное тестирование, осознание того что среда исполнения может быть любая, open source модули, которые у всех на виду, человекопонятные ошибки и все это с учетом многомиллионного масштабирования.
Причем здесь разработчики? Если бы все зависело только от разработчиков, то программы пилились бы годами, и не факт, что большинство из них вообще когда либо увидели бы свет. А реальность такова, что сегодня вечер пятницы и нам необходимо пойти туда — не знаем куда, сделать то — не совсем понимаем что, на когда — на вчера.
Проблема не только в качестве продукта, но и в возможности его оценки. Простой потребитель не может объективно измерить качество продукта. Возьмем простой пример, почтовый сервер. Для его пользователя, критерием качества будет то, что сервер отправляет и получает письма (а что еще пользователю надо?). Если заказчиком выступает именно пользователь, то критерии очень простые.
Второй вариант, заказчиком является хостер, который будет обслуживать почтовый сервер. Тут на первое место выходит удобство настройки и стабильность, ну и, конечно же, подразумевается, что письма будут уходить и приходить.
Третий вариант, заказчиком является компания, которая заказала разарботку почтового сервера для своих внутренних нужд. На первый план вхыодит удобство доработки и поддержки этого сервера, потом, возможно, удобство администрирования (но этим же будут другие заниматься, может быть) ну а если вдруг отправка и получение не работают так как надо, то либо допилим, когда баг произойдет, либо забьем, если никто не обнаружит.
Таким образом, получается что качество продукта сильно зависит от того кто будет его принимать и для каких целей он будет использоваться. Газовая компания, думаю, чихать хотела на то что у какого-то пользователя браузер красненьким что-то рисует, потому что сайт свою функцию выполняет (с их точки зрения).
Можно, конечно, шлифовать продукт до идеала, но вот только конечный пользователь не оценит. А если два решения делают одно и то же, но одно стоит дешевле, то выбор очевиден.
Внимание к мелочам и вылизанность, это признаки товара из категории «люкс», к коим софт никак не относится. Можно купить себе Бентли и испытывать эстетический оргазм от того насколько вылизанно и аккуратно автомобиль сделан, но никто не купит себе почтовый сервер чтобы потом хвастаться им в кругу друзей «глядите, тут даже строчки в конфиге выровнены по фэншую, а уж сорцы вообще эталон».
Второй вариант, заказчиком является хостер, который будет обслуживать почтовый сервер. Тут на первое место выходит удобство настройки и стабильность, ну и, конечно же, подразумевается, что письма будут уходить и приходить.
Третий вариант, заказчиком является компания, которая заказала разарботку почтового сервера для своих внутренних нужд. На первый план вхыодит удобство доработки и поддержки этого сервера, потом, возможно, удобство администрирования (но этим же будут другие заниматься, может быть) ну а если вдруг отправка и получение не работают так как надо, то либо допилим, когда баг произойдет, либо забьем, если никто не обнаружит.
Таким образом, получается что качество продукта сильно зависит от того кто будет его принимать и для каких целей он будет использоваться. Газовая компания, думаю, чихать хотела на то что у какого-то пользователя браузер красненьким что-то рисует, потому что сайт свою функцию выполняет (с их точки зрения).
Можно, конечно, шлифовать продукт до идеала, но вот только конечный пользователь не оценит. А если два решения делают одно и то же, но одно стоит дешевле, то выбор очевиден.
Внимание к мелочам и вылизанность, это признаки товара из категории «люкс», к коим софт никак не относится. Можно купить себе Бентли и испытывать эстетический оргазм от того насколько вылизанно и аккуратно автомобиль сделан, но никто не купит себе почтовый сервер чтобы потом хвастаться им в кругу друзей «глядите, тут даже строчки в конфиге выровнены по фэншую, а уж сорцы вообще эталон».
Внимание к мелочам и вылизанность, это признаки товара из категории «люкс», к коим софт никак не относится.
Зависит от софта, есть огромные энтерпрайз порталы для внутреннего пользования бешенной ценой, есть банковский софт, есть софт для ракет, самолетов, автопилотов для машин.
Можно купить себе Бентли и испытывать эстетический оргазм от того насколько вылизанно и аккуратно автомобиль сделан, но никто не купит себе почтовый сервер чтобы потом хвастаться им в кругу друзей «глядите, тут даже строчки в конфиге выровнены по фэншую, а уж сорцы вообще эталон».
Почему никто? В корп. секторе это сплошь и рядом, когда и конфиги выравнивают по фэншую и в сорцах в комментах пишут войну и мир и траву красят лишь бы Клиент с большой буквы был доволен. Тут вопрос просто количество желающих получить супер-пупер люкс продукт за Овер кучу баксов, где все вылизано вплоть до исходного кода (такие Клиенты тоже есть).
К сожалению, когда перед разработчиком выбор: успеть в срок, выкатить в сегодняшнем релизе и получить премию, или отправить фичу на дополнительное тестирование и лишиться премии, большинство выбирают первый вариант, и не совсем правильным будет их осуждать. Кроме того, зачастую от релиза фичи в срок зависит и премия менеджера, который подгоняет разработчика быстрее пилить, а тестировщиков — быстрее тестировать.
У разбойника есть выбор — оставить свидетелей в живых и рисковать тем, что те донесут в полицию. А можно их догнать и убить, и спать спокойно. И не совсем правильным будет их осуждать за этот выбор. Не они такие, жизнь такая.
Если ты получаешь деньги за имитацию работы, за кривой и глючный продукт, то не удивляйся, когда, например, чиновники станут исходить из тех же предположений, и предоставлять за свою зарплату глючный и неполноценный сервис.
Если ты получаешь деньги за имитацию работы, за кривой и глючный продукт, то не удивляйся, когда, например, чиновники станут исходить из тех же предположений, и предоставлять за свою зарплату глючный и неполноценный сервис.
Просто очень много людей идут работать за большую зарплату, а не на интересный проект. Поэтому, им не важны эти баги, тестирование и т.п., важно лишь отработать норму и получить з/п. Они себя утешают чем-то вроде: «Я скоро уволюсь, найду нормальную работу, и буду всё делать правильно».
Но мы то знаем…
Но мы то знаем…
Мне кажется, тут вопрос приоритетов конкретного Василия. И если у Василия семья, которую надо свозить в отпуск, дети, которых надо собрать в школу и ипотека, которую надо платить, то его предпочтение в пользу премии легко понять. Правда думаю, что и такого разработчика можно мотивировать делать более качественный продукт: например, сделать KPI для премии не соблюдение сроков, а уменьшение количества багов, обнаруженных на тестинге/в проде.
Если ты получаешь деньги за имитацию работы, за кривой и глючный продукт, то не удивляйся, когда, например, чиновники станут исходить из тех же предположений, и предоставлять за свою зарплату глючный и неполноценный сервис.Вы уж конечно, извините, но между чиновниками и «конкретным Василием» есть небольшая, но принципиальная разница: возможность выбора. Продукцию «Василия» заказчик (или покупатель) может использовать или не использовать — по своему желанию. Отказаться от «сервиса» чиновника — увы, нельзя.
P.S. Предупреждая очевидное возражение: да, если компания становится где-то монополистом, то требования к ней меняются и с неё начинают спрашивать гораздо серьёзнее. По, в общем-то, понятням и разумным причинам.
PayPal после редизайна вообще имеет уйму битых ссылок.
Visual Studio перестала предлагать поставиться в другое место, что неимоверно ужасно.
Visual Studio перестала предлагать поставиться в другое место, что неимоверно ужасно.
Если продуктом пользуются, значит его соотношение «цена/качество» выше доступных альтернатив. Или выше выбора «не пользоваться вообще»
Всегда есть, как минимум, пожелания к качеству. Но все ли готовы заплатить за него более высокую цену? Если уверен, что желающие есть и их много — создавай стартап, который выкатит аналог высокого качества задорого
Всегда есть, как минимум, пожелания к качеству. Но все ли готовы заплатить за него более высокую цену? Если уверен, что желающие есть и их много — создавай стартап, который выкатит аналог высокого качества задорого
Одна из причин — здравая мысль сделать все рутинное и повторяемое тестирование автоматизированным выродилась в «мануальное тестирование не нужно, только автоматизированное». Очень часто, тестировщиков вообще не нанимают — программисты сами способны написать автотесты… В итоге качество здорово просело.
Имхо, это последствия не лени, а моды на аутсорсинг, который делают индусские программисты.
Есть очень важный момент, который упоминался только вскользь в этой статье. Это безопасность данных.
Если из-за низкого качества разработки не получается скачать нужный файл, заполнить заявку или прочитать статью на сайте, то это очень плохо, но не слишком критично. Реально критично то, что из-за низкого качества кода стали появляться серьезные ошибки в безопасности.
Например, недавно здесь была статья о выборе хостингов в качестве альтернативы DO. Я специально посмотрел каждый из представленных в статье и в комментариях хостинг, на многих быстро нашел довольно критичные уязвимости уязвимости. При этом, среди компаний, которые работают с конфиденциальными данными, мало кто готов сотрудничать с теми, кто находит уязвимости.
Но недавно я получил чудесный ответ на сообщение об уязвимости.
«Мы сознательно пошли на игнорирование проблем в безопасности, чтобы ускорить процесс разработки».
Если из-за низкого качества разработки не получается скачать нужный файл, заполнить заявку или прочитать статью на сайте, то это очень плохо, но не слишком критично. Реально критично то, что из-за низкого качества кода стали появляться серьезные ошибки в безопасности.
Например, недавно здесь была статья о выборе хостингов в качестве альтернативы DO. Я специально посмотрел каждый из представленных в статье и в комментариях хостинг, на многих быстро нашел довольно критичные уязвимости уязвимости. При этом, среди компаний, которые работают с конфиденциальными данными, мало кто готов сотрудничать с теми, кто находит уязвимости.
Но недавно я получил чудесный ответ на сообщение об уязвимости.
«Мы сознательно пошли на игнорирование проблем в безопасности, чтобы ускорить процесс разработки».
Но недавно я получил чудесный ответ на сообщение об уязвимости.Интересно кто таким честным оказался.
«Мы сознательно пошли на игнорирование проблем в безопасности, чтобы ускорить процесс разработки».
Ведь это то, что делают 90% (если не 99%) разработчиков, но при этом мало кто готов об этом вот так просто сказать…
Мы все в сети, и даже прямо сейчас. Гораздо прибыльнее выкатить продукт, который потом возможно допилится. НО, выкатить его прямо сейчас и раньше конкурентов, и начать зарабатывать деньги. Нет смысла всё отлаживать и вылизывать.
Я не разработчик, я связист сетевик. И да, приходится ковыряться в старых многослойных паутинах. И да, заказчики часто просят просто кинуть провод или поставить точку доступа просто так, а потом они сами когда-нибудь это всё приберут. Но по факту, следующая группа аутсорсеров так же будет плеваться и разгребать паутины пытаясь понять, как это всё работает и как это всё починить.
Я не разработчик, я связист сетевик. И да, приходится ковыряться в старых многослойных паутинах. И да, заказчики часто просят просто кинуть провод или поставить точку доступа просто так, а потом они сами когда-нибудь это всё приберут. Но по факту, следующая группа аутсорсеров так же будет плеваться и разгребать паутины пытаясь понять, как это всё работает и как это всё починить.
Большинство ошибок из разряда «ой, мне так не нравится». При этом почему-то не учитывается, что некоторые программные продукты довольно большие, и в них много функций, которые работают, и для выполнения которых они и создавались. NPM, PayPal, Visual Studio. Амперсанд 2 раза проэкранировался, ай-яй-яй)
Проблема не уникальна и применима к любой деятельности, т.к.:
Был в одном проекте показательный момент. Мощный кусок безумного говнокода (оставшегося с прототипа), в котором, изнутри вложенных вью моделей писались обновления в базу данных. Ошибки стреляли то там, то здесь. В рамках спринта они латались, затем вываливались новые. Раз в спринт вопрос этого бага поднимался — и мы были готовы голой грудью кинуться на амбразуру, и со своим овертаймом тоже… Но. Это несколько рабочих дней программиста и несколько дней тестирования (ком и в правду большой разросся). А значит — полусорванный спринт. Инвесторы будут злы. Манагеры вопрос заворачивали. Вопрос: что может сделать программист, в не зависимости от его квалификации, чтобы починить это?
Посчитать сколько уже было потрачено денег на латание дыр и экстраполируя показать через сколько рефакторинг окупит себя.
Посчитал, показал, рассказал. Покивали, похвалили, но делать отказались. Потому что «это мы заказчику не продадим». А открыть небольшой инвест в рамках текущей разработки это же надо рискнуть. «А вдруг мало ли что?» Зато очень эффективные менеджеры. На очень хорошем счету у акционеров компании. А проблемы же не на месте стоят: они нарастают.
Экстраполяция не всегда работает: я перенял у индусов (настоящих, стереотипных) разработку три года назад. Сначала, когда я ещё толком не понял что к чему, на меня свалилась гора ошибок, при этом индусы сказали «ну тут мы не знаем, мы уже всё передали». Ошибки нужно исправлять срочно, клиенты могут понести финансовые потери, а значит и мой работодатель может попасть на штрафы или даже лишиться клиента. Баги исправил, потом нужно было править свои исправления, потому что где-то они выпали из общей архитектуры и привели к новым багам. Сейчас приходит пара сообщений об ошибке в квартал, трачу по полдня на правку, попутно вынося функциональность с ошибкой в отдельные модули, покрываемые тестами. Продукт с точки зрения разработчика — полный ужас, поддержка дорогая, развивать невозможно… но он стабилен! Мне два года не давали возможность его отрефакторить, а теперь я уже и сам не хочу: развивать не нужно, говнокод из костылей работает как надо. Сейчас мы сделаем рефакторинг и снова будет период стабилизации с затратами на поддержку. А если сделать сразу качественно (привет топик-стартеру), то это просто невероятно дорого.
Нет, просто стало больше дешевых программистов.
Статья — крик моей души. Сливайте как хотите за мой бесполезный комментарий, но я в сети вижу множество деградаций. Разработчики работают в угоду скорости и менеджеров, а не ради конечного потребителя. Сатана там правит бал.
А вы, конечно же, работаете ради конечного потребителя и всегда выпускаете хороший качественный код, в котором нет ошибок?)
Прямо сейчас, в данный момент времени да, работаю ради конечного потребителя за бесплатно (в минус), заглянул сюда на чаек :)
За деньги делаю по ТЗ. Но все равно, к примеру, если я верстаю, то не использую бешеное количество фреймворков для отображения одной более-менее статичной странички и на мобильниках аккум не жрется неистово.
Насчет качественного кода не могу сказать — все мы люди и нам свойственно ошибаться.
Еще я вижу менеджеров, которые действительно хотят вчера как и разработчиков, которые говорят «надо сделать это так, чтобы ничего не делать и все работало». Подобные выражения их порой приводят к совсем неверным суждениям и результатам.
Посмотрим, какое у меня будет суждение, когда я буду ПМом…
За деньги делаю по ТЗ. Но все равно, к примеру, если я верстаю, то не использую бешеное количество фреймворков для отображения одной более-менее статичной странички и на мобильниках аккум не жрется неистово.
Насчет качественного кода не могу сказать — все мы люди и нам свойственно ошибаться.
Еще я вижу менеджеров, которые действительно хотят вчера как и разработчиков, которые говорят «надо сделать это так, чтобы ничего не делать и все работало». Подобные выражения их порой приводят к совсем неверным суждениям и результатам.
Посмотрим, какое у меня будет суждение, когда я буду ПМом…
К сожалению широко практикуется — менеджеры зачастую продают продукт лишь бы продать, обязуются что будет море новых и стабильных фич и что это будет сделано к моменту наступления вчера, а разрабов ставят уже перед фактом. Готов поспорить что так делается в большинстве компаний. Я даже уверен что часть кодеров хотела бы сделать все как надо, но делать все как надо каждый день в свой овертайм только для того чтобы менеджер и топы каждый раз получал плюсики, хорошая попытка но нет.
Абсолютно согласен с автором. Я, например, уже полгода наблюдаю в стандартной программе MIUI (форк Android от Xiaomi) для регулярной чистки устройства такую фразу «Файлов кэша: %d». В продакшн ушла неотформатированная строка, и она не спрятана где-то в настройках, а в самом основном экране, посередине.
Нет, мир остался прежним. Стало меньше… содержимого©
Согласен с товарищами высказываюми своё фи про Agile. Имхо, эта соковыжималочка сгубит ещё не одну хорошую идею. Хотя, тут всё зависит от жадности рулевых товарищей. Но все они «покупая машину о самолёте мечтали» ©.
Лично я, не раз и не два получал проникновенный разговор с тимлидом или пмом о том, что слишком много времени трачу на качественную реализацию функционала. Пару раз после такого разговора фича сворачивалась в некотором спешно недоделанном порядке, и шла в продукт/заказчику как есть.
Последние пару лет, как в наших снг стало де-факто стандартом всякое гибкое, я чувствую как накапливается усталость(может конечно тупо старею, хм).
Слышал от товарища опыт работы в одной зарубежной конторе, там сий процесс поставлен совершенно на другой уровень:
имеется система баллов, если ты не набрал норму баллов — уволен, если ты попал в tail пусть будет 100 (точную цифру не помню) — ты тоже уволен. Т.е. контора постоянно увольняет сотрудников и набирает не успевший подустать свежачёк с рынка. Мы с вами, как разумные люди понимаем, что менее чем за полгода в крупный проект вникнуть не выйдет. Среднее время выживаемости человека в сей конторе (сужу по выносливости и замотивированности товарища) порядка 7-8 месяцев. Итого, полезная контрибьюция в продукт на минимуме, контора аутсорсная и не самая мелкая, вакансии на том же stack overflow висят постоянно, зп для России и прочих индусов более чем высокая (на hh такие цифры практически не попадаются для разработчика). Ждём, когда появится на экранах страны сия картина.
При чем тут agile и перечисленное? Чем лучше «традиционные методологии» с высосаным из пальца сроком и подгонянием результата под них?
Старые — ничем, кроме того, что горстка действительно хороших инженеров, имела крайне не плохие шансы сделать не самый худший продукт, за разумное время. На сколько я слышал, в том же ibm, до сих пор никому никакой agile никуда не упёрся.
А нынешние адепты этого же agile, в большинстве своём забывают первые же строчки того манифеста, про то, что там главное и всё такое. Всех интересует бабло, прямо сейчас, а потом можно с красивой строчкой в резюме стартануть новый проект, можно и в новой конторе.
Лично я вижу былинное назначение agile методик продать 20 джунов во главе с мидом, разрываемых чувством долга и своей крутоты, как трёх синьёров, потом, тем кто выживет приписать лычлку мида и выше и поставить во главе следущей волны нанесения качества и высокого уровня услуг бедному кастомеру.
А нынешние адепты этого же agile, в большинстве своём забывают первые же строчки того манифеста, про то, что там главное и всё такое. Всех интересует бабло, прямо сейчас, а потом можно с красивой строчкой в резюме стартануть новый проект, можно и в новой конторе.
Лично я вижу былинное назначение agile методик продать 20 джунов во главе с мидом, разрываемых чувством долга и своей крутоты, как трёх синьёров, потом, тем кто выживет приписать лычлку мида и выше и поставить во главе следущей волны нанесения качества и высокого уровня услуг бедному кастомеру.
Наблюдаю agile с нормальными разработчиками в большой компании. Все работает быстро и хорошо. Все еще не вижу как какой-нибудь водопад спасет от плохих разработчиков и менеджеров.
Я не хочу ничего сказать лично про вас. Так же я уверен на 100%, что исключения, и грамотное не столь жадное руковдство имеет место быть в отдельно взятых компаниях (обычно это компании небольшие, до пары тысяч человек штата).
Но, я смел наблюдать именно такое мирощущение, глубоко вовлечённых товарищей, что всё Ок. Однако, именно в таких командах встечались технические лиды, уверенные, что например, переполнение буффера вызывает исключение, зато, они были сертифицированными скрам мастерами.
Не так уж много я и информации имею, сужу в основном по тому что вижу вокруг и по рассказам от различных людей с которыми общаюсь. Про тот же ibm слышал от товарища который там работал, правда лет эдак 5 назад, поэтому вполне могу иметь и тухленькую информацию. Но о5 же — выпускать софт для поддержки процессов и говорить всем, что «мы им пользуемся» не значит жениться.
Вполне допускаю, что вообще 90% сказанного мной бред, вызванный недостаточной осведомлённостью и текущим окружением. Что вижу — то пою.
Но, я смел наблюдать именно такое мирощущение, глубоко вовлечённых товарищей, что всё Ок. Однако, именно в таких командах встечались технические лиды, уверенные, что например, переполнение буффера вызывает исключение, зато, они были сертифицированными скрам мастерами.
Не так уж много я и информации имею, сужу в основном по тому что вижу вокруг и по рассказам от различных людей с которыми общаюсь. Про тот же ibm слышал от товарища который там работал, правда лет эдак 5 назад, поэтому вполне могу иметь и тухленькую информацию. Но о5 же — выпускать софт для поддержки процессов и говорить всем, что «мы им пользуемся» не значит жениться.
Вполне допускаю, что вообще 90% сказанного мной бред, вызванный недостаточной осведомлённостью и текущим окружением. Что вижу — то пою.
Водопад — не спасёт. Но, разом покажет глубину фейла. Остальные, посмотрев на то, как лажанула контора никогда в неё не придут. И при приёме на работу в новую контору, сей опыт примут во внимание, и очень внимательно выяснят вашу роль в том провале.
При agile — глубина падения размазанна во времени, прогресс имеется, но что бы понять всё ли идёт хорошо на старте, нужны всё-таки верная декомпозиция и предварительная оценка. Единственное достоинство для клиента — возможность соскочить в начале или в середине. Для этого, он должен крайне внимательно следить за тем, что происходит. Т.е. риски нарезанны мелкими кусочками, но никуда не делись. Нужно вести постоянный подсчёт, что тоже чего то да стоит.
С другой стороны если из 10 проектов по тому же водопаду командой было сделанно 10 проектов в срок, шанс что они налажают на проекте того же типа стремиться к нулю. Куча затрат на коммуникации и итеративную работу с рисками пропадает. Но нужно иметь дорогую, хорошо обученную команду на всех этапах, да.
При agile — глубина падения размазанна во времени, прогресс имеется, но что бы понять всё ли идёт хорошо на старте, нужны всё-таки верная декомпозиция и предварительная оценка. Единственное достоинство для клиента — возможность соскочить в начале или в середине. Для этого, он должен крайне внимательно следить за тем, что происходит. Т.е. риски нарезанны мелкими кусочками, но никуда не делись. Нужно вести постоянный подсчёт, что тоже чего то да стоит.
С другой стороны если из 10 проектов по тому же водопаду командой было сделанно 10 проектов в срок, шанс что они налажают на проекте того же типа стремиться к нулю. Куча затрат на коммуникации и итеративную работу с рисками пропадает. Но нужно иметь дорогую, хорошо обученную команду на всех этапах, да.
Если дорогая, хорошо обученная команда сделал 10 типовых проектов в срок, то они и 11 по любой методологии сделают. Небольшие размазанные риски это лучше чем дойти до срока выпуска продукта и понять, что ничерта не работает, идея неправильная, все плохо.
И, во всяком случае для внутренней разработки, проваленные проекты это нормально если делать новое, особенно когда можно рано соскочить поняв, что оно не работает и работать не будет. И я что-то не вижу ни одного преимущества для компании-разработчика от использования этого водопада, ибо «посмотрев на то, как лажанула контора никогда в неё не придут» сомнительное преимущество.
И, во всяком случае для внутренней разработки, проваленные проекты это нормально если делать новое, особенно когда можно рано соскочить поняв, что оно не работает и работать не будет. И я что-то не вижу ни одного преимущества для компании-разработчика от использования этого водопада, ибо «посмотрев на то, как лажанула контора никогда в неё не придут» сомнительное преимущество.
Ах да, я не знаю откуда вы слышали про IBM не использующий Agile, но они разрабатывают софт для поддержки Agile процессов, который сами и используют.
На сколько я слышал, в том же ibm, до сих пор никому никакой agile никуда не упёрся.
Хоть и являюсь ярым сторонником водопада, всё же не стоит упоминать софт от ibm если близко с ним не работали.
После знакомства с семейством продуктов Tivoli у меня сложилось впечатление что «там всё очень плохо».
Уже есть такое нечто на экранах страны. Ну почти такое. По результатам ежеквартальной аттестации если ты попал в первые 5% — вэлком в кадровый резерв и дальше в манагеры. Если в так сказать в последние 5% — репрессии таковы, что уволишься сам. Половина так и уходит. Самое смешное, что есть при этом некая норма баллов, от набора которой зависит квартальная премия. Так вот можно набрать норму (это 0.7 от max) и при этом все равно быть в последних 5%. Ротация людей в компании довольно большая в итоге.
Довольно самонадеяно приписывать все баги софта лени разработчика.
Имея в виду коммерческую разработку, думаю, здесь присутствует сочетание разных факторов, один явный общий фактор это зрелость, определяющий то, что мы все считаем нормой:
Думаю много еще факторов есть, и не надо валить все на Agile методики, это лишь инструменты.
Но, очевидно, что происходящее на рынке это что-то новое, так что все держим ухо востро.
Имея в виду коммерческую разработку, думаю, здесь присутствует сочетание разных факторов, один явный общий фактор это зрелость, определяющий то, что мы все считаем нормой:
- Разумная попытка менеджмента сэкономить — Очень трудно построить вменяемый бизнес кейс, почему нужно тестирование разного типа. Ну и построив его — попробуйте этот кейс протащить до бюджетного комитета. Инициатор, скорее всего столкнется с людьми далекими от понимания сути тестирования, но знакомыми с финансовыми расчетами, надо их суметь грамотно убедить не только в конечных 100500% ROI, но и в изначальных посылках
- Безграмотность руководства — слепая уверенность, что разработчик сам все протестирует, а если не сделает, мы его накажем. При этом упускается из вида, что отвечает за продукт сам заказчик в итоге, тот кто акты подписывает. В конечном счете, тот, кто подписывает, понимает, что нужно тестировать, обычно после факапа, но сталкивается с тем, что это надо как-то продать наверх, может получится, а может нет: лень, боится за свое место, не разбирается в теме… (нужное подчеркнуть). По принципу лучшее из двух зол, попытается создать тестирование своими силами, тут и велосипеды бывают и удивительно удачные попытки
- Пользователи — в общем-то они стали драйвером толкнувшим рынок в гибкие методики и в DevOps. Они неразборчивы в среднем, ведь нужно понимать что такое качественный софт, чтоб как-то ранжировать тот софт которым пользуешься.
- Отсутствие обратной связи — Коммерческие разработчики пытаются удовлетворить этого среднего пользователя, тщась угадать, что из параметров софта ему важно. Скорость выпуска фич? Продвинутость фич? UX? Стабильность? и так далее… При этом угадать — самое верное слово. Сейчас появляются решения которые могут помочь выяснить профиль использования софта, т.е. понять как используется то, что сделано, используется ли, есть ли какие ошибки. Пока этой обратной связи нет для большинства коммерческих разработчиков. Типовую поддержку я не считаю этой связью, т.е. она не собирает профиль использования и т.д.
Думаю много еще факторов есть, и не надо валить все на Agile методики, это лишь инструменты.
Но, очевидно, что происходящее на рынке это что-то новое, так что все держим ухо востро.
Совершенно согласен про невиновность инструментов. И про влияние рынка согласен. Но количество имеет свойство перерастать в качество.
Клиент, ввязавшийся в agile разработку с неопытной командой, родившийся в ряде других подобных разработкок, и получающий свой mvp рано или поздно понимает, что если он не выпустит эту сыроту на рынок, то просто напросто прогорит.
Он говорит своим клиентам — теперь, я тоже, придерживаюсь agile, вы стройте свои решения, а я выкачу вам mvp. И мы вместе будем гибки. Ну, и дальше больше.
В итоге все продают друг другу прототипы и наброски, на фронте их кое как подкрашивают и выставляют конечным пользователям. А т.к. так поступают подавляющее количество людей на рынке, ибо конкуренция, пипл хавает. Ослик плакал, но продолжал кушать кактус.
Вот ребяты уже во всю пиар компанию проводят. Ни в одном браузере ни одна фигня кроме открытия plain text документов, лично у меня не заработала.
Клиент, ввязавшийся в agile разработку с неопытной командой, родившийся в ряде других подобных разработкок, и получающий свой mvp рано или поздно понимает, что если он не выпустит эту сыроту на рынок, то просто напросто прогорит.
Он говорит своим клиентам — теперь, я тоже, придерживаюсь agile, вы стройте свои решения, а я выкачу вам mvp. И мы вместе будем гибки. Ну, и дальше больше.
В итоге все продают друг другу прототипы и наброски, на фронте их кое как подкрашивают и выставляют конечным пользователям. А т.к. так поступают подавляющее количество людей на рынке, ибо конкуренция, пипл хавает. Ослик плакал, но продолжал кушать кактус.
Вот ребяты уже во всю пиар компанию проводят. Ни в одном браузере ни одна фигня кроме открытия plain text документов, лично у меня не заработала.
У меня заработала — многоугольнички двигаются, если я по главной странице возюкаю мышиный курсор :)
Пипл хочет именно этого — скины, заставки…
Пипл хочет именно этого — скины, заставки…
Ну дык. Прямое и естественное следствие эффекта айсберга.
Если заказчик не готов платить за 99% работы, а готов платить только за 1%, то понятно, что инженеры будут с сниматься той части, за которую не плалят и перебрасываться на то, за что платят. Движущиеся многоугольнички, к примеру.
В этом смысле меня скорее удивляет удивление автора: а почему он считает, что какие-то огрехи, за устранение которых программисту никто не заплатит, должны быть устранены? С чего вдруг?
ПО тут ни разу не уникально. Китайские ножи которые выглядят «как настоящие» но разваливащиеся после отрезания пары кусков колбасы — их аналог в реальном мире.
Со временем люди научатся замечать «подводную часть айсберга» (или сами или экспертов наймут) и всё станет получше, а пока — вот так.
Если заказчик не готов платить за 99% работы, а готов платить только за 1%, то понятно, что инженеры будут с сниматься той части, за которую не плалят и перебрасываться на то, за что платят. Движущиеся многоугольнички, к примеру.
В этом смысле меня скорее удивляет удивление автора: а почему он считает, что какие-то огрехи, за устранение которых программисту никто не заплатит, должны быть устранены? С чего вдруг?
ПО тут ни разу не уникально. Китайские ножи которые выглядят «как настоящие» но разваливащиеся после отрезания пары кусков колбасы — их аналог в реальном мире.
Со временем люди научатся замечать «подводную часть айсберга» (или сами или экспертов наймут) и всё станет получше, а пока — вот так.
Вряд ли. Не останется тех, кто знает как делается подводная часть. Сейчас происходит нечто похожее на гонку вооружений между США и СССР. Только вместо количества боеголовок наращивают скорость разработки. А что получается в итоге гадость — никого не волнует, рынок сам себя привёл к этому состоянию. И разработчикам противно делать какашку и пользователям противно с ней работать, а у всех компаний — одно и то же. А если кто идёт против потока, то разоряется.
Вот так бывает, как в рыночные отношения вступают не идеальные эгоистичные и осведомлённые агенты, а реальные люди. Невидимые части айсберга первыми засасываются в водоворот лоукоста.
Вот так бывает, как в рыночные отношения вступают не идеальные эгоистичные и осведомлённые агенты, а реальные люди. Невидимые части айсберга первыми засасываются в водоворот лоукоста.
Мне кажется просто всего стало «больше и быстрее» и пропорционально увеличилось к-во багов. Как доказательство можно привести множество софта (в том числе ядро линукса к примеру) который вроде бы писался давно и умными людьми, но до сих пор там находят дыры и баги.
А по статье добавлю — недавно пытался записать видео с экрана на win8, в итоге перепробовал 4 программы, ниодна не записала видео нормально, поставил кучу кодеков (и вирусов наверное заодно с ними), почистил реестр и директ фильтры всякие, ничего не помогло.
А по статье добавлю — недавно пытался записать видео с экрана на win8, в итоге перепробовал 4 программы, ниодна не записала видео нормально, поставил кучу кодеков (и вирусов наверное заодно с ними), почистил реестр и директ фильтры всякие, ничего не помогло.
Разработчики в край обленились?
Нет, это переводчики в край недоучились.
Статья в оригинале назвывается "Have Software Developers Given Up?". "To give up" — "сдаться, прекратить деятельности или попытки, особенно в признание поражения". Правильный перевод — "У разработчиков [совсем] опустились руки?". И лень тут совсем ни при чём.
х/як-х/як в продакшн — наше все
Длина пароля в 8 символов максимум — ограничение протокола VNC, а не конкретного клиента.
Полез в комменты чтобы написать про это, а Вы опередили. В этом случае ошибка вовсе не программиста, а юзера, который не прочитал документацию. Конечно, в целях user-friendly интерфейса можно было прямо в приглашении к вводу написать, что нужно ровно 8 символов, а не пинать пользователя уже после ввода.
Ну если вам так интересно — попробуйте связаться с Olivetti или Oracle'ом. Хотя, конечно, с учётом того, что с тех пор много реорганизаций прошло будет тяжело до истины докопаться.
Ну так есть ещё более выдающийся пример. Когда разработчиков TCP/IP критиковали создатели пресловутых протоколов OSI за 4-байтный адрес, то кто-то из разработчиков TCP/IP сказал «да, в сетях OSI этой проблемы не будет...», а когда у его собеседников вспыхнула на лице улыбка продолжил "… потому что они никогда не станут настолько популярными, чтобы иметь столько пользователей".
Вот, собственно, и всё: либо вы «вкручиваете» костыли, либо опаздываете — и умираете.
P.S. Разработчики «протоколов OSI», правда, отыгрались: использовав «административный ресурс» они заставили все ВУЗы учить TCP/IP в терминах пресловутой модели OSI, не имеющей к TCP/IP, в общем-то, никакого отношения. Но это уже совсем другая история.
Вот, собственно, и всё: либо вы «вкручиваете» костыли, либо опаздываете — и умираете.
P.S. Разработчики «протоколов OSI», правда, отыгрались: использовав «административный ресурс» они заставили все ВУЗы учить TCP/IP в терминах пресловутой модели OSI, не имеющей к TCP/IP, в общем-то, никакого отношения. Но это уже совсем другая история.
Тестировщики наше все. Не представляю, что бы мы делали без этих людей. Работаю в российской компании, делающей софт и железки. Да, такие (и компании, и тестировшики в штате у них) есть, точно вам говорю…
Как правило, условия разработки диктует тот, кто платит денежку. Каким бы крутым и опытным разработчиком ты не был, ты работаешь за деньги, добровольно продавая себя и свои навыки. За деньги, Карл. А не за идею о хорошем и качественном софте и железе, и тем более не за идею радостных и веселых конечных пользователей.
А если по простому — дядя сказал сделать завтра, ты берешь палки, какашки и делаешь завтра. Или делаешь, чтоб было готово завтра, если ты лидер группы. Или отдела. Причем, если у тебя есть совесть и… не знаю, что-то такое, что не позволит тебе сделать «полный тяп-ляп», который развалится при первом запуске прям на столе приемной комиссии — ты делаешь хорошо, продумывая мелочи и за нехваткой времени залепляя их заглушками с грустным «потом доделаем, наверное». Что будет, если ты не сделаешь? Плохо. А если ты потратишь ограниченные человекочасы на качество, не выполнив основной поставленной перед тобой задачи? Очень плохо. А что же будет, если ты выполнишь основную задачу, с 5-10 (да хоть 20) неточностями и багами, но таки в рабочем состоянии, по большей части? Плохо. Но лучше, чем очень плохо, правда?
И тестировщики, и разработчики, и менеджеры тут не причем. Тестирование не гарантирует отсутствие ошибок. Порядок — он в головах. Дело в поставленных задачах и их исполнении. Порою очень смешно читать про всякие методики планирования и расчета времени на разработку, особенно если задания, исходящие от руководства компании, начинаются со слов «Бросай все свои текущие дела, и делай срочно ». Я очень надеюсь, что это специфика именно российских компаний, во всяком случае хочется в это верить.
П.С. В коллективе даже есть специальный локальный мем, «бросай все и иди настраивать мультики», именно для таких заданий, срочных, бессмысленных и беспощадных )
Как правило, условия разработки диктует тот, кто платит денежку. Каким бы крутым и опытным разработчиком ты не был, ты работаешь за деньги, добровольно продавая себя и свои навыки. За деньги, Карл. А не за идею о хорошем и качественном софте и железе, и тем более не за идею радостных и веселых конечных пользователей.
А если по простому — дядя сказал сделать завтра, ты берешь палки, какашки и делаешь завтра. Или делаешь, чтоб было готово завтра, если ты лидер группы. Или отдела. Причем, если у тебя есть совесть и… не знаю, что-то такое, что не позволит тебе сделать «полный тяп-ляп», который развалится при первом запуске прям на столе приемной комиссии — ты делаешь хорошо, продумывая мелочи и за нехваткой времени залепляя их заглушками с грустным «потом доделаем, наверное». Что будет, если ты не сделаешь? Плохо. А если ты потратишь ограниченные человекочасы на качество, не выполнив основной поставленной перед тобой задачи? Очень плохо. А что же будет, если ты выполнишь основную задачу, с 5-10 (да хоть 20) неточностями и багами, но таки в рабочем состоянии, по большей части? Плохо. Но лучше, чем очень плохо, правда?
И тестировщики, и разработчики, и менеджеры тут не причем. Тестирование не гарантирует отсутствие ошибок. Порядок — он в головах. Дело в поставленных задачах и их исполнении. Порою очень смешно читать про всякие методики планирования и расчета времени на разработку, особенно если задания, исходящие от руководства компании, начинаются со слов «Бросай все свои текущие дела, и делай срочно ». Я очень надеюсь, что это специфика именно российских компаний, во всяком случае хочется в это верить.
П.С. В коллективе даже есть специальный локальный мем, «бросай все и иди настраивать мультики», именно для таких заданий, срочных, бессмысленных и беспощадных )
ставьте заказчика в известность что при таких условиях качество будет низким. Как минимум сможете сказать — мы ж предупреждали.
Хочет чуда — ну пойди поищи волшебников.
Понятно что заработок терять не хочется, но потеря репутации может обойтись дороже.
Хочет чуда — ну пойди поищи волшебников.
Понятно что заработок терять не хочется, но потеря репутации может обойтись дороже.
Не всегда получается, это было бы во многих случаях к месту.
Но посыл поста не в этом… Вам не кажется, что раз явление присутствует на рынке и многие люди это замечают, то это ни плохо и ни хорошо — это просто движение рынка.
В ту же степь можно вспомнить советские ботинки (некрасивые, да), которые носились три поколения VS китайские тапочки из клетчатых сумок. Да, невысокого качества. Но ведь пост именно об этом. Почему такая странная аналогия? Очень много параллелей лично мне видится. Нет смысла тратить год на разработку качественного приложения для интернет магазина, который закроется через полгода. Нет смысла разрабатывать софт под тендер и вылизывать код, потому что тендер разыграют через две недели, а ваша компания уже подала заявку.
По большому счету вообще нет смысла писать что-то достаточно длительное время, с современным темпом развития технологий и рывками моды и спроса. Слишком много рисков пролететь.
Но есть исключения. Много. Например — когда приобретается не сам продукт, а продукт как сервис. Абонентская плата. Постоянный штат. Техподдержка. Но это уже совсем другая история, верно?
Но посыл поста не в этом… Вам не кажется, что раз явление присутствует на рынке и многие люди это замечают, то это ни плохо и ни хорошо — это просто движение рынка.
В ту же степь можно вспомнить советские ботинки (некрасивые, да), которые носились три поколения VS китайские тапочки из клетчатых сумок. Да, невысокого качества. Но ведь пост именно об этом. Почему такая странная аналогия? Очень много параллелей лично мне видится. Нет смысла тратить год на разработку качественного приложения для интернет магазина, который закроется через полгода. Нет смысла разрабатывать софт под тендер и вылизывать код, потому что тендер разыграют через две недели, а ваша компания уже подала заявку.
По большому счету вообще нет смысла писать что-то достаточно длительное время, с современным темпом развития технологий и рывками моды и спроса. Слишком много рисков пролететь.
Но есть исключения. Много. Например — когда приобретается не сам продукт, а продукт как сервис. Абонентская плата. Постоянный штат. Техподдержка. Но это уже совсем другая история, верно?
>ставьте заказчика в известность что при таких условиях качество будет низким
и он уйдет к тому, кто согласится на те же сроки, а в известность про косяки не поставит
и он уйдет к тому, кто согласится на те же сроки, а в известность про косяки не поставит
Я очень надеюсь, что это специфика именно российских компаний
Вы можете с чистой совестью хоронить эту надежду. В Европе подобные компании также встречаются.
Думал кто-то из коллег отписался. У нас тоже есть «мультики», используются когда «не готово, но вот тот „может быть заказчик“ захочет, поэтому надо показать хорошо», как правило сопровождаются ответными комментариями «но мы ж делаем не то, что ему нужно» и дальнейшей перепалкой.
Вообще можно провести аналогию со старой историей о портном, которого жадный клиент уговорил сделать из одного куска ткани не одну а десять шапок. Один портной скажет что клиент рехнулся, объяснит ему что невозможно сделать хорошую шапку из такого малого количества материала, и либо потеряет клиента — либо добьётся нормального технического задания. Другой же сделает эти 10 «микрошапок», а клиент пусть сам думает, как он их теперь будет надевать.
Проблема программистов не в том, что им платят за то чтобы они делали работу быстрее чем возможно сделать качественно. Проблема в том что программисты не готовы объяснять начальству, что за такие сроки работа будет говно, не готовы отказаться от работы, если видят что получится говно. А поскольку таких кадров, не готовых обсуждать разумность выставленных сроков — дофига, остальные тоже вынуждены торопиться за поездом чтобы не остаться без работы.
Проблема программистов не в том, что им платят за то чтобы они делали работу быстрее чем возможно сделать качественно. Проблема в том что программисты не готовы объяснять начальству, что за такие сроки работа будет говно, не готовы отказаться от работы, если видят что получится говно. А поскольку таких кадров, не готовых обсуждать разумность выставленных сроков — дофига, остальные тоже вынуждены торопиться за поездом чтобы не остаться без работы.
> Проблема в том что программисты не готовы объяснять начальству, что за такие сроки работа будет говно
Или в том, что начальство не знает старой хохмы про "быстро, качественно, недорого".
Или в том, что начальство не знает старой хохмы про "быстро, качественно, недорого".
Раскажу о ситуации с точки зрения 1сника, новичка правда (не закидывайте сразу). Итак, есть человек, вчерашний студент который нашел свою первую работу. Ему дают книжку по 1с и видео, а через неделю-две изучения пихают на производство реального продукта. При этом наставник лишь изредка смотрит написанный код (раз-два эдак в месяц), а результат требует еще вчера, мотивируя это тем что работник паршивый, и вот эту фичу он(стажер) бы мог реализовать на 2 часа быстрее. В результате стажер начинает думать что его нафиг уволят если он будет работать медленно, и все ускоряется в ущерб качеству. Подумаешь на 15-20 закрытых обращений хоть одна ошибка но найдется, а даже чаще, но ведь больше не ругают, и даже платить начали деньги которых не только на еду и жилье хватает, значит это правильно, значит так и буду делать. Руководству тоже хорошо, лишь бы клиенту указать меньше часов (вдруг за большее количество не продадим), а на ошибки плевать, мыши кактус едят — значит их все устраивает. А возмущаться бесполезно, головой покивают и опять на задачу дают минимальное количество времени за которое вообще успеть можно (а часто еще меньше), бывает просят оценить за сколько справишься, называешь им цифру — не, мы столько не продадим, надо в 3-4 раза быстрее.
дружище, у меня было такое же, только с C++ и на производстве софта для военных
Вот, кажется, и нашёлся тот, кто вот этот софт писал…
Верно ли я понимаю, что вы франшизники с почасовой оплатой? Те, кто пилят собственный продукт (пусть на 1С) — к примеру, типовые конфигурации, или вообще кастом под клиента, в меньшей степени подвержены таким проблемам. Тоже самое касается и тех (не ИТ компании), у кого свои программисты сами делают свой продукт — у них то аврал, то тишина, а зарплата капает — во время тишины и спокойствия как раз приводят в божеский вид все то, что сделали наспех во время очередного аврала, комментируют код и ваяют описание систем.
Хм, ну как сказать, в целом мы франч, разрабатываем два собственных продукта (я на одном из них, он два последних года даже умудряется в этот список попадать: http://1c.ru/news/info.jsp?id=19719), плюс дорабатываем наши же продукты под конкретных заказчиков. И я говорил как о разработке типовой конфигурации, так и о адаптации под заказчика. Зарплата сотрудников от часов не зависит.
Извините, не смог пройти мимо.
Работаю сисадмином в одной IT компании ориентированной за США. Имеется весьма крупный клиент. Пишем по большей части на C#. С разработчиками имею дело каждый день весьма плотно. И знаете что? Сейчас в ходу ASAP Driven Development. Таки да — «сделать максимум за неделю», «мы уже продали, срочно напилите функционал» — нормальный QA процесс просто невозможно произвести за сроки которые ТРЕБУЕТ клиент. Потеря клиента — минус большой капитал для фирмы. Посему так и работаем.
З.Ы. Есть проект в котором логи дев-консоли просто потрясают воображение количеством информации. Туда выводится практически все что происходит на фронте и беке. 2 года как в релизе…
Работаю сисадмином в одной IT компании ориентированной за США. Имеется весьма крупный клиент. Пишем по большей части на C#. С разработчиками имею дело каждый день весьма плотно. И знаете что? Сейчас в ходу ASAP Driven Development. Таки да — «сделать максимум за неделю», «мы уже продали, срочно напилите функционал» — нормальный QA процесс просто невозможно произвести за сроки которые ТРЕБУЕТ клиент. Потеря клиента — минус большой капитал для фирмы. Посему так и работаем.
З.Ы. Есть проект в котором логи дев-консоли просто потрясают воображение количеством информации. Туда выводится практически все что происходит на фронте и беке. 2 года как в релизе…
> «Мне ругнулось, что пароль слишком короткий. Окей, я добавил пару символов, после чего мне вернуло сообщение о том, что пароль должен состоять из восьми знаков»
*Что введенный пароль был *сокращен* до 8-ми символов
Т.е. сначала ему написали что пароль слишком короткий, а когда он ввел подлиннее — ему его сократили т.к. слишком длинный получился.
*Что введенный пароль был *сокращен* до 8-ми символов
Т.е. сначала ему написали что пароль слишком короткий, а когда он ввел подлиннее — ему его сократили т.к. слишком длинный получился.
ну и тестеры давно уже вымерли, никто и не заметил. Мы теперь пишем интеграционные тесты и догфудим, во как.
В университете преподаватель по курсу экономика на производстве рассказал советскую байку.
Решили поменять руководящий состав на заводе. Пришли молодые управленцы и говорят:«У вас есть брак, а почему мы его не учитываем в планах?». В итоге установили планку брака не более 10%. Шло время. На других заводах брака уже меньше 1%. Начали разбираться в чём дело. Оказалось, что когда в плане по браку оставался запас, весь исправимый брак «списывали» в неисправимый.
Факторов которые влияют на качество продукции много — это и не профессиональное управление, инертность пользователей(в первую очередь выбирают не качественное, а что первым выдаст гугл), низкий порог вхождения в сферу информационных технологий, отсутствие нормальной стандартизации и т.д.
На сегодняшний день, создание качественной продукции — это выбор, а не обязанность.
P.S. Что странно, а почему за один месяц он не нашёл ни одного бага в windows 10?
Решили поменять руководящий состав на заводе. Пришли молодые управленцы и говорят:«У вас есть брак, а почему мы его не учитываем в планах?». В итоге установили планку брака не более 10%. Шло время. На других заводах брака уже меньше 1%. Начали разбираться в чём дело. Оказалось, что когда в плане по браку оставался запас, весь исправимый брак «списывали» в неисправимый.
Факторов которые влияют на качество продукции много — это и не профессиональное управление, инертность пользователей(в первую очередь выбирают не качественное, а что первым выдаст гугл), низкий порог вхождения в сферу информационных технологий, отсутствие нормальной стандартизации и т.д.
На сегодняшний день, создание качественной продукции — это выбор, а не обязанность.
P.S. Что странно, а почему за один месяц он не нашёл ни одного бага в windows 10?
Качество падает потому что программисты больше зарабатывают чем другие. Заканчивает юное создание школу, крутит головой по сторонам — где больше платят. Понятно что в IT да еще и в уютном офисе сидишь а не где то на улице впахиваешь. А программирование все таки процесс творческий и к этому нужны хоть какие то природные задатки.
.
.
Всё упирается в требования. При ужесточении требований к качеству, стоимость ПО растет по экспоненте, что не выгодно никому. Клиент, очевидно, хочет дешевле. Клиент предпочтет бажную версию сейчас, чем готовую позже, т.к., даже в бажном исполнении, программа уже может экономить ему время и тем самым приносить прибыль. Да вспомните хоть, как народ дерется за доступ в бету к всяким-разным играм :-)
С другой стороны, разработчику тоже нужны деньги пораньше — чтобы довести продукт до ума при перерасходе бюджета (что при разработке ПО встречается сплошь и рядом), ну или чтобы просто отдать пораньше кредит в банк, сэкономив на процентах.
И не нужно говорить, что раньше софт был качественней — раньше софт сыпался в access violation через раз из-за несовершенного инструментария.
Из-за отсутствия интернета не было возможности взять и накатить патч, так что да, тестировали и вылизывали как могли. Что не лучшим образом сказывалось и на сроках разработки, и на цене. А дешевое и некачественное всегда конкурентноспособнее дорогого и качественного. Тот же айфон — это редкое исключение. Было.
С другой стороны, разработчику тоже нужны деньги пораньше — чтобы довести продукт до ума при перерасходе бюджета (что при разработке ПО встречается сплошь и рядом), ну или чтобы просто отдать пораньше кредит в банк, сэкономив на процентах.
И не нужно говорить, что раньше софт был качественней — раньше софт сыпался в access violation через раз из-за несовершенного инструментария.
Из-за отсутствия интернета не было возможности взять и накатить патч, так что да, тестировали и вылизывали как могли. Что не лучшим образом сказывалось и на сроках разработки, и на цене. А дешевое и некачественное всегда конкурентноспособнее дорогого и качественного. Тот же айфон — это редкое исключение. Было.
В подтверждение к статье, при попытке залогиниться для написания комментария я получил вот такой дивный результат:
$('#captcha-s-field').removeClass('hidden');
//$('#recaptcha_response_field').attr('data-required', 'true');
form_errors_show('#login_form', {
'captcha':'Необходимо разгадать капчу'
});
reloadRecaptcha();
setTimeout(function(){
toggleSubmitButton($('#login_form'));
},200);
$('#captcha-s-field').removeClass('hidden');
//$('#recaptcha_response_field').attr('data-required', 'true');
form_errors_show('#login_form', {
'captcha':'Необходимо разгадать капчу'
});
reloadRecaptcha();
setTimeout(function(){
toggleSubmitButton($('#login_form'));
},200);
Рассказываю из опыта. Наша беда не в качестве кода, и не в кривых руках программистов.
Проблемы в больших запросах у программистов. Работодателю надо сделать продукт за месяц, но ему не выгодно держать большой штат разработчиков с большими зарплатами, поэтому на рынок выпускается хоть какая-нибудь альфа, едва прошедшая тестирование.
Проблемы в больших запросах у программистов. Работодателю надо сделать продукт за месяц, но ему не выгодно держать большой штат разработчиков с большими зарплатами, поэтому на рынок выпускается хоть какая-нибудь альфа, едва прошедшая тестирование.
Проблемы в больших запросах у программистов
А что значит большие запросы у программистов? Если по деньгам и прочим вкусностям, то это закон спроса и предложения. Не была бы спроса, не было бы запросов.
Если о желании сделать качественнее, а не тяп ляп это нормальное желание любого специалиста, за исключением тех кто тупо просиживает штаны за зар.плату (скажем, не каждому архитектору или строителю хочется сдавать кривое, разваливающуюся здание, да ещё и ставить на это свою репутацию).
> Проблемы в больших запросах у программистов.
В процессе чтения статьи за спиной разворачивалась очередная серия «на месте допилите» сериала «нам же обещали что до отправки мы у себя всё соберём и протестируем».
Не знаю как у остальных разработчиков, но моя лень мне помогает а не наоборот, после прочтения ощущение что он просто создан работать тестером ПО так как притягивает баги.
Да и бывает что не только разработчики не доглядели но и тестеры и всплывают баги в процессе эксплуатации.
Всякое в жизни бывает, все не предусмотришь.
Да и бывает что не только разработчики не доглядели но и тестеры и всплывают баги в процессе эксплуатации.
Всякое в жизни бывает, все не предусмотришь.
> Не знаю как у остальных разработчиков, но моя лень мне помогает а не наоборот
Хороший разработчик должен быть ленивым.
Хороший разработчик должен быть ленивым.
сообщение о том, что пароль должен состоять из восьми знаков
password truncated to length of 8 — означает, что пароль обрезан до 8 символов, а не должен состоять из 8 символов. Это автора и возмутило, что то короткий, то длинный
откладываю установку адблока
…
причина этой беды: всплывающая реклама во всю страницу
сам себе злобный буратино
Добавлю майкрасофта:
1. Не заменили значок для сайта офиса:
2. Установка офиса — не полностью помещается на экран форма входа (и проскролить нельзя! )
Мелочи конечно но вот такое отношения сейчас к выпускаемым продуктам.
1. Не заменили значок для сайта офиса:
2. Установка офиса — не полностью помещается на экран форма входа (и проскролить нельзя! )
Мелочи конечно но вот такое отношения сейчас к выпускаемым продуктам.
Добавлю: время такое что понастоящему опытных программистов сейчас все меньше в процентном отношении.
Сейчас уже считается нормой
Сейчас уже считается нормой
- херачить классы на 2000 строк
- использовать наследование там где оно вообще не нужно
- усложнять код анонимными методами
- использовать в работе только шаблон Repository
На самом деле сама статья — это один огромный наброс. Не говоря уже о провокационном переводе заголовка. Как тут уже выше указывали, «Have Software Developers Given Up?» правильнее перевести как «Сдались ли разработчики ПО?». Т.е. сам неправильный перевод заголовка статьи — это уже наброс.
Но даже при корректном переводе статья не передаёт быть набросом. Так можно на самом деле раскритиковать любую профессию. Например — дворников.
Вот без напряга родил план статьи «Сдались ли дворники?» чисто на жизненных примерах:
— кушал в заведении — под столом была прилеплена жвачка;
— шел по улице — увидел переполненную мусорку, из которой вываливался мусор;
— выпал снег — не расчистили проезд к подъезду;
— шел по улице — навернулся на льду;
— огромные лужи перед работой;
— дым от сжигаемых осенних листьев не даёт нормально дышать;
— дома на мониторе неубранная пыль;
— в офисе прошел по вымытому полу — остались грязные следы!!!
Теперь осталось добавить пафоса, сверстать всё в одну статью и прикрепить заголовок — «Неужели дворники опустили руки?»
Смешно? Вот и я о том же…
Но даже при корректном переводе статья не передаёт быть набросом. Так можно на самом деле раскритиковать любую профессию. Например — дворников.
Вот без напряга родил план статьи «Сдались ли дворники?» чисто на жизненных примерах:
— кушал в заведении — под столом была прилеплена жвачка;
— шел по улице — увидел переполненную мусорку, из которой вываливался мусор;
— выпал снег — не расчистили проезд к подъезду;
— шел по улице — навернулся на льду;
— огромные лужи перед работой;
— дым от сжигаемых осенних листьев не даёт нормально дышать;
— дома на мониторе неубранная пыль;
— в офисе прошел по вымытому полу — остались грязные следы!!!
Теперь осталось добавить пафоса, сверстать всё в одну статью и прикрепить заголовок — «Неужели дворники опустили руки?»
Смешно? Вот и я о том же…
Согласен с автором. У меня аналогичные ощущения возникают уже лет 10.
Защитники разработчиков вызывают улыбку. Вспомните Райкина:
«я лично пришиваю пуговицы. К пуговицам претензии есть?»
…
«я лично писал цикл do-while. К циклу претензии есть?»
Защитники разработчиков вызывают улыбку. Вспомните Райкина:
«я лично пришиваю пуговицы. К пуговицам претензии есть?»
…
«я лично писал цикл do-while. К циклу претензии есть?»
Спрашивать с разработчиков за то, что они сделали программу, которая удовлетворяет спецификациям и уложились в отведенные сроки — это уже как-то… за гранью!
А если хотите хороший костюм… э… хороший код — тогда и отдайте управление процессом разработки в руки программистов! Будет вам отличный продукт — без багов, удовлетворяющий каждого клиента, использующий новейшие разработки в области ПО — только очень дорого и медленно. Но вам-то хочется быстро, качественно, НЕДОРОГО?
Так что — к циклу do-while претензии есть?
А если хотите хороший костюм… э… хороший код — тогда и отдайте управление процессом разработки в руки программистов! Будет вам отличный продукт — без багов, удовлетворяющий каждого клиента, использующий новейшие разработки в области ПО — только очень дорого и медленно. Но вам-то хочется быстро, качественно, НЕДОРОГО?
Так что — к циклу do-while претензии есть?
Всем добрый день!
я пишу исследование на тему применения agile методов в российских digital проектах, если вы можете, проведите, пожалуйста 5 минут и помогите хорошему человеку :) http://goo.gl/forms/FzvhiLyciH Спасибо!
я пишу исследование на тему применения agile методов в российских digital проектах, если вы можете, проведите, пожалуйста 5 минут и помогите хорошему человеку :) http://goo.gl/forms/FzvhiLyciH Спасибо!
Маркетологи (и сеошники) — ГАААВНООО!
Это все, что я хотел сказать здесь — обсуждение полностью не читал (упаси Боже!)
Это все, что я хотел сказать здесь — обсуждение полностью не читал (упаси Боже!)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработчики в край обленились?