Мне в почтовый ящик упало одно письмо, ответ на которое, полагаю, будет интересен доброй половине аудитории сайта и рассылки (если, конечно, статистика мне не врет).
Кстати, хочу отметить, что получать письма от вас мне крайне приятно, да и полезно. И дело не в том, что ваши письма являются моим единственным гонораром за сайт и рассылку, а в том, что так я могу узнать о ваших интересах и проблемах. А зная это - быть более полезным, опять же вам.
В общем, пишите мне чаще, не стесняйтесь. Отвечу, быть может, не сразу, но всем без исключения.
Разумеется, что автор письма, на которое я отвечаю сейчас, согласен с его публикацией
Письмо
Уважаемый Григорий!
Я подписался на Вашу рассылку, так как она связана с моей будущей
деятельностью - разработкой ПО. Я пока что учусь на 2-м курсе в
киевском политехе (КПИ). Однако уже сейчас начинаю приучать себя к
разработке достаточно сложных систем, поскольку это наилучшая практика
для того, кто хочет посвятить себя этому роду деятельности. Да и
замашки у меня нетривиальные - хочется создать что-то действительно
грандиозное и полезное. Даже не столько ради денег.
Я буду очень Вам благодарен, если Вы найдёте время и сможете мне
посоветовать как правильно использовать своё время и силы, что бы
научиться разрабатывать сложные программы: может, это какие-то книги
или же другие источники информации. Может быть, что-то из Вашего
личного опыта: как Вы стали тем кем стали?
Надеюсь, Вы меня поняли.
Заранее благодарен.
С уважением, Антон.
Ответ
Здравствуйте, Антон.
Я начну с конца, с вашего позволения и отвечу на вопрос о том, как я стал тем, кем стал.
Рецепт прост: надо всего лишь не бояться экспериментировать. Никогда не угадаете, что я сделал со своим первым PC-совместимым компьютером через час после того, как распаковал коробку и подключил (кстати, методом псевдо-научного тыка) его части друг к другу. Я снес программу "SuperStore", а вместе с ней и всю таблицу разделов. Сразу после этого мне стало интересно, почему компьютер перестал загружаться.
Пришлось разобраться с MBR, FAT и вообще логикой хранения информации в MS-DOS. Зато именно с тех пор я не испытываю панического ужаса при удалении важного файла, а попросту восстанавливаю его (пусть даже и руками, как после некоторых антивирусов).
В общем, первое правило начинающего волшебника: не бояться и экспериментировать. В крайнем случае - не покупать дорогой техники и держать все критичные файлы на дискетах (а лучше еще и на компакт-дисках).
Второе правило, вытекающее из предыдущего повествования - всегда анализировать свою работу, причем до полного понимания проблемы или причины успеха.
Теперь я хочу сказать по поводу "сложных" программ. Во-первых, критерии сложности у всех разные. К примеру, мой HomeBank (тут я отсылаю вас к одному из прошлых выпусков рассылки) является довольно сложной системой. Для вас же, Антон, она может показаться простой. Но, дело даже не в этом...
Дело в том, что многие думают, что во время написания "сложных" программ можно большему научиться. Это заблуждение, притом серьезное. И вот почему: любой объект в нашем мире состоит из элементарных частиц. Не являются исключением и программы.
Для того, чтобы написать небольшую утилиту, генерирующую тестовые данные для базы данных надо знать о работе с базами данных ровно столько же, сколько и для написания программы класса SQL Navigator или IBExprert. Методы работы-то одинаковые, различается лишь количество применений этих методов и их комбинации.
В результате я хочу порекомендовать тебе, Антон, не плодить сущностей, как говорил Мудрый, а начать изучать и применять именно методы. Причем, лучше всего это делать на небольших программах, так небольшой размер позволяет добиться более четкого контроля и понимания.
Тем не менее, такой метод ущемляет одну из первейших потребностей любого человека, потребность самовыражения, которой часто сопутствуют еще и честолюбие с амбициозностью (кстати, "неплохие" качества, если в умеренных дозах).
В таком случае, я бы посоветовал придумать для себя "большой" и нужный не только тебе, но и другим проект, а потом последовательно начать его реализовывать. Хочу предупредить сразу, что можно планировать достижение результата только через несколько лет. К примеру, неплохо бы было придумать серьезную тему для выпускной дипломной работы в институте. Заодно и польза будет.
После того, как идея родилась надо набросать план ее жизненного пути. К примеру:
недели 1 - 8, разработка концепции и vision-документа
недели 9 - 36, разработка моделей подсистем
недели 36 - 37, разработка документации разработчика
недели 37 - 64, программирование
недели 64 - 72, тестирование и написание документации пользователя
Такой план можно повесить у себя над кроватью и отмечать вехи. На первый взгляд может показаться, что в этом плане зашито слишком много времени. Это не так. Ведь по ходу работы придется научиться всем технологиям, которые используются при создании системы. Именно потому, что информацию надо искать, обрабатывать и применять было задано столько времени. Приведу пример: для разработки моделей подсистем, не плохо бы было изучить методологию UML, а еще лучше вест RUP. Кстати, временные диапазоны плана указаны для задачи класса HomeBank (с небольшими вариациями, конечно).
Еще одно замечание - после того, как сроки заданы, их следует придерживаться во что бы то ни стало. Это, заодно, научит работать в жестких временных рамках, без которых сейчас не делается ничего.
Итак, третье правило волшебника: не делать ничего без планирования и документирования. Как бы это отвратительно для творческого ума не звучало.
Надеюсь, Антон, и вы, мои читатели, прониклись вышеизложенными идеями. В любом случае, буду рад продолжить разговор на эту тему, как на форуме сайта, так и по электронной почте.
С уважением, Григорий Ситнин.
(c) Григорий Ситнин, 2002. Все права защищены.
Все упомянутые в статье торговые марки и товарные знаки принадлежат их уважаемым владельцам.
Данная статья не может быть воспроизведена полностью или частично в электронном, печатном, или ином виде, без письменного разрешения автора.