Преамбула
Доброго дня %user_name%. За годы накопленного опыта в сфере программирования у меня накопились некоторые наблюдения, заслуживающее того, что бы быть структурированными. Сегодня я поговорю о той части работы программистом где он соприкасается с необходимостью обучения. Постараюсь изложить некоторые неоднозначные принципы, а таких в программировании ой как много!
1. Программируйте как можно больше!
Кодить, кодить и еще раз кодить. Это то что чаще всего советуют более зрелые девелоперы начинающим. И кажется что этот совет действенный. Так и есть, но не совсем. Истинна намного глубже.
Для компании важно то, что бы каждый программист овладел инструментарием который используется на производстве и по возможности тот, который потенциально будет использоваться. Многие из начинающих программистов покупают толстенные книги по Android, Java EE, Qt или еще чему то что они используют на практике. Думаю все понимают что из этих книг усвоиться лишь та часть которую они действительно апробируют практикой в своих проектах.
Набрав некоторые знания программисты иногда начинают забавляться своими собственными задачами и все они сформированы следующим образом: «выбрать что-то что потенциально можно сделать теми средствами которые я знаю и реализовать на практике». Такой подход у 90 процентов молодого поколения. Которые начинают со временем оттачивать знания своего той области с которой они работают и ОЧЕНЬ замедляют свой рост как профессионала.
Мало кто изучив работу SQLite в Android начинает изучение ORM в связке с ORMlite если этого нету в его проекте на котором он задействован. Разумеется его код с каждым новым проектом становиться все более и более лучшим но… С того момента когда программист научился писать потоко-защищенный сингелтон каждый следующий инициативный проект в котором он его создает он будет попросту тратить свое время в холостую (быть может где-то на самом деле нужно использовать статическую фабрику?!?).
Сегодня существует целая армия программистов со стажем на Java которые уделяют не мало времени саморазвитию и довольно поверхностно знакомы с многопоточностью на практике ибо в их конкретных задачах это не требовалось!
Для того что бы активно расти над собой мало писать много, необходимо писать разнообразно. И да, это сопряжено с тем что вместо проторенного пути который программист может реализовать с закрытыми глазами необходимо выбирать что-то не изведанное, менее понятное и не всегда даже несущее прикладную выгоду (в каком либо конкретному случае). Выгодно ли это компании? НЕТ! Разумеется нет ибо такой программист может завалить сроки, создать потенциальные проблемы и вообще привести к состоянию когда часть кода придётся переписывать заново!
Выгодно ли это программисту? Могу смело утверждать что имея светлую голову на плечах спокойно можете перепрыгнуть с мидла (а иногда и джуна) на синьера за один-два года! Да это риск но он того стоит, да и в конечном счете необходимо помнить что каждый программист работает на себя самого да и компаний которые хотят взять себе толкового сотрудника всегда много.
2. Укладывайтесь в сроки
Сроки важны кампании. Они важны менеджерам которые не всегда хорошо разбираются в программировании. В крупных международных компаниях программисты часто жалуются на то, что сталкиваются с тем, что сроки вообще составляются чисто «бизнесами» без оглядки на разработчиков. Трудно последним объяснить зачем в этап разработки ПО включено тестирование без которого, как им кажется, процесс станет быстрее…
Несмотря на позицию менеджера/компании/начальника код должен быть протестирован! Unit тесты, это не панацея, но говорить о том, что дело уже завершено, нельзя, до тех пор, пока код не покрыт тестами. Работа программиста завершается не тогда когда «оно заработало», а когда вместе с ПЗ программист предоставляет следующее данные:
— сколько и при каких входных параметрах работает ПО;
— при каких типах входных параметров гарантируется на выходе корректный результат;
— какое поведение будет при некорректных параметрах подающиеся на любой (основной) модуль программы.
Без этого в сроки то может и уложитесь но надо понимать что в релиз программа выйдет с намного большим опозданием нежели изначально планировалось, так как минуя тесты выигрываешь битву но войну однозначно сливаешь…
3. Творите на этапе создания архитектуры
Хотите писать хорошие программы, изучите UML. Самый лучший софт который когда либо рождался из под моей клавиатуры был качественно спроектирован. Написанная архитектура должна быть масштабируема что бы легко включать потенциальные изменения (новые требования заказчика) без изменения архитектуры (ну или с минимальными изменениями). Так же качественная архитектура позволяет а самом раннем этапе создать ключевые характеристики программы и сформулировать требования к конечному продукту (по производительности или функционалу и т.д.). Именно тут можно составить все тесты для TDD.
Разработав архитектуру необходимо определиться с технологиями которые будут задействованы. После переходим к кодированию, где много времени придется потратить на изучение (смотри пункт 1), но НЕ творчество! Разумеется некоторые вещи можно реализовать по разному и это так же творчество, но думаю все же понятно о чем я сейчас. Придумали очередную «загогулину» и хочется ее тут же внедрить – поздно, подождите момента когда вновь будете творить концепты нового ПО, или новой версии. На этапе разработки и так хватает рисков связанных с реализацией концептов используя новые технологии или решения.
4. Всегда решайте причину проблемы
Очень часто программисты ставят проверку на null/NULL/0/etc в место того, что бы потратить время и понять почему стандартная системная функция вернула это нулевое значение, в то время когда не должна была! Важно знать суть, всегда, а не бороться с последствиями. Да, иногда решения требуют сейчас, и не дают времени на обучение и совершенствование мат. части. В таком случае лучше дольше посидеть на позиции джуна что бы иметь больше время для решения сложных проблем но все же учиться и еще раз учиться! Лишь тогда когда программист знает почему его приложение предсказуемо он может быть спокоен. Всегда стоит помнить что между знанием что ПО предсказуемо и знанием почему оно предсказуема пропасть в сотни часов обучения!
Послесловие
Многое сказанное у многих вызовет чувство не согласия. В первую очередь в вопросе того что все эти принципы стоит осуществлять на рабочих, боевых проектах. Я слышал у многих оппонентов точки зрения в стиле: все это да но применимо только на учебных проектах и не в коем случае не реальных где есть четкие сроки, требования, рамки. И в определенном смысле они правы, с одной оговоркой, если не начнете употреблять это все на всех своих проектах (как рабочих так и учебных) то скорость роста как специалиста резко уменьшиться. Ибо личное и свободное время не такое больше как рабочая неделя и исключение составляют те, у кого нет потребности работать, жизнь им подарила самый ценный ресурс – время которое в место работы можно тратить на саморазвитие и творчество перерастающее в прекрасный FrameWork, стартап, проект… Но все это тема еще одной статьи.благодарен за
Автор: b0noII
