Индустрию спасут массовые расстрелы

Из ленты: OpenQuality.ru | Качество программного обеспечения | Опыт экспертов

За плечами системного архитектора Максима Крентовского десятки завершенных проектов, опыт создания приложений различной тематики и сложности. Ночные кошмары и риски, спагетти-код и баги-кровопийцы, “время-качество-деньги” и взаимодействие с заказчиком, идеальный код и программистский коммунизм, “тяп-ляпы” и “кризис перепроектирования” – вот далеко не полный перечень вопросов, затронутых в беседе.

Максим, сможете ли вы выделить факторы, которые влияют на успех/провал разработки и внедрения любого продукта (вне зависимости от его предметной области)?

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

Помимо рисков огромное влияние оказывает мотивация участников процесса. В случае отдельной незаинтересованности (неважно с чьей стороны – заказчика или исполнителя) велика вероятность краха проекта.

Каким образом методология работы позволяет учитывать риски?

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

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

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

Что нужно учесть с момента первого разговора с заказчиком (внешним или внутренним) и до выхода продукта в свет?

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

Другой момент – степень информированности. Не секрет, что очень часто стороны не обладают полной информацией о действиях противоположной стороны. Это вносит неопределенность, которая обычно трактуется с позиции ожиданий. Если ожидается провал, то начинает копиться негатив, а если успех, то мечты. Поэтому чем больше информации о деятельности по проекту доступно, тем лучше. Разумеется, это не следует утрировать до сообщения каждого шага противоположной стороне.

Третий аспект – целеполагание. Если цель проекта недостаточно четко определена хотя бы на уровне менеджеров проекта, то в итоге и результатом будет непонятно что. Цель, безусловно, должна быть достижима в разумные сроки и может быть пересмотрена в процессе проекта. Последнее часто является необходимой процедурой, поскольку локальные цели проекта (написание CRM-системы, например) могут быть следствием более глобальных целей (устранение бардака в клиентском отделе), и ожидания заказчика строятся именно относительно глобальных, а не локальных целей.

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

Как происходит разработка приложения после того как техзадание согласовано с заказчиком? Пишите ли вы псевдокод, создаете ли прототипы или сразу же приступаете к реализации «боевой» системы?

Это обычно зависит от количества имеющихся наработок и/или готовых решений, которые применяются в проекте. Если количество разработки незначительно относительно настройки уже имеющегося кода, можно сразу в бой. Если же система требует значительных усилий по разработке, пишется «с нуля» или в дальнейшем может серьезно видоизмениться, то первым этапом обязательно будет продумывание архитектуры, затем прототипирование (отдельно – пользовательского интерфейса, отдельно – программных механизмов), затем можно приступать к реализации.

В разрезе создания большой системы: какой стиль разработки – нисходящий или восходящий – вы предпочитаете и почему?

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

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

Максим, какая из реализованных систем была наиболее интересной и технически сложной? Сможете ли вы описать ее жизненный путь с точки зрения выбора архитектуры и средств разработки?

Обычно при ответе на такой вопрос я подробно рассказываю о проекте создания системы управления театральными подъемами, но в данный момент, думаю, это не самый сложный проект. Хотя и не самый простой.

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

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

Изначально задача была поставлена в виде «нам нужна база по клиентам с отслеживанием сроков исполнения». Вооруженный ею, а так же кратким описанием процесса, я попытался продумать интерфейс системы. Поскольку единственное ограничение от внутреннего заказчика состояло в том, что система должна быть веб-приложением, доступным из любой точки с интернетом, в качестве инструмента был выбран комплект LAMP, в рамках которого у меня был большой опыт и неплохое количество наработок. Была еще идея реализовать все в рамках Google Apps, но этот вариант был отвергнут, поскольку я не знал Python, а мой коллега, хоть и знал, никогда не работал с Google Apps API. В свете этого разработка могла значительно затянуться, а нужно было, как всегда, «еще вчера». Поэтому выбор инструмента был определен, на вооружение взята типовая архитектура веб-приложения (которой я придерживался уже несколько лет при реализации подобного рода проектов), а я занялся проектированием пользовательского интерфейса.

Пользовательский интерфейс во всех приложениях является бичем разработчика. Как ни странно, но почти во всех встречающихся мне задачах (в т.ч. и в задаче с театральными подъемами), на интерфейс, его реализация и связанные с ним вещи занимали до 75-80% времени проекта. Поэтому при создании приложений необходимо уделять максимальное внимание простоте и удобству пользовательского интерфейса. Это в дальнейшем сократит как нервы пользователя, так и временные затраты разработчика. Предполагалось, что в системе будет веб-интерефейс, основанный на HTML4 совместно с применением библиотеки jQuery. В качестве шаблонизатора использовалась технология XSLT: бэкэнд генерировал XML с данными, на который затем одевался XSL-шаблон, который мог быть разным в зависимости от условий, например, предназначены ли данные для передачи на сторону клиента посредством AJAX или же, наоборот, должны быть отправлены на печать.

