Студент-первокурсник, математик-программист — вот кто поведёт рассказ в этом топике о мире ООП, а точнее о том видение построения структуры проекта, которое на данный момент сложилось у меня.
Первое, что хочется при построении проекта — придумать граммотную структуру будущих классов, их иерархию, принципы наследования и инкапсуляции данных, чтобы приложение получилось логически законченным, но в то же время оставляло некий запас в плане модульности и дальнейшего развития.
Несмотря на то, что я уже встречался с исходными кодами достаточно крупных проектов — ни разу ещё не видел полностью логически-продуманной структуры. Везде встречаются части, которые можно было бы реализовать изящнее и правильнее, но очевидно, не придя на ум на определённом этапе проектирования, они вынуждают прикручивать необходимый функционал в виде обидных с эстетической точки зрения костылей.
Конечно, если идет речь про real-time ресурсоемкие операции, то такие костыли будут допилены до определённого уровня, но так или иначе они останутся подпорками.
Возникает вопрос, возможно ли вывести некоторую схему построения будущего проекта, чтобы все описанное мною в пожеланиях к проектам было выполнено, и при этом не свихнуться с заблаговременной оптимизацией кода?
Если вы задумываете месссендждер для передачи сообщений — не нужно пытаться туда уже после завершения написания кода пытаться впихнуть возможность видео-конференций. Ведь изначально планирую сделать мессенджер, вы придумывали структуру, которая подразумевает наиболее полную и четкую реализацию быстрой передачи сообщений между клиентами, и уж никак не обработку видеопотоков.
Конечно же, можно прикрутить видео-переговоры, не так сложно: дописываем несколько классов, поменяем пару методов в уже имеющихся классах, перепишем некоторый функционал на сервере и готово. Но все ли правильно? Нет! Мы тестировали систему, да и разрабатывали систему, для передачи сообщений, а идея видеопотоков нам пришла уже позже, значит, ничего для этого ранее нами написано не было, значит все возможные глюки, которые мы отловили на этапе дебага программы, могут легко появиться вновь, ведь добавления нового функционала ведёт к их появлению — факт.
Ранее весьма элегантно придуманная нами структура всех данных теперь расширяется, если не вглубь — так вширь, а значит, теряется вся та философия четкой иерархии, которая должно присутствовать в ООП проектах. Именно поэтому сначала четко подумайте, что будет делать ваш проект, и уж потом начинайте реализацию. Не знаете, будут ли у вас видеоконференции, но рынок развивается, а вы думаете о будущем — оставьте запас в функционале, так, чтобы это можно было добавить позднее, без ущерба для существующего функционала.
Именно так, дайте время идеи созреть, ведь в период обдумывания возникнут новые детали, новые идеи, которые можно как принять в оборот, так и исключить из дела. Думайте о вашей программе все свободное от остальных дел время. Вам может это показать невероятным: блин, ну это же не нормально быть одержимым идей постоянно, так и до психической болезни не далеко. Верно, и в какой-то степени это трудоголизм, но именно такой подход приносит наиболее ценный плоды. Человек сложное вещество, возможностей нашего мозга не знает никто, так что чем больше мы думаем, тем больше хороший идей нам может прийти в голову.
Не ленитесь записывать всё, что вам приходит в голову дельного по поводу вашего проекта. Собирайте такие записки, клочки бумаги вместе (конверт, блокнот, что угодно). Линкольн перед каждым своим публичным выступлением обдумывал тему разговора минимум неделю собирая все свои мысли, записанные на клочках попадавшихся ему под руку бумажек, по этому счету в цилиндр, который он носил. В последний день, садясь за финальную шлифовку текста, он вновь раскладывал все эти записи, и доводил тексты выступлений до совершенства. Может показать, что связь здесь отсутствует: публичные выступления и ООП, что между ними общего?
Это не так, и там и там важна структура, которая получается действительно завершенной только после тщательнейшего обдумывания.
Каждый вечер выделите себе 20-30 минут на анализ всего того, что пришло вам в голову и выкинете все, что вам не понравилось, правьте то, что как вам кажется может пригодится, ну и наконец в окончательную папку проекта складывайте все, что вы считаете достойным для реализации.
Думайте все свободное время о вашем проекте, и тогда вся структура со временем обретет необходимую ясность.
Пишите код всего проекта (или его части, за которую вы ответственны), по всему объему. Реализовывайте потихоньку каждую часть проекта вместе с остальными, так у вас постоянно будет свежая информация по каждой части вашей программы, все будет держаться в памяти, и вся картина будет представляться целиком и полностью. Вы постоянно будете работать со всем функционалом в целом, и тем самым проводить некоторую ревизию уже сделанного.
Ведь достаточно часто бывает, что, написав какой класс или функцию 2 месяца назад и теперь ещё нужно поковыряться, чтобы понять, как оно там работает. Безусловно, грамотная реализация кода позволит сократить до минимума необходимое время для разбора, написанного ранее, но все равно оно нужно, а время — самое дорогое, что есть у человека. Или же реализовав что-то месяц тому назад у вас, вы вдруг открываете этот класс, а там такой код, который конечно работает, но так, что застрелиться хочется. Все может работать быстрее и правильнее, да и переписать не сложно.
Переделав некоторые методы у вас возникает глюк в другом конце программы(а вот оно все работало верно, но медленно, теперь работает быстро, но вы не учли одной мелочи, которая теперь вызывает ошибку работы всего приложения). Самое страшное в такой момент начать работать по принципу домино: исправил в пункте 1 код — возникла ошибка в пункте 2; исправил ошибку в пункте 2 — появилась в пункте 3; и т.д. На каждом этапе код в месте возникновения ошибки будет казаться немного неверным (ну вы ведь только что переписала неверный код на верный и он вызывает ошибку в другом куске кода, очевидно, что этот другой кусок написан немного не так, как хотелось бы). Не гонитесь за этим призрачны оптимизированным кодом. Остановитесь в одном месте, и скажите себе: «Пусть уж лучше работает тут чуть медленнее, чем может, но работает, чем я потрачу ещё уйму драгоценного времени на изменения кода всей программы».
И так — пишите программу масштабно, по всему фронту сразу, пусть и продвигаясь по чуть-чуть.
Ну вот пожалуй три самых простых совета по поводу того, как мне кажется верным реализовывать ООП проекты.
Подумайте хорошенько, что именно должен делать ваш проект, представьте все ту сферу, которую хотите охватить. Подумайте над тем, что вы задумали, поразмыслите, прикиньте некоторые hot spot-ы в голове. Не спешите, записывайте приходящие идеи, вам это сильно пригодится. Пишите проект масштабно, по всему объему сразу, пусть и с меньшей скоростью: актуальность информации по всему проекту сразу — сложно переоценить.
Всё это получилось благодаря собственному горькому опыту(а может и не горькому). Все приходит с опытом. Я только начинаю свой пункт в мире программирования, и поэтому все это пропитано некоторым юношеским максимализмом и наивностью, но вещи верны, много где уже обсуждались и могут принести ощутимую пользу при правильном использовании.
Первое, что хочется при построении проекта — придумать граммотную структуру будущих классов, их иерархию, принципы наследования и инкапсуляции данных, чтобы приложение получилось логически законченным, но в то же время оставляло некий запас в плане модульности и дальнейшего развития.
Несмотря на то, что я уже встречался с исходными кодами достаточно крупных проектов — ни разу ещё не видел полностью логически-продуманной структуры. Везде встречаются части, которые можно было бы реализовать изящнее и правильнее, но очевидно, не придя на ум на определённом этапе проектирования, они вынуждают прикручивать необходимый функционал в виде обидных с эстетической точки зрения костылей.
Конечно, если идет речь про real-time ресурсоемкие операции, то такие костыли будут допилены до определённого уровня, но так или иначе они останутся подпорками.
Возникает вопрос, возможно ли вывести некоторую схему построения будущего проекта, чтобы все описанное мною в пожеланиях к проектам было выполнено, и при этом не свихнуться с заблаговременной оптимизацией кода?
Первое что, как мне кажется нужно сделать — понять, что будет делать ваш проект в дальнейшем.
Если вы задумываете месссендждер для передачи сообщений — не нужно пытаться туда уже после завершения написания кода пытаться впихнуть возможность видео-конференций. Ведь изначально планирую сделать мессенджер, вы придумывали структуру, которая подразумевает наиболее полную и четкую реализацию быстрой передачи сообщений между клиентами, и уж никак не обработку видеопотоков.
Конечно же, можно прикрутить видео-переговоры, не так сложно: дописываем несколько классов, поменяем пару методов в уже имеющихся классах, перепишем некоторый функционал на сервере и готово. Но все ли правильно? Нет! Мы тестировали систему, да и разрабатывали систему, для передачи сообщений, а идея видеопотоков нам пришла уже позже, значит, ничего для этого ранее нами написано не было, значит все возможные глюки, которые мы отловили на этапе дебага программы, могут легко появиться вновь, ведь добавления нового функционала ведёт к их появлению — факт.
Ранее весьма элегантно придуманная нами структура всех данных теперь расширяется, если не вглубь — так вширь, а значит, теряется вся та философия четкой иерархии, которая должно присутствовать в ООП проектах. Именно поэтому сначала четко подумайте, что будет делать ваш проект, и уж потом начинайте реализацию. Не знаете, будут ли у вас видеоконференции, но рынок развивается, а вы думаете о будущем — оставьте запас в функционале, так, чтобы это можно было добавить позднее, без ущерба для существующего функционала.
Второе, перед тем, как писать код — вынашивайте вашу идею некоторое время. Неделю, две, месяц — может даже больше.
Именно так, дайте время идеи созреть, ведь в период обдумывания возникнут новые детали, новые идеи, которые можно как принять в оборот, так и исключить из дела. Думайте о вашей программе все свободное от остальных дел время. Вам может это показать невероятным: блин, ну это же не нормально быть одержимым идей постоянно, так и до психической болезни не далеко. Верно, и в какой-то степени это трудоголизм, но именно такой подход приносит наиболее ценный плоды. Человек сложное вещество, возможностей нашего мозга не знает никто, так что чем больше мы думаем, тем больше хороший идей нам может прийти в голову.
Не ленитесь записывать всё, что вам приходит в голову дельного по поводу вашего проекта. Собирайте такие записки, клочки бумаги вместе (конверт, блокнот, что угодно). Линкольн перед каждым своим публичным выступлением обдумывал тему разговора минимум неделю собирая все свои мысли, записанные на клочках попадавшихся ему под руку бумажек, по этому счету в цилиндр, который он носил. В последний день, садясь за финальную шлифовку текста, он вновь раскладывал все эти записи, и доводил тексты выступлений до совершенства. Может показать, что связь здесь отсутствует: публичные выступления и ООП, что между ними общего?
Это не так, и там и там важна структура, которая получается действительно завершенной только после тщательнейшего обдумывания.
Каждый вечер выделите себе 20-30 минут на анализ всего того, что пришло вам в голову и выкинете все, что вам не понравилось, правьте то, что как вам кажется может пригодится, ну и наконец в окончательную папку проекта складывайте все, что вы считаете достойным для реализации.
Думайте все свободное время о вашем проекте, и тогда вся структура со временем обретет необходимую ясность.
Не спешите реализовывать отдельный функционал проекта, оторвав его от всего остального.
Пишите код всего проекта (или его части, за которую вы ответственны), по всему объему. Реализовывайте потихоньку каждую часть проекта вместе с остальными, так у вас постоянно будет свежая информация по каждой части вашей программы, все будет держаться в памяти, и вся картина будет представляться целиком и полностью. Вы постоянно будете работать со всем функционалом в целом, и тем самым проводить некоторую ревизию уже сделанного.
Ведь достаточно часто бывает, что, написав какой класс или функцию 2 месяца назад и теперь ещё нужно поковыряться, чтобы понять, как оно там работает. Безусловно, грамотная реализация кода позволит сократить до минимума необходимое время для разбора, написанного ранее, но все равно оно нужно, а время — самое дорогое, что есть у человека. Или же реализовав что-то месяц тому назад у вас, вы вдруг открываете этот класс, а там такой код, который конечно работает, но так, что застрелиться хочется. Все может работать быстрее и правильнее, да и переписать не сложно.
Переделав некоторые методы у вас возникает глюк в другом конце программы(а вот оно все работало верно, но медленно, теперь работает быстро, но вы не учли одной мелочи, которая теперь вызывает ошибку работы всего приложения). Самое страшное в такой момент начать работать по принципу домино: исправил в пункте 1 код — возникла ошибка в пункте 2; исправил ошибку в пункте 2 — появилась в пункте 3; и т.д. На каждом этапе код в месте возникновения ошибки будет казаться немного неверным (ну вы ведь только что переписала неверный код на верный и он вызывает ошибку в другом куске кода, очевидно, что этот другой кусок написан немного не так, как хотелось бы). Не гонитесь за этим призрачны оптимизированным кодом. Остановитесь в одном месте, и скажите себе: «Пусть уж лучше работает тут чуть медленнее, чем может, но работает, чем я потрачу ещё уйму драгоценного времени на изменения кода всей программы».
И так — пишите программу масштабно, по всему фронту сразу, пусть и продвигаясь по чуть-чуть.
Заключение
Ну вот пожалуй три самых простых совета по поводу того, как мне кажется верным реализовывать ООП проекты.
Подумайте хорошенько, что именно должен делать ваш проект, представьте все ту сферу, которую хотите охватить. Подумайте над тем, что вы задумали, поразмыслите, прикиньте некоторые hot spot-ы в голове. Не спешите, записывайте приходящие идеи, вам это сильно пригодится. Пишите проект масштабно, по всему объему сразу, пусть и с меньшей скоростью: актуальность информации по всему проекту сразу — сложно переоценить.
Всё это получилось благодаря собственному горькому опыту(а может и не горькому). Все приходит с опытом. Я только начинаю свой пункт в мире программирования, и поэтому все это пропитано некоторым юношеским максимализмом и наивностью, но вещи верны, много где уже обсуждались и могут принести ощутимую пользу при правильном использовании.