Что такое быть хорошим разработчиком?

    Опыт вождения по дорогам Киева натолкнул меня на пару интересных мыслей. Все мы знаем, что на дорогах «куча идиотов». Ровно так же дело обстоит и в разработке – куда ни глянь, страшно на код взглянуть. Почему так происходит?

    image

    Ведь каждый из нас считает себя классным водителем! Мы умеем быстро ездить, втискиваться между машинами, проскакивать где нельзя и т.д. В общем, быстро добираться до нужного нам места. Да и классным разработчиком многие себя тоже считают. Только дай нам задачу посложнее – наваяем для нее решение очень быстро, возможно даже шаблонов проектирования нагородим. Так в чем же тогда дело?

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

    Крутой водитель? Хочешь ездить быстро и перестраиваться из ряда в ряд? Показывай при этом повороты, не подрезай на скорости другого водителя. Не хватает времени или реакции на это? Тогда ты ни хрена не крутой и едь спокойно как все! Действительно классный водитель не гонит, а знает много вариантов проезда, когда надо заранее перестроиться, какую скорость развивать для попадания в «зеленую зону», грамотно оценивает риски попасть в пробку и принимает адекватные решения…

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

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

    Для водителей предусмотрены хоть какие-то штрафы (не будем начинать разговор об их действии в Украине) за ложный «профессионализм». В разработке их нет и это делает наши проекты из радостных и «цветущих» «дурно пахнущими» и унылыми. А «профессионалы» дуют щеки и рассказывают как они быстро смогут написать любой сложности код…
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 27
    • –6
      В разработке их нет
      Лишать премии.
      • +2
        премию еще заработать нужно
        а если забирать часть з/п, то так команда быстро разбежится, еще и ужасы про компанию рассказывать будут
        • 0
          Да это я просто как пример. Методов воздействия то не мало, даже не обязательно по карману бить.
          По факту же — надо было думать до приёма подобного разработчика.
          • 0
            Не нанимать таких говнюков. Попросить примеры кода или написать небольшое тестовое задание на час-два. И можно будет понять, что за человек. Если еще не ясно — есть испытательный срок. В это время можно вдоволь насмотреться на то, какой код пишет человек. Но лучше всего смотреть личные проекты. Если таковых нет, то я даже не приглашал бы на интервью.
          • +1
            У некоторых премии просто нет.

            Если ты плохой разработчик, то и получать ты должен соответственно меньше других, вот и вся арифметика.
            • 0
              Если бы только в разработчике было дело.
              Бывает и такое, что вся цепочка дефектная: плохой разработчик -> плохой проектировщик -> плохой менеджер -> плохой директор.
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Плохой проект с точки зрения архитектуры/реализации может быть вполне прибыльным, к сожалению.
                • 0
                  значит и компания будет убыточна. Если же деньги приходят и не малые — значит время пересмотреть свою оценку.
            • +3
              Да никто никогда не будет писать афигенски читаемый переносимый суперкод! Весь вонючий output программиста необходимо контроллировать, контроллировать и еще раз контроллировать, а еще пинать за говнокод и т.п.

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

              Как-то так. Причем это относится ко всем слоям, от кодеров до архитекторов. Архитекторы например могут завернуть все такими кренделями, что без него не то что разобраться, а сбилдить проект будет невозможно пол года =)

              Еще раз повторюсь: Контроль, контроль и контроль! Говнокод не должен попасть в главную ветку репы.
              • +10
                Неправда ваша. Многие программисты еще и эстеты в отношении кода. Часто можно слышать, что код «красивый» или «изящный», или бывает «корявый». Писать и одновременно наслаждаться написанным — в этом ловят свой кайф множество программистов. Я лично знаю примеры, когда программисты уходили из компании, где их так или иначе вынуждали писать код, не удовлетворяющий их эстетическим чувствам. Получение удовольствия от процесса работы — мотиватор едва ли менее значительный, чем деньги.
                • +3
                  Я не говорил, что эстетов не бывает, но вы же не наберете в команду исключительно их? Обычно 50% кода (если не больше) пишутся низкоквалифицированными кадрами, они лишь кодируют что им говорят. Изначально тепличные условия очень редки. Если вы подскажете такую контору, то с удовольствием конечно попытаю счастье там. Но поймите, чтобы создать такие условия нужен жесткий КОНТРОЛЬ кода и вообще архитектуры! Ревью всегда должно быть.

                  И вообще 90% эстеты только на словах, им лишь бы поболтать и покритиковать. А уходящие по этим «эстетическим» принципам программисты часто напоминают боящихся испортить педикюр девочек, болтающих беспрерывно за чашечкой чая своим язычком о новых веяниях моды, но только в сфере IT, в то время как настоящие мужики сидят в наушниках и не подавая ни звука кодят. Если все начнем уходить из-за того, что нам не нравится лапша доставшегося в наследие проекта, то что тогда будет? Часто нужно закатывать рукова и сувать свои мужские руки по локоть в это дерьмо! Прочищать эти вонючие трубы, а потом ставить надежные фильтры! Нужно давать по щам желторотым, ато потом весь проект будет обкомичен с ног до головы всяким говном.
                  Правда бывает, что начальство так или иначе не понимает всей плачевности ситуации, а вы не в состоянии донести до них этого всилу независящих от вас обстоятельств… А еще бывает, что ты становишься уже слишком «немолод чтоли», устаешь от этого всего по горло. Тогда да, лучше искать гнездышко поспокойнее.
                  • 0
                    По моему опыту достаточно одного эстета, который общается с другими программистами.
              • +1
                Сначала составили неправильную формулу классного водителя, затем сами её разрушили.
                Ну и ударю по стереотипам, сказав непопулярное мнение, — не всегда нужно писать хорошо поддерживаемый код в ущерб времени. Лично встречался со случаями, когда я знал что этот код не будет использоваться больше одной недели — прибегает заказчик с ошалевшими глазами, поназаказывает всего «с рюшечками» и чтобы «омлет готовило». Отговаривать это всё равно что ребенку по рукам бить когда он пытается шнурки завязать, поэтому пишу код со скоростью «давай быстрее, не могу терпеть», не в ущерб функционалу, но в ущерб поддержки.
                Он смотрит, радуется, а потом понимает что идея была не очень-то и классная.
                • +1
                  А еще очень часто нужен просто прототип. И здесь во главу угла ставиться скорость написания, и не правильная проработка архитектуры, тестирование всего и вся. Ведь такой прототип должен быть максимально дешевым и максимально быстро написан для первоначального исследования рынка, и потом должен быть переписан. Обратная сторона: потом его «забывают» переписать, наращивают функционал на платформе, которая изначально не была для этого готова, и в итоге имеем то, что имеем.
                  • +1
                    С прототипами полностью согласен — вот тут обсуждали.
                  • +1
                    Ну это вы просто риски на себя перекладываете вместо того, чтобы сделать их публичными и прозрачными для заказчика. Он то потом будет думать, что всегда можно с такой скоростью двигаться. Идеи то далеко не все не нравятся в итоге…
                    • 0
                      Для этого у меня и есть опыт и интуиция, чтобы почувствовать и понять когда можно писать нормально, а когда быстро. К тому же, мои риски это мои риски и я не нагружаю ими заказчика.
                      • 0
                        Ну это если вы пишете в гордом одиночестве. В команде такие вещи не сильно приветствуются.
                  • +1
                    Точно так же у водителей могут быть: плохая логистика, плохой автопарк, необходимость разгружать то, что навозил, постоянно горящие сроки и бесконечный план работ, низкая зп и тд. От всего этого даже лучшие начинают водить абы как.
                    • 0
                      Полностью согласен. Такие негативные проявления я называю низкой моралью. Откуда ноги растут более-менее понятно: из отсутствия или недостаточного управления процессом. В случае наличия высококультурных разработчиков возможна самоорганизация, только тут как курица и яйцо.
                      • 0
                        «Any fool can write code that a computer can understand. Good programmers write code that humans can understand.» — Martin Fowler.
                        • 0
                          А очень хорошие программисты понимают, как тот код будет развиваться, и оставляют самоочевидные места расширения. Высший пилотаж, который средним программистам обычно на первый взгляд незаметен, и только потом когда понадобится что-то дописать, скажешь: «Круто! Предусмотрел ведь!»
                        • +1
                          Последнее время всё больше убеждаюсь, что умение писать код вторично. С повальным переходам в аджайлу куча времени тратися на то, чтобы узнать какую кнопку где расположить и какое действие должно происходить по клику, затем пишешь тесты и вот звёздный час — пишешь две грёбаные строчки кода самой кнопки и обработчика, затем демонстрируешь заказчику и пару раз переносишь и меняешь цвет кнопки.

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

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

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

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

                            Самое читаемое