После проектирования интерфейса была спроектирована и реализована базовая структура БД, в которой предполагалось хранить основные сущности. Второстепенные были добавлены позднее. Как правило, это оказывались всякого рода справочники и шаблоны.

Затем в течение порядка трех-четырех месяцев был реализован основной функционал. Поначалу он представлял собой базу данных по клиентам и смежным сущностям плюс систему назначения и отслеживания задач. В таком виде система и была пущена в бой. Однако последующие два месяца эксплуатации выявили нежелание сотрудников работать в рамках системы. Основой по-прежнему оставались бумажные заявки, а конфликты продолжали возникать. В свете этого было решено модифицировать систему, приведя ее к более привычному для участников процесса виду – в CRM была встроена сущность «Заявки», каждое внесение которой порождало сверку с уже имеющимися данными по клиенту (для исключения операторских ошибок), а так же инициировало последовательное выполнение задач согласно бизнес-процессу со всеми вытекающими бонусами.

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

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

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

О, баги! 🙂 Вообще с возрастом начинаешь замечать, что есть много различных типов багов.

Первый – синтаксический, когда программист ошибается в названии оператора или забывает поставить разделитель. Это неизбежное зло – программисту как оператору свойственно ошибаться при вводе текста, и тут обычно только незамыленный взгляд способен найти ошибку (ну и вменяемое сообщение о ней от компилятора/интерпретатора).

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

И третий, самый злостный тип – ошибки, порождаемые сторонним кодом или сложным взаимодействием. Эти крови пьют больше всего и о них я как раз расскажу.

Первая история произошла как раз при внедрении системы управления театральными подъемами. По заданию требовалось, чтобы запуск двигателей подъемов контролировался не только сенсорным экраном, но и отдельными кнопками, вмонтированными в пульт, плюс присутствовала индикация в виде загорающегося светодиода над нажатой кнопкой. А это означало, что мне в процессе работы надо опрашивать дополнительный контроллер и посылать ему команды на индикацию. Собрали прототип, я протестировал программу – все работает. На следующий день время теста на конечном оборудовании. Включаем… и получаем цветомузыку – светодиоды горят произвольно – вне какой-либо зависимости от нажимаемых кнопок. Вот захотелось так и все. В панике перепроверяю код: все правильно, но такое дурацкое поведение не исчезает. Коллеги хмурят брови и просят проверить еще раз. После обеда.

Разумеется, весь обед голова забита только вопросом «Какого … ?». Возвращаемся. И тут в голову приходит глупая идея – за этот проект мы уже несколько раз наступали в электрические наводки на информационные линии, а с учетом того, что силовые щиты тоже рядом… в общем, прошу коллег заменить кабель от компьютера до контроллера на экранированный. Заменяем. Все начинает работать как и работало на тестовом пульте. Выдыхаю, перехожу к следующему этапу.

Вторая история случилась совсем недавно. Я разрабатывал простенький веб-видеочат, для создания клиентской части использовал открытый Flex вместо традиционного Adobe Flash, а, поскольку знания платформы были недостаточно глубоки, всячески подглядывал в размещенный в сети код и исходники, идущие вместе с сервером для RTMP-трансляций erlyvideo. Чат в итоге был реализован и даже работал, но при тестировании обнаружился очень странный эффект – при ожидаемом поведении в браузерах ОС Windows и Mac OS X ответственный за вещание Flash-элемент категорически отказывался работать в Linux, даже не выдавая предупреждения на захват камеры. Попытки неоднократно переписать код, консультации с опытными Flex-разработчиками, один из которых и был автором того кода, на базе которого я строил тот элемент, не увенчались успехом. Окончательно разочаровавшись во всех испытываемых средствах я полез как можно глубже в документацию. Оказалось, что выдача окошка предупреждения безопасности – это свойство исключительно Flash-плагина, Air-приложения же сразу обломаются. Запустив отладку, я обнаружил – да, действительно, обламывается. Но у меня было не Air-приложение! Сразу пришло на ум, что, возможно, это указывается в параметрах компиляции. Прошерстив все параметры и вдоволь ими наигравшись до такой степени, что даже работающая компиляция перестала функционировать, я сдался, решив проверить последний шанс. Дело в том, что для Linux есть альфа-версия Flex Builder-а, продукта Adobe для удобной работы с Flex-ом. Создав на удачу в нем проект, я скопировал туда прошедший неоднократную переделку код и запустил. Каково было мое удивление, что все заработало! Появилась панель безопасности, заработал захват видео-потока с камеры. А вместе с удивлением пришло и озарение. Я начал проверять, как ролик вставляется в страницу и опасения подтвердились – библиотека jQuery SWFObject откровенно халтурила, пытаясь вставить Flash-элементы в Linux как и на других платформах через тег object, в то время как правильно это делать через тег embed (что и делает оригинальный SWFObject, который занял вакантное место библиотеки для встраивания). В результате чего браузер трактовал ролик как встроенное Air-приложение и применял соответствующую настройку безопасности. Для проигрывания было все равно, а вот с захватом и трансляцией получилось неудобно. В результате, стыдно признаться, но на этот вполне тривиальный баг я потратил почти неделю времени, правда, неполных рабочих дней, потому как делалось это параллельно остальным задачам.

