Мимоволі стає програмістом: як це зробити правильно? [зачинено]


21

Моє передумови - електротехніка, точніше - DSP. Компанія, в якій я зараз працюю, робить безліч різноманітних проектів, в основному будує аналогове обладнання. Будучи дещо ближчим до комп'ютерів, ніж усі інші тут, я часто є одним пишучим кодом як для вбудованих пристроїв (з якими я цілком добре), так і для ОС Windows або Linux. Саме остання є для мене чужою територією.

Я можу кодувати, і я знаю кілька мов (C / C ++, Java, деякі VB.NET), але я використовував їх лише для моделювання алгоритму в обробці сигналів і зображень, нейронних мережах та інших подібних програмах. Для мене програмування було обчислювальним інструментом більше, ніж усе інше. Однак я отримую все більше і більше проектів, де мені доводиться писати належне повноцінне програмне забезпечення, і я не знаю, як це зробити, тому що мені ніколи цього не доводилося робити, і мене ніколи дуже не цікавило. Я сам бачив досить багато інженерів, які певною мірою перетворювалися на кодери через вимоги до роботи, і більшість з них не були такими великими в тому, що вони робили. Я впевнений, що багато людей стикалися з тим самим.

Якби я навчився писати належне програмне забезпечення з хорошим користувальницьким інтерфейсом, хорошою внутрішньою архітектурою тощо, як це зробити? У нас немає нікого на роботі, який би міг сказати мені, що є доброю практикою, а що ні. З огляду на те, що я можу писати код у найсміливішому сенсі цього слова, що ще можна знати про написання хорошого програмного забезпечення та як я можу потрапити туди самостійно?


Якщо ви дали нам сказати мовою, якою ви користуєтесь, ми, можливо, зможемо дати вам більш глибокі відповіді. Знову ж таки, це заперечує суть загальної відповіді.
Сардатріон

2
Без офіційного навчання чи прямого досвіду роботи з наставником, то робити речі правильним шляхом ™ не буде реалістично. Ви навчаєтесь. Є причина, чому інформатика та інженерія відволікаються від електротехніки. Розумна компанія найме інженерів програмного забезпечення для написання інтерфейсів додатків, драйверів додатків і навіть прошивки, тому що вони хочуть якості та хочуть, щоб це було зроблено правильно і щоб воно було ремонтом. Я б пояснив вашому начальникові, що те, що ви робите, трохи перевищує вашу сферу знань і що ці завдання слід краще залишити інженеру програмного забезпечення.
maple_shaft

4
... Я теж хочу додати, що я не вважаю, що ваша ситуація така "мимовільна", як ви заявляєте у назві. Ви самі сказали, що ваші однолітки навіть не знають, як користуватися комп’ютером, але від вас вимагається також бути мимовільним програмним інженером? Це навряд чи здається справедливим. Я вітаю вашу здатність писати прохідне програмне забезпечення та ваше бажання вчитися та робити речі правильно, проте не соромно визнати свого начальника та себе, що деякі речі не у ваших можливостях. Якщо вони серйозно ставляться до вас у цій ролі, попросіть їх витратити на навчання для вас.
maple_shaft

@maple_shaft Я згоден з більшістю речей, які ви говорите; Однак я ніколи не говорив, що мої однолітки не вміють користуватися комп’ютером. Жоден з них не є інженером-програмістом, який міг би мене прикупити, але всі вони дуже володіють комп'ютером. У мене немає проблем з кодуванням, мені подобається вчитися новим речам, і у мене справді немає проблем з цим.
Фонон

6
@Phonon Чудово, це гарне ставлення, але переконайтеся, що ваша компанія купує вам книги, навчальні курси та дає вам час, щоб дізнатися, чи хочуть вони ви грати цю роль. Це все, що я говорю. Тому багато компаній намагаються обдурити вас, переконуючи вас, що ви зобов’язані придбати ці речі для себе.
maple_shaft

Відповіді:


11

Є кілька книг, які вам дуже допоможуть. Я пропоную завжди мати поруч із собою Код Повний . Це неоціненний довідник. У попередній компанії, де я працював, це була також книга, яку ми видавали кожному молодшим програмістам після найму.

Прагматичний програміст - це дійсно корисний ресурс, і він досить короткий, але я пропоную прочитати його після завершення коду.

Ці книги почнуть вас розпочати, потім код, код, код та інше ... але знайте, коли зупинитись, ваше програмне забезпечення ніколи не буде ідеальним.


6

Моя компанія робить це весь час ... і це мене ганяє.

"Я розробник програмного забезпечення, як мені стати EE?"

Ну, я вважаю, що відповідь досить очевидна. На це потрібно багато часу і важка робота. І звичайно, правильні навчальні матеріали. Інженерна підготовка допомагає, в моєму університеті CS та інженерні школи були в одній будівлі з великим перекриттям. Алгоритми та математичні основи є.

Помилка, яку я бачу більшості новачків, - це відкусити більше, ніж вони можуть жувати. Навчальні матеріали через користувальницький інтерфейс, архітектури, код якості ... це дуже важливо . Щось, що справді потребує років, і це часто роблять команди різних експертів програмних компаній.

Не кажучи, що ви не можете бути досить пристойними самостійно, якщо вкладете час. Просто визнайте масштабність матеріалів, щоб ви не перевантажували себе і будь-ласка: А. Вийдіть або В. Створіть основні технічні заборгованості у своїх додатках, взявши основні ярлики у вашому навчальному процесі.

