Для того чтобы стать хорошим программистом, надо уметь заниматься кропотливым трудом, учиться, надо быть всегда открытым для всего нового. Для начала стоит выполнить пару пилотных, собственных проектов. Когда почувствуете, что понимаете и умеете использовать основные возможности языка (для этого надо в зависимости от затрат и способностей от 2 недель до нескольких месяцев), постарайтесь найти работу (пускай даже неоплачиваемую и удаленную) - потому что только реальные задачи полностью загружают программиста, заставляют его развиваться. Возможно следующие советы будут полезны вам, так как “прочувствованны” на собственном опыте.
Начинающему программисту полезно задавать себе следующие вопросы: -достаточно ли я понимаю свою цель? (в конкретном проекте, отдельной задаче и в карьере в целом); -все ли я делаю чтобы достичь ее; -что я могу улучшить; -не размениваюсь ли я, не делаю ли сразу несколько задач, не преследую ли слишком много целей одновременно?
Начинающему программисту полезно помнить: -закон Мерфи: если плохое случилось однажды - оно повторится. Нужно программировать и планировать конфигурацию, ориентируясь на все возможные и невозможные неприятности и неполадки; -всегда есть 2 способа сделать одно и тоже - простой и сложный. В вашей карьере будет много сложных задач и дефектов, так что не стоит усложнять жизнь самостоятельно; -нельзя верить в овертаймы, сверхурочную работу, она сильно ухудшают качество кода; -продукт создается для людей, а не для машины; -если в чем-то уверен - отстаивай свою точку зрения, если не можешь обосновать ее, лучше не пытаться ее продвигать; -код пишется для коллег, а не для машины - пишите код так как будто те, кто будет его саппортить после вас - серийные маньяки и знают ваш адрес; -Бьорн Страуструп:“существует 2 вида знания - усвоенное и знание где подсмотреть”; -не обязательно учиться только на своих ошибках, не изобретайте велосипед - это долго, перенимайте опыт. Изобретательство стандартных вещей может быть полезно на начальном этапе вашей карьеры; -повторное использование кода ускоряет процесс разработки, так как он уже продуман и отлажен.(но остерегайтесь copy-paste, дублирования кода, тем более, что он может содержать ошибку); -java никогда не будет достаточно быстрой для клиентской части (нет ни одного удачного проекта на Swing), но она достаточно быстра для серверных приложений; -”серебрянной пули”, универсальной технологии на все случаи жизни не существует, поэтому нужно знать несколько технологий; -стоит избегать “золотого молотка” - использования технологий не по назначению. Минимум вы заплатите производительностью вашего приложения. К примеру разбор XML файлов это довольно медленная операция, поэтому использование XML не всегда оправданно; -на этапе активного девелопмента нужно как можно чаще общаться с клиентом, заказавшим приложение, нужно знать что проект его полностью устраивает, иначе все придется переписывать. Нужно заранее согласовать с ним все требования и функциональность; -иногда приходится идти на компромиссы; -переносимость, защищенность и абстрагирование уменьшает производительность, а простота, кеширование, амортизация, профилирование и параллельная обработка ее увеличивает; -в IT выгоднее делиться секретами чем скрывать их;
Общие советы: -”не принуждайте себя знать все с самого начала; учитесь в процессе. Это все равно произойдет.” (Брюс Эккель, “Философия Java”); -если не понимаете код достаточно - рисуйте UML-диаграммы (классов и взаимодействия). Это сэкономит вам время и улучшит понимание; -если вы зашли в тупик, посмортите на проблему с разных сторон; -одна голова хорошо, а 2 лучше. В частности очень полезны консультации архитектора проекта, парное программирование и code review; -прежде чем начать писать - планируйте, планируйте и еще раз планируйте; -создавайте модульную архитектуру, чтобы программу всегда легко было переделывать. Не ставьте подпорок, которые усложнят дальнейший процесс девелопмента; -пишите юнит-тесты для вашего кода, это займет какое-то время, но многократно окупится при сопровождении и развитии проекта; -работайте в команде, спрашивайте, спрашивайте и еще раз спрашивайте. Брюс Тейт в своей книге “Горький вкус java” рассказывает: “В IBM, возле кофейных автоматов,в баре или у столов для пинг-понга можно услышать то, что спасает или губит проекты - или целые компании. Программистский фольклор нужно бережно хранить, ибо в нем спрятаны бесценные сокровища”; -Базы Данных (сокращенно БД): не относитесь к БД как к черному ящику - изучите достаточно особенности используемой вами БД; -БД: не старайтесь улучшить перформанс вашего приложения за счет “хаков” БД - скорее всего проблема в бизнес логике вашего приложения; -БД: не доверяйте никогда БД до конца - они часто содержат “вредительские данные” -как минимум проверяйте на null nullable колонки; -БД: используйте повторно подключения к БД (connection pool), не забывайте закрывать connection; -правильно настраивать XML-конфигурации не менее важно, чем писать код; Работая с такими фреймворками, как Struts, Spring, Tiles, Hibernate и так далее, вы сталкиваетесь с необходимостью конфигурировать маппинг объектов в специальных файлах настройки. Это позволяет вашему приложению быть более гибким и настраиваемым. Рекомендую для начала ознакомиться с шаблоном Service Locator. Если речь идет о деплойменте приложения, то крайне желательно автоматизировать этот процесс. В этом случае необходимо иметь понимание Ant [и Maven] скриптов, уметь настроить application сервер, на который будет установлено ваше приложение. Зачастую, в проекте из 20 человек, только несколько человек знают как установить энвайронмент с дистрибутивом, осознают происходящие процессы и принципы интеграции различных сервисов. Знания в этой области крайне полезны; -документируйте код. Это может быть спецификация продукта, но, как минимум, “сам код должен быть самодокументированным” (Мартин Фаулер,“Рефакторниг”): используйте javadoc и правильно подобранные имена классов, их челенов и методов; -выделяйте общий код всякий раз, когда он повторяется больше двух раз (Мартин Фаулер); -сделайте настольными следующие книги: “Философия Java” Брюса Эккеля, “Рефакторинг” Мартина Фаулера, “Применение UML и шаблонов проектирования” К.Лармана, “Объектно-ориентированный анализ и проектирование с примерами приложений на С++” Гради Буча; -выучите и понимайте основные шаблоны проектирования, но без фанатизма, зачастую за них приходится платить быстродействием, да и if-else все еще нужная часть языка Java. Используйте шаблон MVC всякий раз, когда предполагается взаимодействие приложения с пользователем; -выучите спецификацию java, чтобы избежать глупых вопросов и непонимания, также поиграйтесь с ней, изучите несколько java паззлов. К примеруhttp://ua.sun.com/win/news/events/2007/may/javapuzzlesdenistoporov.pdf
- там много поучительных примеров; -читайте http://community.livejournal.com/ru_java/
и прочие подобные коммьюнити, форумы и мэйллисты - читайте о проблемах других людей, чтобы найти решение своих собственных проблем; -хорошо продумайте свой инструментарий: IDE, deploying tools, системы хранения исходного кода, веб сервер, сервер баз данных и прочее - используйте последние и самые лучшие их реализации; -выучите базовые алгоритмы - минимум - бинарный поиск/квадратичную сотрировку, рекурсивный обход дерева, списки и знайте где подсмотреть остальное: базовые знания по управлению памятью - стек, куча, процедурное программирование, “энциклопедией Кнута” - сортировки, оптимизации и т.д.; -если вы пишете веб приложение - не забывайте о прокси-серверах - множество проектов столкнулись с тем, что не учли их использование в своем коде; -ходите на собеседования - вы больше получите, чем потеряете. Посещайте конференции; -будьте всегда готовы доучиваться, узнавать новое, менять взгляды - IT бизнес очень динамичен; -если вы не запланируете масштабируемость вашего приложения - вы его не получите; -перформанс, кеширование, мемори лики, масштабирование, нагрузка, целостность данных и обратная совместимость версий приложений - это не мантры, а насущные проблемы, которые всегда нужно учитывать; -следите за тенденциями. Повышайте свои “общие” знания. Не стоит зацикливаться только на java, сейчас работодатель требует от программиста не только создания кода, но и уменее верстать страницы, настраивать сервер, составлять документацию, работать с javascript и многое другое. По большому счету, сейчас никому не нужны просто программисты, а нужны мастера на все руки; -пишите на будущее, а не с учетом сиюминутных нужд; -используйте итеративный подход создания программ - сначала создавайте базовую версию, костяк, а затем наращивайте функциональность. -отслеживайте производительность; -купите достаточно оперативной памяти, чтобы компьютеру не приходилось обращаться к файлу подкачки, а также крайне важно уметь конфигурировать JVM, т.к. вопрос производительности и масштабируемости очень актуален. Большим плюсом к вашему опыту будет работа, связанная с решением проблем с производительностью. Например, важно понимать механизм работы сборщика мусора и задавать оптимальные параметры, такие как Xms, Xmx,…, чтобы количество его запусков было оптимизированным под конкретное приложение. Также при оптимизации производительности приложения необходимо помнить про кеширование данных, пулы подключений и lazy pattern. Если вам не знакомы эти термины, почитайте о них, скажем в «Горьком вкусе Явы». -необходимо знать и уметь анализировать предметную область - редко когда программист сам ставит себе задачу, чаще задание идет со стороны или “сверху”. В этом случае программисту необходимо хорошо понимать, что ему требуется сделать - в противном случае он не сможет выполнить свою работу качественно. Так же это необходимо для того, чтобы уметь предсказывать - может ли быть проект выполнен с заданными параметрами затрат, времени, качества и объема работ (4 золотые переменные) - может быть проект невозможно выполнить изначально, не по вине программиста? Эти знания помогут отказаться от проектов, способных нанести урон репутации, финансовый или психологический урон; -имеет смысл поддерживать разработку бесплатных опен-сорсных проектов. Очень часто вы будете пользоваться многими очень полезными бесплатными библиотеками, утилитами, средами разработки, операционными системами и т.д. Помните, что они созданы для вас и такими же как вы. Часто вы будете сталкиваться с проблемами в таких приложениях и как минимум стоит исправлять дефекты или сообщать о них и предлагать хорошие идеи; - не задерживайтесь на работе, если вам стало не интересно. Если ваша работа превратилась в рутину и не приносит ничего нового, никаких знаний - бросайте ее. Это путь в никуда. Всегда цепляйтесь только за интересные проекты.
Java: -Compile time полиморфизмом является перегрузка, т.к. компиллятор проверяет сигнатуры методов во время отладки (т. е: имя метода, типы аргументов, порядок аргументов и т.д.). Переопределение методов- это run time полиморфизм (позднее связывание); - дженерики довольно бесполезны в Java, не считая того, что с их помощью можно использовать “for-еасh” циклы; - в Java нет переопределения операторов (operator), аналогичного C++, зато многие обьектно оринетированные парадигмы реализованы в самом языке; -используйте try-catch - пусть система сама ищет ошибки; -NullPointerException, сокращенно NPE: если не уверены - всегда проверяйте полученный обьект на null; -NPE: val.equals(null) для любого val!= null всегда вернет false; -NPE: пишите “string”.equals(val), а не наоборот, чтобы избежать NPE, когда val == null; -используйте хорошие алгоритмы; -делайте цепочки наследования короткими; -используйте библиотеки Java; -финализируйте обьекты; -локальные переменные быстрее, чем переменные класса; -переменные класса быстрее, чем массивы; -буферизируйте ввод-вывод (StringBuffer.java/StringBuilder.java), уменьшайте количество строк. Помните что при конкатенации строк создается новый обьект и зачастую это неоправданные расходы. Порой строки могут исчерпать любые ресурсы. Брюс Тейт называет эту ситуацию “стадо поросят”; -используйте потоки; -используйте синхронизацию как можно реже, не помещайте синхронизированные методы внутрь циклов; -используйте архивы -jar; -создавайте интерфейсы прежде классов, используйте абстрактные классы если вы хотите определить общее поведение методов, для ваших пользовательских классов; -сравнивайте обьекты только через equals. Базовые классы Java, например String, содержат этот метод, для пользовательских обьектов, вам придется самим определить его. Это же касается и метода toString(). Помните что равентсво обьектов - это принадлежность к одному типу и только потом равенство значений; -для сравнения большого числа однородных обьектов часто используются Comparator-ы, классы в которых вы сами указываете как сравнивать те или иные обьекты; -для сравнения пользовательских обьектов нужно переопределить методы equals() и hashCode(); -часто для сравнения строк бывают полезны Collator-ы - это компараторы, которые учитвыают “местные настройки”, locale; -при использовнии SortedSet необходимо прередавать в его конструктор ваш класс, наследующийся от Comparator-а, чтобы SortedSet знал, по какому критерию сортировать ваши обьекты; - целочисленная арифметика всегда возвращает результат типа int или long, поэтому старайтесь избегать short и не смешивайте его с другими целочисленными типами. К примеру добавляя в HashSeths число s типа short, вы не сможете удалить ничего с помощью конструкции sh.remove(s-1) - аргумент removе будет приведен к int, в следствие того, что он определен только для базового типа Object, а не для конкретного типа. Тоже самое касается метода get(Object о) интерфейса Map. Если очень нужно, то для массивов типа short все отработает нормально; -если есть возможность обьявляйте заранее размер буферов и коллекций чтобы сэкономить время и ресурсы на перераспределении памяти; -не используйте URL обьекты как элементы Set или как ключи для Map - для них equals() и hashCode() нормально не работают,например hashCode все время меняется. Согласно спецификации “URL обьекты равны если они ссылаются на одинаковый хост…Два хоста считаются эквивалентными, если оба имени принадлежат одному IP-адресу…Из-за того, что сравнение хостов требует сравнения имен эта операция блокируется.” Таким образом вы не досчитаетесь всех одинаковых урлов если приконекченны к интернету + гарантировано неопределенное поведение, если отключены от него. Взамен нужно использовать URI - это более новый класс с лучшим дизайном: Set favourites = new HashSet();favourites.add(URI.create(uriNameString)); -String root = “C:\windows\mastdie”.replaceAll(”\\\\”, “/”); В таких случаях нужно экранировать java-бекслеш и бекслеш регулярных выражений. Получаем “\\\\”; -добраться до экрана и установить какой-нибудь компонент в режим Full Screen можно с помощью GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().setFullScreenWindow(new JFrame()); -невозможно переопределить статические методы класса-родителя в классе наследнике; -невозможно использовать нестатические методы внутри статического метода;
