Статья 7 золотых правил одного программиста

Тема в разделе "Другие языки программирования", создана пользователем Dragokas, 12 фев 2015.

  1. Dragokas
    Оффлайн

    Dragokas Very kind Developer Команда форума Супер-Модератор Разработчик Клуб переводчиков

    Сообщения:
    4.478
    Симпатии:
    4.306
    7 золотых правил одного программиста

    Автор: voff

    [​IMG]
    Это статья про семь простых правил, которые я сформулировал для себя за годы работы программистом. Семь правил, которые подняли мою эффективность. Сделали меня лучше. Это мои правила и они работают для меня. Я не пытаюсь навязать их вам, я хочу поделиться с вами, и, возможно, узнать о том, каких правил и принципов придерживаетесь вы.

    Компьютер всегда прав

    Самая раздражающая ситуация в программировании — когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка...”. Возникает чувство, будто компьютер над вами издевается!

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

    Успокойся и все получится

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

    Самое сложное — начать

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

    Читай книги

    Читайте книги. Я еще раз напишу: Читайте книги!
    Почему-то многие программисты совершенно игнорируют книги. “Я и на работе отлично просвещаюсь”, “У меня нет времени”, “Я читаю статьи в интернете”. Это все здорово, но лично я считаю, что лучший источник знаний — это все еще книги. Я стабильно покупаю по одной-две книги в месяц, плюс время от времени перечитываю что-то старое. Не буду врать, у меня на полке скопилась внушительная стопка того, что я купил, но пока не читал (как с играми в стиме), но я дойду, обязательно дойду.

    Знай свои инструменты

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

    Не будь перфекционистом

    Выше я писал, что самое трудное — это начать. Так вот, закончить — тоже не всегда легко. Отлаживать и рефакторить код можно бесконечно. “Что-за длинный метод?”, “Может это в отдельный класс?”, “Было бы удобнее если бы...”, “А вдруг потом понадобится...”, “А вдруг...”. В программировании нельзя быть перфекционистом. Проблема в том, что достаточно почитать Роберта Мартина или Банду четырёх, как тут же возникает желание переписать нафиг весь свой код. Нужно понимать, что идеального кода нет. Я придерживаюсь правила: “Код должен работать без багов, быть тестируемым и читаемым”. Все. Пока код метода отвечает этому требованию, я его не трогаю. Даже если в нем два цикла, три условных оператора и четыре параметра.

    Умей отдыхать

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

    Источник.
     
    fseto, Kиpилл, orderman и 2 другим нравится это.
  2. kmscom
    Оффлайн

    kmscom Пользователь

    Сообщения:
    271
    Симпатии:
    43
    с простыми примерами вашего труда в виде скомпилированного машинного кода, полученного в результате соблюдения данных правил, можно ознакомиться?
    --- Объединённое сообщение, 12 фев 2015 ---
    Dragokas, ой извините, я думал это ваши личные правила. вопрос выше снимается
     
  3. Dragokas
    Оффлайн

    Dragokas Very kind Developer Команда форума Супер-Модератор Разработчик Клуб переводчиков

    Сообщения:
    4.478
    Симпатии:
    4.306
    Скомпилированного, будучи находящимся в спортзале ? Думаю, вряд ли :D
     
  4. Dragokas
    Оффлайн

    Dragokas Very kind Developer Команда форума Супер-Модератор Разработчик Клуб переводчиков

    Сообщения:
    4.478
    Симпатии:
    4.306
    не, я прокомментировать конечно могу.
    Честно говоря большинство правил мною не соблюдаются.
    Но я с автором согласен на все 100.

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

    Зачастую негативные эмоции провоцируются из-за плохого знания инструмента.
    Бывает и так, что Вы мысленно ругаете авторов в духе "А я бы мог сделать реализацию этого инструмента лучше", "А почему не вот так?",
    "Та сколько ж можно ставить этих скобок? Автора этого API - мазохисты!".
    Смиритесь, сконцентрируйтесь, и в конце концов - победите лень и прочитайте уже хоть раз эту документацию RTFM !!! .

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

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

    Пример 2.
    "Ух ты, заработало!" или "Работает? - Значит не трогай !"
    Это заблуждения. Через какое-то время Вы что-то измените и перестанет работать ВСЕ.
    И Вы не будете знать ни где сломалось, ни почему. "А как починить? - это не ко мне. Я вообще тут не местный :)"

    Золотые слова.

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

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

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

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

    Самое святое. Подход к задаче со свежей головой.
     
    Последнее редактирование: 12 фев 2015
    Kиpилл, Phoenix и ScriptMakeR нравится это.
  5. Chinaski
    Оффлайн

    Chinaski Ассоциация VN

    Сообщения:
    2.277
    Симпатии:
    502
    Согласен со всем, но с этим особенно. Вчера не выспался, весь день ковырял отчет в 1С (не сложный) так и не сделал, вчера пораньше лег, сегодня чувствую себя хорошо и отчет легко сделался :Acute:
     
    Kиpилл нравится это.

Поделиться этой страницей