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

    Привет, Хабр! Представляю вашему вниманию перевод статьи «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, использование абстракций в случаях, когда классы реализуют смешанную функциональность, обработка исключений по всем возможным ветвям исполнения кода и т.д. применимы практически на любом уровне (фронтэнд, бэкэнд), где возникают задачи для программистов. Держа в голове эти принципы, вы, возможно, будете справляться с задачами, которые на первый взгляд кажутся «не вашей головной болью», так как вы работаете с другим кодом.

    Заключение


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

    Ну. И что?
    Реклама
    Комментарии 295
      +5
      Вроде бы очевидные вещи, жалко только не все их понимают.
        +1

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

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

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

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

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

          Ага. Товарищ один, занимавшийся разработкой модуля для хирургического отделения некоей больницы внял такому совету и начал изучать хирургию. Скальпели купил, маску, перчатки там всякие… И в 40 лет бросил профессию программиста, став хирургом.
            +5
            Очень круто, между прочим. Его междисциплинарный опыт может позволить ему увидеть места для инноваций там, где их никто раньше не видел.
              +4
              Такие сказки только в России возможны. В нормальной стране его бы к пациенту только лет через 10 подпустили бы после получения соответствующего образования, сдачи экзаменов и получения необходимой практики. В общем годам к 50 стал бы хирургом.
                +4
                Мне кажется это был сарказм. По аналогии с многочисленными «историями» в обратную сторону, когда хирург, пройдя пару онлайн-курсов по веб-разработке, сразу же становится востребованным фронтенд-разработчиком.
                  0
                  Ну я прошел путь «повар -> java dev»… всякое бывает.
                  Ах да, в повара я пришел «с улицы», без кулинарного образования (но шальной коллектив и необходимость в деньгах сделали свое дело).
                  0
                  Судя по статье pikabu.ru/story/ob_obuchenii_khirurgov_5060175 потребовалось бы существенно больше десяти лет.
                +4
                Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.

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

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

                      +2
                      Имхо, конечно какое то понимание нужно, но по моему мнению не то что на конкретную предметную область, на конкретные технологии завязываться не очень.
                        +3
                        Как не бывает и лишнего времени.
                      +3
                      1) Изучите сферу, в которой работаете. Работаете в телекоме, изучите телеком. Работаете в банке, изучайте банковское дело. Так вы сможете быстрее и правильнее решать задачи.
                      А если, к примеру, мне неинтересен телеком, всякие сети и передачи данных кажутся скучными? И финансы с бухгалтерией терпеть не могу.
                        0
                        Так и речь не шла про увлечения и интересы. Если в комплекте идет плохая усидчивость и мотивация, то есть риск стать там малополезным парнем. Такое случается и, наверное, стоило бы подумать о другом рабочем месте с более интересной прикладной областью.
                        Ведь ощущение пользы от своего труда (облегчение работы других людей, сэкономленные ресурсы компании или удовлетворение клиентов) — это само по себе неплохая мотивация, как мне кажется. Но как понять боль людей, о которой ты не имеешь даже поверхностного представления?
                          0
                          Хехе. Никогда не понимал этой мотивации. Решить интересную сложную задачу — это да. Даже если у неё нулевая практическая применимость.
                            0
                            Взаимно) В чем радость решения абстрактной в вакууме задачи? Для меня это звучит как рекорды гиннеса про толкание апельсинов носом.
                              0
                              А в чём радость самой по себе пользы от своего труда? :)
                      +4
                      Старайтесь быть добрее

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

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

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


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

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

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

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


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


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


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

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

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

                            массажистку? Есть видео о том, как трое друзей такую заводят.
                              +1
                              Я предпочитаю чтение какой нибудь легкой литературы и просмотр аниме. Все таки трудно массажистку «хобби» назвать)
                              0
                              То есть насчёт «Не женитесь, Не заводите детей» вы согласны ?)
                                +1
                                Лично я вижу это логичным, поскольку и без этого на разное самообразование часов 20 в неделю хорошо если удается выкроить, а уж если заводить семью, или общаться с друзьями чаще чем раз в месяц-два — вообще представить не могу как как то развиваться.
                                  0
                                  Ну я на счёт «не женитесь» не соглашусь, многим женившимся готовить приходится примерно в 2 раза реже, и заниматься всякими подобными вещами по дому… А уж если учитывать особенности менталитета и воспитания, то есть шансы вообще найти вариант, при котором готовить\стирать\работать по дому больше не придётся)
                                  Может, конечно, всё наоборот получиться, но это опять же вопрос выбора и может быть немножко везения..)
                                  UPD: увидел уже подобную ветку обсуждения от другого комментария…
                                    0
                                    Это при условии, что жена не программист)) С тех пор, как я занялась программированием, хозяйство стало прихрамывать. Уповаю только на то, что когда я, наконец, перестану быть личинкой программиста, то можно будет делегировать домашние заботы)
                                +2
                                «Не женитесь» я бы вычеркнул.
                                Иначе кто будет содержать программиста в то время когда он «тесты, опенсурс и прочее», а при этом на всех доступных работах хотят чтобы всё заработало вчера.
                                  +2
                                  … иначе кто будет выносить программисту мозги «опять сидишь в комп уткнулся», когда он «тесты, опенсурс и прочее»…
                                    0
                                    Холодильник поближе поставить и всего делов.
                                      +1
                                      Приготовить простую и вкусную еду занимает не так много времени, ну либо можно в кафе работать :)
                                        0
                                        Confirmed… на борщ с нуля уходит 30 минут. Процесс отлажен до почти машинального поведения. На мясо-гречку-легкий-салат минут 40.
                                        Причем это сразу еда на 2-4 дня. Разбавлять можно той же шаурмой/яичницей/фруктами (т.е. никто не призывает каждый день потом есть одно и то же по три раза на дню).
                                          0
                                          Причём вы пишете абсолютное время, а не время у плиты.
                                          Тушить и варить здорово как раз тем, что в отличии от жарки не нужно следить ни за чем, а можно параллельно заниматься интересными вещами.
                                            0
                                            Ну время да, целиком от «открыл холодильник» до «выключил плиту».
                                            Как правило, знакомые блюда, уже знаешь досконально и примерно на автомате заложен оптимальный порядок действий. При этом на тот же борщ зажарку я таки «жарю» (на самом деле нет). И мясо тоже «немного надо постоять у плиты».
                                            Explanations: я от жарки отошел много лет в сторону «пассеровки» (в начале максимальная обработка высокой температурой, затем резкое снижение температуры путем добавки минимального объема воды и снижение мощности плиты… близко к классическому тушению, но «немного иное»… как бы комбинирование и нечто среднее между обоими вариантами).
                                      +1
                                      Подтверждаю, очень важные пункты, без них к успеху не придёшь.

                                      Я вот завёл хобби в виде всякой математики, теперь меньше времени на опенсорс и программирование :(
                                      0
                                      Это не для России, честное пионерское :)
                                      Ну какой опен- сорс? У нас тестов не делают, а архитектурные вопросы решаюся добавлением глобальных флагов (я уже не говорю об изучении чего-то нового). Компании всеми силами стараются минимизировать расходы на программистов, потому что считается что они и так получают неприлично много. Последнее происходит из- за знания программистами английского языка и как следствие- возможности продавать себя на западном рынке (а значит рынок IT в России должен конкурировать с глобальным).
                                        0
                                        Фух, а то я читая хабр уже начал дикий комплекс неполноценности зарабатывать, так как уже возникает ощущение что наша компания одна такая на всю страну осталась. Теперь знаю что их по крайней мере две (если мы конечно не из одной)))
                                          +4
                                          Честно скажу, меня всегда интересовало, что же держит людей в таких компаниях. Особенно учитывая, что альтернатив на рынке труда просто море.
                                            0
                                            В моем случае то что я программирование изучать начал примерно за год до окончания вуза, на момент окончания почти не знал английский, да и программирование тоже + возможность выбирать только в небольшом городе, где компаний раз — два и обчелся. Собственно в последнее время раздумываю что вариант только один, переезд, но потребуется еще и сильно фундамент подтянуть, плюс стек сменить (текущий выбирал из того что было доступно на момент начала карьеры).
                                            А, ну еще общая тупость мешает конечно же.
                                              0
                                              в небольшом городе, где компаний раз — два и обчелся. Собственно в последнее время раздумываю что вариант только один, переезд,

                                              Почему не удалёнка или фриланс? Вакансий хватает, так что вариант далеко не «только один» -_-
                                                0
                                                Думал, но как я и говорил, хочу стек сменить, а на удаленку, как правило, нанимают уже состоявшихся специалистов на конкретном стеке, ну либо нанимают на небольшие проекты или задачи на несколько месяцев, не больше.
                                                Да и про общую тупость упоминал уже которая не позволит с сотнями других удаленщиков конкурировать. Вон, только в марте прочитал «Грокаем алгоритмы», а уже не только не могу вспомнить решение задач методом динамического программирования, даже не помню список всех рассматриваемых в книге тем. А ведь книга то простая и совсем базовые вещи описывает.
                                                0
                                                Можно сначала сменить город, а там уже действовать по ситуации)
                                                Сам вот переехал, не жалею, климат только бесит. Всем остальным, кто сомневается переезжать или нет, советую переезжать.
                                          +13
                                          Статья — просто куча шаблонов, часть из которых придуманы как раз теми, кто указан в заголовке. Часть из этих советов просто спорны (например «пишите больше кода» ибо без уточнения что код должен реализовывать полезный функционал — совет становится вредным), часть — хорошие, но не имеют отношения к теме статьи (например «будьте честны»), часть — вообще не в тему и потенциально вредные (например «умерьте своё эго», более того у этого совета заголовок не соответствует содержанию).
                                            0
                                            например «пишите больше кода» ибо без уточнения что код должен реализовывать полезный функционал — совет становится вредным

                                            С этим пунктом не согласен. Код может писаться в целях обучения или развлечения. Тогда ему совершенно нет необходимости реализовывать полезный функционал.
                                              –2
                                              Да типичные советы индусов. Выключите мозг и зазубривайте шаблоны до автоматизма, а затем пишите тонны спагетти.
                                              А результат один — текстовый редактор в браузере, который умирает на файле в 100 кб.
                                              +2
                                              Даже если все функции валидации сегодня у вас синхронные, стоит предусмотреть в интерфейсе возможность добавить асинхронную валидацию в будущем:
                                              validate(data)
                                              .then(postdata)
                                              .then(append..)

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

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

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

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

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

                                                    Типизация у меня в коде зачастую строгая. Даже когда кодю на Python, соблюдаю. Внутри сознания, разумеется.
                                                      +2
                                                      Очень долго работал фрилансером, контакта с другими разработчиками не имел и думал что то что вы описали и есть обычный программист. А потом я встретил людей.
                                                        0
                                                        Людей я тоже не люблю, да. От них интернет тупеет.
                                                    +3

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

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

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

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

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

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

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

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

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

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

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

                                                              Да легко. Например, перевод системы на новую кодировку или имперскую систему счисления (ну, там, дюймы, фунты, фаренгейты, MM-DD-YY). Пока в Вилларибо натужно вспоминают все те места, где это может что-то поменять, в Виллабаджо уже по тестам сразу видят, где что не так.
                                                                0
                                                                «Реши другую проблему так, чтобы большинство предыдущих вообще потеряли смысл».
                                                                Unicode, std::chrono — я люблю вас.
                                                                  0
                                                                  Так это надо, значится, типы любить, а не пихать всё в int, string и void*.
                                                              +2
                                                              Поэтому нет смысла писать людям про необходимость тестов и создавать из этого культ карго, когда тесты нужно писать «потому, что в Интеле пишут» или «потому, что best practices». В тех проектах, где тесты нужны, их необходимость становится очевидна всем участникам.

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

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

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

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

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

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

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

                                                                  То есть деньги и время, затраченные на ручной поиск и разгребание регрессий в будущем вы не учитываете?
                                                                    0
                                                                    Это я отвечал про проекты, где тестов не нужно, но очень хочется. Например для тренировки.
                                                                    Там где нужно, я выше упоминал, вопроса не возникает, нужно ли.
                                                                      0
                                                                      Интересно, что это за проекты, где не были бы полезны тесты
                                                                        0
                                                                        Лучше назовите проекты, где они полезны.
                                                                        Вот всякая бухгалтерия с кучей однотипный форм и операций — согласен. И возни с тестированием каждой много, и операции простые.
                                                                        Только вот при слове «бухгалтерия» меня тошнит. Наелся при разработке биллинга. Не берусь за подобное мозгоклюйство в принципе. Нехай зануды без воображения однообразные формы клепают, а я — программист, я решаю задачи.
                                                                          0
                                                                          Для бэкенда они просто обязательны.
                                                                            0
                                                                            Сколько писал бэкендов — ни разу не понадобились.
                                                                            Ещё раз: простейшие глюки вылезают сами или легко тестируются прямо в браузере вручную набранным URL-ом.
                                                                            Сложные, логические — для них тест писать дольше, чем сам продукт. Я не вижу смысла тратить на это время.
                                                                              +1
                                                                              >Ещё раз: простейшие глюки вылезают сами или легко тестируются прямо в браузере вручную набранным URL-ом.

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

                                                                                  Вы такие скрипты пишете?
                                                                                    0
                                                                                    Нет. Я могу это сделать руками, если нужно.
                                                                                      +1
                                                                                      (пошел посмотреть)
                                                                                      У меня есть сервис… раскладывания кошек по коробкам в зависимости от породы кошки, цвета шерсти и 5-и других параметров.
                                                                                      Тест для 300 case'ов работы сервиса распределения занимает 3 минуты. 1 case — это уникальный набор параметров кошки отправленный http запросов в сервис.
                                                                                      Руками это проверять оооооочень долго
                                                                                        0
                                                                                        Параметры по отдельности проверить не вариант? Их всего пять.
                                                                                        Если неправильно работает один параметр — это видно сразу.
                                                                                        Если вы умудрились сделать так, что у вас программа работает в зависимости от сочетания параметров и фазы Луны — ну извините.
                                                                                          +1
                                                                                          Фаза луны не при чем. Но разные комбинации параметров дают разный результат. И таких комбинаций/результатов много, как я описал.
                                                                                          Руками проверить нужно каждый случай, потому что все работать должно на бою правильно иначе потеря тысяч денег
                                                                                            0
                                                                                            Разумеется, разный. Но каждый параметр определяет свой набор результатов. Если анализ каждого параметра сделан верно — результат будет правильным. Я не понимаю, зачем тестировать весь набор.
                                                                                            Впрочем, если у вас есть «тысячи денег» и время, чтобы такую проверку реализовать и гонять каждый раз — вай нот? У меня — нет.
                                                                                              0
                                                                                              Если анализ каждого параметра сделан верно — результат будет правильным

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

                                                                                              Я выше привел пример, 300 случаев, каждый нужно проверить. Тестом — 3 минуты, руками — часы
                                                                                                0
                                                                                                Нужно убедиться, что анализ каждого параметра прописан верно. Это можно узнать, посмотрев на код и покрутив его в голове. Их всего 5.

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

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

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

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

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

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


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

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

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

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

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

                                                                              Тащемта я так и делаю.
                                                                              А ещё printf().
                                                                                0
                                                                                Перефразирую — команды в linux-консоли с тестами к ним же.
                                                                                  0
                                                                                  Именно.
                                                                                    0
                                                                                    То есть если вам нужно, например, пару раз переименовать все файлы в папке из
                                                                                    *_rus_*.csv
                                                                                    в
                                                                                    *_eng_*.csv
                                                                                    , вы пишете консольную команду, и затем после этого (или перед этим) в той же команде создаёте n тестовых файлов с разными названиями и расширениями и проверяете, всё ли правильно переименовывается? Сомневаюсь.
                                                                                      0
                                                                                      Ну сомневайтесь. А я для этого просто создам каталог «на поиграться» и проверю, если случай действительно сложный. Если там будет задействован rm, я ещё и chroot сделаю.
                                                                                        0
                                                                                        Если это действительно важно, я такой скрипт пишу на хаскеле. Логику переименования пишу в отдельной чистой функции, в repl её вызываю с тестовыми данными, а потом к ней пишу IO-обвязку из трёх строк, в котоой ошибиться невозможно.
                                                                    +4

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

                                                                      –2
                                                                      Начал писать юнит тесты, не понял, зачем это мне нужно, бросил писать юнит тесты.
                                                                        +2
                                                                        Может быть, стоило попробоваться поучаствовать в проектах хоть немного сложнее хеллоу-ворлда?
                                                                          –1
                                                                          Комплекс TTC, или, например, система маршрутизации и биллинга и для IP-телефонии (написанная практически в одну харю) — сложнее хеллоу-ворлда, как думаете?
                                                                            +2
                                                                            написанная практически в одну харю

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

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

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

                                                                                        Как ни полезна вещь, — цены не зная ей,
                                                                                        Невежда про нее свой толк все к худу клонит;
                                                                                        А ежели невежда познатней,
                                                                                        Так он ее еще и гонит.
                                                                                          0
                                                                                          Намекаете на «мартышку и очки»? Так я не слаб глазами (образно, физически-то скоро ослепну). Мой код работает.
                                                                                        +1

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


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


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


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

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

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

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

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

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

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


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

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

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

                                                                                                  Паттерн? Окей. Но слово «событие» вам понятно и без знания паттернов, не так ли?
                                                                                              +1
                                                                                              «Зачем думать, если можно взять паттерн?»

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

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

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

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

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

                                                                                          При наличии тестов все проще, если что-то сломал, то это видно сразу — упали тесты
                                                                                            0
                                                                                            Вот это — слабое место. Человек смертен, а хуже всего — что он внезапно смертен.
                                                                                            Я это осознаю и максимально облегчаю работу последователям. А если проект начнёт приносить деньги — возьму падавана.
                                                                                            Так делается у людей тащемта.
                                                                                              0
                                                                                              И как вы ее облегчаете?
                                                                                                0
                                                                                                Хорошо структурированный и откомментированный код, записки о ходе мыслей, архитектуре и планах.
                                                                                                Вряд ли увеличение объёма кода тестами было бы облегчением, если вы об этом.
                                                                                                  +1
                                                                                                  Скажем иначе. Если код не покрыт тестами, то оценка временных затрат на доработку этого кода и тестирование будет значительно выше, т.е. будет стоить дороже.
                                                                                                    0
                                                                                                    Не согласен. Человеку помимо основного кода придётся разбирать и дописывать тесты, а значит, разбираться ешё и в системе тестов.
                                                                                                    А нормальному программисту, как я постулирую, тесты в основном без надобности. Есть пограничные моменты, где они необходимы, но они не так часты.
                                                                                                      0
                                                                                                      А как вы поймете, что ваша правка ничего не сломала?
                                                                                                        0
                                                                                                        Если она что-то сломает, это сразу вылезет. Как я говорил, исключение — сложные системы с множеством форм, которые ручками не протыкать за нормальное время.
                                                                                                        Я таких не делаю. У меня нынче всё по-военному: затвор, приклад, спуск. Всё смазано и вычищено. Не дать дураку выстрелить себе в ногу. Работа такая.
                                                                                                          0
                                                                                                          ручками не протыкать за нормальное время

                                                                                                          А это какое время? Час, два?
                                                                                                            0
                                                                                                            Пять минут. Если интерфейс программы за это время не обойти полностью — с ней что-то не так. Или она для бухгалтера.
                                                                                                              0
                                                                                                              А если нет интерфейса? Тоже что-то не так?
                                                                                                                0
                                                                                                                Тогда она не нужна. Сообщить программе задачу и получить от ней результат — это интерфейс, как бы он ни выглядел. Программа, которая не делает ничего, не нужна.
                                                                                                                  0
                                                                                                                  Я наверное не так понял, вы же имели ввиду графический интерфейс?
                                                                                                                    0
                                                                                                                    Любой. API, к примеру.
                                                                                                                      0
                                                                                                                      Значит я не так понял.
                                                                                                                      А 5 минут это вместе с подготовкой данных для запроса? Ну например мне нужно разными json запросами сервис вызывать
                                                                                                                        0
                                                                                                                        Как правило, данные готовятся один раз. Накидал пару-тройку запросов, сунул их в браузер или командную строку — и погнал. Оттестил — закрыл окно. На крайняк есть история, что в командной строке, что в браузере.
                                                                                                                          +1
                                                                                                                          Это только в совсем простых случаях работает. Вот вы делаете браузер например: надо отрендерить html, css, js. Вам кто то даёт ссылку на сайт где разметку подозрительно перекосило — в других браузерах всё нормально. Допустим вы догадались в чём дело и пофискили баг. Как вы узнаете, что ничего другого не сломалось?
                                                                                                                            0
                                                                                                                            Открою страницу в нескольких браузерах (у меня их 4 штуки до сих пор стоит — да, да, и фронтенд тоже не мне), подвигаю размер окна. Если не сломалось при этом — значит, если и сломалось что-то, то это мизерный процент случаев, на который можно не обращать внимания.
                                                                                                                            То же самое с вашими тестами — сколько ни пишите, 100% никогда не покроете.
                                                                                                                              +1
                                                                                                                              Всё верно, ломается оно допустим в 5% случаев на некоторых сайтах с корпоративной формой авторизации где кривой html нахаченный индусами за еду. У вас даже не будет доступа к этим сайтам. Вы зафигачили багфикс в продакшн, а через неделю 4 компании которые платят вам за браузер говорят, что у них на работе стала часто глючить авторизация — раньше такого не было, поэтому либо платим неустойку либо фиским это в течении 3х дней как сказано в договоре. Были бы тесты, мы бы сразу заметили, что вот такая комбинация css пропертей вызывает глюки, но тестов нет. Что делать будем?
                                                                                                                                0
                                                                                                                                Не будет доступа — это заранее оговорено в договоре?
                                                                                                                                Оговорено — сразу нахрен таких поциэнтов.
                                                                                                                                Я должен знать, с чем работаю.
                                                                                                                                  +1
                                                                                                                                  Ну а что если баг возникает только когда вице президент компании вводит свой пароль на внутреннем сайте авторизации? Он должен вам дать свой пароль, чтобы вы подебажили html разметку? На деле у вас не будет даже такой роскоши как 100% воспроизводимый баг — вам просто скажут, что примерно в таких ситуациях глючит примерно так. Это вы должны будете разбираться что именно не работает.
                                                                                                                                    0
                                                                                                                                    «Плавающий баг» — признак говнокода. Переработай говнокод — баг исчезнет. Так говорит мой опыт.
                                                                                                                                      +1
                                                                                                                                      Баг не плавающий. Он возникает в конкретных условиях: конкретный html, css, js. Но получить именно эти html и т.п. вы не можете по описанной выше причине.
                                                                                                                                        0
                                                                                                                                        Хорошо, вы нашли ещё один из немногих случаев, где тест поможет.
                                                                                                                                        Сколько вы их выкопаете ещё? Из множества всех возможных?
                                                                                                                                          0
                                                                                                                                          Ого, это браузер один из немногих случаев? Да и как вам тест поможет если вы их не пишете?
                                                                                                                                            –1
                                                                                                                                            А у меня всё работает.
                                                                                                                                            Для того, чтобы написать тест к моему коду, который отловит что-то кроме перепутанного знака, потребуется написать код, по сложности и объёму превосходящий то, что я написал. Я не вижу в этом смысла, когда то, что есть, работает.
                                                                                                                                            И да, как предлагаете писать тесты для микроконтроллеров? Создавать программируемое искусственное окружение, имитирующее звуки, удары, освещение?
                                                                                                                                            У меня нет на это времени. Мне проще пару раз постучать по автомату гаечным ключом, передёрнуть затвор и выстрелить. При финальном тестировании — выстрелить десять раз, а то и дать ребятишкам поразвлекаться, записывая логи.
                                                                                                                                              +2
                                                                                                                                              Работает оно по двум причинам: либо ваш код прост как доска, либо его никто толком не проверял (мало юзеров и т.д.). Помню, что в такой уверенности я пребывал когда будучи студентом подрабатывал программёром: когда мой говнокод столкнулся с кучей реальных юзеров и они начали репортить какие то хитрые баги, я просветлился и понял зачем нужны юнит тесты.

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

                                                                                                                                              Для микроконтроллёров и тем более процессоров тесты вообще параноидальные: там тестируется даже очевидное по 100 раз. Потому что исправить софт можно обновлением по сети, а вот исправить баг в процессорах (как это было недавно у Интела) так не получится. Собственно поэтому вы работаете не в Интеле, а стучите гаечным ключом.
                                                                                                                                                0
                                                                                                                                                Именно! Я специально делаю код простым как доска, плоским как блин, и понятным как хрен! Если это не получается — я разделяю его на несколько простых, плоских и понятных частей, каждая из которых по отдельности сломаться не может — просто нечему. Потому всё и работает.
                                                                                                                                                Если бы я работал в Интеле, процессоры не были бы такими, как сейчас. Они были бы больше похожи на модные некогда «транспьютеры»: куча небольших простых блоков.
                                                                                                                                                  +1
                                                                                                                                                  Выше мы обсуждали примитивную функцию с урезанной регуляркой. Делить там дальше уже некуда вроде. Но как видите даже с ней возникли непреодолимые сложности.
                                                                                                                                                    0
                                                                                                                                                    Нет с ней сложностей у меня. Но вы их создали.
                                                                                                                                                0
                                                                                                                                                Для МК тесты пишутся почти так же, как и для «больших» систем. Вы стреляете, стучите и светите не в сам микроконтроллер, а в соответствующий сенсор. В МК оно приходит в виде дискретного сигнала, частоты, битов АЦП, массива данных из I2P/SPI, и т.д.
                                                                                                                                                И вот уже то, как контроллер работает и ведет себя этими данными, и тестируются. А сами тестовые данные или «пишутся» заранее, или генерируются синтетически (по-хорошему и то и то, в зависимости от данных, конечно).
                                                                                                                                                  0
                                                                                                                                                  Как это поможет проимитировать криво наклеенную звукозащиту или хреновую, «дребезжащую» пайку?
                                                                                                                                                    0
                                                                                                                                                    А с чего это у вас тесты программного кода должны диагностировать аппаратные неисправности внешней обвязки?
                                                                                                                                                    Их задача в данном случае — сказать, что ошибка появилась не в коде обработки сигнала после очередного мержа, а нужно брать в руки мильтиметр и осциллограф и проверять источник этого самого сигнала.
                                                                                                                                                      0
                                                                                                                                                      А вдруг уровень превысит или импульсы появятся где не положено?
                                                                                                                                                        0
                                                                                                                                                        Так в случае с «простым» тестированием для чистоты эксперимента еще нужно стараться, чтобы уровень был точно такой же, как и в прошлый раз, и импульсы снова появились в точности «не там». А когда у вас имитируется не реальный сигнал, а его цифровой двойник — у вас неограниченный простор для комбинации самых разных вариантов, которые вы даже не сможете или не подумаете специально воспроизвести «в живую» в лаборатории, но которые могут случиться в реальной жизни.
                                                                                                                                                          0
                                                                                                                                                          Про стоимость и сложность тестовой установки я уже говорил.
                                                                                                                                                          А не проще ли хорошо писать код, прямо клеить звукоизол и правильно паять, м?
                                                                                                                                                            0
                                                                                                                                                            Проще. Но гарантировать постоянную стопроцентную правильность кода, пайки и монтажа, когда это делает даже квалифицированный и сосредоточенный человек, невозможно, увы. Как вы сами сказали, от ошибок не застрахован никто, важно вовремя их найти и свести к минимуму.
                                                                                                                                                              0
                                                                                                                                                              Хотя нет, не проще. Если было бы проще, то все бы так делали.
                                                                                                                                                                0
                                                                                                                                                                Конечно. Знать своё дело и уметь делать его хорошо, быть честным и всё такое — всё это редкость.
                                                                                                                                                                Потому проще наплодить костылей, правил, законов, регламентов, приставить к каждому по полицаю…
                                                                                                                                                                Но можно просто не работать с дураками и жуликами. Это сложнее, но это наш путь.
                                                                                                                                                                  0
                                                                                                                                                                  Есть очень хорошая старая песня «Битва с дураками» от Машины Времени, которая полностью актуальна до сих пор. Послушайте, возможно натолкнет на размышления.
                                                                                                                                                                0
                                                                                                                                                                Устал объяснять. Скажу прямо. Дайте денег на разработчиков и тестовые установки. У нас их нет.
                                                                                                                                                                Я из ничего сделал что-то готовое к работе. Если бы я полагался на автотесты, разработка заняла бы гораздо больше времени.
                                                                                                                                                                А я умею и так, без костылей.
                                                                                                                                                          0
                                                                                                                                                          Подозреваю, что «проимитировать» проблемы с внешними источниками помогут заранее «записанные» или сгенеренные паттерны проблем с внешними источниками.
                                                                                                                                                            0
                                                                                                                                                            Всё это по сложности намного превысит саму разработку. Это какое баблище придётся в это вбухать?
                                                                                                                                                            Когда-нибудь да. Но сегодня у меня, к примеру, одна из задач — вымутить какой-нибудь еды на 43 рубля.
                                                                                                                                                              +1
                                                                                                                                                              Не вижу разницы, честно говоря, разницу в затратах между «выстрелить»/«отклеить»/«подергать» во время ручного теста, или для того чтобы записать сигнал с АЦП/сделать дамп обмена по шине, использовать это потом для тестов.
                                                                                                                                                                0
                                                                                                                                                                Так чем я эти сигналы буду на контроллер подавать? Тут тестовое оборудование надо, и что-то мне подсказывает, что оно ни фига не дешёвое. Или колхозить тестовый стенд самостоятельно. Извините, ни времени, ни денег на это у меня сейчас нет.
                                                                                                                                                                  +1
                                                                                                                                                                  Вы же сами говорили, что программы надо разделять на простые блоки. Блок, тупо получающий данные с АЦП или с порта (по сути дела копирующий массив из одного адреса памяти в другой) — это одна часть, блок, обрабатывающий эти данные — вторая. Если мы тестируем обработку сигнала и какие-то алгоритмы, работу которых этот сигнал должен вызвать, то вместо первого блока мы подсовываем фейковый блок с таким же интерфейсом, который и выдает нужные нам данные.
                                                                                                                                                                    0
                                                                                                                                                                    Повторяю главные аргумент против этого. Создание тестового окружения для программы или железки во многократно сложнее и дороже создания самой программы или железки.
                                                                                                                                                                    Если бы у меня были миллионы долларов, я бы нанял контору, которая мне всё это разработала бы. Мне по фигу было бы, используют ли он TDD, agile и паттерны. Мне важен результат.
                                                                                                                                                                    Но мне приходится всё делать самому и ограниченными средствами. И я, чёрт побери, умею делать конфетку почти из ничего. Если бы я начал с «100% покрытия автотестами», система не была бы сейчас и наполовину готова. А у нас уже в феврале были предсерийные образцы. Учитывая, что ранние наработки были у нас похищены (физически), думаю, не надо объяснять, почему я не пишу тесты и не делаю тестовые стенды.
                                                                                                                                                                    Потому что я могу работать без них. Мне не нужны костыли, особенно сейчас, когда надо бежать, а не ковылять.
                                                                                                                                                                      0
                                                                                                                                                                      Не знаю, что у вас за специфические задачи, но когда я решал похожую проблему (контроллер, обрабатывающий информацию с десятка вторичных преобразователей и других контроллеров по разным протоколам плюс ADC и DI модули ввода), то написание кода, позволяющего захватить обмен за какое-то время и использовать его потом, плюс модификация полученных дампов для некоторых случаев, которые на стенде «наиграть» не так-то просто (учитывая, что одна из железок стоила несколько лямов и физически стояла за пару сотен километров), заняло гораздо меньше времени, чем разработка того функционала, что надо было протестировать — по сути дела, оно собралось из того, что уже было сделано плюс некая обвязка. И больше не было нужды щелкать релешками на стенде, крутить подстроечники и гонять наладчика с ноутбуком в поле за тридевять земель.
                                                                                                                                                                        0
                                                                                                                                                                        Аналоговые сигналы чем захватывать и воспроизводить? Звуковуху не предлагать, не катит.
                                                                                                                                                                        В контроллере килобайт памяти. Отладки нет. Да, я знаю, что бывает JTAG, но нет.

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

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

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

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

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

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

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

                                                                                        Дело в том, что код сначала рождается и тестируется у меня в сознании, лишь потом переносится на язык программирования и в файлы.
                                                                                        И я не понимаю, как программист может работать иным образом.
                                                                                          +2
                                                                                          Вы можете у себя в голове удержать хотя бы миллион строк кода со всеми их нюансами и точностью до мелочей, и каждый раз при внесении изменений тестировать их все в своем сознании?
                                                                                            –5
                                                                                            Зачем держать в голове миллион строк кода, если держать надо модель, как оно работает? Мелочи легко проверить прямым наблюдением кода, да и компилятор/парсер мелочи вроде синтаксиса проверит.
                                                                                              +2
                                                                                              Проект Chromium. В связи со спецификой и сложности задач и требований к производительности, есть свой сборщик мусора и свои библиотеки коллекций, а также многое другое. 8 миллионов строк кода. Около 50 компаний участвует в разработке плюс около тысячи индивидуальных контрибьюторов.
                                                                                              Вы предлагает разработчикам при внесении изменений, например, в подсистему управления памяти, каждый раз «в голове» или «прямыми наблюдениями» кода вручную проверять, как изменения отразились на _всех_ десятках тысяч классов, в том числе с крайне разнообразными и далеко не самыми очевидными сценариями использования этого функционала?
                                                                                                –4
                                                                                                Если у людей в голове нет модели того, как работает их код — это очень плохо. Они не понимают, что делают.
                                                                                                И это всё, что я могу сказать на эту тему.

                                                                                                Изменения в системе управления памятью не должны затрагивать API. Если затрагивают — это надо документировать, а другие разработчики, соответственно, вносить изменения в свой участок кода. Я не понимаю, в чём тут проблема.
                                                                                                  +4
                                                                                                  А мне вот теперь всё понятно. Вы слабо представляете, о чем вообще говорите.
                                                                                                    0
                                                                                                    Тем не менее мой код работает. Не скажу, что он полностью избавлен от багов, но покажите мне баг в моём коде «в диком виде» — и я его исправлю. Потому что я знаю, где его искать.
                                                                                                      +3
                                                                                                      но покажите мне баг в моём коде «в диком виде» — и я его исправлю

                                                                                                      Так любой дурак сможет.
                                                                                                      Когда разработчика заботит качество его софта и экспириенс пользователя, баги должны исправляться без показывания на них со стороны людьми.
                                                                                                        –2
                                                                                                        Для этого код можно предварительно дать поюзать доверенным людям — тестировщикам, альфа/бета-тестерам и т.п.
                                                                                                          0
                                                                                                          А зачем я должен при каждом изменении тратить ресурсы тестировщиков на выполнение одних и тех же проверок, если я могу вместо этого использовать автоматический скрипт?
                                                                                                            0
                                                                                                            А что вы можете автоматизировать скриптом? CRUD-операции?
                                                                                                              0
                                                                                                              Да очень много чего. От низкоуровневых (атомарные методы и обособленные классы) до высокоуровневых (интеграционных, в каком-то случае это может быть CRUD, как вы хотите) проверок, вплоть до пользовательского интерфейса.
                                                                                                                0
                                                                                                                Знаете, я делал «роботов», имитирующих пользователя (SlimerJS там и прочее). Но это были отдельные продукты.
                                                                                                                Писать автоматику, по сложности превосходящую тестируемый код — контрпродуктивно. Простенькие операции я и сам мышкой натыкаю, не заржавею.
                                                                                                                  0
                                                                                                                  В большинстве случаев в этой автоматике как раз-таки никакой магии и сложности нет.
                                                                                                                  Тут вопрос в другом. Для проектов из разряда «кустарщина», либо распильно-откатных вещей, либо команд, состоящих из студентов и индусов смысла в этом может и не быть.
                                                                                                                  Если же цена рабочего времени разработчиков/тестировщиков, которое тратится при каждом обновлении или релизе выше, чем цена однократной автоматизации — это уже выгодно. Если цена ошибки на продакшене, которую пропустят программисты/тестировщики, схалявив на предыдущем пункте, выше, чем цена однократной автоматизации — это снова выгодно. Про сумму этих цен мы даже говорить не будем.
                                                                                                                    0
                                                                                                                    То есть TDD — это средство получить мало-мальски работающий продукт при некомпетентных разработчиках. Океюшки, так и запишем.
                                                                                                                      0
                                                                                                                      Ваша цитата:
                                                                                                                      Да никто и не говорит, что ошибок не бывает.

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

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

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

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

                                                                                                                          Тут примерно как с демократией — плохая система, но все остальные еще хуже. Так и здесь. Если вариант с ручным перетестированием всего что только можно занимает время в десятки и сотни раз больше, чем сама разработка, и проводить его надо регулярно — то лучше «Тест прокатил — ну и ладно» еще ничего не придумали.
                                                                                                                            0
                                                                                                                            «Давайте делать плохо, потому что лучше мы не можем и не сможем никогда, всё тлен».
                                                                                                                            Неа. Я не согласен.
                                                                                                                              0
                                                                                                                              Тогда предложите рабочее и экономически эффективное решение описанной ситации:
                                                                                                                              Если вариант с ручным перетестированием всего что только можно занимает время в десятки и сотни раз больше, чем сама разработка, и проводить его надо регулярно
                                                                                                                                0
                                                                                                                                «Решить другую проблему так, чтобы предыдущие потеряли смысл».
                                                                                                                                Если система слишком сложна — она неправильная.
                                                                                                                                  0
                                                                                                                                  Это экономически неэффективный вариант. Переписывание системы требует в несколько раз больших ресурсов (учитывая уже вложенные в нее человеко-года), чем автоматизация тестирования.
                                                                                                                                    –2
                                                                                                                                    «Давайте оставим плохую систему, потому что хорошую мы себе позволить не можем».
                                                                                                                                    Да ну вас. Всё на бабло перемеряете.
                                                                                                                                    Я занимаюсь искусством.
                                                                                                    +2
                                                                                                    Модель это общие принципы того как система реализована, мозг действительно хорошо приспособлен для хранения и анализа моделей поскольку сохраняет их «нативно», в виде голограмм.

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

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

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

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