Справка - Поиск - Участники - Войти - Регистрация
Полная версия: А вот которые - программисты?
Частный клуб Алекса Экслера > Землячества и клубы
Страницы: 1, 2, 3, 4, 5, 6, 7
Troubleshooter
30 марта 2015, 01:44

Martin написал: А вот, господа программисты, вам часто приходится делать рефакторинг существующего кода?

Чуть ли не ежедневно, это часть производства. И сам и стимулирую подчинённых. Имплементировать сравнительно большую задачу над которой работает несколько программистов без рефакторинга очень сложно, ИМО.
Газонокосильщик
30 марта 2015, 09:10

Troubleshooter написал: Можно, конечно, отрицать чужой опыт и набивать свои шишки

Лично я с твоим опытом не знаком. И с твоими шишками - тоже biggrin.gif !
littlegene
30 марта 2015, 11:16

Газонокосильщик написал:
Лично я с твоим опытом не знаком. И с твоими шишками - тоже biggrin.gif !

Чужой ("всейный") опыт наверное имеется ввиду - просто подразумевает выработку наилучших решений, которыми затем и пользуются опять-таки все(а иначе, любой, даже самый трудолюбивый и продуктивный программист, который гордится, что он "пашет и никого не слушает" - занимается ремесленничеством, только и всего). Эффективные и быстрые алгоритмы важны, но также важны и различные паттерны (не только Gof4), коли мы хотим справляться с ортогональной сутью более-менее сложной системы. Игнорировать чужой опыт(выливающийся в обобщенные решения) - это считать, что кругом -дураки.
Газонокосильщик
30 марта 2015, 12:40
Я про "всейный" опыт не говорил.
ЗЫ - наверное правильнее будет всехный.
Troubleshooter
30 марта 2015, 14:48

littlegene написал:
Чужой ("всейный") опыт наверное имеется ввиду -  просто подразумевает выработку наилучших решений, которыми затем и пользуются опять-таки все(а иначе, любой, даже самый трудолюбивый и продуктивный программист, который гордится, что он "пашет и никого не слушает" - занимается  ремесленничеством, только и всего). Эффективные и быстрые алгоритмы важны, но также важны и различные паттерны (не только Gof4), коли мы хотим справляться с ортогональной сутью более-менее сложной системы. Игнорировать чужой опыт(выливающийся в обобщенные решения) - это считать, что кругом -дураки.

Хорошо сказано!
Troubleshooter
30 марта 2015, 15:06

Газонокосильщик написал:
Лично я с твоим опытом не знаком. И с твоими шишками - тоже biggrin.gif !

Oh, don't be shy smile.gif если интересно - просто спроси. Занимался
разработкой приложений на С++ и asm для контроля bespoke железа, программирование контроллеров на asm, разработка интерпретаторов - это ещё в студенческие годы. Затем работа в очень крупных банках и телеком компаниях в трех разных странах. Сначала С++, затем разработка хранилищ данных на Oracle (oracle ocp dba), когда роль архитектора баз данных перестала быть интересной, переключился на Java (приложения для fx трэдинга, интеграция всяческих энтерпрайз приложений) Java, Oracle db и Coherence. позиции от роли эквивалентной инженеру 2й категории до главного инженера и вице-президента. Сейчас занимаюсь консультированием финансовых организаций по вопросам интеграции энтерпрайз приложений.
Газонокосильщик
30 марта 2015, 16:25
Так это то, чем ты занимался/занимаешься. Речь-то не об этом wink.gif .
ЗЫ - удачи тебе!
Martin
30 марта 2015, 21:43

Troubleshooter написал: переключился на Java (приложения для fx трэдинга, интеграция всяческих энтерпрайз приложений) Java, Oracle db и Coherence

Как ты думаешь о будущем Scala, как замене Java?
Martin
30 марта 2015, 22:03

Troubleshooter написал: Чуть ли не ежедневно, это часть производства. И сам и стимулирую подчинённых. Имплементировать сравнительно большую задачу над которой работает несколько программистов без рефакторинга очень сложно, ИМО.

TDD юзаете?
Troubleshooter
31 марта 2015, 02:40

Martin написал:
Как ты думаешь о будущем Scala, как замене Java?

У этого вопроса две составляющие -

1) теоретическая, как двигатель индустрии и т.п. - тогда думаю если это и произойдёт то не скоро. Почему - хорошо проссумировано в статье по ссылке. Я сам в свободное время смотрю на Скалу, и во многом согласен с тем что здесь написано https://gist.github.com/anonymous/1406238

2) практическая составляющая - стоит ли учить Скалу. ИМО, да, стоит. Причина дана в той же статье "Because it's effectively impossible to hire people with prior Scala experience (of the hundreds of people we've interviewed perhaps three had Scala experience, of those three we hired one)". В то время как у Скалы уже есть своя ниша.

Я думаю, что java заменит язык, который значительно упростит работу с многопоточностью. Но, сколько лет потребуется чтобы окончательно вытеснить java... Например Кобол до сих пор используется в банках. А java сейчас распространена гораздо больше чем был распространен Кобол, хотя бы в силу общего развития IT.
Troubleshooter
31 марта 2015, 02:51

Martin написал:
TDD юзаете?

Конечно. И TDD и BDD. Это часть производства. TDD, помимо контроля качества, отличный способ документирования. Клиентам нередко отправляемых ссылки на тесты в качестве иллюстрации как что то работает, и этого вполне хватает. BDD отлично работает с бизнес-аналистами. Те, после небольших объяснений, сами с удовольствием правят входные файлы облегчая жизнь разработчиков.
Marfutta
31 марта 2015, 03:22
Прочитала первую страницу.
Много ушло в IT из химии. И мы не исключение smile.gif .
Когда мы училмсь, это всё только начиналось, был курс АСУ и вычислительной техники. Между прочим, тогда на этой кафедре лаборантом работал небезызвестный Д.А.Медведев, его отец работал в нашем институте.
Первый мой конфликт с программированием случился тогда же: как-то мы с моим будущим мужем договорились о свидании, он опоздал на час. И сказал, что его пустили на какую-то крутую машину, а если бы там был цветной экран, он вообще бы не пришёл facepalm.gif .

После развала химического завода, на котором мы работали, попали в фирму, где уже требовалось знание компьютера и даже умение программировать. Учились на ходу, знания кой-какие были после завода. Муж мой наконец дорвался до любимого дела, у него очень хорошо всё пошло, увлёкся ораклом, самостоятельно изучал, ездил сдавать экзамены в Питер (тогда в Минске не было конторы по приёму экзаменов), после получения сертификатов сразу предложили работу в Германии. Здесь стал супер специалистом smile.gif .
Dead Knight
31 марта 2015, 03:23

Troubleshooter написал:
Конечно. И TDD и BDD. Это часть производства.

redface.gif Ну вот ни разу не видел ни одного большого проекта полностью соответствующего ТДД...
Troubleshooter
31 марта 2015, 04:21

Dead Knight написал:
redface.gif  Ну вот ни разу не видел ни одного большого проекта полностью соответствующего ТДД...

Для более предметного обсуждения, can you define what full compliance with TDD is, in your opinion?

Во время разработки нужно проверить работает ли только что написанный код. А по завершению какой&то задачи не сломалось ли что-то. Мы относимся без фанатизма, но юнит тесты просто удобны для этого. И начинать удобней с них, хотя допускают что это субъективно.

В проекте где я сейчас работаю СI ( continuous integration ) просто не пропустит код с покрытием меньше чем 70%, но QA team стремится к покрытию 85%. Допуск даётся чтобы учесть "чистые" POJO и т.п. И это во всех банковских проектах где я участвовал за последние 10 лет. Несколько варьируется уровень покрытия только. До этого зачатки TDD тоже были, но выборочно.

На самом деле вопросы по опыту использования TDD одни из основных на интервью.
Газонокосильщик
31 марта 2015, 09:07

Marfutta написала: сказал, что его пустили на какую-то крутую машину, а если бы там был цветной экран, он вообще бы не пришёл

Как я его понимаю! biggrin.gif
littlegene
31 марта 2015, 11:07

Martin написал: А вот, господа программисты, вам часто приходится делать рефакторинг существующего кода?

Рефакторинг у меня когда 80-90 процентов уже написано и работает, и по личной (увы) инициативе.
TDD тоже по личной инициативе, причем специально во время недель рефакторинга.
Да, я не владею TDD хорошо, поскольку принцип S.O.L.I.D. где TDD работает идеально, мне в моих обязанностях требуется только 1 раз из 3 разноманерных разработок.
Troubleshooter
31 марта 2015, 16:18

littlegene написал:
Рефакторинг у меня когда 80-90 процентов уже  написано и работает, и по личной (увы) инициативе.
TDD тоже по личной инициативе, причем специально во время недель рефакторинга.
Да, я не владею TDD хорошо, поскольку  принцип S.O.L.I.D. где TDD работает идеально, мне в моих обязанностях требуется только 1 раз из 3 разноманерных разработок.

На счет SOLID если это java, то есть библиотеки позволяющие обходить подобные ограничения. Понятно, что затраты на создание и поддержание тестов возрастают.

Если это не закрытая информация, то как у вас организовано тестирование? Скажем, разработчик закончил с внесением изменений. Как оценивается что эти изменения работают как ожидается - это касается happy path (извиняюсь, я не знаю некоторых общепринятых терминов на русском) и обработки сценариев ошибок. Как оценивается что изменения не внесли ошибок в других частях приложения? Если приложение должно удовлетворять каким то требованиям по производительности, как оценивается что после внесения изменения производительность приложения не пострадала? Есть ли load tests? Есть ли бизнес пользователи, которые проверяют что приложение работает правильно?
Mx
31 марта 2015, 22:35

Troubleshooter написал: Я думаю, что java заменит язык, который значительно упростит работу с многопоточностью. Но, сколько лет потребуется чтобы окончательно вытеснить java... Например Кобол до сих пор используется в банках. А java сейчас распространена гораздо больше чем был распространен Кобол, хотя бы в силу общего развития IT.

Многопоточности присуща некая неустранимая сложность, которая не может быть устранена с помощью языковых конструкций. Возможно никакого нового языка вместо Javы не появится, а просто Java будет дополнена конструкциями, облегчающими разработку многопоточных приложений. С Javой я мало знаком, а языки .NET эволюционируют в этом направлении.

Troubleshooter написал: В проекте где я сейчас работаю СI ( continuous integration ) просто не пропустит код с покрытием меньше чем 70%, но QA team стремится к покрытию 85%. Допуск даётся чтобы учесть "чистые" POJO и т.п. И это во всех банковских проектах где я участвовал за последние 10 лет. Несколько варьируется уровень покрытия только. До этого зачатки TDD тоже были, но выборочно.

По науке unit тесты должны писать разработчики, а QA должны писать acceptance тесты.

Mx
31 марта 2015, 22:48

Troubleshooter написал: На счет SOLID если это java, то есть библиотеки позволяющие обходить подобные ограничения. Понятно, что затраты на создание и поддержание тестов возрастают.

Можно ради интереса покритиковать некоторые принципы SOLID, чтобы показать что это - не догма, а просто материал к размышлению.
Single Responsibility: если у вас достаточно детально прописана спецификация - слишком скурпулёзное следование этому принципу приведёт к большому количеству мелких классов и росту сложности, потому что появятся ещё классы, которые увязвают эти классы и позволяют им работать вместе.
Open/closed principle: слишком скурпулёзное следование этому принципу в динамически развивающемся проекте может привести к большому количеству частично устаревших сущностей (функций, классов, файлов) и некоторому количеству сущностей-заплаток и натяжек которые подгоняют старые сущности под новые требования. Удаление устаревших сущностей - тоже не очень хорошая операция. Если вы поменяли какую-то функцию/класс/модуль, то вы всегда можете посмотреть на изменения с помощью средств системы контроля версии. Если вы удалили один файл и вместо этого добавили другой - это сложней.
Газонокосильщик
31 марта 2015, 23:19
Ещё раз перечитал https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%...%B8%D0%BD%D0%B3, ещё раз вспомнил Скальпель Оккама применительно к программированию - не занимайся программированием ради программирования.
Dead Knight
31 марта 2015, 23:28

Troubleshooter написал:
Для более предметного обсуждения, can you define what full compliance with TDD is, in your opinion?


Sure, I can. Когда я говорю о ТДД, я говорю о вполне конкретном, классическом понимании ТДД, когда в начале пишутся Unit/Component/System тесты, и только после этого начинается разработка.


Troubleshooter написал:Во время разработки нужно проверить работает ли только что написанный код. А по завершению какой&то задачи не сломалось ли что-то. Мы относимся без фанатизма, но юнит тесты просто удобны для этого.  И начинать удобней с них, хотя допускают что это субъективно.


Конечно удобны. Вот только юниттесты это лишь часть ТДД. Без компонентных и системных тестов это будет лишь профонация, а не ТДД, даже при 100% покрытии. Хотя, если проект маленький, то проблем конечно нет.


Troubleshooter написалВ проекте где я сейчас работаю СI ( continuous integration ) просто не пропустит код с покрытием меньше чем 70%, но QA team стремится к покрытию 85%.


Вообще, QA никакого отношения к юниттестам иметь не должны.


Troubleshooter написал: На самом деле вопросы по опыту использования TDD одни из основных на интервью.

Вопросы на интервью это отдельная и больная для девелоперов тема...
Dead Knight
31 марта 2015, 23:33

Troubleshooter написал: Есть ли бизнес пользователи, которые проверяют что приложение работает правильно?

facepalm.gif Пользователь должен пользоваться софтом, а не проверять, как он работает. Для проверки есть тестировщики на стороне заказчика и разработчика.
Газонокосильщик
31 марта 2015, 23:41

Dead Knight написал: Для проверки есть тестировщики на стороне заказчика и разработчика.

Это в теории.
Troubleshooter
1 апреля 2015, 00:02

Mx написал:
Многопоточности присуща некая неустранимая сложность, которая не может быть устранена с помощью языковых конструкций. Возможно никакого нового языка вместо Javы не появится, а просто Java будет дополнена конструкциями, облегчающими разработку многопоточных приложений. С Javой я мало знаком, а языки .NET эволюционируют в этом направлении.

По науке unit тесты должны писать разработчики, а QA должны писать acceptance тесты.

Вообще то уже появляются подобные языки. У создателя Clojure, Rich Hickeys, есть много интересных статей и лекций вокруг этого http://www.flyingmachinestudios.com/progra...-hickeys-brain/

Да, программисты пишут юнит тесты и передают код QA. При этом QA, например, говорит по принятым стандартам в данной компании программный код не будет выпущен в продакшн если не будет удовлетворять таким то требованиям по качеству. Мало того, мы даже не будем смотреть на него если программист не может наглядно продемонстрировать что его код был протестирован. Да, в теории QA пишут аксептанс тесты, но по факту программисты часто вовлечены в этот процесс в силу многих причин. Не хватка знаний в данной области программирования или в работе с конкретным инструменом одна из основных. Зависит от проекта и кто работает в QA.
Troubleshooter
1 апреля 2015, 00:24

Mx написал:
Можно ради интереса покритиковать некоторые принципы SOLID, чтобы показать что это - не догма, а просто материал к размышлению.
Single Responsibility: если у вас достаточно детально прописана спецификация - слишком скурпулёзное следование этому принципу приведёт к большому количеству мелких классов и росту сложности, потому что появятся ещё классы, которые увязвают эти классы и позволяют им работать вместе.
Open/closed principle: слишком скурпулёзное следование этому принципу в динамически развивающемся проекте может привести к большому количеству частично устаревших сущностей (функций, классов, файлов) и некоторому количеству сущностей-заплаток и натяжек которые подгоняют старые сущности под новые требования. Удаление устаревших сущностей - тоже не очень хорошая операция. Если вы поменяли какую-то функцию/класс/модуль, то вы всегда можете посмотреть на изменения с помощью средств системы контроля версии. Если вы удалили один файл и вместо этого добавили другой - это сложней.

Понятно что во всем нужен здравый смысл. С этим полностью согласен. Single Responsibility - надо определиться со scope, который имеет смысл для конкретного класса в конкретной задаче. Иначе можно все разбить на атомы и потом бороться с этим. На счёт переименования классов, мы это довольно часто делаем в силу того что не совсем точные названия приводили к такой путанице, что поиск и извлечение удалённых классов из системы контроля версий, при необходимости, совсем не кажется проблемой.
Troubleshooter
1 апреля 2015, 00:46

Dead Knight написал:

Sure, I can. Когда я говорю о ТДД, я говорю о вполне конкретном, классическом понимании ТДД, когда в начале пишутся Unit/Component/System  тесты, и только после этого начинается разработка.

Конечно удобны. Вот только юниттесты это лишь часть ТДД. Без компонентных и системных тестов это будет лишь профонация, а не ТДД, даже при 100% покрытии. Хотя, если проект маленький, то проблем конечно нет. 

Вообще, QA никакого отношения к юниттестам иметь не должны.

