Обыкновенные советы по организации рабочего процесса могут быть не наименее полезными, чем исследование новейшей технологии, языка программирования либо фреймворка: они разрешают сберегать время и сформировывать целостное представление о системах. Базисными советами для коллег делится разраб Маниш Джайн.
Три нужных привычки, которые посодействуют стать хорошим разрабом
Александра Степанова
Трудности с кодом — обычная часть процесса разработки. В поисках решения программеры часто обращаются к Stack Overflow. Этот веб-сайт — принципиальный инструмент разработки (может быть, даже наиболее принципиальный, чем кофе и сочетания жарких кнопок). Время от времени готовых решений там не находится, и их приходится находить без помощи других, обращаясь к различным постам и тредам с дискуссиями. Это процесс занимает много времени и серьезно демотивирует.
Я часто убеждаюсь, что трудности, с которыми сталкиваются создатели, весьма похожи. Но даже если какая-то ситуация происходит повторно, большая часть не употребляет свой опыт, а начинает гуглить опять в поисках ее решения. Этот подход работает, но занимает очень много времени: нужные ответы далековато не постоянно удается отыскать сходу.
Вот три совета, которые посодействуют решать возникающие трудности резвее и улучшат общее осознание ситуации.
1. Сохраняйте методы решения заморочек
В процессе разработки часто появляются трудности с библиотеками и фреймворками. Это происходит в особенности нередко при использовании новейших технологий — к примеру, Spring Boot либо Kotlin. Разработка функции — наилучший момент для сохранения методов решения трудности, поэтому что в это время программер стопроцентно обладает контекстом и лучше соображает индивидуальности определенной задачки.
Не так давно при работе с Hibernate на Kotlin мне не удавалось применять классы данных для сотворения концептуальных сущностей. Некое время я пробовал отыскать решение без помощи других, но потом мне попалась не плохая статья с исчерпающим разъяснением трудности и перечислением вероятных путей ее решения. Я сохранил эту ссылку и заместо того, чтоб стремительно воплотить приобретенный совет на практике и запамятовать о нем, решил копнуть мало поглубже. Так я вызнал, что у почти всех библиотек есть трудности с сочетаемостью с Kotlin. Столкнувшись с похожей сложностью в последующий раз, я смогу стремительно обратиться к статье и сберечь время.
Заместо того, чтоб как можно резвее закрыть определенную задачку, постарайтесь выяснить побольше о причинах ее появления и не забудьте сохранить полученную информацию.
2. Создавайте диаграммы архитектуры
Принципиальная вещь для всех разрабов, независимо от их уровня. Для осознания особенностей работы программной системы принципиально представлять общий принцип ее устройства.
Я постоянно стараюсь составить как можно наиболее полное представление о определенной среде: изучаю внутренний сервер, конфигурацию инфраструктуры и посторонние зависимости. Резвый обзор помогает осознать, как та часть, над которой я работаю прямо на данный момент, влияет на функционирование системы в целом.
Потом я рисую общую схему. Поначалу она смотрится весьма примитивно, но с течением времени зарастает подробностями. Если что-то кажется непонятным на 1-ый взор, постоянно можно обратиться с вопросцем к наиболее опытным спецам в данной области. Итоговый итог стоит этих усилий: понятная схема лучше тыщи слов. Можно отыскать и готовые диаграммы архитектуры — почти все из их выложены в сети.
3. Ведите ежедневник
Весьма просто и весьма отлично. Выделите 5 минут в денек на ведение рабочего ежедневника: коротко фиксируйте трудности и методы их решения, не запамятывая упомянуть о том, какие деяния требуются от вас, а какие — от остальных членов команды. К примеру, для вас может потребоваться новейший дизайн от разрабов либо информация о области деяния определенной функции от представителей юзера.
Рабочий денек программера нередко бывает весьма загруженным. Если запамятовать о какой-либо принципиальной мелочи посреди огромного количества задач, встреч и дедлайнов, это может привести к большущим дилеммам. Внедрение ежедневника дозволит избегать таковых ситуаций и повысит вашу эффективность.
Вывод
Эти обыкновенные правила серьезно посодействовали мне в работе: они дозволили мне стать наиболее надежным разрабом и наиболее приметным участником команды. Надеюсь, для вас эти советы тоже принесут пользу.
Как гласит Кент Бек: «Я не величавый программер — я просто неплохой программер с хорошими привычками».
Источник.
Источник: