Есть опыт работы 2 года программистом в одной фирме и 4 года самостоятельной работы.
За время работы с другими программистами в конторе научился у них хорошему, но не слишком многому, поскольку они тоже не всё умели и не всё знали о том, как правильно писать ПО.
То есть были в той фирме проблемы с проектированием, тестированием, взаимодействием разработчиков и т.п., в общем работали "на коленке".
Сейчас в одиночку разрабатываю одну программу, время на разработку/самообучение ничем не ограничивается.
Объем исходников в настоящий момент 600 кб.
Программа работоспособна, свои функции выполняет, успешно эксплуатируется.
Язык С++.
Сейчас глядя на программу считаю, что написано она плохо, "на коленке", не профессионально, неверно структурирована, неправильно разбита на объекты или вообще не разбита там где надо бы разбить и т.п.
Чувствую себя человеком, который знает язык программирования, но не умеет его правильно применять и не организовал нормально процесс разработки.
Как следствие ощущаю нежелание (иногда и неспособность) вносить жизненно важные изменения изменения в программу, особенно если эти изменения не очень хорошо ложатся на написанный код.
Какие-то фрагменты программы написаны хорошо (мне так кажется), но в целом вся программа требует переписывания.
Я пытался переписывать программу заново, но даже с опытом разработки этой же самой программы, с хорошим представление о предметной области, со знанием подводных камней новая версия получается не намного лучше старой.
Надо решить как изменить организацию труда, принципы разработки, чтобы уменьшить количество проблем с программой, вернуть над ней контроль.
Вижу два варианта.
1) Оторваться от работы и почитать книжки.
Тут есть проблемы и сомнения...
а) Надо выбрать про что вообще читать — про ООП, или про рефакторинг, или про организацию разработки, или ещё о чем-нибудь. Собираюсь ознакомиться со всеми озвученными темами, но если вы подскажете порядок в котором надо читать это необъятное море страниц, то буду благодарен.
б) При попытке чтения часто выясняется, что книжка написана водянисто. (Видать, авторам хочется кушать, и они увеличивают объемы пространными разговорами.)
Читать такие книги тяжело. Возможно, вреда от них больше чем пользы, поскольку потратив много времени и сил на изучение сотен страниц остаешься опустошенным, пропадает энтузиазм — и узнал мало и измучился.
в) Самое плохое то, что написанное в книге является неким абстрактным знанием, которое надо еще и уметь применять правильно на практике, а в этом то и моя основная проблема.
Но по идее должны быть полезные мне книги про разработку, написанные хорошими педагогами, легко читаемые, понятные, конкретные... Подсказывайте какие!
2) Можно устроиться на работу в профессиональную контору. Там-то на примере специалистов можно будет набраться хорошему, попробовать разные техники программирования и находиться под контролем опытных товарищей. Код-ревью там точно возможен. Но у этого варианта есть и громадные издержки. Во первых контору, работа в которой мне будет максимально полезна, надо ещё найти. Второе — работа в конторе сопровождается огромными затратами времени и сил: год или несколько лет придется работать 5 дней в неделю на по 8 часов. Кажется очевидным, что для таких усилий можно найти лучшее применение.
Может быть я немного сбивчиво написал, буду дописывать и дорассказывать по мере необходимости...
Высказывайте свои соображения...
Ясно что серебряной пули нет, однако надеюсь, что разговор окажется полезным...
Здравствуйте, i3F, Вы писали: i3F>Сейчас глядя на программу считаю, что написано она плохо, "на коленке", не профессионально, неверно структурирована, неправильно разбита на объекты или вообще не разбита там где надо бы разбить и т.п.
Что именно там плохо? i3F>Надо решить как изменить организацию труда, принципы разработки, чтобы уменьшить количество проблем с программой, вернуть над ней контроль.
Чтобы что-то менять, надо понять, что оно из себя представляет сейчас. Ну, типа, пользуетесь ли вы системами контроля версий и багтрекерами? Делаете ли ежедневные билды? Ревью кода? И прочие стандартные штуки.
On 15.01.2013 17:35, i3F wrote:
> Высказывайте свои соображения...
Сколько раз программу не переписывай, после очередного раза будешь
видеть очередные недостатки и будет хотеться их исправить очередной раз.
Так что определись четко, что тебя не удовлетворяет и исправляй именно это.
Второе — работа в конторе сопровождается огромными затратами времени и сил: год или несколько лет придется работать 5 дней в неделю на по 8 часов. Кажется очевидным, что для таких усилий можно найти лучшее применение.2) Можно устроиться на работу в профессиональную контору. Там-то на примере специалистов можно будет набраться хорошему, попробовать разные техники программирования и находиться под контролем опытных товарищей. Код-ревью там точно возможен. Но у этого варианта есть и громадные издержки. Во первых контору, работа в которой мне будет максимально полезна, надо ещё найти. Второе — работа в конторе сопровождается огромными затратами времени и сил: год или несколько лет придется работать 5 дней в неделю на по 8 часов. Кажется очевидным, что для таких усилий можно найти лучшее применение.
Код-ревью потрясающая вещь. Тут на форуме недавно как раз зашла об этом речь. Если будете искать работу,
обязательно спрашивайте про code review. Отдавайте предпочтение той фирме, где эта практика внедрена.
i3F>Второе — работа в конторе сопровождается огромными затратами времени и сил: год или несколько лет придется работать 5 дней в неделю на по 8 часов. Кажется очевидным, что для таких усилий можно найти лучшее применение.
Во-первых, общение с более опытными коллегами, во-вторых можно и на работе книги читать, в-третьих -- мне нравиться поговорка
"а ищи всех паче разума в задаче."
Здравствуйте, Flammable, Вы писали:
i3F>>Сейчас глядя на программу считаю, что написано она плохо, "на коленке", не профессионально, неверно структурирована, неправильно разбита на объекты или вообще не разбита там где надо бы разбить и т.п. F>Что именно там плохо?
Тяжело сформулировать, пока получилось вот так:
Есть огромные классы, которые делают много всего, как разбить на мелкие не догадываюсь.
Если выделил где-то объект, то часто оказывается, что он обращается к множеству других объектов по всей программе и должен хранить их интерфейсы.
Зависимости между классами могут быть циклическими и тянуться в совершенно неожиданные места, на первый взгляд кажется, что такой зависимости не может быть, но при разработке оказывается, что она должна быть.
i3F>>Надо решить как изменить организацию труда, принципы разработки, чтобы уменьшить количество проблем с программой, вернуть над ней контроль. F>Чтобы что-то менять, надо понять, что оно из себя представляет сейчас. Ну, типа, пользуетесь ли вы системами контроля версий и багтрекерами?
Системой контроля версий пользуюсь.
Багтрекером как специальным ПО не пользуюсь, но есть txt-файл, куда все записывается руками.
Критичные баги чинятся быстро, их просто нет, программа постоянно эксплуатируется.
Некритичные баги, ни на что не влияющие вообще не чинятся (их действительно можно не чинить) или чинятся по настроению.
i3F>>Делаете ли ежедневные билды?
Я работаю один, как внес изменение, так скомпилировал и поставил программу в эксплуатацию.
В этом смысле ежедневные билды делаю.
i3F>>Ревью кода?
Бывает, что переписываю код когда вижу более красивое решение, но целенаправленно такие места не в коде не ищу.
Значит, не делаю.
i3F>>И прочие стандартные штуки.
Чем-то из стандартных штучек не пользуюсь.
Тестами, например, не научился пользоваться (не выделил на это время).
Есть где нибудь исчерпывающий список стандартных штучек?
Спасибо, буду пробовать читать, может быть пойдет легко и окажется полезным.
S>Код-ревью потрясающая вещь. Тут на форуме недавно как раз зашла об этом речь. Если будете искать работу, S>обязательно спрашивайте про code review. Отдавайте предпочтение той фирме, где эта практика внедрена.
S>Во-первых, общение с более опытными коллегами, во-вторых можно и на работе книги читать, в-третьих -- мне нравиться поговорка S>"а ищи всех паче разума в задаче."
code review мне кажется полезен при коллективной разработке, мне самому свой код пересматривать не так полезно (глаз уже замылен), да и заставить себя тяжелее.
Трудоустраиваться я всё таки вряд ли стану.
Здравствуйте, i3F, Вы писали:
i3F>Есть огромные классы, которые делают много всего, как разбить на мелкие не догадываюсь. i3F>Если выделил где-то объект, то часто оказывается, что он обращается к множеству других объектов по всей программе и должен хранить их интерфейсы. i3F>Зависимости между классами могут быть циклическими и тянуться в совершенно неожиданные места, на первый взгляд кажется, что такой зависимости не может быть, но при разработке оказывается, что она должна быть.
Это плохой дизайн. Мне из-за этого приходилось переписывать очень много своего старого кода.
i3F>Системой контроля версий пользуюсь. i3F>Багтрекером как специальным ПО не пользуюсь, но есть txt-файл, куда все записывается руками. i3F>Критичные баги чинятся быстро, их просто нет, программа постоянно эксплуатируется. i3F>Некритичные баги, ни на что не влияющие вообще не чинятся (их действительно можно не чинить) или чинятся по настроению.
Багтрекер помогает видеть динамику работ. А фиксить лучше все баги, чтобы потом реже их создавать.
i3F>>>Ревью кода? i3F>Бывает, что переписываю код когда вижу более красивое решение, но целенаправленно такие места не в коде не ищу. i3F>Значит, не делаю.
Надо делать. Я вот часто смотрю на свой код, написанный полгода назад, пугаюсь и начинаю переписывать. С некоторого момента начал целенаправленно искать плохой код и переписывать его.
Могу поделиться опытом, как я делал из себя программиста (пошел работать плюсовиком через год или два после покупки компа, многому пришлось учиться на ходу).
1. Учиться на своих ошибках.
1.1. Каждый раз после фикса бага или решения какой-либо проблемы: остановиться на минутку и подумать, почему возникла проблема; что можно было бы сделать, чтоб ее предотвратить; как ее можно было бы быстрее задетектить; как ее можно было бы быстрее пофиксить.
1.2. Каждый раз в конце дня посмотреть сделанное с помощью системы контроля версий. Вспомнить, зачем была добавленна каждая строка, возможно, еще раз подумать о решаемых данными изменениями проблемах.
Все это занимает не так уж много времени, зато помогает эффективнее набирать опыт и сохранять в памяти методы решения типовых проблем.
2. Учиться у коллег.
Найти на работе людей, более профессиональных чем вы, невзначай наблюдать за ними и учиться. Смотреть какой код пишут хорошие программисты, не стесняться спрашивать, зачем они пишут его именно таким образом (только не надо задавать вопросы, ответы на которые легко гуглятся или находятся в мануале). Наблюдать за тем как менеджеры разговаривают с людьми, как решают проблемы взаимодействия людей внутри проекта и вне его.
Если на работе отсутствуют люди, у которых можно учиться, — значит это плохая работа, на которой можно работать только из-за зарплаты или высиживая начальственную должность и т. п.
3. Читать книги.
Книги бывают разными. Есть книги насыщенные информацией, которые следует "прорабатывать", типа того же Саттера или Александреску. Такие книги нужно читать медленно и вдумчиво. Есть водянистые книги, типа того же "Рефакторинга" Фаулера. Не стоит бояться потратить на них лишнее время, просто читать их следует по другому: быстро, стараясь ухватить суть, если она там есть, и не дать себе увязнуть в деревьях не увидев леса.
i3F>Чувствую себя человеком, который знает язык программирования, но не умеет его правильно применять и не организовал нормально процесс разработки.
По поводу процесса разработки... В последнее время это слово слишком сакрализовалось. "Процесс" стал чем-то в духе Дао или Благодати. На самом деле, процесс — это просто способ эффективной организации работы группы исполнителей. Если вы работаете один или на вашей прошлой работе, про которую вы упоминали, как "работали на коленке", на проекте было мало людей, значит ничего страшного в отсутствии "правильного процесса" нет. Процесс — это всегда оверхед, который платят для предсказуемости разработки и чтобы сделать возможной работу на проекте достаточно большого количества людей.
i3F>Как следствие ощущаю нежелание (иногда и неспособность) вносить жизненно важные изменения изменения в программу, особенно если эти изменения не очень хорошо ложатся на написанный код. i3F>Какие-то фрагменты программы написаны хорошо (мне так кажется), но в целом вся программа требует переписывания. i3F>Я пытался переписывать программу заново, но даже с опытом разработки этой же самой программы, с хорошим представление о предметной области, со знанием подводных камней новая версия получается не намного лучше старой.
Знакомо. Я могу здесь сильно ошибаться, но мне видится следующая проблема: вы работаете с программой как с целым и этим перегружаете себя. Попробуйте при внесении изменений работать (кодить, думать, осозновать) локально только с теми модулями, в которых необходимо что-то поменять, "забывая" про все остальные и отдельно заводить задачи на рефакторинг архитектуры. Если модули слишком большие — бить их на части (Большой здесь имеется в виду по сложности, а не по числу строк кода или килобайтам). Тогда она не будет вам казаться "большой", "тяжелой", "неподъемной". Дело в том, что у каждого разработчика есть свой предел на объем кода, с которым он может работать как с целым. Студент, например, может легко написать программу на 100 строк, но к 1000 начнет г*дить, у юниора предел чуть повыше, у опытного разработчика еще выше, но тем ни менее у каждого человека есть предел на объем кода (точно так же как и, к примеру, сложность алгоритма), с которым он может оперировать как с целым. При превышении предела, человек начинает уставать, ему становиться лень что-то делать, а делая через силу он допускает множество ошибок.
Здравствуйте, i3F, Вы писали:
i3F>Чем-то из стандартных штучек не пользуюсь. i3F>Тестами, например, не научился пользоваться (не выделил на это время). i3F>Есть где нибудь исчерпывающий список стандартных штучек?
Первое, что приходит в голову — code style. А вообще есть целая книга об этом (вроде даже хорошая): McConnell S. — Code Complete. Сам пока только пролистал, планирую почитать.
, либо эту. Вторая повеселей.
к огромнейшому сожалению там какая-то фигня понаписана относительно проектирования. или не в тему или рассуждения, что делать с говнокодом. впечатляет впечатлительных и выглядит умнО, но бесполезно на деле.
единственная книга, в которой я видел понятный и хороший пример проектирования это Гради Буч — Объектно-ориентированный анализ и проектирование
, либо эту. Вторая повеселей. __>к огромнейшому сожалению там какая-то фигня понаписана относительно проектирования. или не в тему или рассуждения, что делать с говнокодом. впечатляет впечатлительных и выглядит умнО, но бесполезно на деле. __>единственная книга, в которой я видел понятный и хороший пример проектирования это Гради Буч — Объектно-ориентированный анализ и проектирование
Про "Чистый код" не согласен, книга не о проектировании вообще, а о методологии написания качественного кода: именование методов, переменных, классов, юнит-тесты, форматирование и многое другое. На Фаулера ссылки дал больше по рекомендациям других -- в ветке "Архитектуры и дизайна"
на него регулярно ссылаются, на SO в вопросе о книгах, кот. должен прочитать каждый программист тоже далеко не на последнем месте.
Сам пока с его трудами не знаком, поэтому, возможно, Вы и правы.
Про паттерны все мною рекомендуемые книги у меня есть, но GoF что-то не пошел, а вторую ссылку очень рекомендую. Если до этого с паттернами были не знакомы, то после прочтения книги будете ориентироваться значительно лучше, и понимать, где и когда и какой паттерн можно применить. Но тут также и от практики с опытом зависит.
Здравствуйте, i3F, Вы писали:
i3F>Здравствуйте, господа, i3F>нужна ваша помощь.
Известно, что чтобы научиться писать, нужно для начала научиться читать.
Читайте код каких-нибудь хороших OS проектов. Тем более, что на плюсах их более чем достаточно.
Обращайте внимание на именование классов, переменных, методов, на форматирование кода, на декомпозицию кода, на оформление комментариев.
1. Научиться оценивать код , какой хуже лучше и почему. Это основной скил.
как этого добиться
а) Макконнела "совершенный код" прочитать с ПОНИМАНИЕМ. Это азбука програмирования.
б) Смотреть как решаются другими зада которые вы сами решали.
в) выделять время на улучшение собственного кода. Т.е. после окончания кода , попробовать его причесать несколько раз ( часто сложно себя заставить возиться с кодом который уже "работает").
г) Не впадать в крайности, не заниматься "украшательством". Например , хороший код quick sort, корорый некоторые считают пишется за час, может потребовать пару недель анализа и тестирования
Здравствуйте, i3F, Вы писали:
i3F>Здравствуйте, Kernan, Вы писали:
K>>Здравствуйте, i3F, Вы писали:
i3F>>>Заказал себе Лармана K>>Лучше "Совершенный Код" прочитай. i3F>Вы обе книжки прочли?
Да.
Автор(ы): Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес
