1. Код на стероидах
Пашкевич Дмитрий
4й Омский IT-субботник
2 марта 2013г
2. Моя карьера в IT
● Начал программировать еще в СССР
● ФМШ 64 - лаборант - 1995
● Кафедра Общей Физики ОмГУ - лаборант
○ компьютерное моделирование ВТСП СКВИДов
● Интернет-Центр ОмГУ
○ программист - 2001
○ ведущий программист
○ заведующий веб-лабораторией - 2003
○ LibNavigator - первая "шаровара"
● Тамтэк - основатель, директор - 2006
6. Истории из жизни
Если вас беспокоит что-то из упомянутого,
или вы узнали в кейсах себя или свою
команду - нам с вами есть, что обсудить.
7. Истоки
Мы выложились как могли! Почему заказчик
недоволен?
Достаточно ли рефакторить код 2 раза в
неделю? Может лучше каждый день? Что
говорят гуру на этот счет?
Говорят, что американские программисты
продуктивней. Может быть они умнее?
8. О будущем
Наверняка нам нужно будет сменить базу
данных через год. Добавим слой
абстракции, чтобы можно было сделать это
за пару дней.
Вот здесь после выхода в продакшн нам
наверняка понадобится справляться с
нагрузками. Выделим отдельный сервис.
Сделаем архитектуру, как в Инстаграмм.
Когда к нам придут миллионы
пользователей - мы уже будем готовы.
9. Новые няшки
Java недостаточно быстрая. Будем писать
на Erlang, заодно и изучим.
Вышла новая версия Spring Framework. Ура!
Переходим!
На форуме пишут, что эта новая библиотека
лучше всего подходит для нашей задачи.
10. Мы лучше знаем
Использование Active Record позволит
удешевить разработку в два раза? Чепуха!
Заказчик не откажется от хранимых
процедур - они безопасней.
Заказчик просит упростить архитектуру?
Сделаем как планировали - он нам потом
будет благодарен.
11. Мы просто лучше
Потомкам тех, кто запустил первого
человека в космос не пристало
быдлокодить!
Шеф хочет, чтобы мы работали “быстро и
грязно”. Вот недоумок! Так мы сделаем что
попало. Заказчик не будет доволен.
Домашнее задание: Вспомните еще 10 причин, почему
всегда нужно сразу писать правильный код.
12. А как же сроки?
● Без этой фичи продукт будет бесполезен.
Ее нельзя выкидывать.
● Без такой архитектуры все рухнет под
нагрузкой.
● Без этого рефакторинга в коде завтра
невозможно будет разобраться.
● Я плохо знаю Scala, приходится
разбираться "по ходу".
Домашнее задание: Вспомните еще 10 причин, почему
сроками проекта нужно пренебречь.
21. Что делать?
1. Знания
Учиться! Да! Но чему?
2. Опыт
Да! Но сколько лет мне нужно?
3. Воспитание
Что есть - то есть.
4. Гордыня
Не лечится.
5. Жизненная философия
А докажите свою правоту?
22. Что для нас главное?
- Красивый код? /привет, Фаулер!/
- Отсутствие в коде повторений?
/здравствуй, DRY!/
- Четкое следование канонам ООП или
другим шаблонам? /кто не следует GoF -
неудачник!/
23. Что для нас главное?
- Использование последних версий софта?
/в них ведь меньше багов!/
- Удовольствие от созерцания
многоуровневой архитектуры,
умещающейся только на листе A0? /мы ведь
не зря изучили “управление сложностью”?/
- Мнение коллег? /на Друпале пишут только
неудачники и быдлокодеры/
24. Что для нас главное?
- Сделать кого-то более счастливым?
25. Философия прагматичного
минимализма
KISS/Бритва Оккама. Не усложняйте
сущности сверх необходимости.
YAGNI. 20% фич потребуют 80% времени.
Реализуйте только то, что нужно вам прямо
сейчас.
Lean Startup. Не тратьте время и деньги на
то, что может оказаться никому не нужным.
27. #1. Используйте проверенные
решения
Используйте решения, проверенные вами,
коллегами или сообществом.
Используйте “вчерашние” версии библиотек,
если только в них нет известных вам
серьезных дефектов или уязвимостей.
28. #2. Пишите на том, что вы лучше
знаете
Если вы гуру PHP - решайте задачу на PHP,
(если она вообще решается на PHP). Если
услышите, что решение на Scala будет
работать быстрее - 10 раз подумайте,
прежде чем сменить язык.
Ваша неопытность сведет все
преимущества нового языка на нет. Это
можно делать, когда сроки проекта - не
критичны, и вы сможете все переписать с
нуля.
29. #3. Выбирайте подходящие
инструменты
Знайте область применимости и
рекомендуемые сценарии использования
систем и фреймворков.
Не стоит использовать Java для
прототипирования. Не нужно использовать
Ruby в больших приложениях.
30. #4. Думайте про сегодняшний день
Большинство написанных приложений умрут
от того, что они будут никому не нужны, а не
от невозможности обслужить запросы
миллионов пользователей. Помните об
этом!
Если приложение “взлетит” - у вас будут и
деньги и время на то, чтобы переписать его
под миллионы пользователей и высокие
нагрузки.
31. #5. Никаких "прозапас"
Никогда не выбирайте библиотеку /
фреймворк / технологию по принципу
наличия чего-то, что вам возможно когда-то
понадобится. Практика говорит, что оно вам
не понадобится.
32. #6. Падения допустимы!
“Тройное дублирование” нужно только в
космосе. Для большинства приложений
допустимы “вылеты” и перерыве в работе.
34. #8. Чем проще - тем лучше
Никогда не добавляйте слои абстракции “на
всякий случай”. Когда такой слой
понадобится - тогда и введете.
Современные IDE позволяют выполнять
подобный рефакторин “на раз”. Вообще,
старайтесь не делать ничего “на всякий
случай”.
35. #9. Делайте то, что действительно
нужно людям
Прежде чем вложить миллионы в стартап -
убедитесь, что он нужен людям, и будет
приносить прибыль.
Если это работа на заказ - убедитесь, что
заказчик проверил это, иначе даже
отличный продукт окажется на свалке
истории. И кто будет счастливым в конце?
36. #10. Помогайте клиенту
Они сами не всегда понимают, что именно
им нужно. Если вы уверены, что проект в
таком виде не “выстрелит” - говорите об
этом клиенту, не боясь потерять контракт.
Наша миссия - помогать людям, а не
выкачивать из них деньги. Если клиент
упорствует - что ж, это его право. Делайте,
как он велит со спокойной совестью. В
следующий раз он будет прислушиваться к
вашим рекомендациям.
37. #11. Приоретезируйте
нефункциональные требования
Обязательно выясяйте нефункциональные
требования к системе с помощью вопросов,
на которые заказчик способен ответить.
Это будет длинный список (нагрузка,
интерфейс, сопровождение и тд) - поэтому
обязательно выясните, что из этого
наиболее важно. Каждое такое требование в
итоге может стоить миллионы. Чем-то
наверняка придется пренебречь.
38. #12. Выкидывайте лишнее
Если фича или какая-то “хотелка” сложна в
реализации, требует много времени / денег
или потребует серьезной переделки -
откажитесь от нее.
39. Народная мудрость
● Будет день - и будет пища
● Семь раз проверь - один отрежь
● Все гениальное - просто
● Лучшее - враг хорошего
● First things first
"Нет цели лучше, я это понял
Чем приносить людям пользу."
(с) Влади (Каста)
