Яков Сироткин, известный блогер и опытный разработчик любит раскрывать глаза молодых программистов на порой нелицеприятные стороны работодателей, объясняя при этом природу этих фактов.
Проблемы о которых не любят говорить на интервью, но с которыми приходится сталкиваться.
Для обладателей толстых каналов, которые не любят читать — можно предложить видеозапись доклада:
Любите слушать аудио в машине — скачайте и слушайте.
Полистать и скачать презентацию доклада можно здесь.
Подготовил материалы выступления Стас Фомин
Сейчас я сделаю небольшой доклад, но сначала несколько слов о себе. Не то, чтобы я отличался особым умом и сообразительностью, но больше десяти лет разрабатывал программное обеспечение, и все время сильно переживал, что получается в результате.
Я десять лет делал jug.ru, у меня есть ЖЖ, и я люблю выступать на конференциях.
Теперь, мы поговорим, как мне представляется наша индустрия в целом. Есть много программ, у которых есть очень-очень-очень много разных функций. А потом, когда начинается внедрение, заказчика проводят, как по минному полю — а вдруг, что-нибудь да внедрится? Аналогичная схема с минным полем действует и для многих наших аутсорсеров. Т.е. сначала берется как можно больше клиентов, под этих клиентов набирается как можно больше штат, за этот большой штат капает небольшая денежка, а когда деньги заканчиваются, все программисты увольняются, «подрываются».
Знаете, даже если вы разрабатываете под IPhone, теоретически вы сможете стать миллионерами. Но статистически вы оказываетесь глубоко в минусе. Была небольшая обзорная статья, которая была посвящена статистике продаж на AppStore, и так получилось, да, что есть очень успешные программы с большими доходами, но большинство получает совершенно смешные суммы.
И я не претендую, чтобы рассказать вам в своем докладе, как делать успешное программное обеспечение. Почему я не претендую на это? Я глубоко убежден, что нельзя сделать успешный софт, если у вас нет собственных мозгов. А собственный мозг я вам не дам. Это технически невозможно. Но на что я надеюсь? Я надеюсь на то, что я затрону некоторые вопросы, над которыми вам будет полезно подумать. Может это вам понравится.
Мне бы хотелось услышать ожидания аудитории. Какие у вас есть герои, которых вы бы хотели рассматривать как потенциальные примеры для подражания? Есть какие-нибудь версии?
Шум в зале… «Линус Торвальдс», «Сергей Брин», …
Ну на самом деле, должен вас разочаровать (см. слайд). А учится можно у меня, по тому, на что я сам напоролся. Моя ролевая модель — Дон-Кихот, который упорно пытается донести свет истины до начальства. Ну и для всех остальных.
Пытается рассказывать правильные вещи, делать правильные вещи, ну как-то двигаться в общем, вперед. Бывает очень-очень больно и обидно. Не советую.
Капитан Очевидность несколько полегче. Некоторые думают, что это неинтересно, но практика показывает, что всегда находятся желающие поспорить.
А теперь перейдем к вопросу главному — зачем становится героем? Вот смотрите — зарплаты в России, они небольшие очень. Программисты обычно получает вдвое больше, чем в среднем по стране. Если программист обладает какими-то дополнительными качествами, то он получает еще в двое больше, чем средний программист. А качества могут быть разные — знания Java, умение хорошо вести себя на интервью, хороший английский… буквально за что угодно.
И смотрите, как может получится — вот вы пришли на работу, хотите разрабатывать разумное доброе вечное. А ваш начальник хочет смотреть футбол. Кто победит?
Шум и волнения в зале…
Больной вопрос…
Другой вопрос связан с нашей территориальной распределенностью, удаленностью от многих наших заказчиков. Вот представьте себе, что у вашей компании есть филиал в Бобруйске. Поручите ли вы этому филиалу задачу, за которую вам дадут медаль?
Подумайте сами, зачем вам давать задачу в Бобруйск, если вы ее сделаете сами и вам за нее дадут медаль. Вы ее не отдадите. Кроме одного случая — эту задачу невозможно сделать.
Шум в зале → В бобруйске ее за меньшие деньги сделают!
Бобруйск получит свои меньшие деньги. Медаль он не получит. Медаль это больше, чем маленькие деньги.
Шум в зале → Медаль получим мы! А он — меньшие деньги. А большие деньги получат те, кто поручили Бобруйску.
В общем — Бобруйск медали не получит.
Так вот, извините, когда вы из Сан-Франциско смотрите, то там все равно — Бобруйск или Санкт-Петербург.
Кроме глобальной такой древнерусской тоски, есть еще вопросы, которые помогают выяснить, что вообще происходит, и вообще, насколько большие разрушения у вас в проекте.
Хочу сразу предупредить, эти вопросы нужно задавать очень осторожно, потому что если вы их будете задавать очень часто, вы прослывете некоммуникабельными людьми, асоциальными типами.
Кто будет первым пользователем?
Use-case простой: вы делаете прототип для министра. Я вам по секрету скажу — министр, как бы вот он, вот он сидит, а вот (показывает на стол в 5 метрах) компьютер. И министр вот так вот смотрит с трех метров. Ему глубоко все равно, там работающий код, или презентация в пауэрпоинте.
Поэтому, если ваша цель прототип министру разработать, то особо программировать и вообще ничего не нужно, вы так, для вида, для галочки.
Другой вопрос — кто виноват? Представьте, что вот вы — делаете систему. И выпустили ничего. Вот год работали, а релиза — нет. Ничего не случилось. Сплошные баги. Кого накажут?
Очень часто, анализ показывает, что не накажут никого. Потому что, тот человек, который по идее главный за этот проект, он еще по совместительству и владелец компании, и у него еще десять других более интересных и нужных проектов. Т.е. его не накажут, а вас — уволят. Вот и все. Ну и соответственно вину на вас легко переложат, это легко.
Значит накажут исполнителя …
Ну как можно наказать? — можно уволить — ну значит уволят. Еще могут поругать — поругать могут, относитесь к этому спокойно.
Вы понимаeте, что очень тяжело сделать проект, если в его успехе заинтересованы только вы, но не тот человек, который выделяет на него ресурсы.
Этот вопрос — хороший, потому что если окажется, что кто-то действительно виноват, то вы сможете от этого человека получить поддержку. Если с вами работает менеджер, которого снимут, в случае провала проекта, вы сможете ему объяснить, что «есть угроза», и он вам поможет.
Т.е. вопрос скорее звучит «кто виноват кроме меня»?
Это вопрос несколько в будущем — «кто будет виноват в крахе?»
Вопрос менее критичный. Если вы Blizzard, вам наверное все равно, вы и так опережаете рынок на много лет.
Но если вы делаете коммерческий софт, и вдруг внезапно оказывается, что неважно, когда вы его сделаете, это значит, что кто-то просто забыл посчитать, насколько ваша деятельность экономически выгодна.
Когда у вас дедлайн сколь угодно далеко, то проект может съесть сколь угодно много денег. Это значит, он может оказаться сколь угодно экономически бессмысленным.
Так что если дедлайна нет, то тоже есть повод задуматься.
Теперь таки поговорим о том, как все-таки сделать успешный проект. Позволю себе процитировать заголовок из руководства для разработчиков айфона. «Формулируйте что вы делаете, для кого вы делаете и что именно».
Это очень сильно облегчает жизнь. Руководство, кстати, рекомендую почитать в оригинале, его неглупые люди писали и достаточно неплохо у них получилось.
Когда у вас есть определение того, что вы сделали, это помогает вам не тратить время на пустые обсуждения. Например, мы делали проект для Министерства экономического развития Российской Федерации. И нам нужно было построить модель экономического развития регионов по 17 параметрам. Параметры совершенно от балды, мы в них ничего не понимали. Неясно было совершенно, что делать. Я предложил простую модель — «мы будем суммировать эти параметры с произвольными коэффициентами». Это абсолютно понятная модель, которую мы назвали «СуперСумматор».
Дали возможность пользователям менять коэффициенты, и смотреть при этом, какой регион, при каких коэффициентах выходит в топ. Мы ни минуты не спорили о том, что мы делаем. Мы это сразу понимали. Мы выпустили продукт с идеальным качеством.
По функциональности были небольшие замечания, но они никого не волновали.
Чем еще полезно иметь цель? Вы можете преодолевать сопротивление!
Еще один случай из моей практики — мне достался менеджер, который в принципе не хотел работать. У него были какие-то другие интересы в жизни. Запускать какие-то задачи в разработку ему не хотелось, и все, он их практически не запускал. Но, он один раз ушел в отпуск, а наверху произошла небольшая рокировка, мне достался верхний, совсем высокоуровневый менеджер, который мне поставил достаточно четкоопределенную задачу. Я эту задачу сделал, начиная от согласования спецификаций, и кончая поддержкой пользователей, несмотря на то, что менеджер был по прежнему против того, чтобы это делать.
Был против того чтобы ездить согласовывать требования, был против того, чтобы запускать разработку, был против того, чтобы внедрять. Но так как была четкая цель, все равно все получилось.
Давайте поговорим о процессах. Был такой, вернее есть такой человек, Joel Spolsky, который сделал для нас stackoverflow.com.
И он десять лет назад, написал статью «The Joel Test: 12 Steps to Better Code», в которой изложил по пунктам критерии нормального процесса разработки.
Давайте спросим себя, как отреагировала индустрия на статью Джоэля Спольски?
Индустрия положила большой болт на статью Джоэла.
Вы приходите в новый проект, там нет багтрекера.
«У вас нет багтрекера, да как же так? — А нет и нет, нам все равно, мы такие.».
Все, полная автономность. Я сейчас позволю себе немного творчески пересказать идеи Джоэла, но с точки зрения реальности.
Может не очень хорошо видно, но это классический комикс про качели. Про то, как разные стороны понимают проект, как они его видят. Понятно, что видение у всех различное. Это видение нужно синхронизировать, и чтобы с этим справится, вам придется затрачивать усилия, время, спорить, писать письма грамотно, может быть даже собирать совещания и выбивать себе командировки, т.е. за это надо как-то бороться.
Есть хороший метод, как решить эту проблему. Нужно использовать Wiki.
Вики используется личным примером, в него пишутся тексты, просите коллег писать,… есть успешные примеры, когда вики успешно запускается, и успешно развивается.
И в итоге, получаются спецификации, практически в том виде, в том формате, про который писал Джоел, у него есть несколько статей, о том, как писать спецификации.
«Wiki должен победить» — кого он должен победить? Обычно, он должен победить Sharepoint. Это такое большое хранилище документов, в него менеджеры иногда кладут вордовый документ. Кладут вордовый документ, потом его пробуют прочитать. Говорят «что-то ничего непонятно вообще, ерунда какая-то». Менеджер говорит — «ОК, ребята, я понял, действительно ничего не понятно, много вопросов, я перепишу».
Через неделю, коммитит новую версию — ну исправлено что-то в двух местах, по мелочи. Легче не становится. Sharepoint для совместной работы — я не видел, чтобы он когда-нибудь работал. Вики в принципе работает. Бывает тяжело, но работает.
Стас Фомин: Возможно, вас заинтересуют успешные кейсы использования вики-систем:
Из зала — а у нас обратный пример. Вики умер, а шарепоинт победил.
Это удивительно.
Вики оказался неудобен тем, что там крайне неудобно редактировать.
Вы справились, вы молодцы, но вот реальный программист… А если линуксоид? Он даже толком не подконнектится, он скачать документ еще сможет, а отредактировать уже нет.
Вики гораздо проще в редактировании документов!
Этот слайд обусловлен глубокими личными переживаниями. Что будет, если вы будете исправлять баги?
Во-первых, вы получите уважение коллег[1]! «Яша исправляет баги…, подумаешь… » — угу, не очень полезная деятельность.
Во-вторых, вас могут легко уволить! Вот вы, пишите какую-то компоненту, и написали ее без багов. Все, она работает, вас можно уволить. Так бывает, я знаю.
Третий момент — вы приходите на интервью, вас спрашивают, «что вы сделали? — я исправлял баги… — а делали то что?». Вот и все. Иди нафиг, нам нужны люди, которые без багов пишут.
Вы может и не свои баги исправляли, но вот на интервью бывает грустно.
Зачем же все-таки исправлять? Дело в том, что когда вы исправляете баги, вы все-таки делаете свое приложение лучше. И иногда эффект бывает неожиданным. Вы получаете больше, чем ожидаете.
Вот например, у вас был процесс сборки, который занимал полчаса, и при этом требовал каких-то действий руками генерального директора. А вы взяли, и написали автоматический скрипт. И получилось, что вы можете быстрее разработать программное обеспечение, и вам стало качественно лучше жить.
Другой момент — иногда реально баги нужно править. Реальный пример — приходит ко мне начальник, и говорит «через две недели релиз, а у нас одни баги… релиз все-таки, надо бы поправить…». Ну ничего, переписал потихонечку, за две недели.
Третий момент — вот смотрите, есть айфон. В принципе, Nokia, HTC, Microsoft могут сделать девайс, который будет конкурентным по любым параметрам. Цену могут занизить, дисплей поставить, не хуже, по крайней мере, процессор большой поставить, акселерометр, совершенно не проблема. Что они не могут сделать? Они не могут сделать платформу, которая не будет глючить. Т.е. сделать без багов, это очень тяжело. Это реально становится конкурентным преимуществом.
Когда бьются две поисковые системы, на простейших вопросах они совершенно одинаковые, однако выясняется, что на каких-то запросах одна система работает лучше, чем другая. И постепенно, все пользователи переходят на ту поисковую систему, на которых багов меньше. Т.е. на конкурентном рынке очень важно, чтобы исправлять баги.
А написать приложение с багами, может любой студент, это не фокус.
Этот следующий слайд, он про то, чтобы у вас был процесс разработки программного обеспечения. Т.е. вы должны понимать, как выпускать релизы.
Допустим такую ситуацию — вы выпускаете релизы раз в год. Что это означает? Это означает, что те люди, которые выпускали прошлый релиз, покинули компанию.
И вы начинаете выпускать релиз. Вы не понимаете, как это делать. Вы это делаете впервые. Естественно, у вас получается плохо. Поэтому релиз вы выпускаете не раз в год, а раз в два.
Стас Фомин: Если вы не верите в такие долгие циклы релизов, см. видеорассказ о трехлетнем цикле выпуска продуктов.
Один год вы что-то разрабатываете, а потом еще год допиливаете, чтобы как-то выпустить.
Иногда это кончается сверху, и вы не выпускаете релиз вообще.
Это мы поговорили об общей какой-то инфраструктуре, но если вы хотите работать эффективно, вам нужны какие-то теоретические знания. Я бы хотел посоветовать почитать вам пару книг, первая из них это рефакторинг Мартина Фаулера, которая изменила мою жизнь — я сильно прибавил в кодировании после ее прочтения.
Но сейчас я хочу остановится на ее названии, вернее подзаголовке — «улучшение существующего кода». В чем ведь революционная идея рефакторинга? В том, что теперь мы код не выбрасываем, мы его улучшаем.
Теперь мы не говорим о том, что мы сейчас придем и напишем вторую версию кода заново, и она будет более правильная, мы берем существующую версию и начинаем ее дорабатывать. И постепенно дорабатывая, мы получаем более хороший результат.
И теперь, программное обеспечение делается именно так. Никто не делает сразу идеальный продукт, который потом никто не трогает. Все теперь сначала делают первую версию, потом смотрят на реакцию пользователей и дорабатывают.
Т.е. теперь программное обеспечение не столько разрабатывается, сколько улучшается существующее. И начальная разработка, она может длится год. А доработка может длится пять, десять лет, в зависимости от того, насколько ваш продукт успешен. Чем более продукт успешен, тем дольше длится доработка.
Другая книга — «Effective Java», рекомендуется читать второе издание, оно просто по Java 5, более актуальное, по-моему есть оно только на английском.
Джошуа Блох часто выступает, можно смотреть его презентации, видео, слайды, … не обязательно покупать его книжку на Амазоне.
Более актуальная — «Паттерны», есть знаменитая книжка «банды четырех» про паттерны проектирования, но она плохо переведена, и ее применение на практике часто оборачивается, скажем так, не очень желательными результатами, а здесь это все более понятно, и достаточно много мозгов в эту книгу вложено.
Еще один момент в том, что современное программное обеспечение базируется на уже готовых программных компонентах, на чем-то, что уже разработали другие люди. Это сильно сокращает сроки, повышает качество, и в принципе тенденция понятная и правильная.
Есть один минус. Если человек — идиот, то никакие библиотеки ему не помогут. Вот хочет человек использовать SOAP, и ему наплевать, что из-за этого у него получается время реакции на минуту больше, и памяти жрется в три раза больше. Ему просто наплевать, вот хочется и он использует, ему все равно. И если этот проект начинали не вы, то часто приходится с вместе с этим делом … вот у меня был случай, система для проведения опросов через интернет. У нее внутри было Tamino XML Database. Все было очень хорошо, я давно работал с XMLем, но у него была одна проблема — он не мог сделать больше десяти insert-ов в секунду. Как вы понимаете, десять инсертов в секунду это очень мало. Мы никак не можем с этим справиться, мы должны использовать что-то другое, хоть ORACLE можно, он умеет делать, хоть сто в секунду. Не проблема совершенно, вот перейдем на оракл и не будет у нас никаких проблем. Но начальство говорило, «Tamino — это наш ребенок, мы его сами сюда вот вкорячили, и мы его вот так просто не отдадим». А десять инсертов в секунду — это мнээ, никак… Ну меня уволили, потом там все заменили, но — частично…
XSLT
Положительный пример — это XSLT. Позволяет отделять данные от представления. Например, если вы делаете SaaS-сервис, т.е. у вас есть один большой сервер и много клиентов, которые запускают на вашем сервере свои приложения. Вы хотите их кастомизировать, под каждого конкретного клиента. XSLT дает вам такую возможность.
У нас был пример, мы писали SaaS-сервис, тогда он назывался не SaaS-, а Application Service Provider. И клиентская часть была сделана через XSLT, а админская — нет. И клиент переодически спрашивал нас — «А можно админскую часть на XSLT сделать, как клиентскую?». Мы говорили — «ну вот, надо переписать на XSLT». «Переписать — это что-то дороговато.» А потом, через некоторое время снова спрашивал…
Да, кастомизация через XSLT она очень удобна и помогает сильно, работает именно когда вам нужно кастомизировать под разных клиентов.
JSON. Допустим у вас есть два сервера. JSON очень хороший формат, чтобы обмениваться информацией между ними. JSON лучше, чем XML. Он более компактный, он более стандартизированный, у него нет дилеммы атрибут сделать или тег. И в то же время он по-прежнему человекочитаемый, и очень легко обрабатывается программой. И в него можно добавлять произвольные новые данные. Очень рекомендую, по-крайней мере обращать на него внимание и знать, что это такое.
Асинхронная обработка задач
Еще один такой, большой enterprise pattern, это асинхронная обработка задач. Когда он применим?
Допустим, что у вас есть сервер. И на него сыпется большое количество задач. Наивный подход — синхронный, когда вы каждую задачу стремитесь немедленно обработать. В реальной жизни у вас могут случится две неприятности:
Асинхронная обработка задач — это когда вы сначала задачу записываете, а обрабатываете ее потом. И тогда вы можете попытаться ее обработать один раз, потом второй раз, если есть какие-нибудь ошибки, вы можете обрабатывать их постепенно, если их приходит слишком много, вы получаете практически полный контроль.
Я применял это решение начиная с «Яндекс.Денег», под руководством Фила Дельгядо, и практически во всех остальных проектах очень это сильно облегчает жизнь, есть подробная очень статья, отсылаю вас к ней:
www.telamon.ru/articles/async.html
У Джоэла есть еще одна статья, про то, что программное обеспечение разрабатывается десять лет. Хорошее. У Джоэла на примере Excel-а, у меня есть свои примеры.
Я бы хотел поговорить о Sphinxe, вот в зале тут присутствует Андрей Аксенов, я тут на разогреве, он будет выступать после меня, редкая возможность на него посмотреть. У меня тоже много личного в этом слове. Я просто десять лет назад делал поисковую систему для российских музеев. Я изобрел велосипед. Я делал все на базе SQL сделал свой инвертированный индекс. А полноценный полнотекстовый поиск не делал, это «и не в рамках бюджета и вообще не требуется».
В это время начинался Lucene, в это время начинался Sphinx. Т.е. я не заметил, что есть ниша для кастомных поисковых движков. Я не заметил, что существует Lucene, и продолжал, как бы страдать ерундой на работе. А мог бы тогда присоединится к Lucene, и может быть, если бы я тогда к нему присоединился, он бы получше конкурировал с Sphinx. Но не судьба.
Другой пример был вчера, ОС Фантом. Дмитрий Завалишин только начал его делать, а думал над тем, как его делать точно больше десяти лет. И поэтому, я хочу вам сказать, что если у вас есть какая-то идея, поймите, что… JUnit, который за ночь написали, это мелочи… если вы хотите сделать серьезное программное обеспечение, которым будут пользоваться люди, будьте готовы к тому, что вы будете разрабатывать его долго. Может быть не десять лет, но год на первую версию у вас может легко уйти, будьте к этому готовы.
Нельзя разработать хороший софт без труда.
Теперь уже такие более общие вопросы, рекомендации. Понимаете, есть такой конфликт, когда вы работаете программистом.
Допустим, вы хотите разработать хорошее программное обеспечение, чтобы оно было популярным, чтобы оно очень много и без проблем работало. Вам на это нужно полгода-год, ну какой-то пусть существенный промежуток времени.
Но в то же время, у вас есть начальник, не заказчик, он может, и он вам ставит краткосрочные цели. И очень часто, эти краткосрочные цели входят в конфликт, с конечным, долгосрочным результатом.
Заказчик очень хочет посмотреть по часам конкретно чем мы занимались. Или у него есть какие-то сиюминутные хотелки, что сейчас вот обязательно сделайте вот так и по быстрому. Или он просто хочет с вами поговорить и поэтому созывает бессмысленный митинг, на котором вы вообще ничего совсем не понимаете, о чем он говорит.
Мой вам совет — старайтесь поменьше заниматься ерундой. Это деморализует, и в итоге получается плохой результат.
Свежий пример из моей практики. Заказчик, более-менее внезапно, сказал что он больше не хочет автокоммитов, при каждом запросе, а он хочет все, ну просто все транзакцией. Я подумал чуть-чуть и сказал, что если он настаивает на автокоммитах, то давайте контракт разорвем сейчас, ибо что-то мне не нравится идея. Заказчик подумал, и сказал: «Да, Яша, ты продал мне автокоммиты».
Т.е. поймите: не заниматься ерундой — это рискованная позиция.
Как только вы начинаете перечить руководству, сразу над вами нависает риск увольнения. Но иногда получается, если вы можете что-то объяснить, то руководство часть соглашается. Дали приказ, а потом увидели, что вы недовольны — «а, ну мы и не настаиваем».
Т.е. в принципе — говорить, — иногда помогает. Иногда нет.
Тут еще один такой печальный момент. Если вы много разрабатываете, пишете, часто делаете релизы, то рано или поздно вы ошибетесь.
Если вы делаете релиз раз в год, вы ошибетесь один раз в год. Но конкретно. А если вы делаете релиз раз в неделю — пять релизов нормально, десять релизов нормально, а на двадцатом — опа, и ошиблись. Конечно, о вас скажут все, что о вас думают. «Как вы могли! Такой ответственный проект!…»
На самом деле — без ошибок не бывает. И смиритесь с тем, что за ошибки вас будут ругать, ну в известных пределах конечно смиритесь.
Если вы вообще код без багов писать не умеете, и у вас каждый первый релиз падает, то надо конечно качество повысить, или другим каким делом заняться, но иногда ошибки бывают у всех. Простым людям следуюет с этим смирится.
Есть еще параллельный процесс, что ваше программное обеспечение пытаются кому-то продать. И часто ситуация бывает такая — «Мы это уже продали, больше ничего не трогайте». А продали… да там пользователь может данные потерять, если ничего не трогать. И продажи очень часто давят.
Совсем плохой случай, когда продажники что-то пообещали какому-то крупному клиенту, за какие-то большие деньги, а вас поставили перед фактом — вот «мы это уже продали». Пожалуйста, срочно сделай!
И из-за этого, буквально вся система утыкивается костылями. Я буквально видел такую ситуацию, когда полсистемы обслуживает одних клиентов, а другая половина обслуживает только одного клиента. Практически полный копипаст! Т.е. реально, прогибаясь под одного клиента, вы превращаете свой код в руины просто. Снижаете скорость его разработки на порядок.
И поймите — если вы хотите сто новых клиентов, то вы не должны концентрироваться на одном клиенте. Нам нужно именно смотреть в будущее, стремится разрабатывать быстрее, и не пытаться подстроится под одного конкретного клиента. Учитывать его мнение — да, конечно. Но не жертвовать всей разработкой.
Проблемы о которых не любят говорить на интервью, но с которыми приходится сталкиваться.
- Как успешно разрабатывать программное обеспечение вопреки трудностям?
- Понравится ли это начальству?
- Что за это будет?
- Как жить дальше?
Для обладателей толстых каналов, которые не любят читать — можно предложить видеозапись доклада:
Любите слушать аудио в машине — скачайте и слушайте.
Полистать и скачать презентацию доклада можно здесь.
Подготовил материалы выступления Стас Фомин
Введение
Сейчас я сделаю небольшой доклад, но сначала несколько слов о себе. Не то, чтобы я отличался особым умом и сообразительностью, но больше десяти лет разрабатывал программное обеспечение, и все время сильно переживал, что получается в результате.
Я десять лет делал jug.ru, у меня есть ЖЖ, и я люблю выступать на конференциях.
На минном поле нет героев
Теперь, мы поговорим, как мне представляется наша индустрия в целом. Есть много программ, у которых есть очень-очень-очень много разных функций. А потом, когда начинается внедрение, заказчика проводят, как по минному полю — а вдруг, что-нибудь да внедрится? Аналогичная схема с минным полем действует и для многих наших аутсорсеров. Т.е. сначала берется как можно больше клиентов, под этих клиентов набирается как можно больше штат, за этот большой штат капает небольшая денежка, а когда деньги заканчиваются, все программисты увольняются, «подрываются».
Нет смысла без своих мозгов
Знаете, даже если вы разрабатываете под IPhone, теоретически вы сможете стать миллионерами. Но статистически вы оказываетесь глубоко в минусе. Была небольшая обзорная статья, которая была посвящена статистике продаж на AppStore, и так получилось, да, что есть очень успешные программы с большими доходами, но большинство получает совершенно смешные суммы.
И я не претендую, чтобы рассказать вам в своем докладе, как делать успешное программное обеспечение. Почему я не претендую на это? Я глубоко убежден, что нельзя сделать успешный софт, если у вас нет собственных мозгов. А собственный мозг я вам не дам. Это технически невозможно. Но на что я надеюсь? Я надеюсь на то, что я затрону некоторые вопросы, над которыми вам будет полезно подумать. Может это вам понравится.
Как стать героем
Мне бы хотелось услышать ожидания аудитории. Какие у вас есть герои, которых вы бы хотели рассматривать как потенциальные примеры для подражания? Есть какие-нибудь версии?
Шум в зале… «Линус Торвальдс», «Сергей Брин», …
Ну на самом деле, должен вас разочаровать (см. слайд). А учится можно у меня, по тому, на что я сам напоролся. Моя ролевая модель — Дон-Кихот, который упорно пытается донести свет истины до начальства. Ну и для всех остальных.
Пытается рассказывать правильные вещи, делать правильные вещи, ну как-то двигаться в общем, вперед. Бывает очень-очень больно и обидно. Не советую.
Капитан Очевидность несколько полегче. Некоторые думают, что это неинтересно, но практика показывает, что всегда находятся желающие поспорить.
Опасные вопросы
Зачем?
А теперь перейдем к вопросу главному — зачем становится героем? Вот смотрите — зарплаты в России, они небольшие очень. Программисты обычно получает вдвое больше, чем в среднем по стране. Если программист обладает какими-то дополнительными качествами, то он получает еще в двое больше, чем средний программист. А качества могут быть разные — знания Java, умение хорошо вести себя на интервью, хороший английский… буквально за что угодно.
И смотрите, как может получится — вот вы пришли на работу, хотите разрабатывать разумное доброе вечное. А ваш начальник хочет смотреть футбол. Кто победит?
Шум и волнения в зале…
Больной вопрос…
Какие задачи вы поручите Бобруйскому филиалу?
Другой вопрос связан с нашей территориальной распределенностью, удаленностью от многих наших заказчиков. Вот представьте себе, что у вашей компании есть филиал в Бобруйске. Поручите ли вы этому филиалу задачу, за которую вам дадут медаль?
Подумайте сами, зачем вам давать задачу в Бобруйск, если вы ее сделаете сами и вам за нее дадут медаль. Вы ее не отдадите. Кроме одного случая — эту задачу невозможно сделать.
Шум в зале → В бобруйске ее за меньшие деньги сделают!
Бобруйск получит свои меньшие деньги. Медаль он не получит. Медаль это больше, чем маленькие деньги.
Шум в зале → Медаль получим мы! А он — меньшие деньги. А большие деньги получат те, кто поручили Бобруйску.
В общем — Бобруйск медали не получит.
Так вот, извините, когда вы из Сан-Франциско смотрите, то там все равно — Бобруйск или Санкт-Петербург.
Кто будет первым пользователем?
Кроме глобальной такой древнерусской тоски, есть еще вопросы, которые помогают выяснить, что вообще происходит, и вообще, насколько большие разрушения у вас в проекте.
Хочу сразу предупредить, эти вопросы нужно задавать очень осторожно, потому что если вы их будете задавать очень часто, вы прослывете некоммуникабельными людьми, асоциальными типами.
Кто будет первым пользователем?
Use-case простой: вы делаете прототип для министра. Я вам по секрету скажу — министр, как бы вот он, вот он сидит, а вот (показывает на стол в 5 метрах) компьютер. И министр вот так вот смотрит с трех метров. Ему глубоко все равно, там работающий код, или презентация в пауэрпоинте.
Поэтому, если ваша цель прототип министру разработать, то особо программировать и вообще ничего не нужно, вы так, для вида, для галочки.
Кто виноват
Другой вопрос — кто виноват? Представьте, что вот вы — делаете систему. И выпустили ничего. Вот год работали, а релиза — нет. Ничего не случилось. Сплошные баги. Кого накажут?
Очень часто, анализ показывает, что не накажут никого. Потому что, тот человек, который по идее главный за этот проект, он еще по совместительству и владелец компании, и у него еще десять других более интересных и нужных проектов. Т.е. его не накажут, а вас — уволят. Вот и все. Ну и соответственно вину на вас легко переложат, это легко.
Значит накажут исполнителя …
Ну как можно наказать? — можно уволить — ну значит уволят. Еще могут поругать — поругать могут, относитесь к этому спокойно.
Вы понимаeте, что очень тяжело сделать проект, если в его успехе заинтересованы только вы, но не тот человек, который выделяет на него ресурсы.
Этот вопрос — хороший, потому что если окажется, что кто-то действительно виноват, то вы сможете от этого человека получить поддержку. Если с вами работает менеджер, которого снимут, в случае провала проекта, вы сможете ему объяснить, что «есть угроза», и он вам поможет.
Т.е. вопрос скорее звучит «кто виноват кроме меня»?
Это вопрос несколько в будущем — «кто будет виноват в крахе?»
Когда дедлайн?
Вопрос менее критичный. Если вы Blizzard, вам наверное все равно, вы и так опережаете рынок на много лет.
Но если вы делаете коммерческий софт, и вдруг внезапно оказывается, что неважно, когда вы его сделаете, это значит, что кто-то просто забыл посчитать, насколько ваша деятельность экономически выгодна.
Когда у вас дедлайн сколь угодно далеко, то проект может съесть сколь угодно много денег. Это значит, он может оказаться сколь угодно экономически бессмысленным.
Так что если дедлайна нет, то тоже есть повод задуматься.
Create a Product Definition Statement
Теперь таки поговорим о том, как все-таки сделать успешный проект. Позволю себе процитировать заголовок из руководства для разработчиков айфона. «Формулируйте что вы делаете, для кого вы делаете и что именно».
Это очень сильно облегчает жизнь. Руководство, кстати, рекомендую почитать в оригинале, его неглупые люди писали и достаточно неплохо у них получилось.
Что делать?
Когда у вас есть определение того, что вы сделали, это помогает вам не тратить время на пустые обсуждения. Например, мы делали проект для Министерства экономического развития Российской Федерации. И нам нужно было построить модель экономического развития регионов по 17 параметрам. Параметры совершенно от балды, мы в них ничего не понимали. Неясно было совершенно, что делать. Я предложил простую модель — «мы будем суммировать эти параметры с произвольными коэффициентами». Это абсолютно понятная модель, которую мы назвали «СуперСумматор».
Дали возможность пользователям менять коэффициенты, и смотреть при этом, какой регион, при каких коэффициентах выходит в топ. Мы ни минуты не спорили о том, что мы делаем. Мы это сразу понимали. Мы выпустили продукт с идеальным качеством.
По функциональности были небольшие замечания, но они никого не волновали.
Сопротивление бесполезно
Чем еще полезно иметь цель? Вы можете преодолевать сопротивление!
Еще один случай из моей практики — мне достался менеджер, который в принципе не хотел работать. У него были какие-то другие интересы в жизни. Запускать какие-то задачи в разработку ему не хотелось, и все, он их практически не запускал. Но, он один раз ушел в отпуск, а наверху произошла небольшая рокировка, мне достался верхний, совсем высокоуровневый менеджер, который мне поставил достаточно четкоопределенную задачу. Я эту задачу сделал, начиная от согласования спецификаций, и кончая поддержкой пользователей, несмотря на то, что менеджер был по прежнему против того, чтобы это делать.
Был против того чтобы ездить согласовывать требования, был против того, чтобы запускать разработку, был против того, чтобы внедрять. Но так как была четкая цель, все равно все получилось.
The Joel Test: 12 Steps to Better Code
Давайте поговорим о процессах. Был такой, вернее есть такой человек, Joel Spolsky, который сделал для нас stackoverflow.com.
И он десять лет назад, написал статью «The Joel Test: 12 Steps to Better Code», в которой изложил по пунктам критерии нормального процесса разработки.
Давайте спросим себя, как отреагировала индустрия на статью Джоэля Спольски?
Индустрия положила большой болт на статью Джоэла.
Вы приходите в новый проект, там нет багтрекера.
«У вас нет багтрекера, да как же так? — А нет и нет, нам все равно, мы такие.».
Все, полная автономность. Я сейчас позволю себе немного творчески пересказать идеи Джоэла, но с точки зрения реальности.
Процесс
Может не очень хорошо видно, но это классический комикс про качели. Про то, как разные стороны понимают проект, как они его видят. Понятно, что видение у всех различное. Это видение нужно синхронизировать, и чтобы с этим справится, вам придется затрачивать усилия, время, спорить, писать письма грамотно, может быть даже собирать совещания и выбивать себе командировки, т.е. за это надо как-то бороться.
Wiki должен победить
Есть хороший метод, как решить эту проблему. Нужно использовать Wiki.
Вики используется личным примером, в него пишутся тексты, просите коллег писать,… есть успешные примеры, когда вики успешно запускается, и успешно развивается.
И в итоге, получаются спецификации, практически в том виде, в том формате, про который писал Джоел, у него есть несколько статей, о том, как писать спецификации.
«Wiki должен победить» — кого он должен победить? Обычно, он должен победить Sharepoint. Это такое большое хранилище документов, в него менеджеры иногда кладут вордовый документ. Кладут вордовый документ, потом его пробуют прочитать. Говорят «что-то ничего непонятно вообще, ерунда какая-то». Менеджер говорит — «ОК, ребята, я понял, действительно ничего не понятно, много вопросов, я перепишу».
Через неделю, коммитит новую версию — ну исправлено что-то в двух местах, по мелочи. Легче не становится. Sharepoint для совместной работы — я не видел, чтобы он когда-нибудь работал. Вики в принципе работает. Бывает тяжело, но работает.
Стас Фомин: Возможно, вас заинтересуют успешные кейсы использования вики-систем:
Из зала — а у нас обратный пример. Вики умер, а шарепоинт победил.
Это удивительно.
Вики оказался неудобен тем, что там крайне неудобно редактировать.
Вы справились, вы молодцы, но вот реальный программист… А если линуксоид? Он даже толком не подконнектится, он скачать документ еще сможет, а отредактировать уже нет.
Вики гораздо проще в редактировании документов!
Исправляйте баги
Этот слайд обусловлен глубокими личными переживаниями. Что будет, если вы будете исправлять баги?
Во-первых, вы получите уважение коллег[1]! «Яша исправляет баги…, подумаешь… » — угу, не очень полезная деятельность.
Во-вторых, вас могут легко уволить! Вот вы, пишите какую-то компоненту, и написали ее без багов. Все, она работает, вас можно уволить. Так бывает, я знаю.
Третий момент — вы приходите на интервью, вас спрашивают, «что вы сделали? — я исправлял баги… — а делали то что?». Вот и все. Иди нафиг, нам нужны люди, которые без багов пишут.
Вы может и не свои баги исправляли, но вот на интервью бывает грустно.
Зачем же все-таки исправлять? Дело в том, что когда вы исправляете баги, вы все-таки делаете свое приложение лучше. И иногда эффект бывает неожиданным. Вы получаете больше, чем ожидаете.
Вот например, у вас был процесс сборки, который занимал полчаса, и при этом требовал каких-то действий руками генерального директора. А вы взяли, и написали автоматический скрипт. И получилось, что вы можете быстрее разработать программное обеспечение, и вам стало качественно лучше жить.
Другой момент — иногда реально баги нужно править. Реальный пример — приходит ко мне начальник, и говорит «через две недели релиз, а у нас одни баги… релиз все-таки, надо бы поправить…». Ну ничего, переписал потихонечку, за две недели.
Третий момент — вот смотрите, есть айфон. В принципе, Nokia, HTC, Microsoft могут сделать девайс, который будет конкурентным по любым параметрам. Цену могут занизить, дисплей поставить, не хуже, по крайней мере, процессор большой поставить, акселерометр, совершенно не проблема. Что они не могут сделать? Они не могут сделать платформу, которая не будет глючить. Т.е. сделать без багов, это очень тяжело. Это реально становится конкурентным преимуществом.
Когда бьются две поисковые системы, на простейших вопросах они совершенно одинаковые, однако выясняется, что на каких-то запросах одна система работает лучше, чем другая. И постепенно, все пользователи переходят на ту поисковую систему, на которых багов меньше. Т.е. на конкурентном рынке очень важно, чтобы исправлять баги.
А написать приложение с багами, может любой студент, это не фокус.
Как быстро вы исправите опечатку?
Этот следующий слайд, он про то, чтобы у вас был процесс разработки программного обеспечения. Т.е. вы должны понимать, как выпускать релизы.
Допустим такую ситуацию — вы выпускаете релизы раз в год. Что это означает? Это означает, что те люди, которые выпускали прошлый релиз, покинули компанию.
И вы начинаете выпускать релиз. Вы не понимаете, как это делать. Вы это делаете впервые. Естественно, у вас получается плохо. Поэтому релиз вы выпускаете не раз в год, а раз в два.
Стас Фомин: Если вы не верите в такие долгие циклы релизов, см. видеорассказ о трехлетнем цикле выпуска продуктов.
Один год вы что-то разрабатываете, а потом еще год допиливаете, чтобы как-то выпустить.
Иногда это кончается сверху, и вы не выпускаете релиз вообще.
Теория
Это мы поговорили об общей какой-то инфраструктуре, но если вы хотите работать эффективно, вам нужны какие-то теоретические знания. Я бы хотел посоветовать почитать вам пару книг, первая из них это рефакторинг Мартина Фаулера, которая изменила мою жизнь — я сильно прибавил в кодировании после ее прочтения.
Но сейчас я хочу остановится на ее названии, вернее подзаголовке — «улучшение существующего кода». В чем ведь революционная идея рефакторинга? В том, что теперь мы код не выбрасываем, мы его улучшаем.
Теперь мы не говорим о том, что мы сейчас придем и напишем вторую версию кода заново, и она будет более правильная, мы берем существующую версию и начинаем ее дорабатывать. И постепенно дорабатывая, мы получаем более хороший результат.
И теперь, программное обеспечение делается именно так. Никто не делает сразу идеальный продукт, который потом никто не трогает. Все теперь сначала делают первую версию, потом смотрят на реакцию пользователей и дорабатывают.
Т.е. теперь программное обеспечение не столько разрабатывается, сколько улучшается существующее. И начальная разработка, она может длится год. А доработка может длится пять, десять лет, в зависимости от того, насколько ваш продукт успешен. Чем более продукт успешен, тем дольше длится доработка.
Другая книга — «Effective Java», рекомендуется читать второе издание, оно просто по Java 5, более актуальное, по-моему есть оно только на английском.
Джошуа Блох часто выступает, можно смотреть его презентации, видео, слайды, … не обязательно покупать его книжку на Амазоне.
Более актуальная — «Паттерны», есть знаменитая книжка «банды четырех» про паттерны проектирования, но она плохо переведена, и ее применение на практике часто оборачивается, скажем так, не очень желательными результатами, а здесь это все более понятно, и достаточно много мозгов в эту книгу вложено.
Кирпичики
Профанам не важно, какие библиотеки использовать
Еще один момент в том, что современное программное обеспечение базируется на уже готовых программных компонентах, на чем-то, что уже разработали другие люди. Это сильно сокращает сроки, повышает качество, и в принципе тенденция понятная и правильная.
Есть один минус. Если человек — идиот, то никакие библиотеки ему не помогут. Вот хочет человек использовать SOAP, и ему наплевать, что из-за этого у него получается время реакции на минуту больше, и памяти жрется в три раза больше. Ему просто наплевать, вот хочется и он использует, ему все равно. И если этот проект начинали не вы, то часто приходится с вместе с этим делом … вот у меня был случай, система для проведения опросов через интернет. У нее внутри было Tamino XML Database. Все было очень хорошо, я давно работал с XMLем, но у него была одна проблема — он не мог сделать больше десяти insert-ов в секунду. Как вы понимаете, десять инсертов в секунду это очень мало. Мы никак не можем с этим справиться, мы должны использовать что-то другое, хоть ORACLE можно, он умеет делать, хоть сто в секунду. Не проблема совершенно, вот перейдем на оракл и не будет у нас никаких проблем. Но начальство говорило, «Tamino — это наш ребенок, мы его сами сюда вот вкорячили, и мы его вот так просто не отдадим». А десять инсертов в секунду — это мнээ, никак… Ну меня уволили, потом там все заменили, но — частично…
XSLT
Положительный пример — это XSLT. Позволяет отделять данные от представления. Например, если вы делаете SaaS-сервис, т.е. у вас есть один большой сервер и много клиентов, которые запускают на вашем сервере свои приложения. Вы хотите их кастомизировать, под каждого конкретного клиента. XSLT дает вам такую возможность.
У нас был пример, мы писали SaaS-сервис, тогда он назывался не SaaS-, а Application Service Provider. И клиентская часть была сделана через XSLT, а админская — нет. И клиент переодически спрашивал нас — «А можно админскую часть на XSLT сделать, как клиентскую?». Мы говорили — «ну вот, надо переписать на XSLT». «Переписать — это что-то дороговато.» А потом, через некоторое время снова спрашивал…
Да, кастомизация через XSLT она очень удобна и помогает сильно, работает именно когда вам нужно кастомизировать под разных клиентов.
JSON
JSON. Допустим у вас есть два сервера. JSON очень хороший формат, чтобы обмениваться информацией между ними. JSON лучше, чем XML. Он более компактный, он более стандартизированный, у него нет дилеммы атрибут сделать или тег. И в то же время он по-прежнему человекочитаемый, и очень легко обрабатывается программой. И в него можно добавлять произвольные новые данные. Очень рекомендую, по-крайней мере обращать на него внимание и знать, что это такое.
Асинхронная обработка задач
Еще один такой, большой enterprise pattern, это асинхронная обработка задач. Когда он применим?
Допустим, что у вас есть сервер. И на него сыпется большое количество задач. Наивный подход — синхронный, когда вы каждую задачу стремитесь немедленно обработать. В реальной жизни у вас могут случится две неприятности:
- У вас будет очень-очень-очень много задач, которых вы не сможете обработать синхронно.
- Вам начали приходить задачи с ошибками. И у вас вообще, крыша едет.
Асинхронная обработка задач — это когда вы сначала задачу записываете, а обрабатываете ее потом. И тогда вы можете попытаться ее обработать один раз, потом второй раз, если есть какие-нибудь ошибки, вы можете обрабатывать их постепенно, если их приходит слишком много, вы получаете практически полный контроль.
Я применял это решение начиная с «Яндекс.Денег», под руководством Фила Дельгядо, и практически во всех остальных проектах очень это сильно облегчает жизнь, есть подробная очень статья, отсылаю вас к ней:
www.telamon.ru/articles/async.html
Не занимайтесь ерундой
У Джоэла есть еще одна статья, про то, что программное обеспечение разрабатывается десять лет. Хорошее. У Джоэла на примере Excel-а, у меня есть свои примеры.
Я бы хотел поговорить о Sphinxe, вот в зале тут присутствует Андрей Аксенов, я тут на разогреве, он будет выступать после меня, редкая возможность на него посмотреть. У меня тоже много личного в этом слове. Я просто десять лет назад делал поисковую систему для российских музеев. Я изобрел велосипед. Я делал все на базе SQL сделал свой инвертированный индекс. А полноценный полнотекстовый поиск не делал, это «и не в рамках бюджета и вообще не требуется».
В это время начинался Lucene, в это время начинался Sphinx. Т.е. я не заметил, что есть ниша для кастомных поисковых движков. Я не заметил, что существует Lucene, и продолжал, как бы страдать ерундой на работе. А мог бы тогда присоединится к Lucene, и может быть, если бы я тогда к нему присоединился, он бы получше конкурировал с Sphinx. Но не судьба.
Другой пример был вчера, ОС Фантом. Дмитрий Завалишин только начал его делать, а думал над тем, как его делать точно больше десяти лет. И поэтому, я хочу вам сказать, что если у вас есть какая-то идея, поймите, что… JUnit, который за ночь написали, это мелочи… если вы хотите сделать серьезное программное обеспечение, которым будут пользоваться люди, будьте готовы к тому, что вы будете разрабатывать его долго. Может быть не десять лет, но год на первую версию у вас может легко уйти, будьте к этому готовы.
Нельзя разработать хороший софт без труда.
Не занимайтесь ерундой
Теперь уже такие более общие вопросы, рекомендации. Понимаете, есть такой конфликт, когда вы работаете программистом.
Допустим, вы хотите разработать хорошее программное обеспечение, чтобы оно было популярным, чтобы оно очень много и без проблем работало. Вам на это нужно полгода-год, ну какой-то пусть существенный промежуток времени.
Но в то же время, у вас есть начальник, не заказчик, он может, и он вам ставит краткосрочные цели. И очень часто, эти краткосрочные цели входят в конфликт, с конечным, долгосрочным результатом.
Заказчик очень хочет посмотреть по часам конкретно чем мы занимались. Или у него есть какие-то сиюминутные хотелки, что сейчас вот обязательно сделайте вот так и по быстрому. Или он просто хочет с вами поговорить и поэтому созывает бессмысленный митинг, на котором вы вообще ничего совсем не понимаете, о чем он говорит.
Мой вам совет — старайтесь поменьше заниматься ерундой. Это деморализует, и в итоге получается плохой результат.
Свежий пример из моей практики. Заказчик, более-менее внезапно, сказал что он больше не хочет автокоммитов, при каждом запросе, а он хочет все, ну просто все транзакцией. Я подумал чуть-чуть и сказал, что если он настаивает на автокоммитах, то давайте контракт разорвем сейчас, ибо что-то мне не нравится идея. Заказчик подумал, и сказал: «Да, Яша, ты продал мне автокоммиты».
Т.е. поймите: не заниматься ерундой — это рискованная позиция.
Как только вы начинаете перечить руководству, сразу над вами нависает риск увольнения. Но иногда получается, если вы можете что-то объяснить, то руководство часть соглашается. Дали приказ, а потом увидели, что вы недовольны — «а, ну мы и не настаиваем».
Т.е. в принципе — говорить, — иногда помогает. Иногда нет.
Ошибки важнее продаж
Тут еще один такой печальный момент. Если вы много разрабатываете, пишете, часто делаете релизы, то рано или поздно вы ошибетесь.
Если вы делаете релиз раз в год, вы ошибетесь один раз в год. Но конкретно. А если вы делаете релиз раз в неделю — пять релизов нормально, десять релизов нормально, а на двадцатом — опа, и ошиблись. Конечно, о вас скажут все, что о вас думают. «Как вы могли! Такой ответственный проект!…»
На самом деле — без ошибок не бывает. И смиритесь с тем, что за ошибки вас будут ругать, ну в известных пределах конечно смиритесь.
Если вы вообще код без багов писать не умеете, и у вас каждый первый релиз падает, то надо конечно качество повысить, или другим каким делом заняться, но иногда ошибки бывают у всех. Простым людям следуюет с этим смирится.
Есть еще параллельный процесс, что ваше программное обеспечение пытаются кому-то продать. И часто ситуация бывает такая — «Мы это уже продали, больше ничего не трогайте». А продали… да там пользователь может данные потерять, если ничего не трогать. И продажи очень часто давят.
Совсем плохой случай, когда продажники что-то пообещали какому-то крупному клиенту, за какие-то большие деньги, а вас поставили перед фактом — вот «мы это уже продали». Пожалуйста, срочно сделай!
И из-за этого, буквально вся система утыкивается костылями. Я буквально видел такую ситуацию, когда полсистемы обслуживает одних клиентов, а другая половина обслуживает только одного клиента. Практически полный копипаст! Т.е. реально, прогибаясь под одного клиента, вы превращаете свой код в руины просто. Снижаете скорость его разработки на порядок.
И поймите — если вы хотите сто новых клиентов, то вы не должны концентрироваться на одном клиенте. Нам нужно именно смотреть в будущее, стремится разрабатывать быстрее, и не пытаться подстроится под одного конкретного клиента. Учитывать его мнение — да, конечно. Но не жертвовать всей разработкой.
