Смертные грехи разработчика


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


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


    Нихрена ты не разработчик.


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


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


    Из примеров.


    1. Был как-то на собеседовании в Американской конторе. Там на одном из этапов господин, представившийся как CEO, начал спрашивать лютую дичь о Ruby по бумажке (в смысле по заготовленным шаблонам в гуглодоке). На вопросы о том пишет ли он сам код и зачем такое непотребство спрашивать у соискателей он тактично перевёл разговор и попросил сосредоточиться на задачах.
    2. Есть знакомый ресурсный менеджер, который психологом работает на досуге. Так вот этот господин до их пор код пописывает в свободное время и иной раз может сильно удивить кандидата любопытными познаниями в, казалось бы, нехарактерной для него области. Вроде не не программист, но все его принимают за своего.

    Я же запускал тесты, зачем тестировать руками приложение?


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


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


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


    1. Маленький независиый проект — нет препятствий патриотам!
    2. Много внешних интеграций. Значит у вас есть песочницы для каждой из них. Либо у вас есть заглушки или локальные эмуляторы внешних сервисов. Либо у вас есть большие проблемы, которые скоро выстрелят.
    3. Много микросервисов. Суть да дело это предыдущий пункт. С той лишь разницей, что расширяются возможности по локальной эмуляции. Например, набор из докеров с реальными микросервисами вместо заглушек.
    4. Нужно много данных для работы проекта. Но очень редко нужен весь многотерабайтный массив данных для разработки. А если всё-таки нужен, то для этого делают несколько инстансов для разработчиков. Например, 2-3 огромных инстанса на команду из 10-15 разработчиков. Таки да, не шибко удобно и дорого для бизнеса, но иначе вы заплатите ещё больше за разработку на продакшене, которая будет производиться вне зависимости от хотелок высшего руководства.
    5. Монструозный монолит, который работает на определённом железе и только в правильной фазе луны. Если так, то, скорее всего, вы в кровавом энтерпрайзе и здравый смысл там не работает.

    Я уже знаю достаточно и могу больше не учиться


    Если коротко: "кто не развивается, тот деградирует".


    В теоретических науках имеют место случаи, когда можно узнать базу и на ней остановиться. Там всё более-менее стабильно, доказано и неизменно. Физические законы, к счастью, каждую пятилетку не меняют. Так что, если не лезть на передний край науки, то можно жить и даже работу работать. Вот, например, интегралы по контуру: Фейнман их решал в Лос-Аламосе после Второй Мировой и сейчас их решают примерно теми же аналитическими методами.


    А вот с разработкой и программированием так не прокатит. Единого неизменного божественного языка программирования пока не нашли (концепция из Лавины интересна, но пока не открыта). Скорость изменения технологий от пары десятков лет в случае операционных систем и БД до пары месяцев в случае JavaScript'а. И если не развиваться, то за год-другой можно изрядно потерять уровень, а за пятилетку просто обресетиться в ноль.
    Дабы не сильно холиварить о скорости изменения технологий приведу пару примеров. Есть книжка Кернигана и Пайка 1992 года розлива. По ней можно неплохо освоить Unix и не сильно удивиться изменениям, случившимся 15 лет спустя. Можно взять книжку Тома Кайта про Oracle 8, который вышел в районе 2000 года и не сильно удивиться различиям, случившимся в версии 18c. А вот любую книжку по JS пятилетней давности можно смело пустить на растопку.


    Я достаточно крут и могу это не доказывать


    По-моему, это самое тяжкое и самое распространённое.


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


    Частота доказательств разная. В случае друзей и родственников доказывать нужно не так уж часто. А в случае незнакомых людей — на регулярной основе и по полной программе. Места, где потребно доказательство, очень разнообразны: на собеседованиях, на конференциях, новым коллегам, новым возлюбленным… даже в магазине, если покупка немного сложнее табуретки.


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


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

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 27

      0
      Я же запускал тесты, зачем тестировать руками приложение?

      Вот это неправильно. Доказывается очень просто — что можно прокликать вручную, то можно автоматизировать. Вручную можно прокликать 2-3 тесткейса, автотесты могут прокликивать сотни тесткейсов. Для проблем со сломанной версткой есть скриншоты и попиксельное сравнение с эталонной картинкой.

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

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


          (pet projects не считаем, понятное дело)

            –2
            работать на чьем то pet project — это не очень)
          +4
          Было у нас на одном проекте попиксельное сравнение — не взлетело. Для него надо либо жестко фиксировать версию операционки и размер экрана (а так не интересно, да и не особо-то и полезно), либо же делать эталонные скрины для каждого разрешения и версии (в том числе минорной, а это очень затратно по времени) иначе оно будет падать на какое-нибудь немного по другому обрисовывающееся сглаживание шрифта. Проще уж тогда просто делать кучу скринов всех экранов и состояний и потом их просматривать
            0

            вы использовали живые браузеры, не headless?

              0
              Не браузеры, живые айпады (я мобильный разработчик), но не думаю что применительно к попиксельному сравнению это так уж важно
          –3
          Во-первых: код — это не велосипед,

          Ну, смотря какой код. Бывает такой, что из велосипедов состоит чуть более, чем полностью.
            +4
            Вы уполовинили цитату.
            Во-первых: код — это не велосипед, если не практикуешься, то забываешь.

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

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

                +4
                > Я же запускал тесты, зачем тестировать руками приложение?

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

                В случае разработки проектов другого плана: СУБД, бизнес-процессы, общие библиотеки — тесты+code review должны быть критерием корректности изменений.
                  0

                  Да, всё верно, только веб. За остальные области отвечать не могу.

                    0
                    только веб

                    Selenium + несколько грамотных написателей тест-кейсов, хорошо знакомых с продуктом…
                      0

                      К сожалению, это не всегда работает....

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

                  Многие вещи тестировать руками разработчика — слишком дорогое удовольствие. А иногда и вовсе не имеет смысла.
                  Я уже знаю достаточно и могу больше не учиться
                  Это тоже не универсальное утверждение. Иногда учить — лишь отвлекать ценного разработчика от его профессиональной компетенции.
                  Я достаточно крут и могу это не доказывать
                  Вот иногда очень нужно просто сказать некоторым спорщикам именно это — я достаточно крут, потому сделай как я говорю и потом посмотрим на результат.
                    +7
                    К сожалению или к счастью, доказывать свои навыки, проф.пригодность и вменяемость нужно всю жизнь.

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

                      –1
                      Да, всё так. Спасибо! Наконец кто-то озвучил мои мысли.

                      Про покрытие тестами я говорил своим не раз. Фекалии, покрытые тестами, остаются фекалиями, покрытыми тестами. Да, всё зелено. Супер грин. А потом 85 багов, на которые никто не удосужился выделить время. Зато всё покрыто тестами.
                        +2

                        … я так понимаю, ситуация "я запустил и минуту потыкал руками" что-то изменит по вашему мнению?

                          0
                          про минуту я ничего не писал. откуда взялась «минута».
                            +1

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

                        +2
                        любую книжку по JS 5-илетней давности можно смело пустить на растопку.

                        А как насчет десятилетней?)

                        image
                          +1
                          Дабы не сильно холиварить о скорости изменения технологий приведу пару примеров. Есть книжка Кернигана и Пайка 1992 года розлива. По ней можно неплохо освоить Unix и не сильно удивиться изменениям, случившимся 15 лет спустя. Можно взять книжку Тома Кайта про Oracle 8, который вышел в районе 2000 года и не сильно удивиться различиям, случившимся в версии 18c. А вот любую книжку по JS 5-илетней давности можно смело пустить на растопку.


                          т.е. вы пишете, что надо постоянно развиваться и тут же приводите 3 примера, 2 из которых не сильно менялись за последние 10 лет? )

                          Как то… непоследовательно, что ли )
                            0

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

                              0
                              Языки, кстати, даже JS, неплохо дружат с обратной совместимость. Новые фишки крайне редко обнуляют базовые возможности. Особенно, если новое — это щедро пересыпанное сахаром старое.
                                +2
                                А этого мало? )
                                Вебстек лишь часть айти-индустрии и столь радикально заявлять о постоянных изменениях в статье без явного указания что это касается только веба как то опрометчиво и наивно. Говорит о недостатке ширины кругозора )

                                Ну это так, небольшое недовольство общей тенденцией хабра к вебразработке.

                                ЗЫ:delphi изменился сильно за это время? C#? C? и фреймворки к ним?
                                Ну так, чисто косметически. про Т-SQL я вообще молчу.

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

                              В тексте чувствуется знатная попаболь.
                              Дайте погадаю. У «настоящего разработчика» случился факап, пришел «какой-то менеджер» (совсем не настоящий же!!11), показал мастер-класс и теперь перед коллегами неудобно?

                              Разработчик — это, прежде всего, склад ума и понимание CS в целом, а не уверенное жонглирование очередным JS-фреймворком, имя которым легион.

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

                              Only users with full accounts can post comments. Log in, please.