Как НЕ быть посредственным разработчиком -2


Привет, Хабр! Представляю вашему вниманию перевод статьи «How not to be a mediocre developer!»
Dushyant Sabharwal. В статье приведены некоторые советы для начинающих и, возможно, некоторых опытных программистов, которые могут помочь значительно повысить свой профессионализм и изменить отношение к работе. Некоторые из них могут показаться банальными, но новички, возможно, смогут найти что-то полезное для себя.

Пишите больше кода


Если вы хотите улучшить свои навыки в каком-либо занятии, нужно больше практиковаться — обходных путей, к сожалению, не существует. Не важно сколько статей по программированию в день вы читаете или сколько раз в день вы перечитываете документацию — вы не добьётесь результатов, не работая собственными руками. Паттерны проектирования, кажущиеся сложными в применении многим новичкам, начнут автоматически вылетать у вас из под пальцев, когда вы потренируетесь применять их в различных контекстах.



Пишите тесты


Когда я начал активно тестировать свой код, я был удивлён своей неподготовленности к написанию качественных тестов. Написание тестов научит вас по-новому смотреть на свой код, потому что, придумывая способы сломать свой код, вы, скорее всего, глубже осознаете структуру и логику работы своего кода, обнаружите собственные некоторые ошибки (ещё до выполнения тестов, во время их написания) и заметите, что, возможно, стоит вынести некоторые части вашего кода во вспомогательные функции или сделать некоторые функции более обобщёнными — в некоторых случаях вы даже будете вынуждены сделать это, обнаружив, что ваш код невозможно протестировать.

Давайте рассмотрим пример:

function postData(data) {
 boolean valid = true;
 // проверяем наличие данных
 if (data === undefined) {
   valid = false;
 }
// проверяем формат электронной почты
 if (!regex(data['email']) {
   valid = false;
 }
// проверяем длину пароля
 if (data['password'].length < 8) {
   valid = false;
 }
if (valid) {
  http
   .post(`example.com/user/create`, data)
   .then((response) => {
    //добавляем информацию в список
    this.users.append(response.userid);
   })
   .catch((error) => {
    // выводим информацию об ошибке
   });
 } else {
   showValidationError();
 }
}

Метод postData выполняет несколько функций сразу: проверка корректности данных, добавление информации в список пользователей в случае прохождения данными проверки, обработка ошибок. Написать модульный тест для postData может быть довольно сложной и неприятной задачей. Лучше будет разбить этот код на несколько методов и протестировать каждый по отдельности, например:

function postData(data) {
 return http
   .post(`example.com/user/create`, data);
}

function validate(data) {
 // проверяем наличие данных
 if (data === undefined) {
   return false;
 }
// проверяем формат электронной почты
 if (!regex(data['email']) {
   return false;
 }
// проверяем длину пароля
 if (data['password'].length >= 8) {
   return false;
 }
  return true;
}

function appendUsers(userId) {
  this.users.append(response.userid);
}

function main() {
 if (validate(data)) {
  postData(data)
   .then(data => appendToList(data.userId))
   .catch(error => handleError(error))
 } else {
  showValidationError();
 }
}

Уже сейчас вы можете увидеть, что написание тестов приводит к повышению качества кода — вам пришлось разбить вашу длинную функцию на несколько более коротких, выполняющих меньшее количество действий, которые легко можно протестировать по отдельности.

Будьте честны


Не врите о своих знаниях. Делая вид, что разбираетесь в каком-либо API, вы не сможете принести реальной пользы команде, но зато сможете подвести людей, если вам доверят выполнение задачи или просто опозориться, сказав что-то невпопад во время обсуждения.

Участвуйте в open-source проектах


Участвуя в open-source проектах, вы можете столкнуться с ситуациями, которые никогда бы не произошли на вашей обычной работе. Таким образом вы можете расширить свои горизонты. Вы можете больше узнать о работе в распределённых командах. непрерывной интеграции и других средствах разработки, активно используемых в крупных open-source проектах. Как известно, open-source значительно влияет на мир информационных технологий в целом и на разработчиков в частности.

Помогайте людям


Помогая другим людям с чем-то, в чём вы хорошо разбираетесь, повышает вашу ценность и репутацию в коллективе, а также позволяет вам закрепить свои знания и, иногда, обнаружить пробелы в них. Вызываясь на помощь с задачами, в которых вы разбираетесь не на все 100%, зачастую может помочь вам научиться чему-то новому.

Начните собственный проект


Собственные проекты являются отличным способом изучения новых фреймворков и технологий, с которыми вы не сталкиваетесь на работе. При работе над собственным проектом Вы являетесь product manager-ом, разработчиком и проектироващиком — представьте только, какое количество важных решений вам придётся принимать самостоятельно! Возможно, однажды на своей работе вы успешно предложите внедрить новую технологию или фреймворк, изученные вами во время работы над собственным проектом!

Умерьте своё эго


Не позволяйте своему эго и своей рабочей должности вставать на пути между вами и обучением/улучшением навыков. Каждый день думайте о том, кем вы станете, вместо того, кто вы есть сейчас. Всегда будьте открыты новым способам решения задач в которых, по вашему мнению, вы и так разбираетесь. Если это будет не так, вы рискуете упустить более эффективный, чем используемый вами, алгоритм или более подходящее архитектурное решение.



Думайте о причинах существования программных средств


Перед тем, как начать активно пользоваться новым фреймворком, паттерном или API, попытайтесь понять причину (и основную цель) его существования. Попробуйте получить представление о причинах создания средства, которым собираетесь воспользоваться.

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

Выше приведён пример кода, который вы можете встретить на сайте с документацией vue.js. Даже глядя на этот простой пример, я думаю о следующих вещах:

  1. Почему для создания компонента используется ключевое слово new? Почему они не используют паттерн «фабрика» для создания объектов?
  2. Похоже, что свойство el принимает значение id элемента, но почему оно использует #? Означает ли это, что я могу добавить другие селекторы элементов, такие как аттрибуты и классы?
  3. data выглядит как обобщённое имя свойства для объекта vue. Что именно она представляет собой?

Я не говорю, что вы должны быть настолько внимательными ко всему коду, который вы встречаете в своей жизни, но вырабатывание этой привычки поможет вам лучше понимать суть используемых приспособлений.

Не ленитесь


Лень может помешать вам продемонстрировать свои навыки или сделать вещи, которые кажутся вам важными. Например, если вы считаете, что рефакторинг может повысить производительность кода, — сделайте это! Добавьте комментарии, чтобы сохранить время других разработчиков. Задокументируйте написанный вами API. Время, вложенное вами в свой код, является сохранённым временем других разработчиков, которые будут работать с вашим кодом.

Решайте алгоритмические задачи


Решение задач на программирование (имеются в виду алгоритмические, возможно, олимпиадные задачи) заставляет вас задумываться о вещах, на которые вы не всегда обращаете внимание в повседневной работе. Я говорю об асимптотических оценках кода по времени и памяти. Некоторые люди утверждают, что таких задач бесполезно, так как всё уже сделано за вас и вам нужно просто работать с API.

Я не согласен с этой точкой зрения. Это не только помогает вам более критически смотреть на код, но также позволяет вам с уверенностью предлагать решения по улучшению производительности кода. Ещё одним плюсом является то, что знания, приобретённые вами в процессе решения алгоритмических задач, вполне могут пригодиться вам на собеседовании.

К сайтам, содержащим такие задачи, относятся: hackerrank, leetcode, codingame и другие.

Хвалите людей


Если вам понравился коммит, сделанный вашим коллегой, напишите ему об этом. Поставьте плюсик ответу на stackoverflow, оказавшемуся полезным для вас. Проголосуйте на medium за статью, которая дала вам полезные знания. Поставьте звёздочку заинтересовавшему вас проекту на github. Поощрение других людей помогает им, а затем и вам, развивать в себе лучшие качества.

Не отказывайтесь от задач какого-либо типа


Если вы видите проблему в API и представляете, с чем она связана, не стоит говорить: «Я — фронтендер. Это не моя проблема». На мой взгляд, такое отношение к проблемам является неправильным. Основные принципы программирования, такие как DRY, использование абстракций в случаях, когда классы реализуют смешанную функциональность, обработка исключений по всем возможным ветвям исполнения кода и т.д. применимы практически на любом уровне (фронтэнд, бэкэнд), где возникают задачи для программистов. Держа в голове эти принципы, вы, возможно, будете справляться с задачами, которые на первый взгляд кажутся «не вашей головной болью», так как вы работаете с другим кодом.

Заключение


Как я уже говорил, чтение этой статьи может помочь вам узнать о новых для себя вещах, способных сделать вас более квалифицированным программистом, и требующих усилий и дисциплины. Если вы нашли здесь идеи, кажущиеся вам полезными — не затягивайте, попробуйте реализовать их уже сейчас!

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (289):

  1. aFanOfSwift
    /#18870431

    Вроде бы очевидные вещи, жалко только не все их понимают.

    • artskep
      /#18870519

      Понимать, скорее всего, понимают. Но не всегда теория совпадает с практикой (где-то ресурсов не хватает, где-то сроки горят, где-то попытки делать "правильно" могут привести к проблемам, а дома жена и дети и они хотят кушать)
      Это жизнь. Все ведь знают и понимают зачем правила дорожного движения, и их надо выполнять. Но каждый хоть раз их да нарушил.

  2. EvilArcher
    /#18870647 / -1

    Все это замечательно, когда оторвано от бизнес-задач.

    Каким бы советам вы не следовали, главное помнить, что любой наемный работник, в первую очередь, должен уметь приносить пользу компании, в которой работает. В связи с этим, я бы сформулировал другие советы «как стать полезным сотрудником», которые пригодятся не только программистам:

    1) Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.
    2) Изучайте бизнес-процессы компании.
    3) Рационализируйте. Предлагайте идеи руководству по улучшению, не ждите, когда вам принесут ТЗ на блюдечке с золотой каемочкой.
    4) Берите задачи чуть выше вашего уровня (знаний). Так вы сможете развиваться.

    Так вы станете полезным, а значит востребованным и хорошо оплачиваемым. Программирование это всего лишь инструмент. Если вы не знаете как заработать с помощью него деньги для компании, то вы бесполезный балласт.

    • suharik
      /#18870759 / +1

      1) Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.

      Ага. Товарищ один, занимавшийся разработкой модуля для хирургического отделения некоей больницы внял такому совету и начал изучать хирургию. Скальпели купил, маску, перчатки там всякие… И в 40 лет бросил профессию программиста, став хирургом.

      • saluev
        /#18870867

        Очень круто, между прочим. Его междисциплинарный опыт может позволить ему увидеть места для инноваций там, где их никто раньше не видел.

      • zoonman
        /#18872767 / +1

        Такие сказки только в России возможны. В нормальной стране его бы к пациенту только лет через 10 подпустили бы после получения соответствующего образования, сдачи экзаменов и получения необходимой практики. В общем годам к 50 стал бы хирургом.

        • Whuthering
          /#18872809

          Мне кажется это был сарказм. По аналогии с многочисленными «историями» в обратную сторону, когда хирург, пройдя пару онлайн-курсов по веб-разработке, сразу же становится востребованным фронтенд-разработчиком.

    • Whuthering
      /#18871269

      Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.

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

      • arilou_camper
        /#18872435 / +2

        Или не изучайте, и будете как в том анекдоте — «могу копать, могу не копать»

      • kiwokr
        /#18873023

        Лишних знаний не бывает. И работать не зная предметную область и бизнес процессы компании это просто бред.

        • Neikist
          /#18873039

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

        • ankh1989
          /#18874115

          Как не бывает и лишнего времени.

    • Femistoklov
      /#18872513 / +2

      1) Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.
      А если, к примеру, мне неинтересен телеком, всякие сети и передачи данных кажутся скучными? И финансы с бухгалтерией терпеть не могу.

      • Free_ze
        /#18873961

        Так и речь не шла про увлечения и интересы. Если в комплекте идет плохая усидчивость и мотивация, то есть риск стать там малополезным парнем. Такое случается и, наверное, стоило бы подумать о другом рабочем месте с более интересной прикладной областью.
        Ведь ощущение пользы от своего труда (облегчение работы других людей, сэкономленные ресурсы компании или удовлетворение клиентов) — это само по себе неплохая мотивация, как мне кажется. Но как понять боль людей, о которой ты не имеешь даже поверхностного представления?

        • 0xd34df00d
          /#18876219

          Хехе. Никогда не понимал этой мотивации. Решить интересную сложную задачу — это да. Даже если у неё нулевая практическая применимость.

          • Free_ze
            /#18876721

            Взаимно) В чем радость решения абстрактной в вакууме задачи? Для меня это звучит как рекорды гиннеса про толкание апельсинов носом.

            • 0xd34df00d
              /#18876999

              А в чём радость самой по себе пользы от своего труда? :)

  3. peresada
    /#18870725

    Старайтесь быть добрее

    Когда в следующий раз встретите бездомного алкоголика, который идет на Вас с угрожающим видом, предложите ему помощь, отмойте его, обрейте, усыновите, купите ему квартиру, найдите ему жену, пожертвуйте собой ради его будущего.

    __________
    Вот как-то так читаются подобные статьи. Лучше потратить время на какую-нибудь классическую утопию

    • immaculate
      /#18872515

      Нет, не значит. Помочь человеку не значит дать ему денег или квартиру. Иногда даже ударить человека — значит помочь ему (например, когда дают пощечину, человеку, находящемуся в шоке).


      Быть добрым и по-настоящему помогать людям — это очень сложная задача, отнюдь не раздавать деньги и ресурсы каждому встречному.

      • JobberNet
        /#18872665 / +1

        Иногда даже ударить человека — значит помочь ему

        … то есть, гопник помогает лоху понять, что он лох и ссыкло.

        • immaculate
          /#18872681 / -1

          Я в скобках написал пример того, когда ударить человека — помочь ему. Нет однозначного способа помочь каждому, такого как: дать каждому денег, или ударить каждого.


          Помочь — значит вникнуть в ситуацию конкретного человека и дать ему именно ту помощь, в которой он нуждается.


          Здесь нет одного решения, которое годится для всех. Одному человеку нужно дать совет, другому дать денег, третьего утешить, четвертому дать книгу, пятому что-то другое.


          И стараться быть добрым не значит, что надо помогать каждому встречному. От такой помощи нередко даже вред может быть, недаром говорят, что добрыми намерениями дорога сами знаете куда вымощена. Без мудрости помочь другому человеку не навредив себе или ему невозможно.

  4. musuk
    /#18870917

    Главное забыли:
    Не женитесь
    Не заводите детей
    Не имейте других хобби

    А то не будет времени на тесты, опенсурс и прочее.

    • Neikist
      /#18870959

      Насчет других хобби могу поспорить. Например я совмещаю велосипед со слушанием подкастов. Иностранные можно учить с расчетом на переезд, ну и в конце концов иногда нужен отдых, так что можно завести что нибудь расслабляющее для этих целей.

      • suharik
        /#18871061

        завести что нибудь расслабляющее

        массажистку? Есть видео о том, как трое друзей такую заводят.

        • Neikist
          /#18871083

          Я предпочитаю чтение какой нибудь легкой литературы и просмотр аниме. Все таки трудно массажистку «хобби» назвать)

      • Piratz
        /#18873305

        То есть насчёт «Не женитесь, Не заводите детей» вы согласны ?)

        • Neikist
          /#18873313

          Лично я вижу это логичным, поскольку и без этого на разное самообразование часов 20 в неделю хорошо если удается выкроить, а уж если заводить семью, или общаться с друзьями чаще чем раз в месяц-два — вообще представить не могу как как то развиваться.

        • Germanets
          /#18875273

          Ну я на счёт «не женитесь» не соглашусь, многим женившимся готовить приходится примерно в 2 раза реже, и заниматься всякими подобными вещами по дому… А уж если учитывать особенности менталитета и воспитания, то есть шансы вообще найти вариант, при котором готовить\стирать\работать по дому больше не придётся)
          Может, конечно, всё наоборот получиться, но это опять же вопрос выбора и может быть немножко везения..)
          UPD: увидел уже подобную ветку обсуждения от другого комментария…

    • jeConf
      /#18871119 / +1

      «Не женитесь» я бы вычеркнул.
      Иначе кто будет содержать программиста в то время когда он «тесты, опенсурс и прочее», а при этом на всех доступных работах хотят чтобы всё заработало вчера.

      • Whuthering
        /#18871397 / +1

        … иначе кто будет выносить программисту мозги «опять сидишь в комп уткнулся», когда он «тесты, опенсурс и прочее»…

      • Areso
        /#18873379

        Холодильник поближе поставить и всего делов.

      • reiser
        /#18874395

        Приготовить простую и вкусную еду занимает не так много времени, ну либо можно в кафе работать :)

    • 0xd34df00d
      /#18872383

      Подтверждаю, очень важные пункты, без них к успеху не придёшь.

      Я вот завёл хобби в виде всякой математики, теперь меньше времени на опенсорс и программирование :(

  5. AlekseyCPP
    /#18871355

    Это не для России, честное пионерское :)
    Ну какой опен- сорс? У нас тестов не делают, а архитектурные вопросы решаюся добавлением глобальных флагов (я уже не говорю об изучении чего-то нового). Компании всеми силами стараются минимизировать расходы на программистов, потому что считается что они и так получают неприлично много. Последнее происходит из- за знания программистами английского языка и как следствие- возможности продавать себя на западном рынке (а значит рынок IT в России должен конкурировать с глобальным).

    • Neikist
      /#18871387

      Фух, а то я читая хабр уже начал дикий комплекс неполноценности зарабатывать, так как уже возникает ощущение что наша компания одна такая на всю страну осталась. Теперь знаю что их по крайней мере две (если мы конечно не из одной)))

      • Whuthering
        /#18871401 / +1

        Честно скажу, меня всегда интересовало, что же держит людей в таких компаниях. Особенно учитывая, что альтернатив на рынке труда просто море.

        • Neikist
          /#18871431

          В моем случае то что я программирование изучать начал примерно за год до окончания вуза, на момент окончания почти не знал английский, да и программирование тоже + возможность выбирать только в небольшом городе, где компаний раз — два и обчелся. Собственно в последнее время раздумываю что вариант только один, переезд, но потребуется еще и сильно фундамент подтянуть, плюс стек сменить (текущий выбирал из того что было доступно на момент начала карьеры).
          А, ну еще общая тупость мешает конечно же.

          • shmatuan
            /#18873673

            в небольшом городе, где компаний раз — два и обчелся. Собственно в последнее время раздумываю что вариант только один, переезд,

            Почему не удалёнка или фриланс? Вакансий хватает, так что вариант далеко не «только один» -_-

            • Neikist
              /#18873745

              Думал, но как я и говорил, хочу стек сменить, а на удаленку, как правило, нанимают уже состоявшихся специалистов на конкретном стеке, ну либо нанимают на небольшие проекты или задачи на несколько месяцев, не больше.
              Да и про общую тупость упоминал уже которая не позволит с сотнями других удаленщиков конкурировать. Вон, только в марте прочитал «Грокаем алгоритмы», а уже не только не могу вспомнить решение задач методом динамического программирования, даже не помню список всех рассматриваемых в книге тем. А ведь книга то простая и совсем базовые вещи описывает.

          • Areso
            /#18874057

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

  6. firk
    /#18871445 / +6

    Статья — просто куча шаблонов, часть из которых придуманы как раз теми, кто указан в заголовке. Часть из этих советов просто спорны (например «пишите больше кода» ибо без уточнения что код должен реализовывать полезный функционал — совет становится вредным), часть — хорошие, но не имеют отношения к теме статьи (например «будьте честны»), часть — вообще не в тему и потенциально вредные (например «умерьте своё эго», более того у этого совета заголовок не соответствует содержанию).

    • Neikist
      /#18871455

      например «пишите больше кода» ибо без уточнения что код должен реализовывать полезный функционал — совет становится вредным

      С этим пунктом не согласен. Код может писаться в целях обучения или развлечения. Тогда ему совершенно нет необходимости реализовывать полезный функционал.

    • zoonman
      /#18872779

      Да типичные советы индусов. Выключите мозг и зазубривайте шаблоны до автоматизма, а затем пишите тонны спагетти.
      А результат один — текстовый редактор в браузере, который умирает на файле в 100 кб.

  7. vp_arth
    /#18872323 / +1

    Даже если все функции валидации сегодня у вас синхронные, стоит предусмотреть в интерфейсе возможность добавить асинхронную валидацию в будущем:
    validate(data)
    .then(postdata)
    .then(append..)

    .

  8. m0Ray
    /#18872371

    Когда я начал активно тестировать свой код, я был удивлён своей неподготовленности к написанию качественных тестов.

    Когда я начал сдавать свой желудочный сок, я был удивлён своей неподготовленностью к сдаче качественного желудочного сока.
    ЕВПОЧЯ.
    ДТКВТ: «Второе нашествие марсиан».

    Вы удивитесь, но я могу писать рабочий код, не «покрывая его тестами». Я просто вижу, как он работает, моделирую его в сознании. Это требует усилий, разумеется. Но заменять это на тупые автотесты? НетЪ!

    Ваши карманные калькуляторы отучили вас считать в уме. Это больше не искусство, это тупое ремесло.

    • 0xd34df00d
      /#18872389 / +2

      Восхищаюсь вашим умом, способным сохранять ментальную картину кода на многие месяцы, и вашими коммуникативными навыками, способными эту ментальную картину передать следующему владельцу написанного вами кода.

      А как вы к строгой типизации относитесь, кстати? Или лучше всё в строку, а тайпчекер не нужон?

      • m0Ray
        /#18872395 / +1

        Вот тут я немножко уязвим: другому человеку ментальную картину кода/проекта я передать не в состоянии. Хотя чужую, наверное, пойму, хоть и не с единичной вероятностью.
        Что поделать, это текущие ограничения физических тел homo erectus'ов не позволяют прямой обмен мыслеобразами. Эволюция это исправит когда-нибудь.

        Типизация у меня в коде зачастую строгая. Даже когда кодю на Python, соблюдаю. Внутри сознания, разумеется.

        • aikixd
          /#18873137 / +1

          Очень долго работал фрилансером, контакта с другими разработчиками не имел и думал что то что вы описали и есть обычный программист. А потом я встретил людей.

          • m0Ray
            /#18873781

            Людей я тоже не люблю, да. От них интернет тупеет.

    • Avvero
      /#18872487

      "Слишком хорош, чтобы писать тесты"

    • i86com
      /#18872521 / +1

      Тут вся трагедия в том, что этот список ассертов в конце юнита люди (по историческим причинам) называют тестами, из-за чего у них возникают лишние ассоциации к тому, зачем и почему это делается. Ну, мол, «тесты нужны, чтобы протестировать. Не будешь же ты непротестированный код выдавать».

      Так вот для нормального тестирования нужны тестировщики (в мелких проектах эту функцию легко выполняет сам программист или принимающий работу).

      А тесты же нужны в основном для того, чтобы автоматически выявлять ситуации, когда «тут починил, а там в 3 местах отвалилось». То есть в больших, развесистых проектах, с большой командой разноуровневых программистов или если цена ошибки очень велика (биржа, например). Чтобы можно было быстро, просто и без оглядки редактировать код под текущие нужды.

      Поэтому нет смысла писать людям про необходимость тестов и создавать из этого культ карго, когда тесты нужно писать «потому, что в Интеле пишут» или «потому, что best practices». В тех проектах, где тесты нужны, их необходимость становится очевидна всем участникам.

      • m0Ray
        /#18872907 / -2

        «тут починил, а там в 3 местах отвалилось»

        Я с трудом себе могу представить такую ситуацию. Кто в здравом уме допустит криворуких программистов к коммерческому коду? Немыслимо…

        • JobberNet
          /#18872959 / +3

          Аутсорсинг?

          Фреймворки?
          Когда во фреймворке была ошибка — код в этих трёх местах был написан с поправками на наличие ошибки во фреймворке, так что исправление ошибки во фреймворке, привело к тому, что код учитывающий наличие ошибок — теперь сам работает ошибочно.

          Легаси?
          Просто заплатки на заплатках лепившиеся в спешке.

          • m0Ray
            /#18872993

            Ну, работал я на аутсорсинге. Писал код, претензий у заказчиков не было.

            Любимые фреймворки — Drupal, Symfony, jQuery (на фронтенде). Ошибка во фреймворке — issue разработчику. Код, «учитывающий наличие ошибок» — это что? «Грязные хаки» так называемые? Такого в моём коде не бывает.

            Даже «лепившееся в спешке» у меня выглядит прилично, а затем перерабатывается.

            Я так и не понимаю, зачем писать говнокод в файлы, если можно проработать кучу вариантов кода в голове, и только потом изливать это в виде текста программы.

        • aikixd
          /#18873169

          Если задача достаточно сложная, последствия могут быть непредсказуемыми. У нас виртуальная машина, сломать там что-то совсем не сложно. Тем более что весь объем спецификации загрузить в голову невозможно даже теоретически.

          • m0Ray
            /#18873723

            Для этого большая задача разбивается на более мелкие с унифицированным интерфейсом и загружается и решается последовательно (одним программистом) или параллельно (командой). Главное — правильно разделить и унифицировать. Это уже опыт, талант и «чуйка».
            Программирование — творческая работа, щоб ви таки знали.

        • i86com
          /#18873429

          «тут починил, а там в 3 местах отвалилось»
          Я с трудом себе могу представить такую ситуацию.

          Да легко. Например, перевод системы на новую кодировку или имперскую систему счисления (ну, там, дюймы, фунты, фаренгейты, MM-DD-YY). Пока в Вилларибо натужно вспоминают все те места, где это может что-то поменять, в Виллабаджо уже по тестам сразу видят, где что не так.

          • m0Ray
            /#18873697

            «Реши другую проблему так, чтобы большинство предыдущих вообще потеряли смысл».
            Unicode, std::chrono — я люблю вас.

            • 0xd34df00d
              /#18876229

              Так это надо, значится, типы любить, а не пихать всё в int, string и void*.

      • akera
        /#18872931 / +2

        Поэтому нет смысла писать людям про необходимость тестов и создавать из этого культ карго, когда тесты нужно писать «потому, что в Интеле пишут» или «потому, что best practices». В тех проектах, где тесты нужны, их необходимость становится очевидна всем участникам.

        Не лучше ли тогда сразу развивать в себе это полезное качество, чтобы иметь в любую возможность плавно влиться в такие проекты? Для конкретного разработчика это, как мне кажется, сулит бОльшие перспективы.
        Вообще, как начинающий разработчик, я часто в подобных дискуссиях задаюсь вопросом: в чём заключаются явные преимущества неписания юнит-тестов перед их написанием? Потому что в пользу обратного говорит очень много фактов. Если речь, конечно, не заходит о совсем тривиальных элементах кода.
        Так вот для нормального тестирования нужны тестировщики.

        «Нормальное» тестирование — слишком расплывчатое понятие, непонятно, как его интерпретировать. Очевидно, по общепринятым классификациям тестирования ПО для некоторых его видов требуются и отдельные тестировщики, и целые их команды, и наборы технических средств для автоматизации. Но с позиции непосредственно разработчика переносить ответственность за работоспособность своих модулей на кого-то ещё — неправильный подход.

        • i86com
          /#18873279

          в чём заключаются явные преимущества неписания юнит-тестов перед их написанием?

          Экономия сил и времени. Так-то по-хорошему, любой код можно оборачивать тестами, писать к нему документацию на двух языках и оптимизировать мелочи типа «что быстрее в микросекундах — for или while». Но если из-за этого задание на вечер превращается в работу на неделю (особенно если код временный, одноразовый или для собственных нужд) — это, чаще всего, лишнее.

          Если работаете за фиксированную оплату по результату или пишете для себя — ради бога. А если повремёнка — то вы уже просто прожигаете чужие деньги и тратите время (которого обычно и на быстрый-то код не хватает).

          Но с позиции непосредственно разработчика переносить ответственность за работоспособность своих модулей на кого-то ещё — неправильный подход.

          Это не ответственность за работоспособность. Тестировщиков никто не обвинит в том, что они нашли баг и не заставят его чинить.
          Это просто разделение труда — человек, который умеет эффективно писать код продакшен-уровня это редкость и их всегда не хватает. Пусть лучше занимаются самой продуктивной своей деятельностью, а не тем, что можно поручить остальным.

          Также часто это всплывает при работе с нечёткими и постоянно меняющимися требованиями к результату (то есть в реальной жизни бизнеса). Пусть лучше заказчик сам оттестирует или даст оттестировать своим сотрудникам (будущим пользователям), потому что там не столько вопрос работоспособности, сколько вопрос соответствия ожиданиям. А это юнит-тесты не покрывают.

          • Whuthering
            /#18873851

            А если повремёнка — то вы уже просто прожигаете чужие деньги и тратите время

            То есть деньги и время, затраченные на ручной поиск и разгребание регрессий в будущем вы не учитываете?

            • i86com
              /#18873987

              Это я отвечал про проекты, где тестов не нужно, но очень хочется. Например для тренировки.
              Там где нужно, я выше упоминал, вопроса не возникает, нужно ли.

              • Avvero
                /#18874061

                Интересно, что это за проекты, где не были бы полезны тесты

                • m0Ray
                  /#18874125

                  Лучше назовите проекты, где они полезны.
                  Вот всякая бухгалтерия с кучей однотипный форм и операций — согласен. И возни с тестированием каждой много, и операции простые.
                  Только вот при слове «бухгалтерия» меня тошнит. Наелся при разработке биллинга. Не берусь за подобное мозгоклюйство в принципе. Нехай зануды без воображения однообразные формы клепают, а я — программист, я решаю задачи.

                  • Avvero
                    /#18874157

                    Для бэкенда они просто обязательны.

                    • m0Ray
                      /#18874185

                      Сколько писал бэкендов — ни разу не понадобились.
                      Ещё раз: простейшие глюки вылезают сами или легко тестируются прямо в браузере вручную набранным URL-ом.
                      Сложные, логические — для них тест писать дольше, чем сам продукт. Я не вижу смысла тратить на это время.

                      • Avvero
                        /#18874265

                        >Ещё раз: простейшие глюки вылезают сами или легко тестируются прямо в браузере вручную набранным URL-ом.

                        Хорошо, когда ваш бэкенд тестируется «прямо в браузере вручную набранным URL-ом.». А вот мой не тестируется так, он у меня, например, торчит http концом наружу и ждет запросов в свой api. Мне придется дергать кучу запросов руками и проверять толстенные json ответы?
                        А бывает, когда бекенд сервис вообще не имеет http конца, а только ESB слушает и отвечает.
                        А бывает, когда бекенд сервис интегрирован с другим сервисом через хитрый протокол и руками ничего вызвать из «браузера» нельзя
                        Бывает, что нужно проверить нагрузку, а я не могу открыть в своем браузере 10к вкладок с «вручную набранным URL-ом»

                        • m0Ray
                          /#18874315

                          А у меня вообще через MQTT некоторые бжкенды работают, и что? JSON вполне человекочитаем.
                          Нагрузочное тестирование сюда не надо приплетать. Это из другой оперы. Мы о скриптиках, которые подёргают API и найдут тупые ошибки.

                          • Avvero
                            /#18874319

                            о скриптиках, которые подёргают API и найдут тупые ошибки

                            Вы такие скрипты пишете?

                            • m0Ray
                              /#18874363

                              Нет. Я могу это сделать руками, если нужно.

                              • Avvero
                                /#18874409

                                (пошел посмотреть)
                                У меня есть сервис… раскладывания кошек по коробкам в зависимости от породы кошки, цвета шерсти и 5-и других параметров.
                                Тест для 300 case'ов работы сервиса распределения занимает 3 минуты. 1 case — это уникальный набор параметров кошки отправленный http запросов в сервис.
                                Руками это проверять оооооочень долго

                                • m0Ray
                                  /#18874433

                                  Параметры по отдельности проверить не вариант? Их всего пять.
                                  Если неправильно работает один параметр — это видно сразу.
                                  Если вы умудрились сделать так, что у вас программа работает в зависимости от сочетания параметров и фазы Луны — ну извините.

                                  • Avvero
                                    /#18874455

                                    Фаза луны не при чем. Но разные комбинации параметров дают разный результат. И таких комбинаций/результатов много, как я описал.
                                    Руками проверить нужно каждый случай, потому что все работать должно на бою правильно иначе потеря тысяч денег

                                    • m0Ray
                                      /#18874513

                                      Разумеется, разный. Но каждый параметр определяет свой набор результатов. Если анализ каждого параметра сделан верно — результат будет правильным. Я не понимаю, зачем тестировать весь набор.
                                      Впрочем, если у вас есть «тысячи денег» и время, чтобы такую проверку реализовать и гонять каждый раз — вай нот? У меня — нет.

                                      • Avvero
                                        /#18874567

                                        Если анализ каждого параметра сделан верно — результат будет правильным

                                        Если. А как вы этом убедиться? Нужно проверять
                                        если у вас есть «тысячи денег» и время, чтобы такую проверку реализовать

                                        Я выше привел пример, 300 случаев, каждый нужно проверить. Тестом — 3 минуты, руками — часы

                                        • m0Ray
                                          /#18874601

                                          Нужно убедиться, что анализ каждого параметра прописан верно. Это можно узнать, посмотрев на код и покрутив его в голове. Их всего 5.

                                          Если у вас 300 вариантов — то каждый должен быть прописан в коде? Это что-то ненормальное и очень большой объём. Надо посмотреть на задачу с другой стороны и решить её как-то иначе. Например, посмотреть в сторону таблиц или хэшей.
                                          Я в аналогичном случае просто передавал анализатору PNG-изображение, в котором он по координатам получал 4 параметра и делал с ними предписанное. В изображении «косяки» можно обнаружить чисто визуально.

                                          • Avvero
                                            /#18874655

                                            Параметров 8 (порода кошки, цвета шерсти и 5-и других параметров), а для каждого свои варианты значений.
                                            И распределение нельзя как-то высчитать, оно соответствует описанной бизнесом логики.

                                            И да, схемы распределения конечно же хитрые — сегодня черных метровых кошек с зелеными глазами в коробку #21, а завтра в #22

                                            При этом нужно учитывать, что написал я распределение, тесты, все ок и далее идут задачи на изменение схемы и, благодаря наличию тестов, я могу править только нужные кейсы и не переживать за другие части сервиса — там тесты тоже есть. Поэтому оценка задача на правку схемы такой мизерная.
                                            А при отсутствии тестов все эти 300 случаев руками перепроверять

                                            • m0Ray
                                              /#18874769

                                              Океюшки, вы описали случай, где тесты реально нужны. Как я и говорил — такие случаи есть, но это не значит, что их надо лепить везде где ни попадя.
                                              Но я бы подумал над тем, как решить задачу иначе.

                                              У меня, если стрелки попадают по мишени, а она не срабатывает или срабатывает нечётко — это видно сразу. Моя система автоматически подстраивается к разным параметрам окружения, а некоторые другие не меняются практически никогда, они вычислены или подобраны на оптимум.
                                              И так я стараюсь делать всё. Получается слишком сложно — разделяем задачи и оставляем минимум места ошибкам.

                  • 0xd34df00d
                    /#18876243

                    Мне очень нравится писать компиляторы через тесты. Продираешься через спеку языка, реализуешь ещё один кусок — добавляешь тест.

                    Меняешь логику, преобразования AST, кодогенератор, всё такое — чинишь тесты и потом радуешься, что они снова зелёные.

                    Просто рефакторишь код, чинишь всю ругань ghc — а тесты уже зелёные. Приятно сразу!

                • i86com
                  /#18874475

                  Интересно, что это за проекты, где не были бы полезны тесты


                  Я в предыдущих комментах перечислял.

                  По критериям:
                  — проекты, где нет развесистой логики;
                  — проекты, где нет необходимости в долгой поддержке кода и/или большой команде программистов;
                  — где невелика цена ошибки, но при этом крайне важна скорость выхода;
                  — проекты, в которых основное тестирование может выполнить только заказчик и пользователи/тестировщики (т.е. самое главное автоматизировать не получится).

                  Примеры таких проектов:
                  — прототипы;
                  — игры (почти все, за исключением AAA-класса и игр с реальными деньгами);
                  — интерфейсы, основная функция которых — отображать данные с уже существующих API;
                  — прикладные программы, которые нужны временно или одноразово;
                  — практически все проекты от бизнеса, в которых ТЗ пишется умными словами, но на нормальный язык его можно перевести как «Сделайте такое же, как вон там, но другое. Насколько другое — пока не придумали. Увидим — скажем, что поправить.»;

                  Опять же, в тех проектах, где тесты нужны, это всегда очевидно. Если нет, значит, это неэффективная трата времени.

                  А иначе можно дойти и до того, чтобы команды в консоли с тестами писать.

                  • m0Ray
                    /#18874517

                    А иначе можно дойти и до того, чтобы команды в консоли с тестами писать.

                    Тащемта я так и делаю.
                    А ещё printf().

                    • i86com
                      /#18874559

                      Перефразирую — команды в linux-консоли с тестами к ним же.

                      • m0Ray
                        /#18874605

                        Именно.

                        • i86com
                          /#18874833

                          То есть если вам нужно, например, пару раз переименовать все файлы в папке из
                          *_rus_*.csv
                          в
                          *_eng_*.csv
                          , вы пишете консольную команду, и затем после этого (или перед этим) в той же команде создаёте n тестовых файлов с разными названиями и расширениями и проверяете, всё ли правильно переименовывается? Сомневаюсь.

                          • m0Ray
                            /#18874893

                            Ну сомневайтесь. А я для этого просто создам каталог «на поиграться» и проверю, если случай действительно сложный. Если там будет задействован rm, я ещё и chroot сделаю.

                          • 0xd34df00d
                            /#18876255

                            Если это действительно важно, я такой скрипт пишу на хаскеле. Логику переименования пишу в отдельной чистой функции, в repl её вызываю с тестовыми данными, а потом к ней пишу IO-обвязку из трёх строк, в котоой ошибиться невозможно.

    • ProgMiner
      /#18872709 / +1

      Считал, что могу писать нормальный код без юнит тестов, пока не начал писать юнит тесты.

      • m0Ray
        /#18872897 / -1

        Начал писать юнит тесты, не понял, зачем это мне нужно, бросил писать юнит тесты.

        • Whuthering
          /#18872913 / +2

          Может быть, стоило попробоваться поучаствовать в проектах хоть немного сложнее хеллоу-ворлда?

          • m0Ray
            /#18872965

            Комплекс TTC, или, например, система маршрутизации и биллинга и для IP-телефонии (написанная практически в одну харю) — сложнее хеллоу-ворлда, как думаете?

            • IRainman
              /#18873079 / +2

              написанная практически в одну харю

              Вот в этом разница, если была бы команда без тестов было бы совсем грустно.

              • m0Ray
                /#18873089 / -3

                Команда за год написала такое, что я за два вечера переписал и послал нахер такую команду.

                • Avvero
                  /#18873395 / +1

                  Мы обычно наоборот, а потом все еще тестами покроем

                  • m0Ray
                    /#18873455

                    И фирма разорится, потому что код всё равно не будет работать как надо, требовать нового железа (в моём случае были Cisco AS53xx), платных средств разработки, и команда разработчиков будет много кушать.
                    Проходили. К сожалению, реальность такова, что один-два-три нормальных программиста, способных держать задачу (или свою часть оной) в уме, гораздо продуктивнее команды неумех, вызубрившей «паттерны», «TDD», всякие там новомодные способы трахать мозги себе и окружающим (agile или что ещё там) и прочее.
                    Работать надо, и надо знать своё дело. Иначе получается не работа, а ИБД без видимого результата.

                    • Whuthering
                      /#18873551

                      вызубрившей «паттерны», «TDD», всякие там новомодные способы трахать мозги себе

                      Особенно смешно, учитывая, что все это было придумано и успешно используется в деле как раз-таки программистами, для более удобного, эффективного и надежного процесса разработки. Может быть все-таки проблема не в окружающих, а в вас?

                      • m0Ray
                        /#18873659

                        Нет, проблема в тех, кто считает себя программистом, не имея к этому способностей и таланта. Вот они для себя это придумали и как-то так это работает [биллгейтс.жпг].
                        Напоминает: «он стал поэтом, потому что для математики у него не хватало воображения». Мне вроде всего хватает, в костылях нужды не испытываю.

                        • Whuthering
                          /#18873703

                          проблема в тех, кто считает себя программистом, не имея к этому способностей и таланта.

                          а вот уже и началась телепатия и выводы, не основанные ни на чем.
                          Мне вроде всего хватает, в костылях нужды не испытываю.

                          Как ни полезна вещь, — цены не зная ей,
                          Невежда про нее свой толк все к худу клонит;
                          А ежели невежда познатней,
                          Так он ее еще и гонит.

                          • m0Ray
                            /#18873737

                            Намекаете на «мартышку и очки»? Так я не слаб глазами (образно, физически-то скоро ослепну). Мой код работает.

                      • aikixd
                        /#18873727 / +1

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


                        Лично у меня был пример. Несколько лет назад прочитал про паттерн "Команда". Спустя пару лет, когда он мне понадобился, я ничего о нем не помнил. К счастью название не забыл. Зашел на вики, пошуршал, ничего не понял. Может написано плохо, может я тупой. Взял маркер, доску, придумал свою реализацию, закодил, протестил, все работает. Вернулся к статье и тогда внезапно все стало понятно.


                        Суть в том, что паттерны не живут в вакууме. Для них нужны причины, у них есть свои проблемы и узкие места в рамках своего окружения. И в отрыве от окружения они бесполезны.


                        Вот фабрика. Вроде всем понятно зачем она нужна, но в отрыве от задачи ничего не понятно. Зачем городить огород, если можно просто создать объект?

                        • m0Ray
                          /#18873761 / -1

                          «Зачем думать, если можно взять паттерн?»
                          А если паттерн не очень подходит к задаче? А если архитектор некомпетентен?
                          Если я скажу: «нужно исключить возможность создания копии объекта», вы поймёте, что я говорю? И любой, даже не знающий паттернов поймёт. Потому, что я знаю, о чём говорю, и объясняю доступно.
                          Если я скажу: «ну, тут просто сделайте синглтон» — повысится вероятность того, что я получу на выходе НЁХ, не соответствующую задаче. Зато слово умное сказал, паттерны знаю, ога.

                          • aikixd
                            /#18873807 / +1

                            Все сводится ко времени которое вы готовы потратить на общение. Если для описания решения (это в том числе и имена символов в коде, который потом кто-то будет читать) половина времени уходит на описания паттернов (есть паттерны которые реально долго описывать), то это контрпродуктивно.

                            • m0Ray
                              /#18873905

                              Если задачу объясняют мне, неважно, мыслю я зазубренными паттернами, как овощ или, как человек, образами-«голограммами». То же самое неважно, если задачу объясняю я.
                              Я, как правило, ставлю задачу: что этот код должен делать и как я к нему должен обращаться. Потом сам же решаю или передаю другим людям. Главное — сформулировать задачу. Недаром говорят, что это половина решения.
                              Объяснять задачу надо максимально просто и доходчиво. Без «умных» слов желательно. Можно с матюками.

                              «Эта процедура должна найти на изображении красную точку с ограничением по яркости и размеру. Она будет запускаться в многопоточном окружении.»
                              «Требуется передать ряд изображений на многопоточную обработку вон той процедуре, после чего собрать результаты обработки обратно в правильной последовательности».
                              «Нужно проанализировать ряд результатов и найти внезапно появившуюся красную точку, определить принадлежность её координат зоне, определяемой битовой картой, при нахождении вызвать событие.»
                              «При таком-то событии следует передать сообщение по сети, протокол такой-то, параметры должны включать координаты, время и изображение.»

                              Реальные задачи, между прочим. Доска с беспыльным мелом рулит (ненавижу фломастеры).

                              • aikixd
                                /#18874813

                                «Эта процедура должна найти на изображении красную точку с ограничением по яркости и размеру. Она будет запускаться в многопоточном окружении.»
                                «Требуется передать ряд изображений на многопоточную обработку вон той процедуре, после чего собрать результаты обработки обратно в правильной последовательности».
                                «Нужно проанализировать ряд результатов и найти внезапно появившуюся красную точку, определить принадлежность её координат зоне, определяемой битовой картой, при нахождении вызвать событие.»
                                «При таком-то событии следует передать сообщение по сети, протокол такой-то, параметры должны включать координаты, время и изображение.»

                                Это все задачи, тут ни слова об исполнении.


                                вызвать событие

                                События, кстати, паттерн.

                                • m0Ray
                                  /#18874885

                                  Вот именно, я ставлю задачи. Как их решать — должен знать исполнитель.
                                  Берём первую. Исполнитель начинает задавать вопросы.
                                  В: В каком виде изображение?
                                  О: Байтовый массив, представляющий JPEG-rкодированное изображение.
                                  В: openCV можно?
                                  О: Нужно.
                                  Всё. Исполнитель понял, что ему, скорее всего, передадут shared_ptr из стандарта C++11, декодировать изображение надо при помощи cv::imdecode(), преобразовать цветовое пространство, свериться с моделью цветового пространства и т.д., понеслась работа. Это если исполнитель владеет темой.
                                  По счастью, тут исполнитель я и всё это в принципе знаю. А на практике, конечно, пронеслась куча итераций сначала в голове, потом в реальном коде.

                                  Паттерн? Окей. Но слово «событие» вам понятно и без знания паттернов, не так ли?

                          • Whuthering
                            /#18873837 / +1

                            «Зачем думать, если можно взять паттерн?»

                            Вам выше автор комментария написал, что бессмысленно бездумно брать паттерны (да и никто так не делает), а вы приводите реплику ровно с обратным смыслом.
                            А если паттерн не очень подходит к задаче?

                            То ничего не мешает подумать и модифицировать его, чтобы подходил.
                            Если я скажу: «нужно исключить возможность создания копии объекта», вы поймёте, что я говорю?

                            То это будет так:
                            Obj(const Obj&) = delete;

                            Это вообще не похоже на синглтон и не реализует его функционал. Так что вы привели отличный контр-пример к своей же теории.

                            • m0Ray
                              /#18873927

                              Наоборот, я привёл пример того, что задача отлично решается без паттернов. Надо уметь её формализовать и изложить даже самому себе, тогда она решается гораздо проще.

                    • Avvero
                      /#18874049

                      способных держать задачу (или свою часть оной) в уме, гораздо продуктивнее

                      Не понятно, что тут продуктивного
                      А если он в отпуск ушел? Был уволен? Ни документации, ни тестов, ни фига… все унес в своей большой и умной голове.
                      Потом компания тратит деньги — время нового программиста, который вычитывает тонны кода и пытается уместить у себя в голове. А потом еще тратит на регрессионное тестирование сервиса.

                      При наличии тестов все проще, если что-то сломал, то это видно сразу — упали тесты

                      • m0Ray
                        /#18874065

                        Вот это — слабое место. Человек смертен, а хуже всего — что он внезапно смертен.
                        Я это осознаю и максимально облегчаю работу последователям. А если проект начнёт приносить деньги — возьму падавана.
                        Так делается у людей тащемта.

                        • Avvero
                          /#18874071

                          И как вы ее облегчаете?

                          • m0Ray
                            /#18874103

                            Хорошо структурированный и откомментированный код, записки о ходе мыслей, архитектуре и планах.
                            Вряд ли увеличение объёма кода тестами было бы облегчением, если вы об этом.

                            • Avvero
                              /#18874147 / +1

                              Скажем иначе. Если код не покрыт тестами, то оценка временных затрат на доработку этого кода и тестирование будет значительно выше, т.е. будет стоить дороже.

                              • m0Ray
                                /#18874165

                                Не согласен. Человеку помимо основного кода придётся разбирать и дописывать тесты, а значит, разбираться ешё и в системе тестов.
                                А нормальному программисту, как я постулирую, тесты в основном без надобности. Есть пограничные моменты, где они необходимы, но они не так часты.

                                • Avvero
                                  /#18874191

                                  А как вы поймете, что ваша правка ничего не сломала?

                                  • m0Ray
                                    /#18874217

                                    Если она что-то сломает, это сразу вылезет. Как я говорил, исключение — сложные системы с множеством форм, которые ручками не протыкать за нормальное время.
                                    Я таких не делаю. У меня нынче всё по-военному: затвор, приклад, спуск. Всё смазано и вычищено. Не дать дураку выстрелить себе в ногу. Работа такая.

                                    • Avvero
                                      /#18874299

                                      ручками не протыкать за нормальное время

                                      А это какое время? Час, два?

                                      • m0Ray
                                        /#18874323

                                        Пять минут. Если интерфейс программы за это время не обойти полностью — с ней что-то не так. Или она для бухгалтера.

                                        • Avvero
                                          /#18874333

                                          А если нет интерфейса? Тоже что-то не так?

                                          • m0Ray
                                            /#18874357

                                            Тогда она не нужна. Сообщить программе задачу и получить от ней результат — это интерфейс, как бы он ни выглядел. Программа, которая не делает ничего, не нужна.

                                            • Avvero
                                              /#18874367

                                              Я наверное не так понял, вы же имели ввиду графический интерфейс?

                                              • m0Ray
                                                /#18874377

                                                Любой. API, к примеру.

                                                • Avvero
                                                  /#18874419

                                                  Значит я не так понял.
                                                  А 5 минут это вместе с подготовкой данных для запроса? Ну например мне нужно разными json запросами сервис вызывать

                                                  • m0Ray
                                                    /#18874459

                                                    Как правило, данные готовятся один раз. Накидал пару-тройку запросов, сунул их в браузер или командную строку — и погнал. Оттестил — закрыл окно. На крайняк есть история, что в командной строке, что в браузере.

                                                    • ankh1989
                                                      /#18874725

                                                      Это только в совсем простых случаях работает. Вот вы делаете браузер например: надо отрендерить html, css, js. Вам кто то даёт ссылку на сайт где разметку подозрительно перекосило — в других браузерах всё нормально. Допустим вы догадались в чём дело и пофискили баг. Как вы узнаете, что ничего другого не сломалось?

                                                      • m0Ray
                                                        /#18874787

                                                        Открою страницу в нескольких браузерах (у меня их 4 штуки до сих пор стоит — да, да, и фронтенд тоже не мне), подвигаю размер окна. Если не сломалось при этом — значит, если и сломалось что-то, то это мизерный процент случаев, на который можно не обращать внимания.
                                                        То же самое с вашими тестами — сколько ни пишите, 100% никогда не покроете.

                                                        • ankh1989
                                                          /#18874839

                                                          Всё верно, ломается оно допустим в 5% случаев на некоторых сайтах с корпоративной формой авторизации где кривой html нахаченный индусами за еду. У вас даже не будет доступа к этим сайтам. Вы зафигачили багфикс в продакшн, а через неделю 4 компании которые платят вам за браузер говорят, что у них на работе стала часто глючить авторизация — раньше такого не было, поэтому либо платим неустойку либо фиским это в течении 3х дней как сказано в договоре. Были бы тесты, мы бы сразу заметили, что вот такая комбинация css пропертей вызывает глюки, но тестов нет. Что делать будем?

                                                          • m0Ray
                                                            /#18874905

                                                            Не будет доступа — это заранее оговорено в договоре?
                                                            Оговорено — сразу нахрен таких поциэнтов.
                                                            Я должен знать, с чем работаю.

                                                            • ankh1989
                                                              /#18874937

                                                              Ну а что если баг возникает только когда вице президент компании вводит свой пароль на внутреннем сайте авторизации? Он должен вам дать свой пароль, чтобы вы подебажили html разметку? На деле у вас не будет даже такой роскоши как 100% воспроизводимый баг — вам просто скажут, что примерно в таких ситуациях глючит примерно так. Это вы должны будете разбираться что именно не работает.

                                                              • m0Ray
                                                                /#18874969

                                                                «Плавающий баг» — признак говнокода. Переработай говнокод — баг исчезнет. Так говорит мой опыт.

                                                                • ankh1989
                                                                  /#18874993

                                                                  Баг не плавающий. Он возникает в конкретных условиях: конкретный html, css, js. Но получить именно эти html и т.п. вы не можете по описанной выше причине.

                                                                  • m0Ray
                                                                    /#18875003

                                                                    Хорошо, вы нашли ещё один из немногих случаев, где тест поможет.
                                                                    Сколько вы их выкопаете ещё? Из множества всех возможных?

                                                                    • ankh1989
                                                                      /#18875021

                                                                      Ого, это браузер один из немногих случаев? Да и как вам тест поможет если вы их не пишете?

                                                                      • m0Ray
                                                                        /#18875071

                                                                        А у меня всё работает.
                                                                        Для того, чтобы написать тест к моему коду, который отловит что-то кроме перепутанного знака, потребуется написать код, по сложности и объёму превосходящий то, что я написал. Я не вижу в этом смысла, когда то, что есть, работает.
                                                                        И да, как предлагаете писать тесты для микроконтроллеров? Создавать программируемое искусственное окружение, имитирующее звуки, удары, освещение?
                                                                        У меня нет на это времени. Мне проще пару раз постучать по автомату гаечным ключом, передёрнуть затвор и выстрелить. При финальном тестировании — выстрелить десять раз, а то и дать ребятишкам поразвлекаться, записывая логи.

                                                                        • ankh1989
                                                                          /#18875145

                                                                          Работает оно по двум причинам: либо ваш код прост как доска, либо его никто толком не проверял (мало юзеров и т.д.). Помню, что в такой уверенности я пребывал когда будучи студентом подрабатывал программёром: когда мой говнокод столкнулся с кучей реальных юзеров и они начали репортить какие то хитрые баги, я просветлился и понял зачем нужны юнит тесты.

                                                                          Возможно я вас удивлю, но количество кода в тестах часто превышает в несколько раз количество основного кода. Часто одна строчка изменений в основной либе сопровождается 5 тысячами строчек новых тестов. Нафига это нужно? Чтобы надежность была не 74%, а 99.99974%. Если вы фигачите формочки для десятка юзеров, то это конечно не нужно, но как только юзеров становится этак миллиард, ваш подход уже не прокатит.

                                                                          Для микроконтроллёров и тем более процессоров тесты вообще параноидальные: там тестируется даже очевидное по 100 раз. Потому что исправить софт можно обновлением по сети, а вот исправить баг в процессорах (как это было недавно у Интела) так не получится. Собственно поэтому вы работаете не в Интеле, а стучите гаечным ключом.

                                                                          • m0Ray
                                                                            /#18875177

                                                                            Именно! Я специально делаю код простым как доска, плоским как блин, и понятным как хрен! Если это не получается — я разделяю его на несколько простых, плоских и понятных частей, каждая из которых по отдельности сломаться не может — просто нечему. Потому всё и работает.
                                                                            Если бы я работал в Интеле, процессоры не были бы такими, как сейчас. Они были бы больше похожи на модные некогда «транспьютеры»: куча небольших простых блоков.

                                                                            • ankh1989
                                                                              /#18875191

                                                                              Выше мы обсуждали примитивную функцию с урезанной регуляркой. Делить там дальше уже некуда вроде. Но как видите даже с ней возникли непреодолимые сложности.

                                                                              • m0Ray
                                                                                /#18875195

                                                                                Нет с ней сложностей у меня. Но вы их создали.

                                                                        • Whuthering
                                                                          /#18875719

                                                                          Для МК тесты пишутся почти так же, как и для «больших» систем. Вы стреляете, стучите и светите не в сам микроконтроллер, а в соответствующий сенсор. В МК оно приходит в виде дискретного сигнала, частоты, битов АЦП, массива данных из I2P/SPI, и т.д.
                                                                          И вот уже то, как контроллер работает и ведет себя этими данными, и тестируются. А сами тестовые данные или «пишутся» заранее, или генерируются синтетически (по-хорошему и то и то, в зависимости от данных, конечно).

                                                                          • m0Ray
                                                                            /#18875733

                                                                            Как это поможет проимитировать криво наклеенную звукозащиту или хреновую, «дребезжащую» пайку?

                                                                            • Whuthering
                                                                              /#18875765

                                                                              А с чего это у вас тесты программного кода должны диагностировать аппаратные неисправности внешней обвязки?
                                                                              Их задача в данном случае — сказать, что ошибка появилась не в коде обработки сигнала после очередного мержа, а нужно брать в руки мильтиметр и осциллограф и проверять источник этого самого сигнала.

                                                                              • m0Ray
                                                                                /#18875771

                                                                                А вдруг уровень превысит или импульсы появятся где не положено?

                                                                                • Whuthering
                                                                                  /#18875855

                                                                                  Так в случае с «простым» тестированием для чистоты эксперимента еще нужно стараться, чтобы уровень был точно такой же, как и в прошлый раз, и импульсы снова появились в точности «не там». А когда у вас имитируется не реальный сигнал, а его цифровой двойник — у вас неограниченный простор для комбинации самых разных вариантов, которые вы даже не сможете или не подумаете специально воспроизвести «в живую» в лаборатории, но которые могут случиться в реальной жизни.

                                                                                  • m0Ray
                                                                                    /#18875863

                                                                                    Про стоимость и сложность тестовой установки я уже говорил.
                                                                                    А не проще ли хорошо писать код, прямо клеить звукоизол и правильно паять, м?

                                                                                    • Whuthering
                                                                                      /#18875885

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

                                                                                      • Whuthering
                                                                                        /#18875919

                                                                                        Хотя нет, не проще. Если было бы проще, то все бы так делали.

                                                                                        • m0Ray
                                                                                          /#18875945

                                                                                          Конечно. Знать своё дело и уметь делать его хорошо, быть честным и всё такое — всё это редкость.
                                                                                          Потому проще наплодить костылей, правил, законов, регламентов, приставить к каждому по полицаю…
                                                                                          Но можно просто не работать с дураками и жуликами. Это сложнее, но это наш путь.

                                                                                          • Whuthering
                                                                                            /#18876731

                                                                                            Есть очень хорошая старая песня «Битва с дураками» от Машины Времени, которая полностью актуальна до сих пор. Послушайте, возможно натолкнет на размышления.

                                                                                      • m0Ray
                                                                                        /#18875931

                                                                                        Устал объяснять. Скажу прямо. Дайте денег на разработчиков и тестовые установки. У нас их нет.
                                                                                        Я из ничего сделал что-то готовое к работе. Если бы я полагался на автотесты, разработка заняла бы гораздо больше времени.
                                                                                        А я умею и так, без костылей.

                                                                              • F0iL
                                                                                /#18875777

                                                                                Подозреваю, что «проимитировать» проблемы с внешними источниками помогут заранее «записанные» или сгенеренные паттерны проблем с внешними источниками.

                                                                                • m0Ray
                                                                                  /#18875801

                                                                                  Всё это по сложности намного превысит саму разработку. Это какое баблище придётся в это вбухать?
                                                                                  Когда-нибудь да. Но сегодня у меня, к примеру, одна из задач — вымутить какой-нибудь еды на 43 рубля.

                                                                                  • F0iL
                                                                                    /#18875833 / +1

                                                                                    Не вижу разницы, честно говоря, разницу в затратах между «выстрелить»/«отклеить»/«подергать» во время ручного теста, или для того чтобы записать сигнал с АЦП/сделать дамп обмена по шине, использовать это потом для тестов.

                                                                                    • m0Ray
                                                                                      /#18875853

                                                                                      Так чем я эти сигналы буду на контроллер подавать? Тут тестовое оборудование надо, и что-то мне подсказывает, что оно ни фига не дешёвое. Или колхозить тестовый стенд самостоятельно. Извините, ни времени, ни денег на это у меня сейчас нет.

                                                                                      • F0iL
                                                                                        /#18875877 / +1

                                                                                        Вы же сами говорили, что программы надо разделять на простые блоки. Блок, тупо получающий данные с АЦП или с порта (по сути дела копирующий массив из одного адреса памяти в другой) — это одна часть, блок, обрабатывающий эти данные — вторая. Если мы тестируем обработку сигнала и какие-то алгоритмы, работу которых этот сигнал должен вызвать, то вместо первого блока мы подсовываем фейковый блок с таким же интерфейсом, который и выдает нужные нам данные.

                                                                                        • m0Ray
                                                                                          /#18875921

                                                                                          Повторяю главные аргумент против этого. Создание тестового окружения для программы или железки во многократно сложнее и дороже создания самой программы или железки.
                                                                                          Если бы у меня были миллионы долларов, я бы нанял контору, которая мне всё это разработала бы. Мне по фигу было бы, используют ли он TDD, agile и паттерны. Мне важен результат.
                                                                                          Но мне приходится всё делать самому и ограниченными средствами. И я, чёрт побери, умею делать конфетку почти из ничего. Если бы я начал с «100% покрытия автотестами», система не была бы сейчас и наполовину готова. А у нас уже в феврале были предсерийные образцы. Учитывая, что ранние наработки были у нас похищены (физически), думаю, не надо объяснять, почему я не пишу тесты и не делаю тестовые стенды.
                                                                                          Потому что я могу работать без них. Мне не нужны костыли, особенно сейчас, когда надо бежать, а не ковылять.

                                                                                          • F0iL
                                                                                            /#18875969

                                                                                            Не знаю, что у вас за специфические задачи, но когда я решал похожую проблему (контроллер, обрабатывающий информацию с десятка вторичных преобразователей и других контроллеров по разным протоколам плюс ADC и DI модули ввода), то написание кода, позволяющего захватить обмен за какое-то время и использовать его потом, плюс модификация полученных дампов для некоторых случаев, которые на стенде «наиграть» не так-то просто (учитывая, что одна из железок стоила несколько лямов и физически стояла за пару сотен километров), заняло гораздо меньше времени, чем разработка того функционала, что надо было протестировать — по сути дела, оно собралось из того, что уже было сделано плюс некая обвязка. И больше не было нужды щелкать релешками на стенде, крутить подстроечники и гонять наладчика с ноутбуком в поле за тридевять земель.

                                                                                            • m0Ray
                                                                                              /#18876013

                                                                                              Аналоговые сигналы чем захватывать и воспроизводить? Звуковуху не предлагать, не катит.
                                                                                              В контроллере килобайт памяти. Отладки нет. Да, я знаю, что бывает JTAG, но нет.

                                                                                              Для отладки кода на openCV я накидал утилитку, работающую с вебкой. Потом перенёс код и подобранные коэффициенты на рабочую версию. Всё работает.

                                                                                              И так далее.

                                                                                              • F0iL
                                                                                                /#18876653

                                                                                                Зачем звуковуху-то? У вас уже есть сенсор, который этот самый сигнал преобразует в код АЦП. Захватывать ровно тем же, чем и при обычной работе. Как-то же этот сигнал после цепочки преобразований в контроллер попадает в процессе эксплуатации — следовательно, не будет трудностей.
                                                                                                Воспроизводится все «виртуально» записью значения из массива по смещению на вход функции или в заранее определенное место в памяти.

                                                                                                • m0Ray
                                                                                                  /#18877595

                                                                                                  Сенсор даёт сигнал с размахом 3В. Сигнал поступает сразу на ногу контроллера, на которую смультиплексирован АЦП.
                                                                                                  То есть вы предлагаете запилить отдельный контроллер, который запишет сигнал в память (ОЗУ контроллера 64 байта), каким-то хреном передаст его в более умное место (UART на борту нет, ПЗУ 1 килобайт) для хранения… И ещё один контроллер, который в нужное время его воспроизведёт криво-косо при помощи ШИМ… И всё это только на один сигнал?
                                                                                                  Граждане, таким извратом мне сейчас заниматься некогда и даже контроллеров лишних у меня сейчас нет, покупать надо.
                                                                                                  Будет до фига времени и денег — запилю, устрою линию контроля качества и всё такое. Но не сейчас. Сейчас надо быстро бежать. И тут поможет только умение писать код с минимумом глюков и нормально собирать устройства.

                                                                                                  • F0iL
                                                                                                    /#18879551

                                                                                                    Сигнал поступает сразу на ногу контроллера, на которую смультиплексирован АЦП.

                                                                                                    Зачем? Объясните, почему вы все время для чисто программных вещей хотите добавить еще горсть контроллеров и внешней обвязки? Вы тестируете программный код, который работает с цифровым сигналом. Следовательно, все это отлично делается в софте, а не в железе.
                                                                                                    Берем и вотт с этого самого АЦП с этой самой ноги и пишем паттерны для всего того что нужно.
                                                                                                    Да, если у вас 64 байта ОЗУ — это печаль.
                                                                                                    На атмегах, STM8, STM32 и разных там ПЛК проблемы такой нет (это из того, что я работал). Опять же, можно не писать в свою память, а сразу стримить по USART на подключенный ПК — там чтобы это записать хватит программки из десяти строчек. Куски прошивки, которые отвечают за логику, а не за работу с железом, если код действительно разбит на модули и написан не через задницу, без усилий обособленно билдятся для нативного запуска на ПК, где все тесты гоняются даже не задействуя контроллер. Сделать все описанное можно меньше чем за день (если, как я уже сказал, изначально все сделано по уму), а времени в будущем сэкономит вагон.

                                                                                          • Whuthering
                                                                                            /#18876729

                                                                                            Прототипы — это другая история. Там быстрый старт иногда вообще важнее всего.
                                                                                            А часто бывают противоположные ситуации — когда проект долгосрочный, и его развитие и поддержка тянется и будет тянуться не один десяток лет. Там проблема не «сделать конфетку из ничего», проблема не «сделать тратя минимум ресурсов», и даже не «сделать быстрее». Там проблема «сделать так, чтобы оно стабильно работало, поддерживалось и расширялось еще и еще, и не приносило при этом жопную боль тем, кому с этим придется работать». Вот там ваш write-only код уже ну никак не приемлем.

                                                                                            Ну и с костылями аналогия не очень уместна. Вам предлагают автомобиль, а вы отвечаете «да не, мне и пешком норм». Да, когда надо дойти до соседнего ларька, пешком может оказаться даже быстрее, и учиться водить не надо, а вот если нужно в соседний город, то все уже становится не так просто.

                                                                                            • m0Ray
                                                                                              /#18877599

                                                                                              У меня код не write-only, он хорошо читаем и поддерживаем.

                                                                                              Нет, вы предлагаете не автомобиль. Вы предлагаете мотоколяску для инвалидов. Извините, но у меня пока ноги ещё работают. До соседнего города я доеду на велосипеде, возможно, с электроприводом.
                                                                                              А автомобиль я себе позволить не могу. Просто ну вот никак. Если для поездки в соседний город я буду сидеть и копить на автомобиль — я туда не доеду никогда.

                                                    • aikixd
                                                      /#18874825

                                                      То есть вы все-же делаете юнит тестирование, просто руками.

                                                      • m0Ray
                                                        /#18874911

                                                        Это не юнит тестирование. Это метод научного тыка.

    • Nexus7
      /#18872933

      Основное назначение тестов — возможность рефакторинга и расширения кода. Плюс они документируют API и дают примеры его использования. Как говорил классик: «код, не покрытый тестами не существует». Тесты — это инвестиции в будущее проекта и возможность спать спокойно по ночам.

      • m0Ray
        /#18872949 / -3

        Мне не нужны тесты, чтобы рефакторить код. Примеры использования API я могу дать в readme.txt. И сплю я спокойно — мой код работает.

        Дело в том, что код сначала рождается и тестируется у меня в сознании, лишь потом переносится на язык программирования и в файлы.
        И я не понимаю, как программист может работать иным образом.

        • F0iL
          /#18872971 / +1

          Вы можете у себя в голове удержать хотя бы миллион строк кода со всеми их нюансами и точностью до мелочей, и каждый раз при внесении изменений тестировать их все в своем сознании?

          • m0Ray
            /#18873005 / -1

            Зачем держать в голове миллион строк кода, если держать надо модель, как оно работает? Мелочи легко проверить прямым наблюдением кода, да и компилятор/парсер мелочи вроде синтаксиса проверит.

            • F0iL
              /#18873041 / +1

              Проект Chromium. В связи со спецификой и сложности задач и требований к производительности, есть свой сборщик мусора и свои библиотеки коллекций, а также многое другое. 8 миллионов строк кода. Около 50 компаний участвует в разработке плюс около тысячи индивидуальных контрибьюторов.
              Вы предлагает разработчикам при внесении изменений, например, в подсистему управления памяти, каждый раз «в голове» или «прямыми наблюдениями» кода вручную проверять, как изменения отразились на _всех_ десятках тысяч классов, в том числе с крайне разнообразными и далеко не самыми очевидными сценариями использования этого функционала?

              • m0Ray
                /#18873077 / -2

                Если у людей в голове нет модели того, как работает их код — это очень плохо. Они не понимают, что делают.
                И это всё, что я могу сказать на эту тему.

                Изменения в системе управления памятью не должны затрагивать API. Если затрагивают — это надо документировать, а другие разработчики, соответственно, вносить изменения в свой участок кода. Я не понимаю, в чём тут проблема.

                • Whuthering
                  /#18873091 / +4

                  А мне вот теперь всё понятно. Вы слабо представляете, о чем вообще говорите.

                  • m0Ray
                    /#18873107

                    Тем не менее мой код работает. Не скажу, что он полностью избавлен от багов, но покажите мне баг в моём коде «в диком виде» — и я его исправлю. Потому что я знаю, где его искать.

                    • Whuthering
                      /#18873119 / +3

                      но покажите мне баг в моём коде «в диком виде» — и я его исправлю

                      Так любой дурак сможет.
                      Когда разработчика заботит качество его софта и экспириенс пользователя, баги должны исправляться без показывания на них со стороны людьми.

                      • m0Ray
                        /#18873129 / -2

                        Для этого код можно предварительно дать поюзать доверенным людям — тестировщикам, альфа/бета-тестерам и т.п.

                        • Whuthering
                          /#18873359

                          А зачем я должен при каждом изменении тратить ресурсы тестировщиков на выполнение одних и тех же проверок, если я могу вместо этого использовать автоматический скрипт?

                          • m0Ray
                            /#18873459

                            А что вы можете автоматизировать скриптом? CRUD-операции?

                            • Whuthering
                              /#18873515

                              Да очень много чего. От низкоуровневых (атомарные методы и обособленные классы) до высокоуровневых (интеграционных, в каком-то случае это может быть CRUD, как вы хотите) проверок, вплоть до пользовательского интерфейса.

                              • m0Ray
                                /#18873621

                                Знаете, я делал «роботов», имитирующих пользователя (SlimerJS там и прочее). Но это были отдельные продукты.
                                Писать автоматику, по сложности превосходящую тестируемый код — контрпродуктивно. Простенькие операции я и сам мышкой натыкаю, не заржавею.

                                • Whuthering
                                  /#18873693

                                  В большинстве случаев в этой автоматике как раз-таки никакой магии и сложности нет.
                                  Тут вопрос в другом. Для проектов из разряда «кустарщина», либо распильно-откатных вещей, либо команд, состоящих из студентов и индусов смысла в этом может и не быть.
                                  Если же цена рабочего времени разработчиков/тестировщиков, которое тратится при каждом обновлении или релизе выше, чем цена однократной автоматизации — это уже выгодно. Если цена ошибки на продакшене, которую пропустят программисты/тестировщики, схалявив на предыдущем пункте, выше, чем цена однократной автоматизации — это снова выгодно. Про сумму этих цен мы даже говорить не будем.

                                  • m0Ray
                                    /#18873769

                                    То есть TDD — это средство получить мало-мальски работающий продукт при некомпетентных разработчиках. Океюшки, так и запишем.

                                    • Whuthering
                                      /#18873795

                                      Ваша цитата:

                                      Да никто и не говорит, что ошибок не бывает.

                                      Иными словами, вы расписываетесь в том, что вы некомпетентный разработчик? Забавно.

                                      • m0Ray
                                        /#18873813

                                        Неверно. Я знаю о том, что могу допускать ошибки и действую так, чтобы минимизировать их вероятность.
                                        Плюс оптимизирую код.
                                        Некомпетентный этого не делает. «Тест прокатил — ну и ладно».

                                        • Whuthering
                                          /#18873875

                                          ействую так, чтобы минимизировать их вероятность.

                                          Одно другому не мешает.
                                          Плюс оптимизирую код.

                                          аналогично
                                          Некомпетентный этого не делает.

                                          Эти подоходы не исключают, а дополняют друг друга.
                                          «Тест прокатил — ну и ладно».

                                          Тут примерно как с демократией — плохая система, но все остальные еще хуже. Так и здесь. Если вариант с ручным перетестированием всего что только можно занимает время в десятки и сотни раз больше, чем сама разработка, и проводить его надо регулярно — то лучше «Тест прокатил — ну и ладно» еще ничего не придумали.

                                          • m0Ray
                                            /#18873941

                                            «Давайте делать плохо, потому что лучше мы не можем и не сможем никогда, всё тлен».
                                            Неа. Я не согласен.

                                            • Whuthering
                                              /#18874207

                                              Тогда предложите рабочее и экономически эффективное решение описанной ситации:

                                              Если вариант с ручным перетестированием всего что только можно занимает время в десятки и сотни раз больше, чем сама разработка, и проводить его надо регулярно

                                              • m0Ray
                                                /#18874227

                                                «Решить другую проблему так, чтобы предыдущие потеряли смысл».
                                                Если система слишком сложна — она неправильная.

                                                • Whuthering
                                                  /#18874249

                                                  Это экономически неэффективный вариант. Переписывание системы требует в несколько раз больших ресурсов (учитывая уже вложенные в нее человеко-года), чем автоматизация тестирования.

                                                  • m0Ray
                                                    /#18874273

                                                    «Давайте оставим плохую систему, потому что хорошую мы себе позволить не можем».
                                                    Да ну вас. Всё на бабло перемеряете.
                                                    Я занимаюсь искусством.

                • IRainman
                  /#18873139 / +2

                  Модель это общие принципы того как система реализована, мозг действительно хорошо приспособлен для хранения и анализа моделей поскольку сохраняет их «нативно», в виде голограмм.

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

                  Вообще суть тестов в автоматизации. Статический анализ нужен для тех же целей — это автоматизация процесса разработки и поиска ошибок или криво написанного.

                  • m0Ray
                    /#18873171 / -2

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

                    «Костыли для API» — ужас, кошмар, недопустимо!

                    Автоматизация — это хорошо. Но простых ошибок избежать легко, а сложные автоматика не найдёт. Или эта автоматика должна быть сложнее продукта. Смысл теряется тогда. Хороший программист быстро найдёт причину и без такой автоматики.

                    • Whuthering
                      /#18873219

                      Но простых ошибок избежать легко, а сложные автоматика не найдёт.

                      Что вы понимаете под простыми и сложными ошибками?

                      • m0Ray
                        /#18873371

                        + и -, = и == — это простые.
                        Сложные — это с многопоточностью, deadlock-и, race condition, проблемы с очередями и т.д.

                        • Neikist
                          /#18873405

                          А к чему вы относите ошибки в бизнес логике?

                          • m0Ray
                            /#18873469

                            Логические ошибки тоже бывают, как правило, они весьма просты.

                            • Neikist
                              /#18873509 / +1

                              Как правило такие ошибки максимально сложны, поскольку их часто не то что программисты не видят с ходу, но и бизнес аналитики, знающие предметную область очень хорошо. Например какая нибудь «проблема копеек» при расчете себестоимости по партиям товаров по средней, в результате которой оказывается что в определенных, нечастых, случаях на остатках может быть 0 товаров, а себестоимость списана не полностью. Хотя это на самом деле как раз простая и многим известная проблема, а бывают такие дебри…

                              • m0Ray
                                /#18873561

                                Бригадные наряды, к примеру, я кодил. Это когда бригада собирается произвольно, выполняет наряд, а потом надо никого не обидеть копейкой. При этом приходилось использовать ужас под названием BTrieve и проприетарный язык программирования. Не напугали.
                                Проблему можно разложить на простые блоки, применить проверенные подходы и так далее. Тут весь вопрос в том, чтобы уложить задачу в уме, покрутить, помоделировать, «переспать» с ней — и решение вскоре находится. А потом его можно и изложить на нужном ЯП.

                            • Whuthering
                              /#18873517

                              Феноменальная наивность.

                              • m0Ray
                                /#18873567

                                Нет, многолетний опыт.

                                • Whuthering
                                  /#18873581 / +1

                                  А, то есть вы почти не сталкивались со сложными логическими ошибками, но при этом постоянно упоминаете свой многолетний опыт. Ясно, понятно.

                                  • m0Ray
                                    /#18873597

                                    Сталкивался. Как правило, ошибки были тупые. Если разделить многоэтажный if на несколько более простых, ошибка становилась очевидна.
                                    Это вопрос ещё и культуры кода.

                        • 0xd34df00d
                          /#18876295

                          Ну, технически, их искать можно.

                          Раз (можно ещё там в ридмишке внизу пройтись по библиографии), два.

                    • IRainman
                      /#18873353 / +1

                      «Костыли для API» — ужас, кошмар, недопустимо!

                      В реальном мире это есть и чем больше проект тем вот такого больше и это, обычно, таки можно исправить, но за время приближающееся к бесконечности. Ещё существует Legacy и обратная совместимость и там без костылей иногда вообще никак. К сожалению, под определение «хороший программист» в этом контексте попадает только ИИ, мозг по принципу своего устройства не может не совершать ошибок вообще никогда, а ещё не может иметь безгранично расширяемые вычислительные ресурсы и память, такое может только ИИ.

                      • m0Ray
                        /#18873403

                        В реальном мире есть разработчики API. Если они тупы и неповоротливы и не могут за реальное время исправить баг или хотя бы предложить работающий API — меняем разработчиков. Nothing personal, как говорится. Код должен быть «чотким», как «пацан», извините за подзаборную аналогию. Нет «чоткости» — «дитынах».

                        ИИ — тупик. Он не может и никогда не сможет создавать новое. Иллюзия «китайской комнаты», ЕВПОЧЯ.
                        Вот как анализатор типа PVS Studio — ещё можно.

                • F0iL
                  /#18873159 / +1

                  Внешний API здесь непричем. Я вношу изменения в реализацию того, что стоит за этим API.
                  Я могу иметь в голове четкую модель того, как работает мой код, но при этом не иметь подобной модели в отношении миллионов других строк кода, которые прямо или косвенно используют ту часть, в которую я вношу изменения.
                  Одного только первого пункта явно недостаточно для тщательной проверки получившегося результата, как минимум потому, что не получится сгенерировать в голове абсолютно все граничные случаи для всех кейсов использования в оставшихся миллионов строк кода. В случае с тестами же, их сгенерируют как раз авторы этих самых сторонних модулей, потому что они, в свою очередь, имеют в голове четкую модель своего кода, и знают, как он должен и не должен работать. Поэтому любая косвенная регрессия будет выявлена вообще без каких-либо временных и трудовых затрат.

                  • m0Ray
                    /#18873181

                    Если API работает так, как документирован — какое мне дело до внутренней реализации?
                    Если нет — я вам напишу issue.
                    В чём проблема, не понимаю.

                    • F0iL
                      /#18873205

                      В том-то и разница. Я что-то сломал, API перестало работать в каких-то случаях как надо, вы должны это заметить, собрать данные и завести на меня Issue.
                      Это 1) ваши трудозатраты по моей вине 2) время между появлением бага и его обнаружением.
                      И это в том случае, если вы вообще заметите, что после какого-то обновления API в каких-то очень специфичных перестало работать правильно. А можете вообще и не заметить, если случай очень редкий и очень специфичный, и потом эта ошибка сыграет гораздо хуже и больнее.
                      Тесты все эти проблемы полностью решают.

                      • m0Ray
                        /#18873417

                        Работы мы не боимся. Видим, что в данном модуле код не менялся, а баг там — садимся, разбираемся, делаем выводы, пишем issue, а в продакшене мы новую версию ещё не накатили. Нормальная рабочая ситуация.

                        А если я не заметил поломки — тут два варианта. Либо я не использую этот API, либо и мой код сломан (не проверяет данные и т.п.)

                        • F0iL
                          /#18873477

                          А если я не заметил поломки — тут два варианта.

                          То есть вы при каждом (не исключено что очень частом) обновлении какого-то стороннего (по отношению к лично вашему коду) компонента сами вручную полностью проверяете, не сломались ли чего из-за этого у вас?

                          Работы мы не боимся.

                          Видимо, у вас мало работы и много свободного времени.

                          • m0Ray
                            /#18873513

                            Если у меня что-то сломалось — это заметно сразу. Если не сразу — этот функционал используется редко и не критичен.

                            Свободного времени у меня мало, работаю чуть ли не круглосуточно.
                            Правда, сейчас большую часть работы составляет разработка и пайка электроники, но прошивки микроконтроллеров и одноплатников, GUI и облачные сервисы — это я всё делаю сам. На разных языках причём, от ассемблера до PHP и python. И прикиньте, всё работает.

                            • ankh1989
                              /#18874457

                              «этот функционал используется редко и не критичен» — угу, не критичен. А у компании соглашение о service availability 99.995% с штрафом $1M в день за нарушение этого пункта. И вот вы пофиксили какой то мелкий баг, зафигачили в продакшн, конечно потестировав важные сценарии, а тут вдруг выясняется через 6 часов, что uptime упал до 99.2% и совершенно не понятно из за чего — тестов то нет, а разных сценариев миллиона полтора и все их не проверить. И что вы будете делать в таком случае?

                              • Avvero
                                /#18874473

                                Мне кажется, что у m0Ray другие бизнес задачи, когда код можно так протестировать

                                Как правило, данные готовятся один раз. Накидал пару-тройку запросов, сунул их в браузер или командную строку — и погнал. Оттестил — закрыл окно. На крайняк есть история, что в командной строке, что в браузере.

                              • m0Ray
                                /#18874533

                                Вы знаете, я программист, а не «тыжпрограммист», у которого в обязанностях прописана личная ответственность за uptime сервака. Я решаю задачи. Uptime — это к эксплуатационщикам.

                                • ankh1989
                                  /#18874551

                                  А кто написал говнокод который уронил uptime?

                                  • m0Ray
                                    /#18874629

                                    А вы говнокод перед выкатываением в продакшн не обкатываете на локалхосте/деве/бете?

                                    • ankh1989
                                      /#18874697

                                      Цитирую вас же: «Если у меня что-то сломалось — это заметно сразу. Если не сразу — этот функционал используется редко и не критичен.» — протестировали в бете, ничего подозрительного не нашли — вроде работает как раньше (никаких тестов нет, так? поэтому только вручную). Раз работает как раньше, то фигачим в продакшн. А там uptime упал на 0.01%. И что теперь?

                                      • m0Ray
                                        /#18874741

                                        Падение uptime на сотую долю процента видно только в вашем мониторинге, его можно не торопясь найти и отдебажить.

                                        • ankh1989
                                          /#18874795

                                          Эмм… как например? У вас 100 тысяч серверов и в среднем на 10 из них обычно возникают подозрительные лаги. Вы даже видите это в логах но не можете предсказать какой из них начнёт глючить и потому не можете заранее прицепить отладчик, а если глюк произошёл (скажем дропнулось соединение), то цеплять отладчик смысла уже нет. Обновление нужной dll-ки на этих серверах занимает месяц, поэтому добавлять логи в реальном режиме не получится — да и вообще это продакшн. Допустим, что если бы были тесты, мы бы узнали, что всё дело в хитром integer overflow в одной редкой функции которая конвертирует время из UTC в какой то другой формат — но мы это не знаем. Что делаем?

                                          • m0Ray
                                            /#18876061

                                            Цепляем отладчик и пишем его логи, пока не сглючит.
                                            Только вот я отладчиком тоже не пользуюсь. У меня просто практически везде заложен вывод дебага в консоль. Просто перезапускаем программу с нужным ключиком, потом анализируем вывод. Если надо что-то детализировать — добавляем пару строчек в нужных местах.
                                            Представьте, это работает.

                                            • ankh1989
                                              /#18876601

                                              Так работает оно потому что это уровень песочницы. Как вы будете перезапускать 100к серверов с «ключиком»? Они все будут писать логи? А если логов, как это обычно бывает, недостаточно, чтобы понять в чём проблема — будете добавлять логи с итерацией в 1 месяц (обновление серверов в проде)?

                                              • m0Ray
                                                /#18877603

                                                Повторяю: у вас что, локалхоста/дева/альфы/беты нет? На них, вызвав искусственную нагрузку, можно отловить всё что хочешь, с итерацией в 10 секунд.

          • Neikist
            /#18873035 / +2

            Бросьте, с такими людьми спорить бесполезно, проверено. Они свято уверены в собственной непогрешимости, а также непогрешимости всех остальных кто пишет код того же проекта, и тех чьими библиотеками и фреймворками пользуются. А также видимо имеют много времени.

            • F0iL
              /#18873043 / +1

              Больше похоже просто на троллинг, увы.

              • m0Ray
                /#18873059

                Увы, но нет.
                В моём коде всегда куча закомментированных средств диагностики, но ни одного автотеста. Я реально не вижу в них смысла.

                • Whuthering
                  /#18873085

                  закомментированных средств диагностики

                  а как же compile-time defines? dependency injection? mixins?
                  Хотя да, извините, о чем это я.

                  • m0Ray
                    /#18873093 / -2

                    Да, вы о средствах запутать код и наплодить ошибок.

            • m0Ray
              /#18873051

              О, нет, ошибается всякий. Вот и вы ошиблись в оценке моего modus operandi.
              Только код можно писать так, что он либо работает, либо нет. И место, где «не работает», легко находится. Ошибся сам — исправил. Ошибся другой — подозвал, ткнул пальцем (написал issue).

              • Whuthering
                /#18873065

                И место, где «не работает», легко находится.

                Феноменальная наивность.

                • m0Ray
                  /#18873083 / -1

                  Нет, многолетний опыт.

              • Neikist
                /#18873075 / +3

                Только код можно писать так, что он либо работает, либо нет. И место, где «не работает», легко находится.

                В общем как я и сказал — спорить бесполезно.

        • Nexus7
          /#18875587 / +1

          Когда-то я легко писал на ассемблере с листа, держа в уме все регистры процессора и распределение памяти, помня команды управления контроллерами. Но потом деревья выросли, были прочитаны книжки Кента Бека, появились проекты и команды больше двух человек.
          Если вы один, тесты вам могут быть и не нужны, но когда проект состоит из десятков модулей, сервисов и серверов с набором разнообразных протоколов, когда приходится взаимодействовать с внешними сервисами и иметь пользовательский интерфейс, когда это всё делается десятками людей — то без многослойного покрытия тестами не обойтись.
          Мне наоборот странно видеть, что программист работает без тестов, для их написания создано множество разных фреймворков на разных уровнях тестирования, сильно облегчающих жизнь. «мне не нужны тесты» — лишь отмазка, показывающая отношение к своей работе и коллегам.

          PS. Почитал ответы ниже, дальше можно не продолжать, удачи вам в поддержке ментальных моделей.
          PPS. Строительная каска в офисе для того, кто сломал тесты — очень хороший мотивирующий фактор для запуска модульных тестов перед коммитом ;)

          • m0Ray
            /#18875759

            Но у меня так и есть — десятки модулей, сервисов, разные протоколы, и прочее… Я очень люблю свою работу, но считаю, что ей не сожет заниматься только лишь каждый. (С) Костыли в виде тестов и всяких там методик разработки — это для тех, кто работает через силу, не понимает половины того, что делает и т.п.
            Когда живёшь, дышишь этим, плаваешь как рыба в воде и наслаждаешься — ты с большим удивлением смотришь на людей, которые могут передвигаться только на мотоколяске. Да, коляска быстрая, удобная, в ней куча интересных рычажков… Но зачем?
            Да, иногда надо. Но не всем и не всегда.

            • Avvero
              /#18875795 / +2

              Костыли в виде тестов

              Вы же сами тут неоднократно писали, что тестируете, но руками

              • m0Ray
                /#18875821

                Окей, в виде «100% покрытия автотестами».
                Просто писать нормальный код с минимальным количеством ошибок, и тестировать только самые потенциально проблемные места — не судьбец. Надо нахерачить в два раза больше кода, чем есть в проекте, только для того, чтоб защититься от криворуких программистов.

                • Avvero
                  /#18875901

                  Не понятно только почему это нужно делать руками, когда написать автотест — дело несложное и проверка им быстрее ручной

                  Заголовок спойлера
                  Ну вот пример теста
                      @Unroll
                      def "For command #command task type will be #type"() {
                          expect:
                          TaskFactory.createInstance(null, command).type.toString() == type
                          where:
                          command                                | type
                          "info"                                 | "INFO"
                          "Info"                                 | "INFO"
                          "list"                                 | "LIST"
                          "List"                                 | "LIST"
                          "last"                                 | "LAST"
                          "again"                                | "AGAIN"
                          "clear"                                | "CLEAR"
                          "cancel"                               | "CUSTOM"
                          "Cancel"                               | "CUSTOM"
                          "Cancel <context offer=\"12312312\"/>" | "CANCEL"
                          "deploy"                               | "CUSTOM"
                          "foo"                                  | "CUSTOM"
                      }
                  

                  Простой и очень наглядный, написать его просто, добавлять новые кейсы еще проще.
                  А вот зарефакторишь метод или перепишешь и все это руками перепроверять? Ну такое

                  • m0Ray
                    /#18875967

                    Это вообще на каком языке?
                    И как этим пользоваться?
                    Мне теперь новый язык/фреймворк для этого учить? Некогда. Руками быстрее.

                    • Avvero
                      /#18876005

                      Ну мы же тут в целом рассуждаем или только применительно к стеку ваших технологий? Этот тест написан на spock framework. Привел я его как пример тестов, которые просто писать и просто понимать.

                      • m0Ray
                        /#18876025

                        Вот честно, я мало что понял. Синтаксис похож на питоновский, но это явно не программа. Что куда девается — хз. Надо читать про фреймворк и забивать голову ещё этим.
                        Зачем чинить то, что не сломано — ну не понимаю.

                        • Avvero
                          /#18876103 / +1

                          При чем тут сломано? Вы же тестируете? Да, как выяснилось. Но руками. Я тестирую тестами — это быстрее

                          • m0Ray
                            /#18876129

                            Тесты надо написать. Для этого изучить целый фреймворк. Тесты, я так понимаю, длятся долго, уж никак не меньше компиляции.
                            Ваша проблема в том, что вы тестируете всё, даже то, где вероятность ошибки при правильном подходе к написанию кода околонулевая.
                            Я же тестирую руками, но выборочно. И не пишу тесты, и не держу в голове лишних языков и фреймворков. И у меня таки быстрее.
                            Глядя на всю эту современную модную возню вокруг кода, я удивляюсь: а сам код уже когда можно будет писать?
                            Не могу я так работать.

                            • Avvero
                              /#18876169

                              А перед тестирование руками вы приложение поднимаете же? Ну а я тест запускаю. Это в любом случае дольше компиляции.
                              Я привел выше пример теста который проверяет 12 случаев и отрабатывает за меньше секунды. Вы за такое 12 случаев проверите руками? Вряд ли.

                              при правильном подходе к написанию кода околонулевая

                              А вы проверяете зачем тогда? У вас подход не достаточно правильный?

                              • m0Ray
                                /#18876201

                                А мне не надо проверять 12 случаев. Мне надо проверить один — тот, что я изменил. Программы я стараюсь писать так, чтобы не было такого: «здесь изменил, там упало».
                                Но главное в том, что при написании программы я «прогоняю» её в уме. Читаю и выполняю, читаю и выполняю, мысленно подсовывая разные данные.

                                Проверяю — потому что от ошибок я не застрахован. Чаще, конечно, синтаксические бывают, но они ловятся ещё до компиляции.
                                Многопоточность иногда головную боль доставляет. А в python так вообще с ней беда. Совсем без проверки никуда. И перед выкаткой «в бой» проверяем уже всё. Но это много времени не занимает.

                                • Avvero
                                  /#18876287 / +1

                                  Вы изменили код метода или у вас отдельные методы под каждый случай?

                                  Программы я стараюсь писать так, чтобы не было такого: «здесь изменил, там упало».Проверяю — потому что от ошибок я не застрахован.

                                  Ну проверяете-то каждый раз? Значит стараний описанных выше недостаточно или они на что направлены?

                                  • m0Ray
                                    /#18877607

                                    Без проверки — никак. Другое дело, что проверять каждый раз всё не имеет смысла. Никак не могу донести до вас эту простую мысль. Ковровые бомбардировки — это хорошо, но дорого. Можно обойтись меньшими затратами, если есть высокоточные крылатые ракеты. Да, они сложнее, чем фугас с простым взрывателем, но эффективнее. Не умеете работать с ракетами — ну что ж вам остаётся, бомбите всё.

                                    • Avvero
                                      /#18877617

                                      Как же нет смысла? Как можно быть уверенным, что правка метода что-то не сломает левой?

                                      но дорого

                                      совсем нет, очень дешево, «никак не могу донести до вас эту простую мысль»

                            • 0xd34df00d
                              /#18876339 / +1

                              Не всегда долго и уж точно не всегда дольше. В одном из моих проектов тесты длятся меньше секунды из repl'а, тогда как релизная компиляция проекта — пару минут. А их там под тысячу было.

                  • 0xd34df00d
                    /#18876331

                    Не, я всё понимаю, но тест вместо статического тайпчекера — это даже как-то смешно.

                    И вызывает вопросы, ну да ладно.

    • Avvero
      /#18873633 / +1

      Мне кажется, что вам нужно перечитать пункт «Умерьте своё эго». Возможно тесты помогут вам писать более чистый код, так почему бы не попробовать?

      • m0Ray
        /#18873675

        Я пробовал, не помогло. В три раза увеличило объём кода и затрачиваемое время, результат не изменился.

    • ankh1989
      /#18874245 / +1

      Попробуйте решить 10 задач на leetcode из группы hard. Там к каждой задаче есть сотня тестов и вы можете их запустить и проверить ошиблись вы где то или нет. Как решать можете посмотреть в секции discuss. Если вы сможете сделать хоть одно решение сразу без ошибок — я буду впечатлён, если три подряд — придётся признать, что вы гений. Для сравнения, мне требуется обычно десяток попыток пока все тесты не пройдут — мне трудно удержать в голове всю картину и не наделать ошибок. При этом за мой говнокод платят где то $30K в месяц.

      • m0Ray
        /#18874287

        Зачем решать задачи, которые уже решены, да ещё и не по одному разу? Это не интересно.
        Платят? Гордитесь до пенсии. Если доживёте.

        • ankh1989
          /#18874321

          Чтобы проверить свою способность решать задачи и сравнить себя с другими. P.S. Не понял про пенсию.

          • m0Ray
            /#18874341

            Моя способность решать задачи и так проверяется на работе. Писькомерство мне чуждо, не хочу тратить на это своё время, работать надо.
            Про пенсию — вы, наверное, не из Мордора?

            • ankh1989
              /#18874381

              А, вы про это. Верно, здесь пенсий нет.

            • ankh1989
              /#18874671

              Идея в том, чтобы доказать себе, что писать код без ошибок вы не можете. Вот например простая задачка на регулярки: leetcode.com/problems/regular-expression-matching/description Там нужно применить регулярку вида «ab.cd*» — то есть из спец символов только точка и *. Вполне практичная вещь: можно представить себе сервис который хранит логи (терабайты логов) и юзеры могут зайти на его веб интерфейс, набрать вот такую простую регулярку и получить логи которые подходят. Конечно же вы не хотите, чтобы ваш сервис наглухо завис из за неудачной регулярки — поэтому код должен быть быстрым. На вид задачка решается за 10 минут, а вам наверно и вовсе пары минут хватит. Вряд ли у вас нету пары минут, правда?

              • m0Ray
                /#18874793

                Сколько мне за это заплатят?

                • ankh1989
                  /#18874805

                  Могу вам перечислить 0.1 BTC (это чуть больше $600). Довольно неплохо за 10 минут работы?

                  • m0Ray
                    /#18874831

                    Это не 10 минут. И даже не день. Это вам кажется, может быть, что задача проста. Но с кондачка она не решается, это я вижу сразу.
                    Некоторым тоже казалось, что сделать ТТС — как два байта переслать, лазер вон из указки выковыряем, а написать на openCV распознавалку так вообще любой студент сможет. Как бы не так.
                    Извините, но неинтересно. И дело даже не в том, что мало. Сложно — не значит интересно.

                    • ankh1989
                      /#18874855

                      600 баксов даже за два дня вроде весьма некисло? И ниже вы писали, что за вечер переделывали сложные системы которые криворукие кодеры писали годами. А тут жалкая регулярка которая сгодится разве что для вопроса на собеседовании с 20 минутами на ответ.

                      • m0Ray
                        /#18874961

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

                        Я переделывал не всю систему, а ту часть, которую писали на языке TCL и которая исполнялась на Cisco AS5300. Эти скрипты некоторые уникумы писали год. Я переделал за пару дней, когда они сказали, что «вот этого» они ну совсем не могут сделать. И не только сделал, но и выгреб кучу говнокода. При этом практически не отрываясь от основной работы — тогда бухи требовали каких-то мерзких и скучных отчётов для импорта в 1С.
                        Николi знову!

                        • ankh1989
                          /#18874987

                          Не надо ляля. У нас есть простая регулярка и строка — надо выдать 1 или 0. Это стандартный вопрос на интервью, 20 минут на ответ. Вам я даже готов компенсировать ваши усилия в размере 0.1 BTC, что весьма дофига. Можете прям тут функцию написать. Сигнатура пусть будет bool test(char* pattern, char* text); Ограничения: пусть обе строки не больше 100 ASCII символов.

                          • m0Ray
                            /#18874995

                            Чем не устраивает preg_match()?

                            • ankh1989
                              /#18875007

                              Потому что мы пишем код на C — сервис такой. Плюс регулярка у нас урезанная и мы хотим этим воспользоваться, чтобы получить максимальную производительность. Всякие preg_match они для общего случая.

                              • m0Ray
                                /#18875045

                                В C это regex.h, regcomp()/regexec(). Есть ещё libPCRE. Возьмите исходники (благо они открыты) и уберите лишнее ради производительности. Не множьте сущности, от этого глюки плодятся.
                                Зачем решать задачи, которые уже решены и даже протестированы?

                                • ankh1989
                                  /#18875085

                                  Я сомневаюсь, что вы можете решить эту простую задачу без тестов. Вы очень упорно сопротивляетесь. Тут два варианта: либо у вас нет на это 30 минут (зато есть время чатиться на хабре), либо вам не нужны 600 баксов за эти 30 минут (и тогда вы наверно нам пишите из личного самолёта). Фигня в том, что практически никто не сможет решить эту задачу сходу без тестирования — обязательно будет несколько багов. По этой причине когда на собеседовании в крупную компанию задают такие вопросы, ожидают, что вы не только напишите код на доске, но и приведёте список тестов, протестируете (в уме) и исправите все баги. Именно для этого и нужны тесты в реальном мире. Утверждать, что «я могу кодить без тестов» всего лишь невежество, а не опыт. Следующий уровень невежества это «мне не нужна телеметрия — мой код и так хорошо и надёжен ведь у меня столько тестов.»

                                  • m0Ray
                                    /#18875117

                                    Я просто чувствую, что вы мне готовите какой-то подвох. Задача непростая, и если я потрачу на неё 30 минут времени, она явно будет решена неправильно. А больше времени тратить мне не хочется.
                                    Общение в комментах тут у меня идет параллельно с другими задачами, вы и так меня изрядно отвлекаете, пытаясь скормить задачку с подвохом.
                                    А личный самолёт… Если наш проект таки взлетит (а для этого явно придётся покинуть Мордор), то… у меня его не будет. Я, как бывший студент аэрокосмического ВУЗа, посещавший аэродром, на километр не подойду к коммерческой авиации. Жить ещё хочу. Получится плохо и недолго, но это лучше, чем шваркнуться об землю или сгореть в воздухе.

                                    • ankh1989
                                      /#18875169

                                      Подвоха нет. Это стандартная задача для собеседования на 20-30 минут для студентов которые ищут первую работу: проверяется умение написать простой алгоритм и проверить его тестами. Если работа не первая и кандидат претендует на сеньора, ему нужно не только написать этот код, но и рассказать как он будет работать на практике — вся эта многопоточность и т.д. Но если вы не можете написать даже таую функцию, то про многопоточность можно не рассказывать.

                                      • m0Ray
                                        /#18875193

                                        Могу. Но для вас и на таких условиях — не буду. Подозрительно очень.
                                        А на доширак мне сегодня хватит.

                                    • F0iL
                                      /#18875789

                                      Если наш проект таки взлетит (а для этого явно придётся покинуть Мордор), то… у меня его не будет. Я, как бывший студент аэрокосмического ВУЗа, посещавший аэродром, на километр не подойду к коммерческой авиации.

                                      А можете подробнее рассказать, почему?
                                      Я вот, как бывший студент авиационного вуза, студент военной кафедры с ВУС авиатехника (занятия на аэродроме тоже были, и не раз), и разработчик, несколько лет работавший в фирме, которая пишет софт для авиации (в т.ч. который идет на борт и участвует в воздушном движении) и производивший ПНР в аэропорту, наоборот, после всего изученного и увиденного стал бояться летать гораздо меньше, потому что знаю, как оно работает, и что сделано (как технически, так и административно) для того, чтобы оно работало как надо.

                                      • m0Ray
                                        /#18875847

                                        Ага. А самолёты продолжают падать. А те, что не падают — дребезжат во время полётов.
                                        Потому что главное — не состояние техники, не жизни и безопасность людей, а бабло. О людях заботятся только с одной точки зрения — как бы не попасть на штрафы и компенсации. А уж в этой стране вообще лучше не подходить — топливо разольют, потом прикурят.
                                        Нафиг-нафиг.

                        • 0xd34df00d
                          /#18876357

                          Это всё не нужно, если вы делаете NFA simulation. Если регулярки делать через DFA, да, там легко получить экспоненту, а вот через NFA сильно сложнее, оно полиномиально по длине входа и регулярки (лень выводить точную асимптотику сейчас, сорян).

                          Ну и это всё вдвойне не нужно, если вы сами пишете реализацию.

                • 0xd34df00d
                  /#18876351

                  Сколько вам заплатили за этот комментарий?

      • reiser
        /#18874429

        $30K в месяц?
        Можно озвучить историю успеха?
        Ну пожааааалуйста.

        • ankh1989
          /#18874503 / +1

          $360K/год — довольно стандартная зарплата для сеньора в Фейсбуках, Гуглах, Нетфликсах и некоторых других компаниях. История проста: регулярно менять место работы.

    • f0rk
      /#18876315

      Ага, видел я код и продукты этого гения. Понятия не имею, что он там у себя в сознании моделирует, но программировать не умеет совсем.

      • f0rk
        /#18876473

        А не, с другим наркоманом перепутал, tac, сорян :)

        • m0Ray
          /#18877609

          Что значит «с другим наркоманом»? Я не наркоман, максимум — слегка алкоголик. ;)

          • f0rk
            /#18877699

            Ну в данном случае «наркоман» — метафора, намекающая на альтернативное видение жизни, непризнанными гениями.

  9. KoToSveen
    /#18872517

    «Пишите больше кода» © Dushyant Sabharwal

  10. JobberNet
    /#18872637

    Хвалите

    За что? же, не боясь греха, Кукушка хвалит Петуха? За то, что хвалит он Кукушку. © Крылов

    • AlekseyCPP
      /#18872911

      +1
      Вот кого хвалишь, того и сделают начальником, а ты вечно будешь в дураках. У нас 2/3 программистов работает в офисе заказчика (на постоянке), и у такого заказчика уровень IT- развития равен 0. Они ровно ничего не понимают в этих вопросах и ориентируются на сплетни в курилках и подобные похвальбы от коллег по цеху. А в продуктовых фирмах начальники тоже часто плохо понимают глубины программирования и в таком случае пустить пыль в глаза также проще паренной репы (например, во франчайзи 1с руководителями нанимают не программистов, а людей с улицы).

  11. SenorLeoncio
    /#18872937 / +1

    «Кем бы вы ни были, помните мудрый совет: „Ни одного дня без написанной строчки“. Трудитесь! Что такое талант? Трижды и четырежды труд. Любите труд, и пусть вам всегда будет жаль с ним расставаться. Счастливой дороги!»


    Из автобиографической повести Константина Паустовского (где-то в районе 1908-го, что-ли, года) — напутствие диркетора лицея выпускникам.

  12. stalkers
    /#18873759 / +1

    7 советов, как сделать жизнь лучше

    Бесполезный совет.
    Совет, требующий больших затрат времени.
    Очевидный совет.
    Совет, требующий больших денежных затрат.
    Совет, требующий чрезвычайно особенных условий.
    Рекомендация выполнять советы регулярно.
    Совет, который написали для того, чтобы получилось всего 7 советов.

    /* фото девушки в наушниках на пробежке */

    Этот пост изменит вашу жизнь!

    //////////////

    и откуда вы, б…ь, такие лезете…

  13. mbait
    /#18874149

    А где эта чёткая, ровная, словно меч самурая остарая грань, которая делит программистов на постредственных и… непосредственных? По-мойму, автор неправильно применил свой же совет «умерить эго».

  14. urticazoku
    /#18874181

    Вот тут дружно критикуют m0Ray, а между прочим, TDD не работает. Или работает. Смотря кто как исследует).

    • Whuthering
      /#18874231

      Статья про то, что TDD не особо эффективнее в сравнении с TLD.
      Однако, буква T там присутствует в любом случае. Про то, что тесты писать вообще не нужно, там ни слова.

    • Aguinore
      /#18878269

      То есть исследование не показало, что TDD не работает, правда?

      Нет, пожалуй, не показало.

      Что же оно показало?

      Думаю, оно показало, что нельзя интерпретировать выводы исследований без прочтения исследований.


      Тонко

  15. miga
    /#18877159

    // проверяем формат электронной почты
    if (!regex(data['email']) {
    return false;
    }


    Бац — и вы плохой программист