Мораль обоих историй проста – «баги коварны» и «никому нельзя верить». 🙂

Максим, есть три базовых сценария приемочных испытаний: проверку системы осуществляет разработчик, выделенный тестировщик или вменяемый заказчик. При создании каких приложений/систем оптимален тот или иной сценарий? Исходя из вашего опыта, как организовать тестирование продукта наиболее эффективным образом в координатах “время-качество-деньги”?

Для выбора из предложенных варинтов, на мой взгляд, главное – представлять стоимость сбоя и отказа.

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

Если последствия ошибок весьма значительны (для определенных ситуаций и вполне ничтожная сумма может быть серьезной), то да, имеет смысл проводить выходное тестирование. Однако, на мой взгляд, впадать в крайности (как это делают в TDD) не стоит, лучше уделить внимание проработке модели и алгоритма системы, нежели соревноваться в методах доведения ее до граничных состояний, а потом героически эти самые состояния преодолевать, внося дополнительную энтропию в пусть и проходящий тесты код.

Каковы признаки плохого кода? Можете ли вы привести примеры?

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

Технические ошибки на проекте можно подразделить на следующие:

• Неправильный выбор платформы

Здесь, скорее всего, будет все плохо: начиная от архитектуры и заканчивая локальными фрагментами кода, все будет сосредоточено на героическое преодоление нюансов разработки под выбранную платформу. В результате этого скорее всего получится дорогой в разработке и поддержке, но абсолютно неэффективный продукт. К счастью, в наши дни подобные ошибки встречаются все реже и реже. Наиболее абсурдный пример подобного решения – написание интернет-форума на Си в виде CGI-приложения (зачем, когда есть такие языки, как Python, Ruby, PHP, явно больше подходящие для веб-разработки).

• Ошибки архитектуры

Под ошибками архитектуры подразумевают неоправданные приемы, которые разработчики бездумно копируют из других проектов, не особо задумываясь о последствиях. Простейшим примером подобного может быть, например, хранение картинок для небольшого сайта внутри СУБД. При этом при запросе картинки веб-приложение должно будет запросить СУБД на предмет картинки, сформировать правильно заголовки и только затем отдать картинку пользователю, иными словами – это чревато неоправданной нагрузкой по сравнению с вариантом хранения этой же самой картинки как обычного файла (хотя стоит отметить, что иногда это решение тоже приемлемо).

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

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

• Неряшливое кодирование

Под неряшливым кодированием я обычно подразумеваю два явления – несоблюдение стиля кодирования и спагетти-код.

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

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

• Незнание алгоритмов и/или принципов функционирования инструмента

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

• Недостаточная или излишняя документация

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

Как сделать код более читабельным? Как обеспечить возможность его легкого изменения в будущем?

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

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

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

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

• Используйте стили написания кода, такой проще читать.

• Как минимум, подписывайте назначение функций/методов (особенно если их назначение неочевидно из названия) и коммиты в систему контроля версий.

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

• Помните: возможно ваш код будете читать вы сами (лет через пять и бить себя по голове при этом), а возможно – психопат-убийца-маньяк. И не факт, что он не найдет, где вы живете. («Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.» – Martin Golding)

Максим, каковы признаки хорошего кода?

Их не так много:

На самом деле все гораздо проще:

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

Табу для разработчика: каких ошибок не стоит допускать при создании программных продуктов?

При создании программных продуктов не нужно допускать двух ошибок:

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

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

Каковы, на ваш взгляд, наиболее важные навыки для эффективного программиста?

Наиболее важные навыки эффективного программиста:

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

Можно ли после этого спокойно спать? 🙂

Можно. Такие маньяки водятся только в телевизионных сериалах. 🙂

Максим, каких возможностей вам не хватает в современных языках программирования?

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

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

Что нового, на ваш взгляд, появится в языках и средах разработки?

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

В то же время на уровне генерации машинного кода, наоборот, произойдет интеграция всех платформ и систем под знамя LLVM, т.е. исходный и/или промежуточный код (CIL, байткод JVM) будут транслироваться в представление LLVM, а только затем – в бинарный код целевой платформы. Это упростит переносимость продуктов, позволяя модернизировать интерфейсы в зависимости от конечного устройства, оставляя код бизнес-логики неизменным. Впрочем, это весьма оптимистичный прогноз.

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

Максим, что вам хотелось бы изменить в развитии IT?

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

Максим, спасибо за интервью. Хочется пожелать вам новых интересных проектов, развивающихся эволюционным, а не революционным путем! 🙂

Источник