ASP.NET MVC Урок F. Работа как она есть

Цель урока: финальный урок по созданию приложения. Написание технического задания. Создание БД. Переименование webTemplate. Применение скаффолдинга. Админка. Основной сайт. Тесты.

О главном

Это финальный урок, и тут я немного отойду от конкретного программирования и поразмышляю о работе.
Программирование – это работа, это профессия, это творчество. Когда я учился в университете и с кем-то шел по дороге домой, мы часто спорили, что лучше Windows или Linux, Delphi или C++. Тогда мы могли не спать ночами, чтобы красиво переписать построение семантического дерева для компилятора. Мы изучали пролог, лисп, конечные автоматы, структуры данных. Мы учились видеть красоту быстрой сортировки Хоара реализованную на лиспе. ВО!:

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Но теперь я рассматриваю программирование как услугу. Как что-то, за что мне платят деньги. Я занимаюсь фрилансом уже три года. В начале работы фрилансером я программировал не только веб и не только на asp.net mvc. Был и php на ZendFramework, и написание модулей для расчета стратегий для торговли на РТС на Quirk.



Но потом выделил направление asp.net mvc и стал в нем развиваться. Глобальная, стратегическая задача стояла следующая: «Увеличить скорость разработки». Скорость разработки является самым важным параметром. Прежде всего, мы сохраняем свое время, а также лучше придерживаемся сроков. Вместе с тем, я не хотел скатиться в конвейерную разработку, где программист, раз за разом делает одни и те же банальные вещи. Я выделил для себя метод накопления и создания тех инструментов, которые нужны почти всегда.

Так и появился webTemplate. По сути – это шаблон всех моих проектов. Он сам уже четвертой версии. Это основной мой продукт. Но вначале я расскажу о принципах взаимоотношениях с заказчиками, далее о правилах составления технического задания, потом о режиме работы. И в самом конце об webTemplate.

О принципах

Отношения заказчик-работник всегда вызывают много споров. То заказчик обидел, то работник не прав. Фриланс – это то еще болото, и часто заказчик уже «опытный» и при первом разговоре ставит в известность, что «никаких предоплат, ибо повидали!». Вот мои принципы:

• Всегда берите от 30% предоплату. Злопамятные заказчики, которые обобщают всех фрилансеров в одну кучу, в общем-то, не совсем адекватные люди. Но(!) если необходимо это правило нарушить, то нужно договариваться на следующее: «я показываю прототип, а вы тут же перечисляете мне деньги». Ну и понятно, что тут bootstrap + скаффолдинг и 2-3 дня, у нас уже есть что показать, заказчик уходит в лояльность и высылает деньги.
• Всегда сами пишите ТЗ. Хотя бы тезисно. Если заказчик предоставляет ТЗ, а в большинстве своем какой-то документ есть, то не факт что вы поймете правильно. И у меня были такие случаи, что когда я переписал ТЗ, то заказчик сообщил что «всё совсем не так». Так что ТЗ пишите сами. О нем еще поговорим.
• Уделяйте внимание общению. Созвонитесь по скайпу и как можно более подробно проговорите подробности. Не беритесь за создание проекта, пока не закроете все неточности. Если такой возможности нет, то в бюджет проекта пропишите сумму, которая нужна для решения вот этой непонятной задачи. Конечно, сумма может быть большая, и заказчика сразу взволнует этот момент, и, скорее всего, он найдет время сэкономить эти деньги. Если же данной копейки он не заметил, то тем лучше, задача заранее оплачена сполна.
• Никогда, ни при каких обстоятельствах не пропадайте надолго, не предупредив. Этим грешат все. Запороли дедлайн. Должны были стартовать проект, а старый еще недописан, банальная ошибка выбила из колеи на 2 дня. Сроки горят. Всё это фигня, никогда не пропадайте. Если спросят, что происходит – ответьте честно. Если давят на ранюю договоренность, что вы подводите, что «говорили что будет в понедельник, а уже пятница!» — почувствуйте, что вы большой, толстый и меланхоличный слон. Худшее, что вы можете, это поддаться на эту провокацию, хамить в ответ, не сделать работу и свалить.
• Имейте запас денег. Иметь денежную «подушку» на 2-3 месяца такой же качественной жизни. как вы ведете в данный момент, — очень важно. Во-первых, вы не работаете в запарке, что вот долги растут. Во-вторых, не попадете в кабалу текущего проекта. В третьих, если вас кинут, то вы спокойно разрулитесь на следующем проекте.
• Не отдавайте проект на чужой сервер до полной оплаты. Даже, если вам внесли предоплату, и вы отдаете проект, то у заказчика есть возможность вас кинуть. Давайте тестировать на своем сервере.
• Будьте лояльны к доработкам и правкам. Некоторые вещи тяжело предусмотреть, но они могут иметь ключевое значение для проекта. Если это произошло и заказчик настаивает на том, что это было изначально проговорено, то тут два варианта. Всё, что вы напишете в ТЗ, имеет больший вес. Но, если доработки незначительны (чаще всего так и бывает), то проще сделать. Не обязательно каждую мелочь превращать в предмет для дискуссии, но и не позволяйте садиться на голову.
• Не переходите на «ты», пока сам заказчик этого не захочет. Всегда лучше общаться на «вы», даже если вы ровесники. Тем самым это создает более сдержанную и вежливую атмосферу. Хотя в будущем будет легче перейти на «ты». Это уже больше относится к старым заказчикам.
• Не беритесь за поддержку чужих проектов. Не стоит недооценивать то, что вам хотят подсунуть. У меня было несколько проектов, которые нужно было поддерживать, и они были написаны до меня. Мне приходилось разбираться с чужим кодом, на это уходило время, и часто заказчику нельзя было объяснить, какую пользу это приносит. Вторым моментом было то, что часто случался коллапс на ровном месте, код переставал работать, и нужно было искать причину, которая была не до конца ясна.
• Выуживайте как можно больше информации о целях проекта. Чаще заказчик может не знать достаточно о технологиях, и в ТЗ описывает решение, которое, по его мнению, должно работать. Если вы знаете более элегантное и оптимальное решение, то не стесняйтесь предолжить.
• Спорьте о проекте, но помните, что он платит деньги. Да, возможно, что некоторые его идеи и размышления не верны, и вы можете предложить лучшее решение. Предлагайте, убеждайте, даже если это решение и будет стоить дороже. Старайтесь избавиться от глупых решений, но если заказчик сильно настаивает – принимайте его сторону. Он платит, даже за свои ошибки.
• Полюбите работу. Посмотрите на проект, как на свой собственный проект. Сделайте лучшую реализацию, даже если это будет выходить за рамки бюджета и времени.
• Показывайте прогресс. Уведомляйте заказчика о движении по проекту. Ничто так не успокаивает как Progress Bar. Даже если вы опаздываете со сроками, показывайте, что дело идет, не оставляйте в неведении.
• Если нечего показать – спрашивайте. Даже если вам нечего показать, покажите, что задача у вас в голове. Наведите много уточняющих вопросов, вовлекитесь в процесс обсуждения.
• Не работайте по ночам. Не будьте рабом работы, не старайтесь сделать работу за ночь/за выходные. Вы сорветесь, и будете долго восстанавливаться. Но если работа идет и уже три часа ночи – работайте, об этих моментах вы будете вспоминать с удовольствием.
• Посмотрите на проблему издалека. Изучите ТЗ полностью прежде, чем что-то писать. Сформируйте образ, представьте, как будут реализованы блоги, но поставьте вопрос «а как можно это сделать быстрее в три раза, за 2 часа?», «Как можно внести много сложных данных без единой ошибки?», «Быстрее ли будет написать парсер или нет?», «Применимо ли для данного случая разработать свой шаблон или скаффолдер?»
• Не объявляйте сроки и стоимость до тех пор, пока не напишете ТЗ. Тут даже не пытайтесь что-то в уме посчитать, всегда ошибетесь.

Техническое задание

Техническое задание – это ваше всё, это 70% успеха. Техническое задание должно отвечать на следующие вопросы и состоять из следующих частей:

• Цель. Тут кратко описываем цель проекта. Что мы делаем? Для чего нужен этот проект?
• Части проекта. Они должны логично происходить из цели проекта и будут прототипом для создания таблиц в БД. Тут должно быть:
  
  • Язык сайта (если многоязычный, то какие именно языки)
  • Сущности проекта. Это может быть:
    
    • Пользователь
    • Пост
    • Новость
    • Видео
    • Фотоальбом
    • Фотокарточки
    • Машина
    • Друзья
    • Музыка
    • Игра и т.д.
    
    
  • Функции сайта. К этому относится:
    
    • Регистрация
    • Личный кабинет
    • Мои фотографии
    • Статус
    
    
  • Админка сайта.
    
    • Пользователи
      
      • С возможностью активировать
      • Забанить
      
      
    • Видео
      
      • Добавить
      • Изменить
      • Удалить
      
      
    • Новость
      
      • Добавить
      • Изменить
      • Удалить
      
      
    • Работа с смс
    • Регистрация через социальные сети
    • Работа с Webmoney или другими онлайн-системами расчетов
    
    
  
  
• Сроки и бюджет. После описания всех частей проекта составляем табличку
  
  • Работа. Например, «создание БД проекта» или «Регистрация»
  • Сроки (в часах). Старайтесь, чтобы в каждой ячейке сроки не были больше 20 часов. И уж точно не 40+ часов. Иначе, попробуйте разбить задание на более мелкие части.
  • Деньги. Просто умножаете на текущую ставку.
  • Итог. Далее подбиваете итог, не глядя и не округляя. 1695$, например? Да, так и пишете. Сроки и бюджет – это важная часть, она дает нам определение, сколько времени займет разработка (рассчитывайте на 6 часов в день, а не 8 или еще хуже 10) и сколько это будет стоить.
  
  

Таким образом, ТЗ декларирует три вещи, самые важные:

• Что надо сделать
• Сколько это займет времени
• Сколько это будет стоить

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

Да и еще важно: ТЗ не должно быть большим, идеально – до 20 страниц. Не детализируйте слишком сильно, а то заказчик не прочитает его, и будет настаивать на использовании своего документа. Ваш документ должен быть лучше. Он и будет лучше, потому что там будет строка с ценой проекта. Но не перестарайтесь с ним.

Уточню еще раз: ТЗ использует один из самых важных принципов взаимодействия — Принцип декларации. Написано «работаем с 10:00 по 20:00», пришел клиент в 20:10, не стоит и объяснять, почему вы не можете их обслужить. Но в 19:50 закрывать дверь перед носом клиента – нарушение собственных правил, собственной декларации.

ТЗ утверждено. Можно приступать к работе.

Структура базы, webTemplate и Scaffolding

Пробегая по техническому заданию, я выписываю все сущности отдельно в файлик, оцениваю связи. И потом описываю их в базе данных. На это уходит достаточно много времени, до 8 часов. После ТЗ – это самая важная часть проекта.

После этого я копирую проект webTemplate и переименовываю webTemplate –> [новое название проекта]. Это занимает около 30 минут.

После этого в новом проекте я запускаю Scaffolding для нужных таблиц ProviderRepository и Model. Можно сразу составить все команды и скопировав в Package Manager Console запустить процесс и пойти пить чай.

Далее я во ViewModels дописываю необходимые SelectReference, убираю ненужные поля и добавляю необходимые атрибуты из ManagedAttribute и запускаю Scaffolding Controller.

После этого поправляю проект, чтобы он компилировался, и работаю с админкой.

Дальше, начиная от главной страницы, все остальные модули делаю день за днем.

Собственный ритм

Бывало ли у вас такое, что в понедельник вы приходите еще разбитые, а в пятницу уходите уже «убитые», и цель понедельника – это дожить до пятницы. А цель месяца – это дожить до зарплаты. Или, поработав ночью, вы потом неделю ходите «убитыми».
Понаблюдав за собой, я заметил, что выходные у меня наступали в середине пятницы, а если я работал без выходных, то запал заканчивался гораздо быстрее. И еще всякие дела по хозяйству ( например, нужно съездить в город) убивали весь рабочий настрой и целый день.
К тому же заказчики проектов, которые я поддерживаю, практически постоянно обращаются ко мне с правками. И их надо делать. А иногда нет времени на это.
И я сделал недельный ритм, который позволяет мне больше успевать и точнее планировать. Начинается он с воскресенья:

• Воскресенье – день планирования (рабочий). В этот день необходимо спланировать и начать дела, которые будут сделаны в следующие два дня.
• Понедельник – обычный рабочий день. В этот день я начинаю делать то, что запланировал в воскресенье.
• Вторник – ударный рабочий день. В этот день я обычно выключаю скайп и делаю очень большую часть работы. Рабочий день длится около 10-12 часов. Обычно этого хватает, чтобы сделать какой-то кусок, на который бы уходило два-три обычных дня. Цель воскресенья – это как раз спланировать именно этот большой объем работы.
• Среда – полувыходной день. В среду я отвлекаюсь на правки старых проектов, и решаю дела в городе. Может быть, даже полностью выходной день.
• Четверг – это или возврат после вторника к текущему проекту, или продолжение правок, если они еще остались.
• Пятница – это обычный рабочий день, обычно по текущему проекту доделывается что-то рутинное.
• Суббота – никакого программирования. Отдых.

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

Ищите свой ритм, реализуйте свои идеи.

Все исходники находятся по адресу https://bitbucket.org/chernikov/lessons