Понятно. В проектах где я работал/работаю, сomponent и system тесты входят в область аксептас тестов, и там больше не TDD а BDD. На счёт необходимости этих видов тестов совершенно согласен. По поводу отношения QA к юнит тестам тветил выше.
Dead Knight
1 апреля 2015, 00:46

Газонокосильщик написал:
Это в теории.

К сожалению.. Но хочется верить, что разработчики все же разрабатывая продукт не расчитывают, что обкатывать его будут на пользователях..
Troubleshooter
1 апреля 2015, 00:55

Dead Knight написал:
facepalm.gif Пользователь должен пользоваться софтом, а не проверять, как он работает. Для проверки есть тестировщики на стороне заказчика и разработчика.

Это хорошо когда бизнес знания тестера позволяют с уверенностью проверить то что нужно пользователю. Но такое не всегда бывает. Да и принцип разделения ответсвенности никто не отменял. Стандартный life cycle деплоймента - dev, sit (system integration test env), uat (user acceptance test), pre-prod, prod. Если надо то load testing и performance testing. Это в дополнении к TDD и BDD.
Газонокосильщик
1 апреля 2015, 16:07

Dead Knight написал: хочется верить, что разработчики все же разрабатывая продукт не расчитывают, что обкатывать его будут на пользователях

Чисто конкретный пример - КБ Панорама и его геоинформационные продукты. Каждая новая подверсия (про версии умолчу) - это на самом деле платная бета-версия. Форум забит вопросами типа - в прошлой версии работало, а в этой - НЕТ!
Газонокосильщик
1 апреля 2015, 16:15

Troubleshooter написал: знания тестера позволяют с уверенностью проверить то что нужно пользователю. Но такое не всегда бывает

Ещё пример. Пользователи 15 лет вводят название, жмакают ОК и система долго и нудно (в Оракле из Акцесса) ищет такие же. Для всех типов объектов (реки, горы, деревни... по всей территории России). Вываливается окно с результатами (если нашли). А вводит пользователь город Мухосранск в Крыжопольском районе Задрищенской области. Но вот ЭТО можно ввести только после проверки по всей БД. И за 15 лет никто не попросил разработчиков поменять форму ввода!
Mx
1 апреля 2015, 21:14

Газонокосильщик написал:  Ещё раз перечитал https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%...%B8%D0%BD%D0%B3, ещё раз вспомнил Скальпель Оккама применительно к программированию - не занимайся программированием ради программирования.

Рефакторинг это - не программирование ради программирования, а необходимая практика для поддержания проекта в рабочем и пригодном для дальнейшей разработки состоянии. Это - по сути дела практика наведения порядка в коде. Вещь ничуть не менее полезная и необходимая чем наведение порядка дома или на рабочем месте. Хотя, конечно, если вместо наведения порядка на рабочем месте заниматься пустым перекладыванием инструментов из одного ящика в другой - пользы от этого не много.
Например вы исправили какой-то дефект или реализовали какую-то новую функциональность. Самое время просмотреть сделанные изменения и проверить все ли они являются необходимыми, протестированными и написанными с соблюдением стандартов. Если нет - это можно легко исправить пока всё ещё в памяти и есть хорошее оперативное понимание кода. После этого код можно внести в main. Если этого не сделать потом над каждой случайно внесённой и вобщем-то бесполезной особенностью вы или кто-то другой будет ломать голову и пытаться понять зачем так сделали и что имели в виду. То есть рефакторинг облегчает понимание и в конечном итоге экономит рабочее время.

littlegene
1 апреля 2015, 22:07

Troubleshooter написал:

Если это не закрытая информация, то как у вас организовано тестирование? Скажем, разработчик закончил с внесением изменений. Как оценивается что эти изменения работают как ожидается - это касается happy path (извиняюсь, я не знаю некоторых общепринятых терминов на русском) и обработки сценариев ошибок. Как оценивается что изменения не внесли ошибок в других частях приложения? Если приложение должно удовлетворять каким то требованиям по производительности, как оценивается что после внесения изменения производительность приложения не пострадала? Есть ли load tests?  Есть ли бизнес пользователи, которые проверяют что приложение работает правильно?

Мне особо нечего сказать применительно к настоящей конторе...

