18 июля 2013 в 18:53

8 вещей, которых не должен бояться разработчик перевод

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самым распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации, когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль, с которой не захочется связываться.
«Хороший код — это код, который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом». Неизвестный автор.

Удалять мертвый/закомментированный код
Если чувствуете, что мертвый или закомментированный код больше не потребуется, но вы не хотите его удалять, потому что точно не знаете, понадобится он в будущем или нет — УДАЛИТЕ ЕГО ПРЯМО СЕЙЧАС! Хранить код — это работа вашей системы контроля версий, а не комментариев! Я видел очень много ПО заполненного тоннами закомментированного кода о котором уже все давно забыли. И это потому, что если вы не можете вспомнить зачем этот код, страх удалить его еще быстрее появляется в голове. Так, просто удалите — СЕЙЧАС — в самом деле.
«Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего отнять». Антуан де Сент-Экзюпери

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

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

Сталкиваться с неудачами
Это один из самых важных моментов. Если вы дошли до места в вашей работе, где не видите никаких решений проблемы: никогда не оставляйте надежды. Примите это как вызов. Попробуйте взглянуть на проблему под другим углом или объяснить другим людям. Может вы просто застряли решая проблему в другой перспективе. Успешное решение такой головоломки сделает вас еще более сильным разработчиком.
«Я не ошибался. Я просто нашел 10000 способов, которые не работают». Томас Эдисон

Нестабильность кода
Всем знакома такая ситуация: приходите на презентацию вашего проекта к руководству или заказчику и начинаете волноваться. «А заработает ли в этот раз? Возможно я ничего не пропустил в процессе разработки!» Это плохой знак, но не нужно беспокоится. Вам нужно было протестировать ваш проект заранее. Естественно, что вы никогда не можете быть полностью уверены, что все заработает идеально, но вы можете очень сильно повысить уверенность, используя автоматизированное тестирование. Это позволит вам чувствовать себя комфортно при применений изменений в коде и демонстрации вашего ПО.

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

Нехватка времени
Не позволяйте нехватке времени разрушить качество вашего продукта. Это ваша работа содержать код в чистоте и стабильности. Качество требует обдуманных решений и времени. И иногда за это приходится бороться. Ваш заказчик ожидает 100% качества, может даже 120%, готовый, удобный в сопровождении продукт и произведение искусства. Если упадет качество и будет предоставлен посредственный результат, в итоге вы получите еще больше запросов на изменения, еще больше усилий на поддержку и недоверие заказчика. Время которые сэкономили ранее будет съедено техническими долгами, которым вы дали свободу. Если вы упустили одну течь, то шансы чтобы не прорвало всю конструкцию начинают падать. Будьте честными со своим руководством и показывайте все основное, что влияет на качество.
«Программирование, как секс: одна ошибка и ты обеспечиваешь поддержку на всю жизнь». Майкл Синз
Автор оригинала: Gregor Riegler
Александр Малинов @almalini
карма
24,0
рейтинг 0,0
Full Stack Web Dev
Похожие публикации
Самое читаемое Разработка

