Проектирование Дизайн Психология Бизнес Разработка Разное

12 рекомендаций начинающим разработчикам

11 июня 2007

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

Создайте единый интерфейс проектов

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

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

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

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

Выработайте стандарты кода

Пишите код по стандартам всегда.

Есть несколько различных стандартов, поэтому прочитайте их http://en.wikipedia.org/wiki/Programming_style и выберите наиболее подходящий стиль.

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

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

Я не раз встречал в требованиях заказчика соблюдение стандартов кода. Безусловно — это еще один плюс к качеству разработки и к оценке вас как профессионала.

Составляйте блок-схемы и диаграммы

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

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

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

Полезные ссылки:

Составляйте каталог быстрых решений и примеров

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

Я собираю такие решения для всех технологий, которые использую и раскладываю их по рубрикам:

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

Используйте справочники

Есть три основных вида книг по технологиям:

Используйте все три вида книг.

Используйте библиотеки кода

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

Ряд библиотек PHP

Ряд библиотек JavaScript:

Рассчитайте цену за услуги

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

Сделайте как минимум два законченных приложения

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

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

Установите ограничения для своих возможностей

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

Не работайте по 20 часов в сутки. Два-три дня такого ритма приведут к тому, что вам понадобиться два-три дня отдыха. Это равноценно 10 часам работы каждый день в течение 4-6 дней. Возможно, кому то все-таки ближе первый вариант, но моя практика показывает, что я всегда успеваю сделать почти в два раза больше, работая в день по 8-10 часов, чем в один день 18 часов, в другой два часа, в третий не работая.

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

Делайте только то, что умеете сейчас.

Полюбите клиента

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

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

Дайте понять, что вы настроились работать и дальше, без исчезновений. Обменяйтесь номерами мобильных телефонов и хотя бы раз позвоните сами, показав, что вас волнует проект, над которым работаете.

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

Заведите блог

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

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

Изучайте ООП сразу же

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

Поделиться