Продолжая тему, в которую абсолютно внезапно вылился один скромный отзыв...
А то вдруг кто-то из отметившихся там еще не в курсе, что после конференции дискуссия продолжилась и им есть кому ответить :)
Так что же, "есть ли жизнь на Марсе?" (с)
Стоит ли тестировщикам изучать автоматизацию?
Осваивать программирование?
Или "не лезь, куда не просят"? Упал - уходи? (вспоминается доклад Татьяны на SQA Days и слайд со Спартой)
Нет, конечно же, нет. Никогда не ошибается только тот, кто ничего не делает! А мы будем делать, и будем изучать :)
Другой вопрос - как? Объектно - ориентированный язык выбирать или процедурный?
Учиться строить архитекруту или работать с консолькой?
Продолжим диалог :)
Не знаю, как вас, а меня бы больше удивило, если бы у них все было хорошо. Виданное ли дело, чтобы все с первого раза идеально получалось? Разумеется, у них будут проблемы с доступом к полям, с поиском кнопок и вводом строки с символами типа кавычек.
Но если бы все, у кого с первого раза что-то не получилось, бросали бы это дело, люди вообще ничем бы не занимались! Так и жили бы, охотясь на мамонтов, да разводя костер. Кому оно надо, колесо мастерить, против людского мнения переть с девизом "Земля круглая" и тд? Не получилось? Бросаем! Найдем что полегче, попримитивнее!
В котором и ответ кроется. Какие проблемы-то? Изучить то, что ты выбрал сам?
Не ссылаясь на то, что для новичка будет "сложно", а что - "легко"...
Welcome to discuss!
А то вдруг кто-то из отметившихся там еще не в курсе, что после конференции дискуссия продолжилась и им есть кому ответить :)
Так что же, "есть ли жизнь на Марсе?" (с)
Стоит ли тестировщикам изучать автоматизацию?
Осваивать программирование?
Или "не лезь, куда не просят"? Упал - уходи? (вспоминается доклад Татьяны на SQA Days и слайд со Спартой)
Нет, конечно же, нет. Никогда не ошибается только тот, кто ничего не делает! А мы будем делать, и будем изучать :)
Другой вопрос - как? Объектно - ориентированный язык выбирать или процедурный?
Учиться строить архитекруту или работать с консолькой?
Продолжим диалог :)
Прямо на моих глазах два тестировщика осваивают Джаву. Я бы не сказал, что все у них хорошо. То проблемы с доступом к полям, то еще что-нибудь.
Не знаю, как вас, а меня бы больше удивило, если бы у них все было хорошо. Виданное ли дело, чтобы все с первого раза идеально получалось? Разумеется, у них будут проблемы с доступом к полям, с поиском кнопок и вводом строки с символами типа кавычек.
Но если бы все, у кого с первого раза что-то не получилось, бросали бы это дело, люди вообще ничем бы не занимались! Так и жили бы, охотясь на мамонтов, да разводя костер. Кому оно надо, колесо мастерить, против людского мнения переть с девизом "Земля круглая" и тд? Не получилось? Бросаем! Найдем что полегче, попримитивнее!
А без ide приходится постоянно следить за простотой и логичностью конструкций, за лаконичностью кода. Результат: проект растет, но дебаг простой, расширение простое, навигация в ворохе исходников проста, как никогда. Без IDE, без "перейти к".А что, с IDE мозги автоматом отключаются? Ну напишет новичек код, непростой, потом через месяц попробует прочитать, не поймет и перепишет (хотя врядли, скорее пойдет к программистам и вместе каждую строчку разберут). Раз, другой, третий, на пятый запомнит, что значит этот код :) И перепишет более простым языком.
А если выбор экосистемы вообще так жестко не стоит, тогда какие проблемы-то?Самый главный вопрос :)
В котором и ответ кроется. Какие проблемы-то? Изучить то, что ты выбрал сам?
Не ссылаясь на то, что для новичка будет "сложно", а что - "легко"...
Welcome to discuss!
Простите, а что плохого в том, что человек развивается и растет над собой в ту сторону которую выбрал? А если это ещё и для команды полезно?. А если ещё человек сделавший осознанный выбор самомотивирован?
ОтветитьУдалитьМожно подумать все те которые ратуют за "без ide" родились с золотой клавиатурой во рту и сразу же знали про полиморфизм, синглтон и различия в шаблонах проектирования и для того чтобы писать безбажный код достаточно один раз услышать название языка и никогда у них никаких проблем не было. Не верю!
No pain, no gain, как говорят спортсмены.
> Учиться строить архитекруту или работать с консолькой?
ОтветитьУдалитьНе противопоставляйте так. Это не взаимоисключающие вещи, а в такой формулировке еще и холивароопасные.
> Объектно - ориентированный язык выбирать или процедурный?
Опять же - Ruby и Python вполне себе объектно-ориентированные (XD). В Ruby вообще это явление до предела доведено.
> А что, с IDE мозги автоматом отключаются?
Синдром ДжаваБыдлоКодера. Еще одна холивароопасная тема. Если коротко, то - писать плохой код плохо. Лучше учиться сразу писать хороший, чем писать хоть как-то, а потом бесконечно рефакторить и поддерживать.
To Horhe
ОтветитьУдалитьЕсли вы это мне адресовали, то немного ошиблись, я в этом ничего плохо не вижу :)
Хотя, возможно, "плохое" в этом видится многим как раз таки НЕполезность проекту - вы будете писать плохой код, вечно рефакторить, тратить кучу времени, а вам вообще не за это платят :)
Tо Сергей Высоцкий:
Я не противопоставляю :) И не говорила про взаимоисключение. Но - с чего начать? С того или другого. Тут и идет выбор, на тему которого пошел холивар в предыдущем посте...
Насчет сразу хорошего согласна. Особенно это наглядно не на автоматизации, а в целом на программировании. Вначале поленились писать сразу нормально, и с тестами, потом понастроили столько всего, что базовое трогать уже нельзя... Ну и все. Через годик другой будет совсем "хорошо".
Хотя для учебы - почему нет? Я первый тест переписывала по 10 раз, чтобы от "плохого кода" прийти к "хорошему". Конечно, это если делать, то пока у тебя ровно этот тест и есть, а не целая структура, когда уже рефакторинг занимаем много времени и сил.
А для начала - вполне нормально!
2okiseleva
ОтветитьУдалитья как бы тоже ничего плохого не вижу, о чем, собственно, и написал :)
Я мог бы, кстати, и дальше продолжать. Но, раз уж перетекло в отдельную ветку, буду отвечать по существу.
ОтветитьУдалить> Не знаю, как вас, а меня бы больше удивило,
> если бы у них все было хорошо.
Ну ведь плохо-то им делают вещи, которые им не нужны! Программировать надо начинать с записи алгоритмов. Это первичное (если мы говорим о попытках писать программы, а не выучить ЯП, что во многих случаях является почти механическим навыком), а не конструкции языка, которые не позволяют ехать, когда нужно просто ехать. Представьте, что, чтобы поехать в магазин, вам к машине надо приделать сверху лодку, иначе она не поедет. Ну, или маскировочной сеткой под листву закрыть: инкапсуляция же, чо. OOP концептуально сложно, и нифига не интуитивно, потому что все best practices противоречат естественным представлениям "все в этом мире - объект". Все в итоге выливается в нифиговый скилл моделирования, а тогда какая разница? Возьмите, что по-проще. Большая часть паттернов родилась как раз благодаря повсеместному распространению джавы. И паттерны эти - формализация естественных архитектурных решений (только после формализации эти паттерны так и начинают выпирать из кода, от чего он содержит меньше смысла и все больше похож на набор шаблонов). А формализуются они для того, чтобы отключить мозг. Чтобы фирмы, пишущие софт в промышленных масштабах, могли нанимать людей без мозгов штамповать груду кода. Генри Форд изобрел конвеер. В 90х люди обзавидовались и изобрели Джаву. C# ровно такой же, только от Microsoft с их синдромом Not Invented Here. Только и всего. Я, пожалуй, конкретно про джаву больше ничего не буду писать, потому что и так похоже, что я тут войну развожу.
> А что, с IDE мозги автоматом отключаются?
Зачастую, да. А когда еще не и не знаешь, какую область мозга подключать (ничего обидного в этом нет, сами пишите, что не все все сразу знают). У новичка ведь нет навыков. Пусть сразу привыкает к хорошему, обретает правильные навыки. Ошибок хватит и без них (к тому же никто не говорил, что этот путь легкий). А потом можно уже и в IDE (если захочется).
Я-то не против, как раз, чтобы тестировщики программировали (более того, во многих местах тестировщики - те же программисты). Но почему только у них к навыку "программирование" должен быть какой-то особый подход? Хочетс клеймо "этот код написан тестировщиком, за версту видно?"
> Учиться строить архитекруту или работать с
> консолькой?
Архитекторов сначала учат матведу и сопромату, и только потом, как из кирпичей сложить этаж-два. Вы же сначала хотите два этажа, даже не подумав, из чего вы их будете складывать.
> Объектно - ориентированный язык выбирать
> или процедурный?
Строго говоря, это не вполне справедливое деление. Тем более, что в существующем виде OOP воспринимается, как некая надстройка над процедурным программированием (если мы не будем вспоминать тут Smalltalk, конечно). Да и функциональщину / декларативщину позабыли. А в свете того, что есть на свете инструменты, вроде QuickCheck (сам QuickCheck, PropEr и даже http://www.hastests.com/), это некое упущение.
В заключение я немного пофилософствую и открою великую тайну, что на любом языке можно писать в любом (или почти любом) стиле. Так на С вполне можно писать в объектом стиле, на джаве пытаться изобразить функциональщину (на C# ее даже изображать не надо: там итак соответствующего сахара ну просто завались), а на Haskell писать такую махровую императивщину, что из бедного Алонзо Черча можно будет сделать вечный двигатель.
1. По поводу ide - оно действительно расслабляет. Причём очень сильно. Супер навигацией, автодополнением и подстановками и тд. Если ты уже всё знаешь, то наверное удобней и то под вопросом. Я писал на руби с рельсой. Паттерн MVC. Начинал писать тогда, когда из ide был только блокнот. Сейчас понимаю, что быстрое вникание в структуру папок, где что лежит и как всё устроено было именно благодаря отсутствию ide. В итоге я кстати остановился на виме как на редакторе. После 3 недель мучений скорость наборки увеличивается раза в 2.
ОтветитьУдалить2. По поводу выбора языка - мне скриптовые гораздо ближе - кода меньше и всё лаконичней. Но я раненый руби и всю сознательную профессиональную жизнь писал на нём. Когда сейчас смотрю код на джаве понимаю на сколько всё тяжеловесней что-ли. Очень много лишнего. Но это всё имхо.
3. По поводу программирования для тестировщика - it depends :) Имхо лишним не будет точно. Знание sql и основ хоть одного языка точно должно быть. Хотя бы из-за упрощения разговора с программистами. Прикольно, когда ты понимаешь о чём тебе говорят, даже когда уходят в какую-то технику. Много вопросов снимается.
4. Понятно что тестировщик не будет писать лучше чем среднехороший программист. Просто потому что этот самый программист занимается этим каждый день по 8 часов (теоретически). Но это не значит, что любой программист будет писать лучше бэкенд часть для кукумбера. Если программист занимается вебом всё время, а тестировщик разобрался с регулярками нормально и занимается этим всё время, то в итоге он будет это делать лучше чем программист.
Какой-то сплошной холивар у Вас творится на блоге okiseleva :)
ОтветитьУдалитьТестировщик сделал вброс -- тут же собрались матёрые программисты и давай обсуждать высокие материи да поминать авторитетов (Чёрч ещё раз крутанулся). Прям всё как в жизни :)
ОтветитьУдалить@Alexei Barantsev
ОтветитьУдалитьЭто натурально демарш с вашей стороны, Алексей.
Хм, а кстати, все тут отписавшиеся - программисты или тестировщики? :)
ОтветитьУдалитьИ еще, приятно услышать, как от pfocchken, кто с чего начинал, собственно. Немного понятнее будет отстаивание определенной точки зрения :)
Насчет расслабления мозгов вспоминается мой вопрос на докладе "импакт анализ", и докладчика лишь подтвердила, что да. Вот программисты начали писать, где и что задели, тестировщики быстро привыкли и расслабились. Перестали вначале думать своей головой, а потом уже смотреть в эту табличку.
Так и с IDE - конечно, опасность существует всегда, что все эти "авто..." отключают мозги. Тут главное, самому себя контролировать. Вот кстати, зря, чтоли у программистов есть code review? Чтоб не забывались :)
Игнат, ваш пример какой-то... Странный :)
IDE ведь упрощает жизнь. Тут скорее можно сравнить - поехать на простой в управлении машиной или меганавороченной, но в которой вначале надо разобраться...
А то что это за пример - лодка сверху, или машина не едет. Если бы java и C# и правда были бы "ненужной" деталью типа этой лодки, на них бы никто и не писал тогда...
Хотя java меня и саму порой пугает, когда откроешь проект и смотришь первые секунды на "эти непонятные записи". Потом начинаешь читать строчка за строчкой и все вспоминаешь.
Не знаю, возможно, это именно благодаря русским тестам собственная структура пугает меньше :)
> У новичка ведь нет навыков. Пусть сразу привыкает к хорошему, обретает правильные навыки. Ошибок хватит и без них (к тому же никто не говорил, что этот путь легкий). А потом можно уже и в IDE
Ок, этот путь тоже сложный, он его пройдет и освоит, зачем ему тогда надо будет IDE?)) Ведь к тому моменту у него уже будут тесты на часть системы, выкидывать их, чтоли?
> Но почему только у них к навыку "программирование" должен быть какой-то особый подход? Хочетс клеймо "этот код написан тестировщиком, за версту видно?"
А разве java и C# - это "особый подход"? Почему клеймо то сразу? При чем тут язык, вы же сами в своей филосовской части сказали, что на любом языке можно отхватить как клеймо, так и венец славы как крутого кодера :)
> Да и функциональщину / декларативщину позабыли. А в свете того, что есть на свете инструменты, вроде QuickCheck (сам QuickCheck, PropEr и даже http://www.hastests.com/), это некое упущение
Не могу писать о том, чего не знаю :) Да и смотреться глупо будет... В прошлом топике пошла война против IDE и джавы, оттуда и вырос вопрос :)
Andrew
ОтветитьУдалитьНе виноватая я, они сами пришли!!! (с)
@okiseleva
ОтветитьУдалитьЯ хз кто я, но в трудовой на данный момент корень "тест" присутствует. Так что, пожалуй, тестировщик.
Я лет пять просидел по уши в .NET. В основном C#/ASP. Местами были вкрапления Java, Ruby и много-много ActionScript. Сейчас все больше сижу в Python'е и C++ (Java тоже, если так можно назвать то что в Android'е творится). Правда занимаюсь в основном системами, где графического интерфейса нет вообще - очень отрезвляет.
> Ок, этот путь тоже сложный, он его пройдет и освоит, зачем ему тогда надо будет IDE?
Visual Studio + ReSharper это мощный и годный инструмент рефакторинга, например. Правда это очень далеко от начального уровня написания тестов и не то чтобы про паттерны проектирования.
MS (да и не только они) вообще выстроили уже экосистему такую, что без нее нормально кодить не получится. Увы. Но все еще есть языки, где без этих излишеств живется вполне комфортно.
> А разве java и C# - это "особый подход"?
Особым подходом коллега назвал порядок изучения предполагающий, что сначала надо научиться фигачить тонны кода в пустоту, а потом, если захочется, научиться готовить хороший, годный код.
Ладно, отставить демарши. Отвечу по существу, про IDE и отключение мозгов. Я считаю, что IDE не мешает, а помогает писать. Причём помогает научиться писать быстро и правильно.
ОтветитьУдалитьОставим в стороне такие мелочи, как раскраска кода (в конце концов, vim тоже это делает :)) Я вижу основные выпады против автопродоложения и рефакторинга. Выскажусь в защиту.
Что такое автопродолжение?
В первую очередь это урезанная форма документации, быстро доступная, контекстно-зависимая. Вы забыли, как называется тот или иной метод. Поставили точку -- появился полный список методов, с описанием. Не нужно открывать MSDN или лезть браузером в интернеты, чтобы почитать документацию. Это всего лишь экономит время, и вовсе никак не влияет на мозг.
Во вторую очередь это экономия времени на простых действиях. Надо, например, вставить цикл по списку -- пишешь foreach, автопродолжаешь -- вставляется вся конструкция целиком. Зачем всё это писать руками? Где тут мозг участвует? Только руки. Напротив, это даже хорошо, что мозг не отвлекается на такие рутинные задачи.
Про рефакторинг.
Он вовсе не провоцирует сначала писать плохой код, а потом его улучшать. Если вы уже умеете сразу написать хорошо -- вы не будете идти по длинному пути, сразу напишете хорошо. А если с первой попытки не получилось? Так и оставить? Один из путей исправления -- переписать всё заново. Второй путь -- рефакторинг, то есть постепенная трансформация. Я считаю, что оба имеют равные права на существование.
Про алгоритмы.
Откройте любой, самый замечательный тестовый набор, написанный вами или вашим кумиром. Много ли "алгоритмического" кода вы там найдёте? Тесты в большинстве своём не предполагают сложных алгоритмов. Это нормально. Гораздо важнее с практической точки зрения научиться пользоваться стандартными (и нестандартными) библиотеками и фреймворками. Умение ставить аннотацию @Test важнее, чем умение реализовывать "сортировку пузырьком".
Фреймворки и библиотеки -- это всего лишь следующий шаг на пути повышения уровня абстракции. Иначе я должен был бы услышать призывы отказаться от использования ЯП высокого уровня, писать только на C. Сборщик мусора -- зло, надо вручную выделять и освобождать память. Стандартные коллекции -- зло, надо пользоваться только простыми массивами. Регулярные выражения -- зло, надо самостоятельно реализовывать парсер на основе конечного автомата.
Общее.
Я езжу на компактной городской машине с автоматической коробкой передач и с навигатором, который подсказывает мне, куда надо ехать. Мне это нравится и нисколько не мешает. Конечно, я не могу "срываться" по зелёному сигналу светофора, не могу перескочить через бордюр и прокатиться по газонам, не могу, наверное, ещё много чего -- но меня это вполне устраивает :)
> Поставили точку -- появился полный список методов, с описанием.
ОтветитьУдалитьВставили подходящий и забыли о его существовании до следующего случая. Обычно так. Потом видим людей лихорадочно перебирающих комбинации в беспамятстве. И все равно, чтобы хорошенько разобраться в том что откуда растет приходится лезть в MSDN и прочее.
> Он вовсе не провоцирует сначала писать плохой код, а потом его улучшать
Он провоцирует соблазн регулярных избыточных правок. Вот и все.
> Гораздо важнее с практической точки зрения научиться пользоваться стандартными (и нестандартными) библиотеками и фреймворками.
Вот это в консольке зачастую делать проще и удобнее. Вбил что-нибудь в переменную и крутишь ее в консоли как хочешь, развернув на второй монитор доку.
Alexei, вы уж очень идеализируете. Это в теории все так. Но теория и практика, как водится, две большие разницы. И Сергей прав (и про рефакторинг тоже), автодополнение никого еще не избавляло от необходимости заглядывать в документацию. Частоиспользуемые комбинации методов запоминаются и так, а вот редкие все равно не знаешь, как работают, и что им и как передавать. Навигатор тоже опасная штука.
ОтветитьУдалитьПотом люди без него уже перестают ориентироваться :)
> Если бы java и C# и правда были бы "ненужной" деталью типа этой лодки
okiseleva, опять вы прочли меня как-то не так, как я хотел. По одному поинту Сергей уже высказался, что касается этого: лодкой являются не java или c#, а public/protected/internal/static/final/volatile/delegate (последние два-три, в принципе, можно вычеркнуть) и т.п. кейворды и концепции, которые не дают ехать, хотя казалось бы нафига оно нам тут.
> зачем ему тогда надо будет IDE?))
Вот именно, незачем!
> Ведь к тому моменту у него уже
> будут тесты на часть системы, выкидывать их, чтоли?
Зачем их выкидывать? Кто мешает уже написаный код править в IDE?
> Хотя java меня и саму порой пугает
C# не пугает, а Java пугает? Странно, вообще-то, учитывая, что Java гораздо "тупее" (от чего, кстати, гораздо многословнее). Кода много, и смысл размазывается (чем больше сахара, тем выше концентрация смысла), но пугают только объемы, пожалуй. А закорючки все те же.
> Тут главное, самому себя контролировать.
Так ведь не знаешь же еще, какую часть себя контролировать. Вот о чем речь! Надо сначала научиться включать и чувствовать отдельные зоны мозга, ответственные за... Чтобы потом понять, чем можно не пользоваться и в каких случаях. Не, ну давайте все будем пользоваться дрелью и саморезами, даже тогда, когда хватит молотка и гвоздей. Давайте искать в чистом поле электричество: куда дрель-то включать?
А все ещё помнят, что это "программирование для тестировщиков", а не "программирование для программистов"? Как ни крути, а именно тестировать для тестировщика это всё-таки превалирующее занятие.
ОтветитьУдалитьКлючевое слово "программирование" по-моему. Давайте придумаем другое слово, если "как писать код на языке Java/C#/Lisp" кажется вам негативным и унизительным. :) Это, кстати, и "программистам" некоторым подойдет. Есть же, например, т.н. вебмастеры. Они как бы и не программисты, не верстальщики и не дизайнеры и вообще. Но делают же что-то конкретное и полезное. Почему нет?
ОтветитьУдалить> Вставили подходящий и забыли о его существовании до следующего случая.
ОтветитьУдалитьА что, если без автовставки это не так? Частоиспользуемые помним, нечасто - нашли, ввели, забыли...
> Вот это в консольке зачастую делать проще и удобнее. Вбил что-нибудь в переменную и крутишь ее в консоли как хочешь...
А можно пример, зачем оно надо в плане тестирования, а не в плане изучения языка?
> лодкой являются не java или c#
Вы изначально и писали про конструкции языка, но ведь не зная язык, не сможешь писать на нем, не зная всех этих паблик и тд, верно? Они в нем есть, и не могут являться лодкой, лодка в примере выглядит как лишняя часть, а не часть самой машины :)
> C# не пугает, а Java пугает?
Ага. Я уже писала, что пока я пишу тесты на русском языке. Давайте опять не будем уходить от темы. В теме-отзыве на тренинг обсуждать программирование, а в теме программирования - холиварить насчет языка написания.
Да, английский интернациональный, многие даже в джире на нем баги пишут и тд и тп. И учить его надо - не спорю! Но все же родной язык - он ближе...
И опять же, выше я писала - пугает в самом начале, когда вместо родного языка видишь код + англоописание.
Читая построчно, начинаешь понимать, что это не так уж и сложно и страшно :) Просто изначально, на первый взгляд - русский роднее, вот и все
> Да, английский интернациональный,
ОтветитьУдалить> многие даже в джире на нем баги
> пишут и тд и тп. И учить его надо - не спорю!
> Но все же родной язык - он ближе...
Да тут как раз не страшно. Можно и на русском, ведь англоговорящие видят в коде, о боже, то же самое, что видим мы внутри 1C и его переведенного бейсика. До сих пор случаев внезапной кончины, вроде бы, не наблюдалось.
> но ведь не зная язык, не сможешь писать на нем, не
> зная всех этих паблик и тд, верно?
Есть вещи, без которых вполне можно обойтись. Структурное программирование вообще утверждает, что можно обойтись последовательностью инструкций, простым ветвлением (if-else) и циклом (цикла while вполне достаточно). Вот возьмем, к примеру, C++. В нем реализация поддержки ООП даже несколько сложнее, чем в Джаве. Кроме того, есть тьюринг-полные шаблоны, на которых можно вполне строить compile-time вычисления, и вообще забубенить невероятную опердень, эмулирующую крутейшие фичи из модных яп. Но, на С++ можно вменяемо писать и без шаблонов. Можно о них ничего не знать, и писать работающие программы. Можно ничего не знать и про ООП и писать программы на С++. То же самое и с питоном, например: мне надо написать скрипт генерации какой-то фигни по шаблону и переданным аргументам. Нафига мне классы и объекты? Я даже могу и не отдавать себе отчет, когда пишу "Шла Саша по шоссе".replace("Саша", "Маша"), что я использую объект. В данном случае ничего не поменяется и мир не перевернется. Но скрипт я напишу, он сгенерирует все, что надо и сделает меня довольным. Я доехал в магазин без знания о модификаторах доступа. Без этой несчастной лодки, которая мне не нужна. Зачем машине лодка? Зачем всем функциям классы? Почему есть лодки в которые можно снять и залезть внуть (public), а есть лодки, которые прибиты вверх ногами и попасть в них можно только через люк из машины (private). В мире стотыщмиллионов задач, где классы избыточны, _ТЕМ_БОЛЕЕ_ (прошу обратить внимание И на эту часть, а не только на начало предложения) _ТЕМ_БОЛЕЕ_ на начальном этапе, когда и базовые для всего принципы (абстракцию и декомпозицию) еще толком не усвоены.
Если же вам и не надо оно, как, бы вроде, кажется (действительно, написать MyPrettyButton.Click() не требует этих знаний), то простите, но не программирование это. В этом ключе товарищи правы, говоря, что программирование тестировщику, скорее всего, ни к чему.
>> ... простите, но не программирование это ...
ОтветитьУдалитьА что это такое, если не программирование? Когда рабочий пишет программу для станка с ЧПУ -- это не программирование? Когда ребёнок пишет малюсенькую программу для черепашки на лого -- это тоже не программирование?
> А что, если без автовставки это не так? Частоиспользуемые помним, нечасто - нашли, ввели, забыли...
ОтветитьУдалитьВот и я говорю - разницы ноль. Тем более что в тестировании нужен весьма ограниченный набор библиотечек.
> А можно пример, зачем оно надо в плане тестирования, а не в плане изучения языка?
Берете большой массив данных, берете, скажем, GNUPlot и начинаете разбираться в стат. анализе, например. Очень полезно для тестирования ряда систем, а в нагрузке так вообще. Но это сложный вариант.
Простой вариант - подготовка тестовых данных.
> Вы изначально и писали про конструкции языка, но ведь не зная язык, не сможешь писать на нем, не зная всех этих паблик и тд, верно?
Нет. Точнее не совсем. В большинстве случаев баплик или нет вообще для тестового скрипта переферийно. Ряд других вещей тоже.
> А что это такое, если не программирование?
ОтветитьУдалитьА мы с вами в общем, или о частностях? Программирование как таковое давно выросло из штанов простого набора кода. Но при этом программированием называют даже процесс прошивания контроллеров. "Мы программируем МК," - гордо заявляют нам жестянщики, не написав и строчки кода. Если мы будем говорить о таких вот частностях, то давайте не вспоминать архитектуру (о которую в этих топиках мы копий поломали уже будь здоров). Но, хоть убейте, начинать разговор о ней, о рефакторинге, о прочих высокоуровневых вещах, не бельмеса не мысля в более приземленном - это преступление.
Давайте будем честны - ООП в наиболее употребимом сейчас смысле - это архитектурное завоевание. В существующем виде имеет под собой цель скрыть возрастающую сложность программных систем. Отсюда вся эта неадминистративная инкапсуляция, вся эта чудовищная абстракция (не в том смысле, в котором я употребил это слово в предыдущем комментарии).
Вообще, стоит отметить, что этот разговор весь подтолкнул меня к конкретному вопросу: "Зачем тебе ООП?" Он бы очень пригодился мне, когда я проводил собеседования. С другой стороны, он бы не получился без того, что я узнал и чем занимался в последнее время. Смотреть вокруг полезно. Если ты не мазохист, зачем ловить уже пойманные грабли?
>>> А что, если без автовставки это не так? Частоиспользуемые помним, нечасто - нашли, ввели, забыли...
ОтветитьУдалитьИ без автовставки так да не так. :) Просто когда часто копаешься в документации, то параллельно видишь кучу всего ещё. Используя гугл можно наткнуться на довольно неожиданные блоги и тд.
По поводу навигации - наблюдал, когда люди проработав пол года на рельсе в какой-нить ide не понимали структуру папок и где что лежит. А это базовые вещи. Оно конечно удобно, когда кликнул на имени метода и тебя туда унесло. Но многие даже потом не будут смотреть какой класс открыло.
>>>А можно пример, зачем оно надо в плане тестирования, а не в плане изучения языка?
Написание тестов по сути то же программирование, просто использующее другие технологии - вместо написания html и css используем локаторы; вместо бизнес логики и отображения результатов на страницах - перемещения и проверки по тем же страницам; с базой данных точно так же приходится работать.
И соответственно решаются те же мелкие задачи, которые решают программисты - выбрать нужный эллемент из массива, распарсить строку и тд. Не все могут с чистого листа просто сесть и написать. Даже помня имена методов. А эксперементировать прямо в тесте - затратно и долго. Поэтому быстрее открыть консоль и там покрутить метод и посмотреть как он работает не перезапуская тест 3-5 раз, а потом уже вставить готовый кусочек в код теста.
> "Зачем тебе ООП?" Он бы очень пригодился мне, когда я проводил собеседования
ОтветитьУдалитьВот видите, теперь у вас есть провокационный вопрос для собеседований :)
> Если ты не мазохист, зачем ловить уже пойманные грабли?
Что вы понимаете под этой фразой? Не хочу предполагать опять, все равно не угадаю)))
> выбрать нужный эллемент из массива, распарсить строку и тд. Не все могут с чистого листа просто сесть и написать.
Так надо учиться! Чтобы не быть "полгода работаю со средой, а где она лежит - не знаю"...
>>> Так надо учиться! Чтобы не быть "полгода работаю со средой, а где она лежит - не знаю"...
ОтветитьУдалитьДык против этого ж и никаких возражений, просто учиться эффективней без ide. Но это всё конечно моё личное мнение.
Знать всего невозможно - сколько бы не учился, вот тут и приходит на помощь консолька. Открыл, покрутил метод, переменную и тд, разобрался как работает, а потом уже написал непосредственно в коде. Вопрос же был зачем нужна консолька - для экспериментов. :)
> Так надо учиться!
ОтветитьУдалитьНекогда учиться! Работать надо!
> Что вы понимаете под этой фразой?
Кроме буквального, только лишь здоровый скептицизм. Просто обращайте внимание на тех, кто уже потоптался на этом месте (в данном случае, на месте ООП) и отошел. Кто-то мог отойти и вернуться, на то были причины. Поэтому делать поспешные выводы без анализа ситуации нельзя. Нельзя никому слепо верить и впадать в фанатство. Для всего есть причины, и не факт, что причины эти подходят в конкретной ситуации. А то внезапно окажется, что используя не то, что нужно, вы делаете совершенно не то, что собирались.
Игнат, почему Вы всё время поминаете ООП? Все вроде бы обсуждают тему "IDE или консоль", никто ни словом не задевает ООП, ни в положительном ни в отрицательном смысле :)
ОтветитьУдалитьЛадно, пусть консоль нужна для "быстрых" экспериментов, я готов с этим согласиться -- покрутить, попробовать так и сяк, и при этом не нужно писать никакой обвязки. Я подумаю над этим. Может быть буду ещё рассказывать про BeanShell :)
А вообще, надо бы попробовать ещё разок -- построить курс на базе, скажем Ruby (ненавижу PEP8 :)) Жалко только, что RubyMine платная :)
> почему Вы всё время поминаете ООП?
ОтветитьУдалитьПотому что о нем тоже речь шла и кагбе высказывалось что-то про паттерны проектирования в Java
> почему Вы всё время поминаете ООП?
ОтветитьУдалить> Потому что о нем тоже речь шла
И потому, что это единственная нормально поддерживаемая Джавой парадигма. О Джаве (и о C#) тут много шло разговоров. И началось все с утверждения, что скриптовые языки в среднем проще в изучении (и в повседневной работе), чем Джава. И это действительно так.
> Все вроде бы обсуждают тему "IDE или консоль"
Это я тоже обсуждаю, но мнение свое, вроде как, уже озвучил давно :)
>>> Жалко только, что RubyMine платная :)
ОтветитьУдалитьЭто да. Но та же IDEA на основании которой её делали тоже платная.
Eclipse с плагинами вроде нормально работает.
А вообще - вим или нотпад++ точно бесплатные. И очень быстрые. :)