Комментарии (35)

  • +35
    «Удалять мертвый/закомментированный код»

    Я даже научился удовольствие от такого получать. Этот как ранку засохшую ковырять, когда не больно.
    • +19
      пока не больно
      • +8
        не больно когда есть система контроля версий.
        • +9
          Не больно, когда есть бэкап системы контроля версий.
    • +1
      «Очистить корзину»
      • +3
        По ощущениям это больше похоже на очищение кармы.
  • +2
    Разработчики ленивы и часто слишком засиживаются на своих «старых-добрых» технологиях.

    А мне казалось что как раз благодаря своей лени я изучаю новые технологии, чтобы не делать много однотипных вещей приходится как-то выкручиваться и все автоматизировать.
    • +4
      Проблема в том, что новые технологии появляются сейчас чаще, чем завершается цикл разработки проекта. Есть шанс уйти в бесконечный цикл разработки )
      • +2
        Ну если только ради автоматизации рутинных задач то думаю ничего страшного не произойдет, а если ради новшеств то да, можно будет долго так метаться между все более новыми технологиями.
        Вспоминается истории одного аспиранта который писал работу по IP телефонии 8 лет потому что как только часть напишет то выходит что-то новое и интересное, и так по кругу…
        • +3
          Что там студент, я коммерческий проект так завалил на мобильных HTML5 фреймворках.
          • +1
            Было б познавательно почитать, узнать о подводных камнях.
        • +2
          кажется он занимался другими делами
      • 0
        Есть хорошее правило: не более одной-двух новых технологий в новом проекте.
  • +2
    Пункты про боязнь изменения кода и нестабильность сильно перекликаются. Перекликаются они в одном: тесты. Код покрыт тестами — менять не страшно. Код покрыт тестами — ты уверен в его стабильном поведении. Если же тестов нет, приходится бояться и изменений, и нестабильности. Пишите тесты, господа!
    • +1
      А если тест не все варианты покрывает, ну мало ли о чем думал разработчик, то ему станет весело :)
      • 0
        То он сделает комит перед изменениями и откатит назад если будет нужно.
        • 0
          Вопрос не в том что он сделает, а в том насколько далеко он зайдет, когда поймет, что тесты-то не все случаи покрыли.
          Да и revert / roll back commit не самая по-моему хорошая штука, когда у тебя действительно много изменений.
    • +3
      Пишу тесты примерно пять лет. Последние два работаю в основном по TDD. И за это время было так много косяков и аномального поведения систем, что уже давно сбился со счёта.

      К тому же тесты не везде применимы и порой их реализация неоправданна. На пример в embedded программах тестирование порой просто невозможно из-за нехватки памяти в устройстве.
      • 0
        А я сейчас как раз пишу тестирование embedded системы. Причем командами по USB с PC. Тестирую я не все, но тесты мне нужны для того чтобы иметь возможность сменить некоторые части системы и убедиться что все работает.
        • +1
          Это уже тестирование на другом уровне. Обычно его называют Smoke testing, подразумевая, что оно заменяет или дополняет QA работников. Но суть в том, что вы тестируете систему в целом из вне.
          • 0
            Вау :) Круть :) не знал.
            Но вообще говоря тестируем мы не то, что может проверить человек без отладки. Поэтому автоматический тест и стали писать.
            Например, по USB в устройство отправляются команды, а если они уходя слишком часто — устройство не успевает их обрабатывать и они остаются без ответа или вовсе теряются. Тут мы должны посмотреть сколько пакетов устройство успевает обрабатывать (а-ля анализ размера буфера), нужно посмотреть не придут ли лишние ответы, не уйдут ли лишние запросы и т.п.
  • +2
    Попытка абстрагировать опыт в термины, для выделения рецепта волшебной палочки) Оно одновременно так, и нихрена не так) У каждого опыт рождает свою матрицу ощущений. Вот нами делятся… с ней можно соглашаться или нет… просто знайте что если слова зазвенят — это ваше.
    Потом из таких звоночков складывается система мышления и надеюсь это поможет нашим животам все же не набирать вес а код улучшится)
  • +12
    > Если кажется что технология или фреймворк полностью соответствует вашим нуждам, попробуйте.
    Да, пока все эти горы фреймворков/технологий попробуешь (чтобы понять что точно подходит) — пол жизни уйдет, да и сами фреймворки/технологии устареют. Пробовать что-то новое стоит только на досуге или когда старое уже не дает требуемых возможностей. Всё остальное — баловство и бесконечная и бессмысленная гонка за новыми версиями.
    • +1
      Всё остальное — баловство и бесконечная и бессмысленная гонка за новыми версиями.

      Мозги чистит. Я всегда смотрю на новое, но пользуюсь в живом старым, пока есть хоть мелкий шанс.
      • 0
        Аналогично, в продакшене проверенное старье, дома — всё что альфа и бета и вообще не понятно нужно или нет. Кое что потом в работу перетекает.
  • +3
    Бояться удалять старый код? Да это самая приятная вещь на свете!
    • +1
      Это когда речь идет только о вас. Как только к вам в «связку» поступает кто-то еще, часто работа над ошибками и причесывание старого кода вызывает негатив. Хотя и не всегда.
  • +1
    > Что ж, тогда это, возможно, не совсем подходящая для вас работа.

    Ой как он не по-русски (еще бы) написал. Код некрасивый? РАБОТАЙ! СТАРАЙСЯ! ПОВЫШАЙ УРОВЕНЬ!

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

    А вот потом уже (без оговорок) и решай, «подходящая ли это для вас работа».
  • 0
    Качество требует обдуманных решений и времени. И иногда за это приходится бороться. Ваш заказчик ожидает 100% качества, может даже 120%, готовый, удобный в сопровождении продукт и произведение искусства. Если упадет качество и будет предоставлен посредственный результат, в итоге вы получите еще больше запросов на изменения, еще больше усилий на поддержку и недоверие заказчика.
    Я бы попросил еще отметить, что в случае, когда такое случается, первое, что надо сделать — проинформировать заказчика и объяснить, что задержка вызвана не тем, что вы сегодня случайно выпили лишнюю бутлку виски, а именно стремлением победить нестабильность. Со временем небольшая задержка будет заказчиком забыта, а вот стабильная работа продукта в повседневной ситуации наоборот, будет каждый раз напоминать «тот парень — хороший разработчик».
  • +3
    >8 вещей, которых не должен бояться разработчик
    а должен бояться менеджер =)
  • +2
    От себя добавлю – разработчик не должен бояться создавать новые файлы, вынося код в отдельные классы. По моим наблюдениям, в проектах на Rails многие новички страдают этой фобией. Причины тому, чаще всего, несовершенное владение средствами редактора по быстрому поиску файлов в проекте и нежелание «загромождать проект» файлами длинною всего в несколько строк.
  • +4
    Удалять мертвый/закомментированный код

    Когда правишь не свой код или нет достаточного покрытия тестами сложной системы, где есть кандидат в такой код… черт реально стремно!
    • +1
      Что же стремного в удалении чужого закомментированного кода? А под мертвым кодом, я думаю, имелся в виду код, который вообще не вызывается. Опять же — что тут стремного? Такое обычно бояться удалять по причине «а вдруг пригодится», но, как верно указал автор статьи, система контроля версий похранит все за вас.

      А вот рефакторинг и изменение чужого кода с непокрытыми тестами — это да…
  • 0
    Отлично, спасибо!

    Отправил ссылку коллегам.
  • 0
    «Сталкиваться с неудачами» — напомнило историю одного байта :-)

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