У нас все проще. ) Во-первых, наш отдел не занимается enterprize programming и не делает проекты объемом более 80-100 тыс строк кода в пределах одного слоя с очень слабыми связями с другими. Это в основном real-time программинг на разных архитектурах, с коммерческими (нашими) алгоритмами обработки информации как часть middleware и тонкого клиента.
TDD используется только для Функционального тестирования, причем ради рефакторинга, который в свою очередь помогает делать архитектуру пригодной для предсказуемых требований со стороны заказчика. Но это - больше вещь в семе.
Performance тесты как таковые не пишутся - просто используется policy-based design в критических участках, когда софт должен справляться с алгоритмической нагрузкой. Когда рефакторинг дает замедление, host классы банально параметризуются стратегией оценки производительности шагов алгоритмов подвергшихся рефакторингу, и софт размещается на устройство для оценки (поскольку имитационные средства на станциях разработи мало чем помогают). Процесс сборки и заливки софта автоматизируется с тем, чтобы компенсировать затрату времени на комбинаторный перебор искомых узких мест.

Happy path вообще нет так как нет развитой интерактивности (Например, паттерн машины состояний используется чаще не для реализации конечного автомата интерактивных режимов, а для парсинга протоколов;-)
littlegene
1 апреля 2015, 22:24

Mx написал:
а просто Java будет дополнена конструкциями, облегчающими разработку многопоточных приложений.

Я тоже с Java знаком быть очень давно. Удивлен, что в ней нет средств обеспечения разработки такого дизайна ПО, который позволял бы предсказуемое масштабирование run-time по аппаратным ядрам.
Собственно в С++11, C++1x очень развит в этом смысле и практически все компиляторы поддерживают уже новый стандарт с удовлетворением многих капризов и запросов со стороны разработчиков. Вплоть до того как избегать промахов кэшей и многих низкоуровневых проблем при условии хорошего понимания новой модели памяти. Конечно, язык как и прежде требует от участника высокого порога входа в разработку, особенно когда это корпоративная разработка поставленная на поток с проектами огромного размера. (Но управляемые среды по эффективности никогда не приблизятся наверное к этому уровню...)
Dead Knight
1 апреля 2015, 22:44

Газонокосильщик написал:
Чисто конкретный пример - КБ Панорама и его геоинформационные продукты. Каждая новая подверсия (про версии умолчу) - это на самом деле платная бета-версия. Форум забит вопросами типа - в прошлой версии работало, а в этой - НЕТ!

Чисто наболевший пример, это игры, которые время от времени выходят с таким количеством багов, что кажется, что тестировщиков на проекте не было вообще, как класса.
Martin
1 апреля 2015, 23:08
Troubleshooter
1 апреля 2015, 23:30

littlegene написал: э

У нас все проще. )

если для вас работают более простые варианты, то это, на самом деле, плюс. спасибо, очень интересно!
Mx
1 апреля 2015, 23:38
Продолжение спича про рефакторинг: может сложиться такая ситуацию что вам в программу нужно добавить какую-то функциональность, но существующим дизайном программы добавление этой функциональности не предусмотрено. В таком случае для разделения сложности можно сначала сделать рефакторинг - изменить дизайн так чтобы он позволял и делал удобным добавление этой функциональности. После этого - проверить что всё по прежнему работает и уже после этого добавлять новую функциональность.

Troubleshooter написал: Да, программисты пишут юнит тесты и передают код QA. При этом QA, например, говорит по принятым стандартам в данной компании программный код не будет выпущен в продакшн если не будет удовлетворять таким то требованиям по качеству. Мало того, мы даже не будем смотреть на него если программист не может наглядно продемонстрировать что его код был протестирован. Да, в теории QA пишут аксептанс тесты, но по факту программисты часто вовлечены в этот процесс в силу многих причин. Не хватка знаний в данной области программирования или в работе с конкретным инструменом одна из основных. Зависит от проекта и кто работает в QA.

У нас acceptance тесты пишут и QA и программисты, а unit тесты пишут только программисты. QA просто не умеют этого делать. Контроль того что код вообще был хоть как-то протестирован прежде чем передать его QA фактически выполняет руководитель группы или ведущий программист.
Developer
1 апреля 2015, 23:47

littlegene написал: Я тоже с Java знаком быть очень давно. Удивлен, что в ней нет средств обеспечения разработки такого дизайна ПО, который позволял бы предсказуемое масштабирование run-time по аппаратным ядрам.

А Java предназначена для класса задач, где это действительно нужно?
По моему, Java большей частью используется в Enterprise приложениях, где управлением потоков занят сервер приложений. А для остального пакета java.util.concurrent вполне хватает. smile.gif
Mx
1 апреля 2015, 23:50

