Код на стероидахПашкевич Дмитрий4й Омский IT-субботник2 марта 2013г

Моя карьера в IT

● Начал программировать еще в СССР● ФМШ 64 - лаборант - 1995● Кафедра Общей Физики ОмГУ - лаборант

○ компьютерное моделирование ВТСП СКВИДов● Интернет-Центр ОмГУ

○ программист - 2001○ ведущий программист○ заведующий веб-лабораторией - 2003○ LibNavigator - первая "шаровара"

● Тамтэк - основатель, директор - 2006

Владею технологиями

● С/С++ (STL, WinAPI, MFC, POSIX)● Java (тысячи их!)● С# (1.0-3.5)● MatLab● PHP● XML / XSLT / XPath● SQL / NoSQL / NewSQL / YaSQL● Network protocols● Parallel computing● Cloud computing

Проекты (человеко-лет)

● Tallygram (социальная сеть) ~11● NYTimes Sartre (эл. подписки) ~10● iFactory DeGruiter ~10 ● NYTimes EGNG (почтовые рассылки) ~7● AppNexus ~4● The Weekly Standard ~4● ...● Тамтэк ~100

Познакомились? Перейдем к делу!

Истории из жизни

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

Истоки

Мы выложились как могли! Почему заказчик недоволен?

Достаточно ли рефакторить код 2 раза в неделю? Может лучше каждый день? Что говорят гуру на этот счет?

Говорят, что американские программисты продуктивней. Может быть они умнее?

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

Вот здесь после выхода в продакшн нам наверняка понадобится справляться с нагрузками. Выделим отдельный сервис.

Сделаем архитектуру, как в Инстаграмм. Когда к нам придут миллионы пользователей - мы уже будем готовы.

Новые няшки

Java недостаточно быстрая. Будем писать на Erlang, заодно и изучим.

Вышла новая версия Spring Framework. Ура! Переходим!

На форуме пишут, что эта новая библиотека лучше всего подходит для нашей задачи.

Мы лучше знаем

Использование Active Record позволит удешевить разработку в два раза? Чепуха! Заказчик не откажется от хранимых процедур - они безопасней.

Заказчик просит упростить архитектуру? Сделаем как планировали - он нам потом будет благодарен.

Мы просто лучше

Потомкам тех, кто запустил первого человека в космос не пристало быдлокодить!

Шеф хочет, чтобы мы работали “быстро и грязно”. Вот недоумок! Так мы сделаем что попало. Заказчик не будет доволен.

Домашнее задание: Вспомните еще 10 причин, почему всегда нужно сразу писать правильный код.

А как же сроки?

● Без этой фичи продукт будет бесполезен. Ее нельзя выкидывать.

● Без такой архитектуры все рухнет под нагрузкой.

● Без этого рефакторинга в коде завтра невозможно будет разобраться.

● Я плохо знаю Scala, приходится разбираться "по ходу".

Домашнее задание: Вспомните еще 10 причин, почему сроками проекта нужно пренебречь.

Ура! Картинки!

Поиграем в ассоциации

Где спрятана проблема?

1. Знания2. Опыт3. Воспитание4. Гордыня5. Жизненная философия

Что делать?1. Знания

Учиться! Да! Но чему?2. Опыт

Да! Но сколько лет мне нужно?3. Воспитание

Что есть - то есть.4. Гордыня

Не лечится.5. Жизненная философия

А докажите свою правоту?

Что для нас главное?

- Красивый код? /привет, Фаулер!/

- Отсутствие в коде повторений? /здравствуй, DRY!/

- Четкое следование канонам ООП или другим шаблонам? /кто не следует GoF - неудачник!/

Что для нас главное?

- Использование последних версий софта? /в них ведь меньше багов!/

- Удовольствие от созерцания многоуровневой архитектуры, умещающейся только на листе A0? /мы ведь не зря изучили “управление сложностью”?/

- Мнение коллег? /на Друпале пишут только неудачники и быдлокодеры/

Что для нас главное?

- Сделать кого-то более счастливым?

Философия прагматичного минимализма

KISS/Бритва Оккама. Не усложняйте сущности сверх необходимости.

YAGNI. 20% фич потребуют 80% времени. Реализуйте только то, что нужно вам прямо сейчас.

Lean Startup. Не тратьте время и деньги на то, что может оказаться никому не нужным.

Полезные советы

#1. Используйте проверенные решения

Используйте решения, проверенные вами, коллегами или сообществом.

Используйте “вчерашние” версии библиотек, если только в них нет известных вам серьезных дефектов или уязвимостей.

#2. Пишите на том, что вы лучше знаете

Если вы гуру PHP - решайте задачу на PHP, (если она вообще решается на PHP). Если услышите, что решение на Scala будет работать быстрее - 10 раз подумайте, прежде чем сменить язык.

Ваша неопытность сведет все преимущества нового языка на нет. Это можно делать, когда сроки проекта - не критичны, и вы сможете все переписать с нуля.

#3. Выбирайте подходящие инструменты

Знайте область применимости и рекомендуемые сценарии использования систем и фреймворков.

Не стоит использовать Java для прототипирования. Не нужно использовать Ruby в больших приложениях.

#4. Думайте про сегодняшний день

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

Если приложение “взлетит” - у вас будут и деньги и время на то, чтобы переписать его под миллионы пользователей и высокие нагрузки.

#5. Никаких "прозапас"

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

#6. Падения допустимы!

“Тройное дублирование” нужно только в космосе. Для большинства приложений допустимы “вылеты” и перерыве в работе.

#7. Избегайте преждевременной оптимизации

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

#8. Чем проще - тем лучше

Никогда не добавляйте слои абстракции “на всякий случай”. Когда такой слой понадобится - тогда и введете. Современные IDE позволяют выполнять подобный рефакторин “на раз”. Вообще, старайтесь не делать ничего “на всякий случай”.

#9. Делайте то, что действительно нужно людям

Прежде чем вложить миллионы в стартап - убедитесь, что он нужен людям, и будет приносить прибыль.

Если это работа на заказ - убедитесь, что заказчик проверил это, иначе даже отличный продукт окажется на свалке истории. И кто будет счастливым в конце?

#10. Помогайте клиенту

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

#11. Приоретезируйте нефункциональные требования

Обязательно выясяйте нефункциональные требования к системе с помощью вопросов, на которые заказчик способен ответить.

Это будет длинный список (нагрузка, интерфейс, сопровождение и тд) - поэтому обязательно выясните, что из этого наиболее важно. Каждое такое требование в итоге может стоить миллионы. Чем-то наверняка придется пренебречь.

#12. Выкидывайте лишнее

Если фича или какая-то “хотелка” сложна в реализации, требует много времени / денег или потребует серьезной переделки - откажитесь от нее.

Народная мудрость

● Будет день - и будет пища● Семь раз проверь - один отрежь● Все гениальное - просто● Лучшее - враг хорошего● First things first

"Нет цели лучше, я это понялЧем приносить людям пользу."(с) Влади (Каста)

Спасибо за внимание!

Пашкевич Дмитрий, Тамтэкemail: dmitry.pashkevich@thumbtack.netskype: dmitrypashkevichVK: vk.com/dmitrypashkevich