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

[Dragokas]

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

Автор: voff

​

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

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

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

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

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

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

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

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

Читай книги

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

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

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

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

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

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

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

Источник.

 

[kmscom]

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

 

[Dragokas]

Скомпилированного, будучи находящимся в спортзале ? Думаю, вряд ли

 

[Dragokas]

Dragokas, ой извините, я думал это ваши личные правила. вопрос выше снимается

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

“Да тут три строчки, блин, просто негде ошибиться!

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

Эмоции — наш злейший враг.

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

Читайте книги. Я еще раз напишу: Читайте книги!

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

Не поленитесь выделить время на подробное изучение инструментов и технологий

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

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

Отлаживать и рефакторить код можно бесконечно.

“Код должен работать без багов, быть тестируемым и читаемым”

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

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

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

Во многом при рефакторинге лучше полагаться на интуицию, основанную на опыте. Тем не менее имеются некоторые видимые проблемы в коде (англ. code smells), требующие рефакторинга:

1. дублирование кода;
2. длинный метод;
3. большой класс;
4. длинный список параметров;
5. «завистливые» функции — это метод, который чрезмерно обращается к данным другого объекта;
6. избыточные временные переменные;
7. классы данных;
8. несгруппированные данные.

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

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

И здесь как нельзя применимо правило:

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

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

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

Самое святое. Подход к задаче со свежей головой.

 

[Chinaski]

Самое святое. Подход к задаче со свежей головой.

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