Расширение языка

30.06.2014 9 комментариев

Очередной айтишный пост, ибо как я сейчас активно разрабатываю новый продукт. Мысли, соответственно, крутятся именно вокруг девелопмента :)

Как я уже говорил, свои 10,000 часов программистом я уже отработал. В реальности эта цифра ближе уже к 20,000 часов: было время, когда я кодил по 10-12 часов ежедневно по нескольку месяцев.

Так вот, дам полезный совет тем, у кого эта цифра значительно меньше: вместо создания библиотек расширяйте язык. Благо .NET дает для этого отличный функционал в виде Extention Methods.

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

Особенно это касается багов: если в первые недели после написания либы ты легко и непринужденно их правишь, то через полгода ты вынужден будешь разбираться в своем коде, как в чужом — проверено не раз.

В отличие от «библиотечного» подхода расширение языка дробит изначально цельную библиотеку на отдельные простые функции, которые ты можешь удалять и добавлять по желанию. Миграция этих функций в другие проекты — обычная копипаста, без необходимости перекомпиливать проекты при изменении функционала.

Представим себе сферического коня в вакууме: нам понадобилась шифрация, допустим.

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

В случае с расширением языка у меня есть просто большой класс Extentions, в котором находятся описания Extention Methods. Я просто добавляю туда две функции Encrypt(this byte[], string password) и Decrypt(this byte[], string password). При этом в любом месте своего проекта я могу написать data.Encrypt(«password») или data.Decrypt(«password») без создания классов и подключения библиотек.

Более того, я не должен заботиться даже о том, что data может быть null — он передается моей функции в виде параметра, который можно всегда проверить. Если эти же функции нужны в другом проекте, я просто копипастой переношу именно их, можно даже среду разработки не открывать. Достаточно обычного менеджера файлов с функцией просмотра.

В итоге вместо тонны классов, их экземпляров и вызовов функций получается компактный и понятный код, в котором баги сведены к минимуму: каждый из Extention Methods достаточно просто и незатейлив.

По мере расширения языка ты все больше приближаешься к программированию в терминах предметной области, все меньше обращая внимание на второстепенные технические детали.

В общем, рекомендую :)

VN:F [1.9.20_1166]
Rating: 0.0/5 (0 votes cast)
Share

Продукт = интерфейс

29.06.2014 8 комментариев

Эта тема будет больше интересна программистам, но и к бизнесу она имеет непосредственное отношение, так как значительно облегчает и ускоряет его автоматизацию.

Если брать опыт в программировании, то я свои пресловутые 10,000 часов отработал еще лет 10 назад, так что советы давать имею право :)

Увлеченные программисты знают, как прикольно иногда бывает «занырнуть» в какую-нибудь мелкую задачу и сделать ее просто мега-круто. И ничего, что это займет несколько дней в ущерб срокам проекта :)

В принципе, я вообще-то не противник такого подхода: если что-то действительно хочется сделать, если ты действительно увлечен своей работой — да пожалуйста! Понятно, что при этом сроки проекта сильно увеличивать не стоит, но любой новый код или изучение чужого фреймворка в итоге где-то да пригождаются.

Тут, правда, стоит учесть один важный аспект, который должен направлять не только основной проект, но и твою «второстепенную» работу: продукт является интерфейсом. Никакой внутренний функционал ничего не стоит, если он не влияет позитивно на тот самый интерфейс. Еще хуже, когда дополнительная работа выливается в его усложнение, замедление или утяжеление.

Когда я говорю «интерфейс», я не имею в виду только конечного пользователя продукта. Разрабатывая библиотеку, в первую очередь стоит сделать ее использование максимально простым и удобным с помощью заглушек и лишь потом заниматься «внутренностями».

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

Купите себе планшет. Не электронный, а бумажный, под формат A4, пачку бумаги и механический карандаш с мягким грифелем (удобнее писать лежа, обычные ручки перестают писать в таком положении).

Возьмите себе за правило перед написанием любого мало-мальского «серьезного» кода на этом самом планшете набросать отнюдь не структуру кода, а интерфейсы. В случае с веб-мордой — пользовательские сценарии и грубый набросок внешнего вида, «поиграйтесь» с ним на бумаге. В случае с библиотекой — API и опять же «поиграйтесь» в вызовы, прорабатывая детально форматы запросов и ответов.

Вот серьезно: подобной работы там — максимум на полчаса-час, но экономит целые дни, а иногда и недели! Бумажку всегда можно просто почеркать и выкинуть, а вот в связном коде, особенно разделенном на отдельные библиотеки начинаются такие танцы с бубном…

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