Troubleshooter написал: Это хорошо когда бизнес знания тестера позволяют с уверенностью проверить то что нужно пользователю. Но такое не всегда бывает. Да и принцип разделения ответсвенности никто не отменял. Стандартный life cycle деплоймента - dev, sit (system integration test env), uat (user acceptance test), pre-prod, prod. Если надо то load testing и performance testing. Это в дополнении к TDD и BDD.

Прямо скажем редко такое бывает чтобы разработчики и тестеры хорошо разбирались в бизнес логике приложения. Поэтому прежде чем давать продукт клиентам нужно чтобы его потестировали люди хорошо разбирающиеся в предметной области. Эти люди могут называться Application Engineers или System Engineers или Support или ещё как-то или это могут быть даже привелигированные дружественные клиенты.

Dead Knight написал: Чисто наболевший пример, это игры, которые время от времени выходят с таким количеством багов, что кажется, что тестировщиков на проекте не было вообще, как класса.

У любого коммерческого приложения важный параметр это - time to market. Нужно сделать новый продукт, или новую версию раньше конкурентов, или раньше чем он устареет. Выпуск приложения с некоторым количеством багов это - просто компромисс. Кроме этого набор платформ, конфигураций и сценариев которые реально можно протестировать силами имеющейся группы как правило довольно ограничен. Как только это попадает в широкий доступ - сразу всплывает то что не было протестировано.
Martin
1 апреля 2015, 23:57


Странно, что до сих пор в российских оборонных предприятиях используется иностранное ПО и иностранные микропроцессоры. Вроде бы опыт иранской ядерной программы должен был кое-чему научить.
Troubleshooter
2 апреля 2015, 00:11

littlegene написал:
Я тоже с Java знаком быть очень давно. Удивлен, что в ней нет средств обеспечения разработки такого дизайна ПО, который позволял бы предсказуемое масштабирование run-time по аппаратным ядрам.
Собственно в С++11, C++1x очень развит в этом смысле и практически все компиляторы поддерживают уже новый стандарт с удовлетворением многих капризов и запросов со стороны разработчиков. Вплоть до того как избегать промахов кэшей и многих низкоуровневых проблем при условии хорошего понимания новой модели памяти. Конечно, язык как и прежде  требует от участника высокого порога входа в разработку, особенно когда это корпоративная разработка поставленная на поток с проектами огромного размера. (Но управляемые среды по эффективности никогда не приблизятся наверное к этому уровню...)

В Java есть чётко определённая модель памяти. Появилась она довольно давно, в версии 1.5. Я не знаком с С++11, но судя по общему описанию его модели памяти, она очень похожа на то что есть в Java.

Проблема в том, что программистов которые понимают Java memory model (JMM) не так много. Ещё меньше тех, кто может это понимание применить на практике. Часто требуется довольно много времени прежде чем разработчик осознал всю важность использования JMM на практике при работе в многопоточной среде. При этом программисту нужно понимать не только свой код, но и как многопоточность используется в 3rd party библиотеках, что в библиотеках thread safe что нет. Соответственно, количество ошибок связанных с этим огромно. Все это довольно часто сравнивается с проблемой указателей в С/С++, которые сделала популярными языки использующие гарбадж коллекторы.
Troubleshooter
2 апреля 2015, 00:21

Developer написал:
А Java  предназначена для класса задач, где это действительно нужно?
По моему, Java большей частью используется в Enterprise приложениях, где управлением потоков занят сервер приложений. А для остального пакета java.util.concurrent вполне хватает.  smile.gif

Большинство low-latency приложений работающих в банках (например трэйдинг) написаны на Java. Но даже без этого понимания concurrent библиотеки недостаточно. Больной вопрос smile.gif
Газонокосильщик
2 апреля 2015, 08:52

Dead Knight написал: Чисто наболевший пример, это игры

Без бажных гам жизнь пресной кажется! 3d.gif

Mx написал: Например вы исправили какой-то дефект или реализовали какую-то новую функциональность. Самое время просмотреть сделанные изменения и проверить все ли они являются необходимыми,

Предпочитаю сначала определить - надо ли ЭТО делать, а не сначала сделать, а потом чесать репу - а зачем я это сделал? kos.gif
littlegene
2 апреля 2015, 10:35

Газонокосильщик написал:
Без бажных гам жизнь пресной кажется! 3d.gif

