За все время работы в ИТ я принимал участие в различных сферах деятельности. Я был и тимлидом, и разработчиком и менеджером проекта. Вел крупные и не очень проекты, среди них были как успешные, так и не очень. Я работал как с профессионалам высочайшего класса (по крайней мере именно такими я считал и считаю этих людей до сих пор) так и с не очень опытными коллегами. Я сотрудничал как с людьми проработавшими в ИТ всю свою жизнь, так и с теми — чьи интересы и деятельность лежит в совершенно других сферах.
Все это время я чему-то учился и продолжаю учится по сей день.
После каждого завершенного проекта кроме удовольствия от проделанной работы, приходило так же понимание того, что было сделано хорошо, а что можно было сделать лучше.
Сегодня я хочу поделится теми советами, которые сам был бы рад услышать тогда, когда только начинал свою деятельность.
Чем проще решение тем оно надежней
В решении с большим количеством кода гораздо проще сделать ошибку. Кроме того, правильное решение должно быть очевидно и понятно.
Не стоит изобретатель велосипеды
Если есть готовый фреймворк, или библиотека который Вы можете использовать — используйте его. Не стоит писать свой.
Логику и типы данных лучше выносить в отдельные сборки
При разработке даже не очень большого проекта стоит разносить отдельно логику и типы. Это позволит в будущем облегчить тестирование и повторное использование кода. А так же снизит временные затраты при необходимости расширения проекта.
Open Source надо использовать с умом
Если за основу своего продукты вы берете open source проект, не стоит сразу кидаться внутрь него и переписываться кучу кода. При выходе новых версий основного продукта merge может превратится в головную боль. Если возможно — свой код стоит выделять в модули и отдельные файлы кода. Если решили кардинально изменять код — надо полностью оценить все риски и возможные проблемы в будущем.
Не стоит сразу писать платформу
Лучше решать поставленную задачу. Многие разработчики (и я в том числе иногда страдаю этим же подходом :) ) сразу стремятся написать универсальное решение для всего и сразу. Не стоит этого делать. Чаще лучше решить конкретную задачу и получить результат. Потраченное на создание универсального решения время может не окупиться, и часто не будет востребовано в будущем. Кроме того, чем универсальнее решение, тем чаще оно получается сложнее и ограниченное в использовании.
Зачастую такой подход бывает у начинающих разработчиков, поэтому совет относится в первую очередь к ним — прежде чем начинать писать такое решение — посоветуйтесь со старшим товарищем в команде — будет ли оно полезно и востребовано. И только если получите положительный ответ — стоит начинать такую работу.
CMS не панацея
Мне часто доводилось видеть веб-проекты, которые начинались с того, что ставилась какая-то популярная CMS и продукт развивался путем «накручивания» на нее кода. В результате получался неповоротливый механизм который процентов на 10% использовал функционал CMS, а 90% кода были перегружены и нечитаемы, так приходилось учитывать структуру самой CMS и структуру ее БД.
Гораздо эффективнее писать решение конкретной задачи, чем пытаться приспособить для этого неповоротливую CMS.
Предметная область важнее всего
Во всех проектах соблюдайте приоритет: Предметная область -> Архитектура -> Административные задачи
Продукт создается для клиента, а не для разработчика, или системного администратора.
Мне приходится встречать ситуации, когда администратор начинает рассказывать разработчикам как им лучше писать API для продукта. Так же встречались разработчики, которые предлагали клиенту отказаться от функционала, так как его не поддерживает CMS с которой разработчик умеет работать. Такой подход недопустим, если вы действительно хотите создать качественный продукт.
Решение создается в первую очередь для клиента, а не для программиста, или администратора.
Оптимизация нужна только там, где нужна
Иногда встречаю разработчиков которые говорят «Я не буду использовать Entity framework, он генерирует не эффективный SQL», или «Использование linq — это синтаксический сахар! Циклы и перебор лучше.» Да, иногда не все вещи которые удобны — будут максимально эффективны в плане быстродействия. Но стоят ли проценты производительности снижения уровня удобства разработки и увеличения объема кода?
Часто бывает достаточно выделить две три «тяжелые» функции в хранимую процедуру и обвернуть ее вызов через Entity Framework, или провести оптимизацию конкретных узких мест в коде, чем полностью отказываться от тех преимуществ которые дают новые технологии.
Читаемый код, лучше переоптимизированного
В большинстве случаев удобно читаемый и понятный код, лучше чем высокооптимизмрованный но непонятный.
Инструмент должен быть удобен
Бывает так, что выходит новая технология, появляется инструмент, или продукт, который получает широкую огласку и восхищенные отзывы. Но по сути инструмент еще не готов технологически. Внедрение такого инструмента, несмотря на кажущуюся перспективность и технологичность может негативно сказаться на продуктивности работы команды. А преимущества могут не перекрыть недостатки.
Инструмент должен в первую очередь удобным и решать задачу.
ТЗ должно быть
Даже плохое ТЗ лучше чем отсутствие какого либо.
Мне также встречались и такие проекты где документацию по проекту отсутствовала вообще и очень многое находилось на уровне устных договоренностей. При этом размеры таких проектов были самые разные — как мелки, так и достаточно крупные.
Даже если вы в отличных отношениях с заказчиком и полностью ему доверяете — все пункты необходимо фиксировать. И даже это не всегда помогает. Понимание одних и тех же терминов и описаний может кардинально различаться у различных участников проекта.
Так мне доводилось быть на встрече, на которой несколько часов обсуждалось только основное понимание терминов предметной области. Разработка при этом еще даже не начиналась.
Лучше применять готовый продукт, чем писать свой
Есть много ситуаций, когда разработчик, или клиент решают что стоит написать свое решение. На самом деле, где-то в половине случаев так поступать не стоит.
Разработка — это всегда длительный и дорогой процесс. Поэтому, даже если кажется что написать свой аналог проще и дешевле — в 90% это только иллюзий.
Если на рынке есть аналогичное решение — лучше приобрести его. Оно уже есть и уже работает. Здесь и сейчас.
Писать свое решение стоит только в том случае, все участники проекта осознают риски, понимают что процесс будет длительным и дорогим.
Явные признаки того, что лучше купить и внедрить чем писать:
- существует продукт который покрывает предполагаемый сценарий использования
- существует продукт который покрывает предполагаемый сценарий использования после определенной конфигурации
- существует несколько продуктов которые при взаимодействии и интеграции покрывают предполагаемый сценарий использования
- существует продукт который можно расширить определенным функционалом (дописать модуль для CRM) и после этого он покроет сценарий использования
Когда есть смысл писать свой:
- человек принимающий решение точно знает почему он начинает разработку
- на рынке нет продукта который мог бы реализовать требуемую функциональность
- у компании достаточно финансов что бы не только длительное время инвестировать в продукт, но и заниматься в последствии его поддержкой
- Вы стартап, и для Вас работают совершенно другие критерии
Кроме ИТ есть еще много чего в жизни
Этот совет последний по списку, но не по важности. Я не просто так поставил в начале статьи фотографию из ONE ☆ LIFE Everest Expedition организованной Артемием Суриным. Для очень многих в нашей профессии ИТ стало не только работой, но и самой жизнью. Я и сам довольно много времени провожу за экраном ноутбука/планшета/телефона. Но кроме этого есть вещи которые так же доставляют многим из нас немало удовольствия. Для кого-то это дельтапланеризм, для кого-то чтение книг, спорт, путешествия, общение с новыми людьми, коллекционирование, рисование сочинение.
Хочется пожелать всем — не только работайте, но и живите!
P.S. Отдельное спасибо MarcusAurelius — за предварительное ознакомление со статьей и дельные замечания.
Автор: Ernado
