Комментарии 28
Имхо, на старте важно изучающему дать возможность сделать что-то, выглядящее закончено, полезно. А не все эти надуманные "напишите консольную программу по учёту мешков картошки в подвале".
Поэтому я ученику сходу дам законченную программу с интерфейсом, научу её компилировать, и скажу "свой код вписываешь сюда. Теперь о том, что такое переменная..." Чтобы у него результат был не из 1980х.
Согласен. Это мотивирует продолжать обучение!
Действую по такому же принципу: сначала собираю с ребятами простое приложение (макет), примерно объясняя что как работает и для чего используется.
Плюсы:
- приложение используется в дальнейшем обучении для составления спринтов (для самого себя, но появляется некое понимание о дейликах, демо и ретро).
- это не просто приложение из стора. Ты собрал его сам (ну или почти сам :) ).
- при изучении проще понимать, где может использоваться та или иная конструкция.
- дает более широкий взгляд на разработку.
Минусы:
- можно заиграться и "вслепую" пытаться делать "что-то свое" на имеющейся основе, пропуская фундаменталку.
Лучше взять какую-нибудь насущную задачу пользователя (ученика) и решить её написанием программы. Например, у него кончается место на диске - пусть напишет утилиту, которая анализирует занятое место, ищет дубликаты, определяет нужность файлов, и т.д.
Тоже хорошо, я просто туториал писал, поэтому у меня ученик гипотетический.
Согласен. То, что пригодится самому, писать гораздо приятнее и интереснее.
В "советах" я больше нацелен на людей, которые только изучают фундаменталку.
А приложение - для тех, кто хочет просто понять, нравится ли ему работать с кодом.
Когда смотрю советы современным начинающим программистам, вспоминаю свое детство. В нем не было крутых современных IDE и графического интерфейса из коробки. Начинать приходилось с простейших задач, так как не было интернета и гугла. Была книжка, реже 2-3.
Порог вхождения мог казаться высоким, но ты знал, что ты хочешь сделать. Было и огромное желание это сделать.
Современные гайды говорят об обратном - многие начинающие не знают, чего они хотят, не смотря на упрощение входа в специальность.
Все течет, все изменяется :)
Сомневаться это нормально. ИТ перестало быть для "гиков". Теперь это обычная профессия.
С другой стороны, тогда IT-знаний было тупо меньше в разы, а то и на порядки.
Сравните С++ в 90-х годах и сейчас. Сравните веб, количество технологий для него))
Сейчас и железо стало довольно сложным, приходится обращать внимание на большее количество нюансов при сборе.
Ну и да, тогда в IT было на порядки меньше людей и можно было чувствовать себя одним из первых (как на диком западе или в открытом космосе, кто как воспринимал), это охренеть как мотивировало и создавало чувство общности. Сейчас человек берётся за IT, уже видя как дохрена людей в этой индустрии, как много в ней топовых специалистов всех сортов, и как жёстко придётся с ними всеми конкурировать. Это знатный такой дебаф к мотивации.
судя по заголовку раскольников был айтишником
Случайно отклонил чей-то комментарий, сорян...
Самое классное время в программировании - когда ты программируешь так, как думаешь. Нужно сложить два и два, ты просто складываешь, нужно принять решение - просто пишешь if и тд.
Потом наступает время, когда сначала нужно наделать абстракций, интерфейсов, а твой код тонет в бесконечных вызовах api, фреймворках и тд.
КАША в голове, КАША в коде — первые шаги к порядку
Любовь к разговорам «вообще», это, пожалуй, наша национальная особенность.
Неужели начинающим программистам нельзя дать более дельных советов? Например:
Нельзя объять необъятное.
Это значит, будьте конкретны в своих желаниях. Допустим, по программированию вы выбрали направление С++ и программирование с использованием пользовательских интерфейсов.
Программирование – иерархично. Сначала проект, потом прототип, потом версии программы.
Главное в разработке – программная логика, для моделирования которой удобно использование древовидной иерархии классов, в связке с менеджером видов (другими словами, дочерних окон), менеджером потоков и менеджером событий.
Выберите интересующий вас класс задач и напишите для него общий прототип.
Например, для себя я выбрал тему: «Управление видами для SDI-приложений, на базе C++ / WTL». Имеется в виду, использование перегружаемых («последовательных») видов (см. мою статью: https://habr.com/ru/articles/848836/ ) либо применение «параллельных» видов, с использованием многопоточности, для встроенного видео (см. скриншот моей неопубликованной программы «МедиаТекст»: http://scholium.webservis.ru/Pics/MediaText.png ). Другие варианты похожих задач пока в разработке. Надеюсь, со временем, рассказать и о них.
Используйте итерационное программирование.
Каждая новая итерация это копия предыдущего проекта плюс реализация какого-нибудь класса. Отдельные классы удобно хранить в отдельных файлах. Для внешних классов (и прочего опенсорсного кода) лучше использовать отдельные каталоги.
Разные итерации одного проекта должны иметь общий доступ к неизменяемому коду, вроде, опенсорса.
Нужно стремиться к тому, чтобы новый программный модуль можно было бы, как легко подключить, так и легко отключить. Соответственно, изменить старый модуль на новый.
Документируйте изменения во всех итерациях.
Это позволит, со временем, обосновать фразу: «Неужели этот код я написал?». И что, именно, делает эта программа?
Различные задачи, используемого класса задач, должны иметь общий прототип, как выбранный дебют в шахматах.
Оформляйте код «красиво». Не ленитесь быть аккуратными и не забывайте о комментариях.
Чтобы про вас не злословили:
«Программист Вася Пупкин и аккуратность – не близнецы-братья. Мы говорим «аккуратность», но не подразумеваем программиста Васю Пупкина! Мы говорим «программист Вася Пупкин», но не подразумеваем аккуратность!»
Как-то так. Это пока полуфабрикат мыслей, иначе я бы написал статью на эту тему…
С кодом так же: не надо ломать голову, пытаясь запомнить все. Главное - помнить, что нужный инструмент рядом, и при первой же проблеме просто найти его в гугле или при помощи ИИ.
Код - умение в нужный момент достать из головы то, что нужно, и не сойти с ума. Так что забудь зубрежку и учись решать задачи, а не пытаться держать все в голове.
Совет N: Но на собесе это не прокатит, поэтому зубри
Даже 30 файлов!)) сейчас на проекте, где 80мб сами исходники кода весят
Вот ещё советы.
Программирование состоит из двух разных навыков. Навык правильно использовать фреймворки и архитектурные решения с ними связанные это один навык. Навык самому на пустом месте написать программу с логикой в несколько тысяч строк и не начать тонуть это другой навык. Первый обязателен, но в итоге потребуются оба.
Пока вы один, не на работе и учитесь, пишите подобные комментарии. Не нужно лицемерия про само описываемый код. Этот навык придет не скоро, если это не тупой crud. Потом в команде пробуйте писать без комментариев.
Начните новую фитчу по старинке с юз-кейзов. Выпишите сценарии, придумайте для них примерную архитектуру и начните писать код для какого то кейза постепенно реализуя и проясняя архитектуру.
Не увлекайтесь сильно ООП, пока нет ощущения зачем оно, чтобы не было карго культов. Пока нет ясного понимания что в конкретном случае нужно ООП, пусть будут функции или просто процедурное программирование с немного god объектами. Потом чтобы это все стало яснее, попробуйте применять ООП. Стало только хуже? Теперь все совсем запутано? Значит рано. Надо ещё учиться
Прежде чем реализовывать что-то напишите комментарий как это будет работать. Когда напишите код, удалите эти комментарии. Не нужно думать кодом. Лучше думать словами.
В момент когда код частично заработал, обязательно пройдитесь каждый шаг дебагером, размышляя о соответствии замыслу. Так можно вовремя понять что что-то нужно улучшить.
Если перестаёте понимать что это будет, останавливайтесь и придумывайте "теорию" и абстракции как это систематизировать. Но придерживаться найденной концепции будет чем дальше тем сложнее. Искусство в том, чтобы придумывать эффективные простые концепции и чувствовать баланс - когда нужно просто делать чтобы работало а когда изобретение ограничивающих концепций окупиться.
Если вы уже начали вайб-кодить, все эти советы никоим образом не теряют актуальности!
Приятная статья😊 Некоторые из этих тезисов полезно освежать периодически в голове.
КАША в голове, КАША в коде — первые шаги к порядку