Да и кода получается ощутимо меньше, кстати. Ты уже не работаешь с абстракцией под названием «библиотека» или «продукт», а видишь конкретную его реализацию. Соответственно, нет соблазна запихнуть туда функционал вне рамок спроектированного интерфейса. Иначе придется снова переписывать интерфейс, а это — лениво :)

При проектировании интерфейса не стоит использовать ничего, кроме бумаги. Тут ведь цель — не «сделать красиво», а просто дать себе возможность поиграться с продуктом до его реализации. Увлекшись каким-нибудь супер-модным редактором интерфейсов, тебе будет реально лениво переделывать или даже выкидывать свою работу. В итоге интерфейс получится тяжелее и неудобнее «бумажного», а лишнего кода будет написано больше — проверено.

В общем, планшет, пачка бумаги и механический карандаш — наше все :)

VN:F [1.9.20_1166]
Rating: 4.0/5 (1 vote cast)
Share

Талант и сила воли

28.06.2014 2 комментария

Обращали, наверное, внимание, что чаще всего таланты идут пачками? Если человек хорошо танцует, то и поет, и рисовать умеет. Ну и наоборот: бывают абсолютно бесталанные люди.

Если задуматься, то все это укладывается в схему 10,000 часов: если человек занимается чем-то достаточно долго, он становится в этом экспертом мирового уровня. Если же человек занимается всем по верхам, он ни в чем не будет хорош.

Не спорю, что есть врожденные таланты и склонности. Но, как мы видим (к сожалению!), любой талант без упорной работы останется нереализованным. Хотя и бывает так, что человеку что-то настолько нравится, что оно выполняется (по мнению окружающих) без особых усилий.

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

Тут хорошо было бы встать в позу: «Все лавры — людям с силой воли», но реальность все-таки чуть сложнее. Человек физически не сможет заставлять себя те самые 10,000 часов. Когда мы видим гения, он горит своей работой, живет ей. Это — не только сила воли, а все-таки что-то изнутри. Чрезмерная сила воли может даже навредить: ты заставишь себя заниматься чем-то не своим и убедишь себя в том, что это тебе нравится.

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

Но тут мы уже натыкаемся на конкуренцию: скорее всего, ты не одинок в своих желаниях. И опять сила воли выходит на первое место: если ты работаешь над чем-то не просто увлеченно, а активнее и больше других, ты и денег с этого имеешь гораздо больше.

Интересное наблюдение: новости делают упор именно на уме и таланте, мало кто упоминает упорство, везение или неудачи/провалы. Это создает ложную картинку того, что все обычно идет по плану, причем сила воли особо и не нужна. Она если и упоминается, то не в контексте конкретной геморройной работы, а в виде «принял волевое решение», как будто бы оно было реализовано само по себе :)

Резюмируя: ни талант, ни сила воли по отдельности ничего не решают. Идеальная ситуация — талантливый человек с силой воли. И если первое в тебе уже заложено, стоит только копнуть в себя, то со вторым — гораздо сложнее. Силу воли, дисциплину можно и нужно развивать. Каждая победа над собой делает немного повышает дисциплину, даже самая незначительная уступка — резко снижает ее.

VN:F [1.9.20_1166]
Rating: 5.0/5 (2 votes cast)
Share

Суть и процесс

27.06.2014

Когда мы только выбираем себе бизнес по душе, мы обращаем внимание на его суть и думаем, что именно этим мы и будем заниматься большую часть времени. В реальности, к сожалению (а иногда и к счастью), мы тратим время на самые разные задачи, имеющие к сути лишь косвенное отношение.

Я уже упомянул про Пейпал: вроде как суть — денежные переводы. Ну а в реальности компания тратит большую часть времени и ресурсов на борьбу с фродом, разработку, администрирование и маркетинг.

Вообще, когда начинаешь исследовать работу известных компаний более глубоко, они уже не выглядят столь однозначно. Часто оказывается, что айтишная на поверхности компания оказывается сугубо маркетинговой, как тот же Алавар. Или торговая — аналитической, как тот же Амазон.

Причем, что интересно, развитие компании определяется именно этими процессами, а не ее «сутью». Амазон не был бы Амазоном без восхитительного внимания к аналитике и мелочам.

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

Я это к тому говорю, что выбор направления бизнеса, по большому счету, вторичен: главное — чем ты будешь в нем заниматься, на что тратить большую часть своего времени. Хороший способ узнать это авансом — посмотреть на себя сегодняшнего. Мы вообще редко меняемся :)

Ну и выбирать себе бизнес, соответственно, где не сколько суть, сколько основные задачи подходили бы под твои увлечения и навыки, где твое хобби или опыт могли бы дать конкурентное преимущество. Причем под словом «опыт» я не имею в виду профессионализм: какие-то отдельные, вырванные из контекста навыки могут «стрельнуть» совершенно случайно, как у Стива Джобса с его мимолетным увлечением типографикой в университете.

Мой совет — всего лишь смягчение «фильтров» отсева проектов и продуктов: на поверку может оказаться, что большая часть времени будет тратиться отнюдь не на них, а на более интересные и «вкусные» задачи. Но это не отменяет моих советов о том, что стоит тщательно выбирать себе клиентскую базу: тебе с ними придется ежедневно общаться и плохо, если у вас не будет ничего общего.

VN:F [1.9.20_1166]
Rating: 5.0/5 (2 votes cast)
Share

Работа на результат

26.06.2014

Казалось бы, правильный подход: всегда «работать на результат»?

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

Бегите от тех, кто работает чисто ради денег, обычно это превращается в «скользкие» темы вроде МЛМ, «работа из дома без вложений», «канадскую оптовую компанию», инфобизнесовое лоховодство или даже откровенное мошенничество.

Работа ради конкретной цели, будь то какой-то проект, деньги, успех или слава выливается в непрерывный поиск себя до тех пор, пока ты все-таки не наткнешься на то, что тебя действительно увлечет. Если же ты не нашел себя, ты гарантированно будешь либо «троечником», либо откровенным лузером.

Прыгать с темы на тему, искать «кремлевскую таблетку», тоннами поглощать книги, курсы и семинары по бизнесу, самосовершенствованию, маркетингу. В общем, идеальный клиент лоховодов от инфобизнеса.

Мне кажется, основная причина успеха бизнеса увлеченного человека — в эффективной и продолжительной инвестиции времени и усилий в какое-то конкретное занятие. Правило 10,000 часов. Если же тебя не тянет к чему-либо, ты будешь либо откладывать реальную работу в долгий ящик, либо подсознательно «сачковать», создавая иллюзию активной работы.

Обычно это выглядит как активное просирание времени на мелкие, абсолютно бесполезные задачи, в том числе и чтение, исследование «в стол», улучшение своего рабочего места, покупка и изучение инструментов без реального их использования.

Я все это говорю не как критику силы воли: она все равно понадобится, даже в самом интересном и увлекательном деле по-любому будут сложные и геморройные задачи. Другое дело, что объем этих задач по факту будет незначительным, как в правиле Парето 80/20. Причем в тех самых 20% геморроя даже самый увлеченный человек будет пытаться откладывать, «сачковать» и вообще всячески саботировать свою же работу.

Стоит посмотреть со стороны на то, что ты сейчас делаешь: если тебе сложно заставить себя работать 80% времени — пора что-то менять в консерватории. В своем бизнесе стоит искать именно те процессы, которыми ты будешь по-настоящему увлекаться: именно там ты сможешь получить неиллюзорное конкурентное преимущество, даже если они тебе и покажутся мелкими и несущественными со старта.

Немного конкретики: мне, допустим, с детства нравится программирование. Я готов сидеть часами над кодом, особенно где это касается работы с данными, их сбора и обработки. Интерфейсы не люблю. Поэтому базы «появились сами собой»: просто в одном геморройном для меня бизнесе я нашел увлекший меня процесс. Сам бизнес был — маркетинговые исследования, с первого же заказчика я увлекся автоматизацией этого процесса. Причем увлекся там, где можно было вполне обойтись и без автоматизации. Результат налицо, в общем.

Если бы я пытался именно «сделать бизнес маркетинговых исследований», ничего бы путного не вышло. Я бы не смог работать по 12-16 часов (не утрирую!) в течение 5+ лет над одной и той же задачей, раз за разом переписывая и полируя продукты. Первые версии которых, кстати, были ужасно убогими, именно продолжительная работа сделала их коммерчески успешными.

Ищите себя не читая книги, а экспериментируя. Лучший способ создать что-то хорошее — создать и попытаться продать какой-нибудь шлак.

Причем даже там, где ты уверенно идешь к «идеальному бизнесу», ты (если не обладаешь железной силой воли, которая в этом случае будет только во вред) все равно сконцентрируешься на каких-то его деталях, что и даст в итоге лично твое дело.

VN:F [1.9.20_1166]
Rating: 5.0/5 (3 votes cast)
Share