Pull to refresh

Организация рабочего пространства перед началом нового проекта

Хочу поделиться полученным опытом в разработке на разные платформы, разных языках программирования, разных машинах и разном ПО. Я для себя нашел несколько приемов, которые позволяют мне быть намного более продуктивным. Некоторые приемы покажутся довольно очевидными, а какие-то, надеюсь, будут не так прозрачны.
Так или иначе, в итоге я подошёл к одной общей схеме, которую успешно применяю сейчас. Будем исходить из того, что мы занимаемся разработкой приложений. Итак, разделите предстоящую работу на 5 частей.




Working place


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


Например
  • для разработки приложений под android я использую AndroidStudio — он включает в себя достаточный функционал и очень удобен (но к сожалению только на неслабых машинах)
  • для написания простых приложений на c++ (фриланс для студентов) я посчитал достаточным использования sublimetext и gcc. Очень нетребовательный функционал. Таким образом я создал систему, с помощью которой я могу легко писать приложение на моём домашнем компьютере на Windows и без проблем продолжать работу на нетбуке слабой мощности на Debian
  • так же был опыт в разработке приложения на Unity3d. В данном случае я использовал конечно Unity3d, но он на самом деле выполняет только часть задач. Например для редактирования скриптов на C# нужно использовать специальную утилиту. Мне не понравилось предлагаемое решение MonoDevelop. Я посчитал его слишком требовательным (с учётом работы на относительно слабой машине) для того чтобы писать небольшие скрипты. Поэтому для этого проекта я использовал комплекс из Unity3d+Notepad++

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


Folder


Теперь не такие важные, но очень полезные приёмы. Итак под каждый проект нужно создать специальное место для хранения сопутствующих файлов. Внимание, необходимо разделить понятия файлы проекта и сопутствующие файлы. Т.е. это не исходный код. А хранилище ресурсов. Всё что можно уложить в файл. Это должны быть медиафайлы(во многих проектах существует специальные папки под используемые в приложении ресурсы, я говорю о медиафайлах в более широком смысле). Сборки проекта в разных версиях. Необходимые файлы настроек проекта. Сопроводительные документы. Необходимые библиотеки. Суть этой части в создании порядка. Мне часто попадались программисты которые хранили данные беспорядочно, на рабочих столах, с непонятными названиями, файлы от разных проектов в одном месте. А так же часто теряли их.


Например

Я лично большой фанат облаков. Для разработки использую Dropbox. Там у меня создана своя собственная и, что важно, удобная мне иерархия. Хочу сказать, что важно, чтобы у вас всё было по полочкам.
Dropbox имеет очень удобный (по моему мнению) клиент на android. И я могу получить доступ к файлам проекта везде и почти всегда. Разворачиваясь на новом месте для работы, теперь всё что мне необходимо — это зайти в хранилище с другого компьютера и через браузер получу доступ к сразу всем файлам проекта. Конечно этот способ работает именно в моём случае, т.е. я всегда ношу с собой телефон с мобильным интернетом и плюс работаю только в местах подключенных к интернету так же.


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


VersionControl


Если вы ещё не используете систему контроля версий, то бегите изучать эту тему. Чем раньше начнёте её применять, тем быстрее станете более эффективными. В разработке конечно это незаменимый инструмент. Тут нужно сказать, что главное использовать эту технологию верно и пользоваться удобными инструментами. Таким образом ваша разработка не будет стоять на месте. Код будет развиваться, а обо всех изменениях будет заботиться система контроля версий. Если у вас есть доступ в интернет, то вы так же получаете сохранение кода и истории на сервисе к которому можете получить доступ из любого места, и защищаете себя от потери кода и его порчи.
Важно не путать использование системы контроля версий и хранение файлов сопутствующих проекту. Эта часть отвечает за сохранение именно той части приложения, которая необходима для его сборки. Я часто вижу как эта система используется не совсем верно. В репозиторий заливается весь проект созданный какой-нибудь IDE. Что я считаю крайне неправильным — репозиторий только для кода. Там не должны лежать файлы настроек проекта и тем более относящиеся к конкретной операционной системе. Так же если вы имеете некий склад ресурсов для сборки и запуска проекта. Оцените сами, что это из себя представляет.


Например

Если это является файлами кеша для приложения, которое разрабатывается под две платформы (два репозитория). И этот кеш весит 70мб. Считаю было бы логичнее как раз эту часть приложения (кеш) передать в какой-нибудь общий ресурс с общим доступом у разработчиков (сервер, облака и т.д.). Думаю при таком раскладе кеш будет изменяться по воле заказчика и пусть эти изменения не отслеживаются системой контроля версий. Таким образом у вас будет два репозитория по 2-5мб для кода под каждую платформу и общий ресурс с кешем в 70мб с которого будут брать файлы все кому это необходимо.


Лично я использую git и сервисы: github для личных проектов, assembla для работы. А в процессе работы я нашёл для себя, что более удобный вариант — пользоваться консольной версией, а не встроенными в ide аналогами. В управлении быстрее, работает с любыми git репозиториями, и на всех машинах одинаково. Найдите лучший вариант для вашей ситуации и личных предпочтений.


Notes


Для упорядочивания мыслей рекомендую использовать записные книжки. И записывайте всю информацию, относящуюся к проекту, которую можно перевести в текст. Создайте систему, с помощью которой всегда под рукой будет возможность манипулировать этим. Удобное чтение и запись мыслей по теме конкретной работы. Однако, легко запутаться в истинном назначении данного кейса. Текстовый документ со списком сценариев unit тестов с доступом к комментированию и редактированию лучше отнести к файлу, который нужно определить в место с общим доступом для работников (сервер, облака… folder). А если в голове появилась идея о том как расположить элементы на экране, тут же записывайте список этих элементов в специально отведённое место в вашей книжке. Тут же вы можете оставить комментарии о каждом элементе. К тому же вам никто не мешает продублировать список unit тестов из официального документа к себе для удобного чтения. Чем больше мыслей, идей и вспомогательной информации вы будете оставлять у себя в удобном виде с удобным доступом, тем меньше вероятность потери данных. И ещё вы экономите себе время на поиск необходимых элементов.


Например

Мне в разработке помогает сервис OneNote. Облачная записная книжка с отличными десктопной, онлайн и android версиями. Пользуюсь им для описания элементов и этапов разработки приложений. Дизайны, модели данных, локализация, мысли вслух. Установленное приложение на моём телефоне позволяет не терять ход мысли даже если я в пути или не на работе. Рекомендую дополнительно использовать бумажную записную книжку для тех же целей. И ещё на бумаге удобнее создавать зарисовки и делать наброски.


Task manager


Фиксирование задач, над которыми вы работаете, и, которые необходимо выполнить, поможет вам в отслеживании прогресса и достижении цели. Так же можно получить немало другой полезной информации исходя из полученных данных. Например учёт времени позволит оценить сложность задач и в дальнейшем вы сможете оценить свои силы более точно.
Я перепробовал много менеджеров для отслеживания выполнения задач. Некоторые включают в себя очень много сервисов и функций. Другие упрощены и являются вариацией записной книжки. Лично мне потребовалась именно такая система в которой сами постановки задач упрощены, но при этом существовала удобная древовидная система. Могу порекомендовать сервис Todoist. Который к тому же онлайн и имеет отличные клиенты под разные платформы.


Пример применения Todoist

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


Заключение


Эти пять моментов я считаю самыми главными (хотя я сам использую намного больше) и хочу чтобы мой личный опыт помог вам в применении полезных сервисов для более качественной и быстрой разработки отличных приложений. Итак, группируйте все ваши проекты и всё с ними связанное сразу в понятном и удобном вам виде. Перепробуйте разные способы и выберете свой собственный. Добавьте сюда всё необходимое для вашего удобства. Найдите таймер по типу toggl. Если вы фанат pomodoro приглядитесь к pomodoneapp, а если вам больше по душе kanban то попробуйте Trello. Обязательно общайтесь с другими людьми (или даже сами с собой), создавайте беседы и диалоги, в которых ведите горячие споры в telegram или начинайте мозговые штурмы в gitter.im. Пользуйтесь сервисами по созданию блок-схем для построения алгоритмов, draw.io — очень хороший пример. Если вы пользуйтесь онлайн сервисами то группируйте ссылки к сервисам под каждый проект для быстрого доступа. Удачи!

Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.