З-за всього цього, з цією книжкою там не існує жодного "лову всіх". Я рекомендую почати з того, щоб забрати найкраще оцінену книгу на найбільш часто використовуваній мові, а також взяти участь у спільноті Стек, особливо для оглядів коду.

Спробуйте Amazon.com, вони мають хороші відгуки про книги.


3

Книги : Головне - читати (хороші) книги на вашу мову, що вибираєте. Коли ви дізнаєтесь вашу мову вибору, ви можете отримати " Ефективніший X" або "Y кращі практики" тощо. Я вважаю, що кулінарні книги дуже добре подолають прогалини, які можуть виникнути. Тож, мабуть, вам потрібно принаймні три книги. Одне: виконайте вправи та ката-код, щоб покращити розуміння мови. Звичайно, вам потрібен хороший візерунок xUnit .

Алгоритми важливі для конкретності, і вам слід вибрати книгу, яка детально описує їх - знову ж таки, вашою мовою на вибір. Шаблони дизайну та анти-візерунки варті того, щоб знати про будь-які мови.

Підсумок: потрібен час. Не поспішай.


+1, але завжди пам’ятайте, що лише одне правило не має винятків: всі правила мають винятки.
Ян Худек

@JanHudec: Кого з них ви тут мали на увазі?
Сардатріон

3

Ви всмоктуєте кодування. Так.

Але - це не означає, що ви не можете доставляти програмне забезпечення, що робить людей щасливими;)

Будь покірним. Напишіть «ділову» логіку, яка вам потрібна. Використовуйте код бібліотеки для всього іншого. Не намагайтеся писати фундаментальні алгоритми (наприклад, сортування масивів ), не використовуйте жодних «хитромудрих хитрощів», дотримуйтесь деяких драконівських конвенцій коду.

Використовуйте хороший IDE. Це важливо, оскільки це допоможе вам відформатувати свій код і відстежити помилки друку / прості помилки.

Читайте книги на кшталт " Код завершений " та " Прагматичний програміст ", спробуйте змусити себе і вивчити ООП (його просто і допоможе вам зберегти свій код більш рентабельним).

Використовуйте SVN , виконайте часто, - ви зможете відновити зміни (коли ви щось зіпсуєте).

Знайдіть когось із справжніх програмістів із академічним досвідом, якщо це можливо. Таким чином, ви зможете поговорити з ним, поділившись своїми проблемами з новичками та отримавши освічуючі відповіді.

І, звичайно, найголовніше - це також тримати кодування, кодування, кодування .


ps: якщо ви вмієте писати код C ++, який працює, і ви пишете нейронні мережі (!) - тоді ваш мозок добре підходить для програмування;) Удачі!


2

Тут є хороші відповіді.

Великий оберт на вашу користь - простий факт, який ви хочете знати.

Багато інженерії програмного забезпечення (яке, звичайно, слід сприймати зі здоровим скептицизмом), полягає в тому, як це зробити так, як згодом ви не пошкодуєте. Одним із прикладів є використання системи управління версією вихідного коду. Інший - це поділ коду на файли, щоб було легше працювати над ним по частинах. Інше - бути стикером щодо впорядкованості - форматування коду та іменування умов. Точні конвенції мають значення не стільки, скільки послідовність щодо цього.

Таким чином, коли ви повернетесь до коду через рік і більше, ви не подумаєте: "Хто створив цей безлад?" Ви зможете знайти речі та змінити їх без особливого ризику поломки. **

Хороший спосіб почати - це знайти різні приклади програм та працювати над ними. Тоді ви можете адаптувати їх під свої потреби.

** Однією з моїх найбільших головних болів є намагання працювати з кодом, написаним людьми, які не думали, що форматування чи називання мають значення.


1

Хоча є багато і багато хороших ресурсів щодо того, як робити і не робити речей, врешті-решт найголовніше - це бачити багато коду та працювати з ним і бачити, наскільки легко чи складно підтримувати для себе.

Хороший спосіб навчитися - це те, щоб хтось із досвідчених був зробити початковий дизайн, а потім переглянув ваш код і показав вам корисні методи, якими ви користуєтесь для них. Тож якщо вам випадково вдасться переконати ваших начальників найняти хоча б одного програмного інженера з досвідом роботи в провідних (малих) програмних проектах та розробці програмного забезпечення для керівництва проектами, я думаю, це було б найкращим варіантом.

Якщо ви не можете змусити когось причаїти вас, в наші дні існує сильний рух з відкритим кодом. Можливо, ви використовуєте деякі інструменти з відкритим кодом у своїй роботі, тому спробуйте виправити в них помилки або додайте прості функції, якими ви користуєтесь, та обговоріть, як це робити із відповідною спільнотою. Це невміле практичне навчання, щоб навчитися застосовувати будь-які загальні правила, які ви знайдете в книгах про фактичні практичні проблеми.


0

Одне, що я дійсно рекомендував би для вивчення якості кодування та питань архітектури, - це навчання "дядька Боба" (Роберт Мартін). У нього є кілька відеозаписів на 1 долар, які мають дуже гарний розмір, якщо, можливо, занадто примхливі, а також кілька хороших книг.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.