Предпочитаю сначала определить - надо ли ЭТО делать, а не сначала сделать, а потом чесать репу - а зачем я это сделал? kos.gif

Разработка оптимальной архитектуры как и реализаций ее частей при помощи нещадных вопрошаний и глубоких раздумий уже ушла в прошлое. Поскольку, все что надумалось сейчас обязательно изменится в будущем.
Рано или поздно придется тянуть все самому, поскольку в случае успеха ПО, система будет неизбежно обрастать кодом и завоевывать новые ниши. Те, кто могли бы помочь обязательно потребуют тесты, позволяющие глубоко понять как все работает. Они не станут читать скучную документацию и понимать имплементационный код без наглядных примеров его использования. В итоге, они не согласятся придти к вам на работу.
Troubleshooter
2 апреля 2015, 14:35

Газонокосильщик написал:
Ещё пример. Пользователи 15 лет вводят название, жмакают ОК и система долго и нудно (в Оракле из Акцесса) ищет такие же. Для всех типов объектов (реки, горы, деревни... по всей территории России). Вываливается окно с результатами (если нашли). А вводит пользователь город Мухосранск в Крыжопольском районе Задрищенской области. Но вот ЭТО можно ввести только после проверки по всей БД. И за 15 лет никто не попросил разработчиков поменять форму ввода!

Чтобы избежать или минимизировать такие проблемы в Agile, в частности в Scrum, есть роль product owner. В идеале это юзер, если нет, то тогда это человек хорошо знакомый с бизнесом. Подобный подход улучшает общение между разработчиками и представителем пользователей.
Газонокосильщик
2 апреля 2015, 14:53
Коллеги, вы на землю спуститесь, а? Есть немерено прикладников, которым ваши глобальные проблемы по-барабану, но к которым приходят и говорят - Саня, есть проблемка...
whitekiller
2 апреля 2015, 15:09

Troubleshooter написал:
Чтобы избежать или минимизировать такие проблемы в Agile, в частности в Scrum, есть роль product owner. В идеале это юзер, если нет, то тогда это человек хорошо знакомый с бизнесом.  Подобный подход улучшает общение между разработчиками и представителем пользователей.

Я считаю, что без этого разработку даже начинать нельзя, а то получится армия без командира.
Mx
2 апреля 2015, 22:22

Газонокосильщик написал: Предпочитаю сначала определить - надо ли ЭТО делать, а не сначала сделать, а потом чесать репу - а зачем я это сделал? kos.gif

Для этого нужно очень хорошо знать и понимать систему и инструментарий. А если система сложная, незнакомая, а проблему решать всё равно надо - иногда приходится пробовать.

Газонокосильщик написал:  Коллеги, вы на землю спуститесь, а? Есть немерено прикладников, которым ваши глобальные проблемы по-барабану, но к которым приходят и говорят - Саня, есть проблемка...

Правильный процесс состоит в том что нужно решать конкретные проблемы которые попросили решить, но при этом желательно задумываться о том как сделать так чтобы они не возникали впредь или их было проще найти, отловить и решить в будущем если они возникнут.
Газонокосильщик
3 апреля 2015, 13:36

Mx написал: Правильный процесс состоит в том что нужно решать конкретные проблемы которые попросили решить, но при этом желательно задумываться о том как сделать так чтобы они не возникали впредь

Так они уже решены. С чего ж они опять возникнут?
Anton
3 апреля 2015, 23:12

Газонокосильщик написал: Так они уже решены. С чего ж они опять возникнут?

Например есть проблема - программа глючит. Анализируем, выясняем, что не хватает разрядности какой-то переменной.
Простое решение - увеличить разрядность, отрефакторить код, который с ней работает, проверить, что нигде это значение бльше ничего не переполняет от входа до выхода и забыть.
Сложное решение - задуматься, а какого хрена она вообще переполнилась, что не учили разработчики, когда писали этот код, учитывали ли они вообще возможность переполнения чего-либо, и если не учитывали, то где еще те десятки мест, где то же самое произойдет через неделю/месяц/год.
Дальше >>
Эта версия форума - с пониженной функциональностью. Для просмотра полной версии со всеми функциями, форматированием, картинками и т. п. нажмите сюда.
Invision Power Board © 2001-2017 Invision Power Services, Inc.
модификация - Яро & Серёга
Хостинг от «Зенон»Сервера компании «ETegro»