пятница, 16 марта 2012 г.

Советы программистам-новичкам. Настройка на работу

Как я уже ранее говорил, в работе программиста есть творческая часть. Это приводит к некоторой проблеме. Например, слесарь может точить детали хоть трезвый, хоть “с бодуна”- руки-то “помнят” и “на автомате” будут строгать детали. С творчеством так не бывает- муза капризна и когда “накроет” не угадаешь. А работать-то надо. Одна из черт профи- стабильная работоспособность.

Поэтому, надо учиться управлять своим состоянием. Отличный материал на эту тему в статье Джоэля Спольски. Для себя я выработал такой подход. Всю мелочевку я сразу не исправляю- оставляю “на потом”. Если у меня получилось по-джоэлевски попасть в состояние потока, то я берусь делать что-то большое и сложное. Когда состояние потока проходит, то берусь делать как раз те мелочевки, которые специально откладываю для таких периодов работы, когда творческий запал угасает. Это позволяет мне равномерно “размазать” работу, заполняя рутиной пустоты между творческими пиками.

четверг, 15 марта 2012 г.

Советы программистам-новичкам. Не твое- не трогай!

Есть такой старый армейский принцип: “Не твое- не трогай.” Этот принцип верен и в отношении программирования в команде. Делай свой кусок работы, и не меняй что-либо в чужом коде. В чем смысл данного правила?

Например, вы поменяли, буквально, чуточку в чужом коде, т.к. заметили в нём ошибку (на ваш взгляд ошибку). Проверили тут же- работает. Выложили код. И тут оказывается, что старик Мерфи прав. Ту части кода, которую вы “осознали” и подумали, что это ошибка, вы-то исправили. А вот оказывается, что ваше исправление поломало функционал в куче других мест, о которых вы и не подозревали.

Как же быть тогда? Надо узнавать ответственного за этот код. Лучше всего, конечно, лично подойти и решить вопрос. Если это невозможно, то “кинуть” ему в трекер багу. Если изменения надо внести срочно, то можно и самим это сделать, но обязательно надо в трекер на соответствующего ответственного разработчика кинуть описание этого бага с описанием тех изменений, которые внесли вы. Попросить при этом разработчика проверить, допустимо ли так делать. При выкладке кода в репозиторий надо в комментариях указать номер вашей заявки в трекере.

Таким образом, если вы ошиблись, и ваши изменения неправильны, то ответственный разработчик быстро разберется что к чему и поправит. Даже если по времени это произойдет не скоро, то, все равно, ваша “задница” прикрыта- вы сделали все, зависящее от вас.

Из  этого правила есть следствие: не меняй ничего в чужих строчках кода. Даже если это всего лишь вопрос форматирования кода. Даже лишний “пробельчик”. Ничего. Если будут выяснять, после какого коммита поломался код, то будет видно, что эта строчка кода записана за вами. Вот потом и будете вспоминать и доказывать: “А я там всего лишь “пробельчик” для красоты поставил.” Зачем вам это? Еще раз:

“Не твое- не трогай!”

среда, 14 марта 2012 г.

Советы программистам-новичкам. Не умничай

Это распространено не только в среде программистов- от любого мастера (парикмахера, сантехника, строителя) можно услышать фразу: “Да кто же так делает! Это все неправильно…” В отношении программистов эта фраза дополняется восклицанием: “Это все надо переписать! Я сейчас это сделаю.”

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

Если на ваш ПЕРВЫЙ взгляд вам кажется, что можно было сделать проще/лучше, то помните:

  1. Код был написан, скорее всего, несколько лет назад. Для программирования- это не малый срок:
    • Может быть, в те времена было так принято писать.
    • Не было такого API, которым можно было бы сделать все проще.
    • Не было такого синтаксиса, позволяющего выразить мысль компактнее.
  2. Вы не знаете обстоятельств, которые сопутствовали его написанию:
    • Просили сделать очень быстро- лишь бы работало.
    • Хотели посмотреть “на попробовать” как будет и нужен был набросок. А потом возникли другие обстоятельства и про код забыли.
    • Изначально было сделано хорошо, а потом код многократно изменялся разными программистами, проповедующими различные подходы к написанию кода, которые еще своего там намешали.
  3. Личные обстоятельства:
    • Программист увольнялся- ему было “пофигу”.
    • Не дали премию, мало заплатили.

Ну и, конечно, остаются варианты, относящиеся напрямую к исходной фразе: “Да кто же так делает!”:

  1. Мало предлагали денег по вакансии и на работу наняли слабого программиста.
  2. Наняли по блату.
  3. Наняли умного парня, но большого любителя поэкспериментировать.

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

вторник, 13 марта 2012 г.

Советы программистам-новичкам. Инструменты

Очень простой совет: используйте лучшие инструменты. Хорошего мастера всегда можно определить по его инструментам. Как у классного плотника будет хорошая фирменная пила, у опытного монтажника- перфоратор “мохита”, так и у хорошего программиста должен быть отличный инструментарий.

Не буду спорить с приверженцами аскетизма, что для программирования достаточно текстового редактора и компилятора. Я свой выбор сделал однозначно в пользу развитых IDE, не выходя из которых программу можно написать, скомпилировать и отладить хоть по шагам, хоть по точкам останова.

Распространите этот принцип на все ваше рабочее место:

  1. Хороший компьютер, монитор (а лучше два), удобная мышь и клавиатура.
  2. Настройте автоматическое резервирование (потерять время на переустановку системы из-за полетевшего диска- это дорогое удовольствие, дешевле стоит внешний диск для резервирования).
  3. Удобный трекер, быстрый репозиторий, хорошую “мержалку” бранчей.
  4. При программировании используйте хорошие библиотеки, системы сборки.

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

Не берите тот инструмент, который проще всего достать, который под рукой- ищите лучший. Простой пример: MS XML есть в каждой ОС, и, поэтому, его очень просто начать использовать. А если померять скорость работы этой библиотеки, то обнаружите, что она примерно в два раза медленней работает большинства других библиотек. Может для простых “конфигов” это и не важно, но если надо читать файлы в несколько мегабайт, то здорово с MS XML намучаетесь.

понедельник, 12 марта 2012 г.

Советы программистам-новичкам. Творчество и рутина

Все слышали про то, что программирование- творческая профессия. Отчасти это так. Когда вам выдают задание, где можно попробовать что-то новенькое, то внутри вас зажигается творческий огонек и “вы как на духу” выдаете код- первый черновой вариант. Как правило, после этого творчество и связанная с этим продуктивность куда-то улетучивается. Далее доделывать работу очень не хочется.

То, что вы сделали, можно назвать прототипом. Да, это творческая часть работы, раскрывающая ваш творческий потенциал. Но затем необходимо:

  1. Вписать ваш прототип в существующую архитектуру приложения (рефакторинг в несколько итераций).
  2. “Дожать” все проявляющиеся баги.
  3. Сделать удобный UI.
  4. Расставить комментарии (допустимо и просто хорошо продумать названия функций, переменных).
  5. Отдать это пользователям- они еще “наваляют” 20-30 багов и пожеланий по интерфейсу.
  6. Исправить баги (“заплаток” не делать!).
  7. Повторить п.5,6 еще пару раз.

Справится с заданием в его творческой части и остановится на этом (тут еще пренебрежительно говорят: “А, далее уже мелочи!”) означает НЕ выполнить задание. Это означает, что каким бы творческим программистом вы ни были, в первую очередь вы- ХРЕНОВЫЙ программист. И это главное.

Присмотритесь- “творцов” среди программистов “пруд пруди”. А вот профессионалов мало. Воспитывайте в себе профи. Заставляйте себя тщательно копаться в багах, аккуратно размещать элементы UI на форме, комментировать код. Да- это рутина, да- это не интересно. Но без этого вы- ХРЕНОВЫЙ программист.

воскресенье, 11 марта 2012 г.

Советы программистам-новичкам. Цена “заплатки”

Известная ситуация. К вам прибегает менеджер и говорит, что срочно надо исправить ошибку в программе, или набросать новый функционал. Или это может быть заказчик. Не важно. Отправная точка- вы решаете угодить менеджеру, решив ЕГО проблему заплаткой в программе. В текущей ситуации это проще всего: ЕГО проблему можно решить быстро, к удовольствию менеджера. К сожалению, потом переделать все по-нормальному у вас, скорее всего, времени не будет. Появятся новые задачи.

Через некоторое время, как всегда неожиданно, в самый неподходящий момент, выясниться, что эта заплатка сбила с толку другого программиста- у него работало и перестало. Он потратит кучу времени, чтобы найти и выкорчевать эту заплатку. Хуже, если заплатка замаскирует проблему в одном месте, а в другом- ошибка, полностью не прикрытая заплаткой,  будет продолжать “жить”, и даже портить данные. Вас могут вслух и не обматерить, но за спиной вас обзовут “говнокодером”. Оправдаться не получится. Что в итоге получается? Цена заплатки- ваша репутация.

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

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

Еще раз подумайте: цена заплатки- ваша репутация.